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:[EMAIL PROTECTED] > Sent: 23 September 2007 13:25 > To: [email protected] > 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:[EMAIL PROTECTED] > Sent: 22 September 2007 21:38 > To: [email protected] > 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
