cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@iona.com>
Subject Re: WS-SX
Date Mon, 01 Oct 2007 17:26:36 GMT
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" <sergey.beryozkin@iona.com>
To: <cxf-dev@incubator.apache.org>
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" <dan.diephouse@mulesource.com>
To: <cxf-dev@incubator.apache.org>
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/%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

----------------------------
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message