cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: WS-SX
Date Thu, 27 Sep 2007 16:15:04 GMT
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/%3c004701c7fc2c$acabf6a0$e002050a@pcgroupiona.com%3e

>
>
> 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" 
> <sergey.beryozkin@iona.com>
> To: <cxf-dev@incubator.apache.org>
> 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


Mime
View raw message