Hi Dan It's good to see us coming to some agreement.
I agree that users should be able to use a feature only if it is what they prefer. I belive we also agree that supporting a WS-SecurityPolicy is about CXF being able to consume explicit policy expressions. As I suggested earlier, supporting only those policies (and their suboptions) which map to what we already have in CXF with respect to WS-Security, would be a good start IMHO. In some sense, nothing changed with respect to how CXF can deal with the configuration. That is we have features (security feature) and we have policies (WS-SecurityPolicy). One can use a feature or a policy to achieve the same effect (to provide input to the WS-Security runtime). However, the positive thing is that I believe we've come to the conclusion that implementing a WS-SecurityPolicy means being able to consume WS-Policy expressions. More importantly, I feel there's at least some agreement that in the presense of multiple (configuration) alternatives for setting up/configuring the runtime, policies are a better fit for keeping the public bits, those which can be exposed to and consumed by the outside world, by all the policy-aware design and runtime tools out there. Surely, features will live their own life, as some users would see little advantage in using WS-Policy expressions. It's much better to have some kind of guideline rather than just presenting all the alternatives to users and suggesting them to choose any of those alternatives. As far as complexity is concerned. Polices are starting to look complicated when multiple alternatives are used across the board. Tha gives more power, but that would be the next step. When used to express the minimal set of requirements WS-SecurityPolicy policies should not be any more complicated to type than corrresponding feature expressions. I don't believe, that as far as manual typing is concerned, a feature is easier to type anyway, and how many people dealing with WS-Security are going to manually deal with the configuration anyway ? Why don't we have a go at some policy expression and see how it all will look like ? Lets not take a sophisticated policy, just the one which matches what we already have in CXF (WS-Security) at the moment... Thanks, Sergey ----- Original Message ----- From: Dan Diephouse To: [email protected] Sent: Monday, October 01, 2007 8:36 PM Subject: Re: WS-SX Hi Sergey, Sorry I'm behind on emails, but how you described things below is exactly how I'd like to see things working. Coming back to what you previously wrote: As far as supporting WS-SecPolicy is concerned it means : * being able to consume explicit WS-SecPolicy expressions at the least * providing private stuff through features +1. I think it'd be *nice* to support specifying private stuff through policy at some point, but for me, thats of secondary concern. Similarly supporting WS-Security means : * do the actual security runtime work * providing all the information the runtime needs either through a combination of WS-SecPolicy(public stuff) and WS-Feature (private stuff) or * providing all the information the runtime needs only through a WS-Feature (all stuff) - hence no support for WS-SecurityPolicyI would prefer that users be able to configure things through WS-SecPolicy. But I don't have a great idea of how complex that will be for users. If a user just needs WS-Security and we can provide a simplified WSFeature that makes it significantly easier than WS-SecPol, than I'd be for it advocating a feature in that case. In general though, i think we should push ws-secpol + feature for private stuff. Cheers, - Dan Sergey Beryozkin wrote: Hi Another follow-up email. Lets' assume for a sec that we do agree that as far as a WS-SecurityPolicy support is concerned, we're talking about putting the public stuff inside a policy expression and a private stuff inside a feature. The more I think about it the more it seems to be like the best combination. Consider a WS-SecurityPolicy policy-aware CXF client consuming a NET service annotated with a WS-SecurityPolicy policy expression. CXF-based client itself can work with just a private stuff being setup in its feature config, the public stuff can be 'borrowed' from the policy attached to a Net's service contract. This highlightes the fact a runtime policy has not only been designed for a publication, but also for a consumption. In this scenario a CXF client does not yet have its own policy expresssion. But surely, it can have the one of its own. So what we have now is a CXF client with its own policy expression keeping all the public stuff and with its security feature keeping the private stuff, and we have a NET (or indeed a CXF) server service having its own policy expression. That's where the power of using polices starts paying off as the client can do the policy intersection, by matching its own policy expression against the one associated with a provider's service. And this is where the design decision to keep the public stuff in a policy and the private one in a feature would start paying off as it will make the intersection process much easier to perform. Cheers, Sergey ----- Original Message ----- From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, September 28, 2007 5:54 PM Subject: Re: WS-SX Hi Dan Sorry for the delay and for actually not looking at the actual policy expression :-) Ah wait, I didn't read the full message. I wasn't on crack :-) the <KeyStore> element *is* proprietary. It's supposed to be stripped off at the publication time, I believe that policy expression was copied from the Metro sample and in Metro private stuff is located inside a policy expression itself and then stripped off. As we discussed, this one of the options on how to provide the private stuff for the runtime, albeit not terribly secure. Here's all I want out of the WS-SecPol stuff. An easy way to configure key store information for the server/client from the API. Sorry for being pedantic :-) WS-SecPol stuff is about providing the public stuff. It was designed for it. Some stacks decide the problem of providing the private stuff to the runtime by embedding it directly into the the polcies themselves, it overloads the purpose of polices but it works (not secure though :-)) The other approach is to fetch the private stuff from some complementary sources. The best way to do this seems to be a WSSXFeature of some sort. +1. Seems to be we're on the same page ? As far as supporting WS-SecPolicy is concerned it means : * being able to consume explicit WS-SecPolicy expressions at the least * providing private stuff through features Similarly supporting WS-Security means : * do the actual security runtime work * providing all the information the runtime needs either through a combination of WS-SecPolicy(public stuff) and WS-Feature (private stuff) or * providing all the information the runtime needs only through a WS-Feature (all stuff) - hence no support for WS-SecurityPolicy Do you agree ? Cheers, Sergey ----- Original Message ----- From: "Dan Diephouse" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, September 27, 2007 5:40 PM Subject: Re: WS-SX Ah wait, I didn't read the full message. I wasn't on crack - the <KeyStore> element *is* proprietary. Here's all I want out of the WS-SecPol stuff. An easy way to configure key store information for the server/client from the API. The best way to do this seems to be a WSSXFeature of some sort. We can also support our own <KeyStore>/<TrustStore> elements and the like. But it seems critical to me that we support configuration of this information via the API as well, and the best place for this seems to be a Feature. This is *complementary* to policy and I'm not trying to replace it. Both will still be needed for the server/client configuration. Cheers, - Dan Dan Diephouse wrote: Thanks for the example Sergey, that does help clear things up. I didn't realize there was a visibility element, nor did I realize that there were actually standard expressions for configuring the private key info. Question then: what *can't* be configured via standard ws-secpol policy expressions? I'm confused now, as it was my understanding that these things required proprietary extensions for configuration. If there isn't actually anything else the user needs to supply, I agree - it makes sense to just configure ws-sx via policy. In the case of the client, they can just write a small policy file with the necessary trust information and attach it via the policy feature bits which have already been developed. Cheers, - Dan Sergey Beryozkin wrote: Sorry, spam filter does not allow a link to nabble, here's the link to the message on a cxf-user archive : [1] http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/200709.mbox/[EMAIL PROTECTED] and in cryptic form to nabble [1] www dot nabble dot com forwardslash Problems-with-Policy-file-tf4492323 dot html ----- Original Message ----- From: "Sergey Beryozkin" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, September 26, 2007 2:27 PM Subject: Re : WS-SX Hi Dan Here's a follow-up mail. I was thinking that it would help if we look at a concrete user query [1]. Note that there's a WS-SecurityPolicy policy expression attached to the WSDL contract. The user has tried this WSDL with a policy expression in Metro and it worked for him. I've no doubt it will for him with quite a few other stacks. Please also note that no private stuff is located in the policy itself. How Metro achieved hiding the private stuff is immaterial. Now, when we're talking about supporting WS-SecurityPolicy, we need to be concrete about exactly are we talking about. If a user asks [1], can I do it in CXF, what will be our answer once we start claiming we support WS-SecurityPolicy ? As I said I start feeling that the way you see CXF "supporting" WS-SecurityPolicy is that we look at what is possible to enable with WS-SecurityPolicy expressions and then translate it all into corresponding feature expressions. As I said it will mean that we will support no WS-SecurityPolicy but WS-Security. That's why I've quotes about "supporting". As such the only answer we could give to users asking questions like [1] is that they'll have to convert the security policy expressions into corresponding CXF configuration artifacts. I don't think it'll be good enough. I'll be happy to be corrected if I've misunderstood the way you envisage it all and I apologize in advance if it's the case. Supporting WS-SecurityPolicy means : * runtime should be capable of accepting explicit policy expressions such as those shown at [1]. As we've discussed there's a number of ways to provide the missing private stuff to the runtime * When a secure service provider publishes its WSDL, this WSDL has to contain WS-SecurityPolicy expressions in the right attachment points inline or through external references. (optional bit) This is what I believe will make "CXF supports WS-SecurityPolicy" a true statement. Now if there's a strong interest behind providing a WS-Security feature which will let users to basically set up the runtime by providing it the same info WS-SecurityPolicy policies can give it, then it's fare enough. It's likely some users will want to use this option. I just don't think it has something to do with the work required to support WS-SecurityPolicy. Thanks, Sergey ---------------------------- 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 -- 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 -- 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
