cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Eric" <Eric.John...@iona.com>
Subject RE: Policies and features (Was : WS-SX)
Date Mon, 24 Sep 2007 14:22:27 GMT
Pardon the real simplistic black/whiteness of this comment, but it is
directed toward figuring out the message to a user trying to sort out
which of the myriad configuration mechanisms to use....

So what you are saying, in general, is:
* Use policies when you want a service provider to advertise
requirements for interaction to a consumer. For example, I use RM and
require strong encryption.
* Use features to configure stuff that is local to a running process.
For example, use this persistent data store and this security key store.

For things like credentials and other private information the mechanism
gets more complicated, but for the user who is trying to figure out how
to set up a CXF based application the above rules are good.

Or am I missing something?


-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] 
Sent: Monday, September 24, 2007 9:34 AM
To: cxf-dev@incubator.apache.org
Subject: Policies and features (Was : WS-SX)

Hi Eoghan

I've created a new topic so that I don't interfere with the original
WS-SX topic...


I'd like to step back for a second before answering to your specific
question.

Lets say we have an ability to express the same capability/requirement
using several alternative mechanisms, for ex, using a WS-Policy policy
expression and a CXF feature. We can probably agree that providing
several options is confusing to users and to those writing the
documentation. At the same time I don't think we can enforce the usage
of a single alternative. Hence we should have a good idea of when to the
WS-Policy expressions, when to use CXF features, when to use both, and
provide guidelines. 

IMHO a general guideline is : if it's of public interest (interest to
consumers) then it's a policy. Otherwise it's a feature. If
policy-unaware consumers are targeted then both alternatives might be
used, as such consumers still have to configure themselves. If it's a
consumer which is being configured then both alternatives are usable too
but the policy is better because more advanced WS-policy features can be
used when both a consumer and a provider are configured with ws-policy.

I think it was too strong to suggect a WS-Security feature would be
redundant/obsolete if WS-SecurityPolicy were supported. I just don't see
why would people use a CXF feature if a corresponding WS-SecurityPolicy
expression were available. Only if we could have this feature usable in
scenarios when no WS-Security was involved (say when people work with
restful services and do XMLEncryption, etc) then I can see why would
people choose to use a feature. 
When users are unhappy when seeing WS- appendix then let them use
features and not worry about policies (though it's worth saying a
WS-Policy language is not bound to WS-* services and the frameworks
defines the mechanism to attach policies to arbitrary XML elements).

If we were to use WS-SecurityPolicy then we'd need to decide where the
private stuff would go. As I said earlier two options are possible. 
One is to embedd the private stuff inside the policy itself and strip it
out at the publication time, works with wsdl/java first developement,
see for example :

1. http://blogs.sun.com/ritzmann/entry/ws_policy_in_wsit_milestone
"As is the case when you develop your service from WSDL, private policy
assertions are removed before the final WSDL is published. "
2. Similar pattern is used in Apache Rampart :
http://www.apache.org/dyn/closer.cgi/ws/rampart/1_3

Alternative approach is to put the public stuff into a policy and a
private stuff into a feature and merge the info. Possibly using the
advanced CXF feature mechanism where a policy assertion can be embedded
into a feature, as in case with RM assertions.

So finally I'm getting to your question :

>>Would the same logic apply to the reliableMessaging feature versus the

>>RMAssertion?

I believe we should advise users to use a reliableMessaging feature only
when it can add a private stuff (which is of no interest to consumers of
such polices) in addition to what a public WS-RM policy can already
express.

Alternatively we can advise people to put a private stuff inside a
policy itself but we'd have to strip it off at the publication time. In
case of RM we may not even have to do it as the private stuff won't be
as sensitive as the private security stuff and well-behaved RM consumers
should ignore unrecognized RM extensions.

I think both options can be supported, but with guidelines people would
be less confused with a number of configuration options we have. 

Would you agree with what I said ?

Thanks, Sergey




Hi Sergey,

A quick question on your observation that the WS-Security feature would
be redundant/obsolete if WS-SecurityPolicy were supported.

Would the same logic apply to the reliableMessaging feature versus the
RMAssertion?

Obviously there are some differences in the RM case, in the sense that
(a) an RMAssertion can be embedded in the reliableMessaging feature, and
(b) otherwise the primary purpose of the reliableMessaging feature is to
specify "non-private" behavior outside the scope of the RMAssertion
(e.g. the sequenceTerminationPolicy).

But I'm wondering if your line of reasoning would extend to embedding
e.g. the sequenceTerminationPolicy as a custom extension of the
RMAssertion?

Cheers,
Eoghan 

> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: 23 September 2007 13:25
> To: cxf-dev@incubator.apache.org
> Subject: RE: WS-SX
> 
> Hi
> 
>  
> 
> A couple of comments on WS-SecurityPolicy:
> 
>  
> 
> 1.       The core policy framework needs to be enhanced a bit 
> to deal with
> the normalization of nested polices which are abound in 
> WS-SecurityPolicy policies,
> 
> to deal with the effective policy calculation when multiple 
> Ws-SecurityPolicy polices are attached to multiple points for a given 
> policy subject like Endpoint, etc.
> 
> This is something I'd be willing to contribute to.
> 
> 2.       Supporting those policy assertions which map to what 
> CXF security
> runtime already supports would be a great start IMHO. This includes an

