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