> HTTPS-related assertion too.
> 
>  
> 
> A separate comment on a WS-Security feature. I strongly believe that 
> we need to revisit the guidelines on when to use WS-Policy expressions

> as opposed to CXF features.
> 
> For ex, lets take WS-SecurityPolicy which we all agree is worth 
> supporting.
> WS-SecurityPolicy policy expressions are in themselves can do the 
> configuration just fine.
> 
> But using policy expressions provides for much more than just 
> statically configuring the runtime. They allow for a next to unlimited

> set of enhancements be applied to the consumer of
> 
> services annotated with such polices. Hence when thinking on how a 
> given capability or requirement should be  configured one should 
> prefer using policy expressions when
> 
> such requirements can be of use to a client/consumer.   
> 
>  
> 
> If we take WS-SecurityPolicy then we can see its policy expressions 
> are about expressing requirements to the consumers. Configuration is a

> positive side-effect. One can attach such a WS-SecurityPolicy 
> assertion either directly in a WSDL, or using an external attachment 
> mechanism supported by CXF. I believe Metro and Axis2 support both 
> approaches.
> Either way, the question arises where to put the private stuff, like 
> the key material location, passwords, and the like. One approach is to

> put them inside the policy expression and strip them out at a WSDL 
> publication time.
> Another approach is to put the private stuff outside the policy 
> expression but then merge the information from multiple sources. 
> Either approach has its pros and cons. The latter approach, by the 
> way, works perfectly well with Java-first style of service 
> development, the runtime could smartly annotate the WSDL at a 
> publication time, which is what Metro can do.
> 
>  
> 
> So lets have a look at a WS-Security feature. Basically I believe that

> if we start supporting WS-SecurityPolicy then the WS-Security feature 
> becomes redundant/obsolete. If one uses WS-SecurityPolicy then one 
> does not need to use WS-Security feature, and if one uses a 
> WS-Security feature then there's no point in using WS-SecurityPolicy. 
> Supporting both WS-SecurityPolicy and WS-Security feature will add to 
> the confusion people already when choosing how to configure a given 
> capability. Additionally, using policies one can annotate the contract

> at a very fine-grained fashion, which is not possible when using 
> features.
> 
>  
> 
> I still think something like WS-Security feature has its 
> place. It can be used by users which just don't want to use 
> WS-SecurityPolicy for whatever reasons and who are happy with 
> being able to annotate a limited part of the contract. More 
> realistically though one can probably use WS-Security feature 
> to keep the private stuff like passwords but have everything 
> else kept in the corresponding policy expression.  
> 
>  
> 
>  Cheers, Sergey
> 
>  
> 
>  
> 
>  
> 
>  
> 
>   _____  
> 
> From: Dan Diephouse [mailto:dan.diephouse@mulesource.com]
> Sent: 22 September 2007 21:38
> To: cxf-dev@incubator.apache.org
> Subject: WS-SX
> 
>  
> 
> One of the things on my wishlist for 2.1 is support for WS-SX 
> - WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. Its 
> a very important feature for a lot of corporations because it 
> enables much faster security and it also enables a range of 
> security scenarios which weren't possible before. 
> 
> I know I've chatted with Fred a bit about this before, but 
> I'd like to bring the discussion to the dev list for a while 
> so we can a) figure out the scope of the work b) decide if we 
> can do it for 2.1 and c) figure out who's going to do what. 
> Regarding this last point, I will be very happy to 
> particpate, but I'm not sure I can do the majority of the 
> work. But I can certainly code some and help brainstorm.
> 
> At a high level I suppose there are several things we need to do:
> 
> 1. Build a WS-Trust service for token exchange. At the 
> very least we
> need to be able to create symmetric keys from the asymmetric 
> public keys for WS-SecureConversation.
> 2. WS-SecurityPolicy
> 
> 1. First we need to start using JAXB catalog files. These 
> files allow
> JAXB to use classes which have already been generated when 
> doing xsd2java.
> In other words, our ws-security module can generate the 
> security policy beans and reference the beans in the policy 
> module. Whereas right now, the policy beans would be 
> regenerated by JAXB. This requires an upgrade to JAXB
> 2.1 and also it requires use of the official/Mojo JAXB plugin 
> instead of our own. Our own plugin is architected in such a 
> way that adding this feature isn't really possible without a 
> rewrite, which seems like a waste of time.
> 2. Which, if not all, policy assertions do we need to support?
> 
> 3. WS-SecureConversation service and interceptors
> 4. WS-Security feature for configuration (I heard through 
> the grapevine
> someone may have started on this. Would be interested to see 
> what has been done - I really like the way Spring-WS does 
> WS-Security configuration so it may be interesting to look into that)
> 
> So with that - anyone else looked into this in more detail? 
> Anyone want to help pick up this feature for 2.1?
> 
> Cheers,
> - Dan
> 
> 
> 
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
> 
> ----------------------------
> IONA Technologies PLC (registered in Ireland) Registered 
> Number: 171387 Registered Address: The IONA Building, 
> Shelbourne Road, Dublin 4, Ireland
> 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
Ireland

Mime
View raw message