You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Rhenius, Karl Stefan" <ks...@mach.de> on 2011/02/24 15:59:49 UTC
cfx and policy alternatives
Hi,
I'm a little bit confused about policy alternatives in cfx.
As far as I understand, the server offers multiple policies, and a
client may implement just one of them. So my setup is like this:
Server-policy:
<wsp:ExactlyOne>
<wsp:All>
#1 SecureConversation policy
</wsp:All>
<wsp:All>
#2 nothing special, clients just send an UsernameToken
</wsp:All>
</wsp:ExactlyOne>
Client-policy:
<wsp:ExactlyOne>
<wsp:All>
#1 SecureConversation policy
</wsp:All>
</wsp:ExactlyOne>
The client defines only the SecureConversation policy in it's wsdl.
If I test my service, they communicate like this:
Client > Server: RST/SCT message
Server > Client: answers with a token
Client > Server: calls the webservice with an encrypted soap message
Server > Client: answers the service call with an unencrypted message
(the server took policy #2 for the answer) -> client throws an exception
"These policy alternatives can not be satisfied"
Shouldn't the server answer with the same policy, that the requesting
client used?
The SecureConversation policy is correct - everything is fine, if I
remove the UsernameToken policy on the serverside.
I can attach my wsdl, soap messages etc, if you need them.
Thanks
Karl
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Karl
On Fri, Feb 25, 2011 at 4:38 PM, Rhenius, Karl Stefan <ks...@mach.de> wrote:
> Hi Sergey
>
>> thanks for the clarifications and your patience :-)
> You are all making a great job with cxf, being patient or building a
> testcase is the minimum I can do for you!
>
>> Would it make sense to have two ports for a single service or two
>> services, one supporting a SecCon only and the other supporting plain
>> UTs only ?
>
> That doesn't sound as cool as policy alternatives.
> Do you mean something like:
> <wsdl:service>
> <wsdl:port name="Foo" binding="UtBinding" />
> <wsdl:port name="FooSec" binding="SecConvBinding" />
> </wsdl:service>
>
> Is this a valid configuration? I'll test it on Monday, but I'd prefer
> policy alternatives.
It is a valid configuration, but you may want to have a single binding
and push the policies to the individual ports :
<wsdl:service>
<wsdl:port name="FooUT" binding="HelloWorldBinding" >
<UT/>
</wsdl:port>
<wsdl:port name="FooSec" binding="HelloWorldBinding" >
<SecureConversation/>
</wsdl:port>
</wsdl:service>
Policy alternatives are fine, and if it makes sense to have them
available in the context of a single port/endpoint then sure, why not,
but spreading them across ports/services may also be an option, it
really depends on the actual case...
>
> Even if the mix of encrypted messages and plain text isn't common, there
> are other scenarios, where the outgoing message format relates to the
> incoming.
> Let's assume you'd like to offer two SecureConversation policies with
> different encryption algorithms or key strength - cxf shouldn't roll a
> dice to chose an output format :)
>
>> This is what I meant, it could be tricky, though feasible, to figure
>> out dynamically which alternative has to be satisfied
>
> I think cxf should remember which policy was valid for the incoming
> message and use it for the outgoing message. This seems to involve no
> guesswork on the outgoing side. But that's just an idea without knowing
> anything about the code.
That is the tricky bit. Even a single Ws-Sec policy may have many
nested policies.
May be CXF can add its own custom SOAP header to the response, which,
assuming the CXF client is on the other side will be returned.
Or may be it should iterate over all the alternatives and then have
PolicyAlternative return a matching score, say UT-only policy will
return 1, SecureConversation policy will return 2, given that it will
recognize the SecCon header and the UT. But this is just a theory :-)
Cheers, Sergey
>
> Cheers
> Karl
>
RE: cfx and policy alternatives
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
Hi Sergey
> thanks for the clarifications and your patience :-)
You are all making a great job with cxf, being patient or building a
testcase is the minimum I can do for you!
> Would it make sense to have two ports for a single service or two
> services, one supporting a SecCon only and the other supporting plain
> UTs only ?
That doesn't sound as cool as policy alternatives.
Do you mean something like:
<wsdl:service>
<wsdl:port name="Foo" binding="UtBinding" />
<wsdl:port name="FooSec" binding="SecConvBinding" />
</wsdl:service>
Is this a valid configuration? I'll test it on Monday, but I'd prefer
policy alternatives.
Even if the mix of encrypted messages and plain text isn't common, there
are other scenarios, where the outgoing message format relates to the
incoming.
Let's assume you'd like to offer two SecureConversation policies with
different encryption algorithms or key strength - cxf shouldn't roll a
dice to chose an output format :)
> This is what I meant, it could be tricky, though feasible, to figure
> out dynamically which alternative has to be satisfied
I think cxf should remember which policy was valid for the incoming
message and use it for the outgoing message. This seems to involve no
guesswork on the outgoing side. But that's just an idea without knowing
anything about the code.
Cheers
Karl
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Fri, Feb 25, 2011 at 2:13 PM, Rhenius, Karl Stefan <ks...@mach.de> wrote:
>
>
>> Do you mean you are ok with UT requests which are not part of
>> the SecureConversation flow being accepted as well ?
>
> Yes, they are fine.
>
> CXF should answer to an UT request in plain text and to a
> SecureConversation request in something unreadable.
thanks for the clarifications and your patience :-)
This is what I meant, it could be tricky, though feasible, to figure
out dynamically which alternative has to be satisfied, thus I was
hoping that explicitly specifying that the UT as part of the flow can
be supported can help.
Imagine what CXF does now. You have a SecureConversation policy which
probably has a UT assertion embedded in one of its deeply nested
sub-policies. And you have a UT policy on its own which has allows for
exchanges which have nothing to do with the SecureCon flow.
So we have a message with the UT arriving. The CXF Policy interceptors
will iterate over alternatives and decide which interceptors should
handle the request. It probably checks the UT policy first and thus
selects that policy and thus ignores the SecCon one.
I'm out of my depth by now so let Dan or David V or someone else to
fix it :-), but to be honest, I'd not try to create a semi kind of
secure port where which allows for message with/without SecCon
headers.
Would it make sense to have two ports for a single service or two
services, one supporting a SecCon only and the other supporting plain
UTs only ?
Just my 2c
thanks, Sergey
>
> cheers
> Karl
>
RE: cfx and policy alternatives
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
> Do you mean you are ok with UT requests which are not part of
> the SecureConversation flow being accepted as well ?
Yes, they are fine.
CXF should answer to an UT request in plain text and to a
SecureConversation request in something unreadable.
cheers
Karl
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Karl
>> <wsp:ExactlyOne>
>> <wsp:All>
>> <SecureConversation>
>> <UsernameToken>
>> <wsp:All>
>> </wsp:ExactlyOne>
>
> Are you sure, that this is equivalent? In the WS-SecurityPolicy spec are
> examples, that imply <wsp:ExactlyOne> choses one of the direct childs,
> so <wsp:all> is used to combine multiple policies. But nevertheless, I
> wrapped each in a <wsp:all>.
>
http://www.w3.org/TR/ws-policy/#Normal_Form_Policy_Expression
seems to be indicating that wsp:All is needed, it's not used in the
examples, but ExactlyOne with direct assertion children seems like a
shortcut for ExactlyOne/All...Not really sure 100% though :-)
>> Indeed. Sorry if I don't understand, but the way you
>> described the flow sounded like the one which would be
>> validated by this policy, that is, the first message is
>> starting SecConversation flow, no UT, and the subsequent
>> messages will be validated by the 2nd alternative where both
>> SecConversation and UT assertions are available....
>>
>> Your original policy:
>> [...]
>>
>> is actually equivalent to two alternatives (because of embedded
>> wsp:Alls) : either SecureConversation only or UT only, it
>> does not express the requirement that UT messages should be
>> part of the SecConversation flow.
>
> thats exactly what I'd like to have - SecureConversation only or UT
> only.
Do you mean you are ok with UT requests which are not part of the
SecureConversation flow being accepted as well ?
thanks, Sergey
>
> I hope this makes it clearer :)
>
> cheers
> Karl
>
RE: cfx and policy alternatives
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
Hi Sergey
> To me this policy reads:
>
> Ensure the message satisfies both SecureConversation and
> UsernameToken policies at the same time, because <wsp:ExactlyOne>
> <SecureConversation>
> <UsernameToken>
> </wsp:ExactlyOne>
>
> is equivalent to
>
> <wsp:ExactlyOne>
> <wsp:All>
> <SecureConversation>
> <UsernameToken>
> <wsp:All>
> </wsp:ExactlyOne>
Are you sure, that this is equivalent? In the WS-SecurityPolicy spec are
examples, that imply <wsp:ExactlyOne> choses one of the direct childs,
so <wsp:all> is used to combine multiple policies. But nevertheless, I
wrapped each in a <wsp:all>.
> Indeed. Sorry if I don't understand, but the way you
> described the flow sounded like the one which would be
> validated by this policy, that is, the first message is
> starting SecConversation flow, no UT, and the subsequent
> messages will be validated by the 2nd alternative where both
> SecConversation and UT assertions are available....
>
> Your original policy:
> [...]
>
> is actually equivalent to two alternatives (because of embedded
> wsp:Alls) : either SecureConversation only or UT only, it
> does not express the requirement that UT messages should be
> part of the SecConversation flow.
thats exactly what I'd like to have - SecureConversation only or UT
only.
I hope this makes it clearer :)
cheers
Karl
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Karl
On Fri, Feb 25, 2011 at 11:56 AM, Rhenius, Karl Stefan <ks...@mach.de> wrote:
>
>> In fact, I'm wondering, if your policy is totally correct.
>> Given that you expect the secure conversation flow all the
>> time, should it look like this instead:
>>
>> <Policy>
>> <ExactlyOnce>
>> <SecureConverstaion/>
>> </ExactlyOnce>
>> <ExactlyOnce>
>> <SecureConverstaion/>
>> <UT/>
>> </ExactlyOnce>
>> </Policy>
>>
>> What do you think ? Wondering if it will work...
>
> Hi Sergey,
>
> no, the webservice should be accessed either with SecureConversation
> messages or
> plain text with a UsernameToken, so I think
>
> <wsp:Policy>
> <wsp:ExactlyOne>
> <SecureConversation>
> <UsernameToken>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
To me this policy reads:
Ensure the message satisfies both SecureConversation and UsernameToken
policies at the same time, because
<wsp:ExactlyOne>
<SecureConversation>
<UsernameToken>
</wsp:ExactlyOne>
is equivalent to
<wsp:ExactlyOne>
<wsp:All>
<SecureConversation>
<UsernameToken>
<wsp:All>
</wsp:ExactlyOne>
> is right. If I understand your policy correct, it would describe
> SecureConversation + an optional UsernameToken?
Indeed. Sorry if I don't understand, but the way you described the
flow sounded like the one which would be validated by this policy,
that is, the first message is starting SecConversation flow, no UT,
and the subsequent messages will be validated by the 2nd alternative
where both SecConversation and UT assertions are available....
Your original policy:
<wsp:ExactlyOne>
<wsp:All>
<SecureConversation>
<wsp:All>
<wsp:All>
<UsernameToken>
<wsp:All>
</wsp:ExactlyOne>
is actually equivalent to two alternatives (because of embedded
wsp:Alls) : either SecureConversation only or UT only, it does not
express the requirement that UT messages should be part of the
SecConversation flow.
Again, I may be misunderstanding...
cheers, Sergey
>
> cheers
> Karl
>
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
This option should fix the ordering issue at least because at the
moment CXF gets the union of all the assertions included in multiple
alternatives.
Not sure about the dynamic selection at the runtime though....
cheers, Sergey
On Fri, Feb 25, 2011 at 11:15 AM, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
>
> On Fri, Feb 25, 2011 at 11:04 AM, Rhenius, Karl Stefan <ks...@mach.de> wrote:
>>
>>> > I'm going to make a testcase for jira.
>>>
>>> Yea. Please do. This definitely sounds like a bug, but a
>>> complicated enough
>>> one that a good test case is probably required.
>>
>> Hi Dan,
>>
>> the jira issue is here: https://issues.apache.org/jira/browse/CXF-3365
>>
>> I noticed, that the ordering of policies affects the response too.
>> Defining SecureConversation as 2nd policy causes a bug during the
>> RST/SCT message.
>>
> Dynamically choosing the right alternative is tricky/complex.
>
> In fact, I'm wondering, if your policy is totally correct.
> Given that you expect the secure conversation flow all the time,
> should it look like this instead:
>
> <Policy>
> <ExactlyOnce>
> <SecureConverstaion/>
> </ExactlyOnce>
> <ExactlyOnce>
> <SecureConverstaion/>
> <UT/>
> </ExactlyOnce>
> </Policy>
>
> What do you think ? Wondering if it will work...
>
> cheers. Sergey
>
>> cheers
>> Karl
>>
>
RE: cfx and policy alternatives
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
> In fact, I'm wondering, if your policy is totally correct.
> Given that you expect the secure conversation flow all the
> time, should it look like this instead:
>
> <Policy>
> <ExactlyOnce>
> <SecureConverstaion/>
> </ExactlyOnce>
> <ExactlyOnce>
> <SecureConverstaion/>
> <UT/>
> </ExactlyOnce>
> </Policy>
>
> What do you think ? Wondering if it will work...
Hi Sergey,
no, the webservice should be accessed either with SecureConversation
messages or
plain text with a UsernameToken, so I think
<wsp:Policy>
<wsp:ExactlyOne>
<SecureConversation>
<UsernameToken>
</wsp:ExactlyOne>
</wsp:Policy>
is right. If I understand your policy correct, it would describe
SecureConversation + an optional UsernameToken?
cheers
Karl
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On Fri, Feb 25, 2011 at 11:04 AM, Rhenius, Karl Stefan <ks...@mach.de> wrote:
>
>> > I'm going to make a testcase for jira.
>>
>> Yea. Please do. This definitely sounds like a bug, but a
>> complicated enough
>> one that a good test case is probably required.
>
> Hi Dan,
>
> the jira issue is here: https://issues.apache.org/jira/browse/CXF-3365
>
> I noticed, that the ordering of policies affects the response too.
> Defining SecureConversation as 2nd policy causes a bug during the
> RST/SCT message.
>
Dynamically choosing the right alternative is tricky/complex.
In fact, I'm wondering, if your policy is totally correct.
Given that you expect the secure conversation flow all the time,
should it look like this instead:
<Policy>
<ExactlyOnce>
<SecureConverstaion/>
</ExactlyOnce>
<ExactlyOnce>
<SecureConverstaion/>
<UT/>
</ExactlyOnce>
</Policy>
What do you think ? Wondering if it will work...
cheers. Sergey
> cheers
> Karl
>
RE: cfx and policy alternatives
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
> > I'm going to make a testcase for jira.
>
> Yea. Please do. This definitely sounds like a bug, but a
> complicated enough
> one that a good test case is probably required.
Hi Dan,
the jira issue is here: https://issues.apache.org/jira/browse/CXF-3365
I noticed, that the ordering of policies affects the response too.
Defining SecureConversation as 2nd policy causes a bug during the
RST/SCT message.
cheers
Karl
Re: cfx and policy alternatives
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 24 February 2011 11:05:47 AM Rhenius, Karl Stefan wrote:
> Hi Sergey,
>
> according to your answer this seems to be a bug? (That would be great,
> because I could stop trying to find the right configuration :)
>
> > Dan has enhanced the Neethi implementation to properly
> > support the policy intersection but that is more likely to
> > affect the client side. But in this case, how does the server
> > knows the 2nd request is coming from the original client
> > which is supporting a SecureConversation policy ?
>
> I attached the incoming message from my client and the servers response.
> There are many header information, that could be used to track the
> session, i.e.
> <wsc:Identifier>BC4D3B6C7539DA347C12985615449223</wsc:Identifier> for
> the SecureConversation.
>
> I didn't checked, how the policy is chosen, so this is just speculative:
> I would add the chosen policy somewhere in the exchange or message
> object, so the outgoing handler can take an appropriate format. There is
> no need to track a session, the first valid policy on the incoming side
> should be used for the outgoing message.
>
> I'm going to make a testcase for jira.
Yea. Please do. This definitely sounds like a bug, but a complicated enough
one that a good test case is probably required.
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com
RE: cfx and policy alternatives
Posted by "Rhenius, Karl Stefan" <ks...@mach.de>.
Hi Sergey,
according to your answer this seems to be a bug? (That would be great,
because I could stop trying to find the right configuration :)
> Dan has enhanced the Neethi implementation to properly
> support the policy intersection but that is more likely to
> affect the client side. But in this case, how does the server
> knows the 2nd request is coming from the original client
> which is supporting a SecureConversation policy ?
I attached the incoming message from my client and the servers response.
There are many header information, that could be used to track the
session, i.e.
<wsc:Identifier>BC4D3B6C7539DA347C12985615449223</wsc:Identifier> for
the SecureConversation.
I didn't checked, how the policy is chosen, so this is just speculative:
I would add the chosen policy somewhere in the exchange or message
object, so the outgoing handler can take an appropriate format. There is
no need to track a session, the first valid policy on the incoming side
should be used for the outgoing message.
I'm going to make a testcase for jira.
Bye
Karl
Re: cfx and policy alternatives
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Dan has enhanced the Neethi implementation to properly support the
policy intersection but that is more likely to affect the client
side.
But in this case, how does the server knows the 2nd request is coming
from the original client which is supporting a SecureConversation
policy ? It might be coming from the client starting with a UT only ?
Unless this 2nd request, as part of the SecureConversation flow, does
indicate via some SOAP header it belongs to that flow (sorry - just
don't know). If it is the case then it's a bug to do with the server
not picking up the correct policy alternative...
cheers, Sergey
On Thu, Feb 24, 2011 at 2:59 PM, Rhenius, Karl Stefan <ks...@mach.de> wrote:
> Hi,
>
> I'm a little bit confused about policy alternatives in cfx.
> As far as I understand, the server offers multiple policies, and a
> client may implement just one of them. So my setup is like this:
>
> Server-policy:
> <wsp:ExactlyOne>
> <wsp:All>
> #1 SecureConversation policy
> </wsp:All>
> <wsp:All>
> #2 nothing special, clients just send an UsernameToken
> </wsp:All>
> </wsp:ExactlyOne>
>
> Client-policy:
> <wsp:ExactlyOne>
> <wsp:All>
> #1 SecureConversation policy
> </wsp:All>
> </wsp:ExactlyOne>
>
> The client defines only the SecureConversation policy in it's wsdl.
>
> If I test my service, they communicate like this:
> Client > Server: RST/SCT message
> Server > Client: answers with a token
> Client > Server: calls the webservice with an encrypted soap message
> Server > Client: answers the service call with an unencrypted message
> (the server took policy #2 for the answer) -> client throws an exception
> "These policy alternatives can not be satisfied"
>
> Shouldn't the server answer with the same policy, that the requesting
> client used?
>
> The SecureConversation policy is correct - everything is fine, if I
> remove the UsernameToken policy on the serverside.
> I can attach my wsdl, soap messages etc, if you need them.
>
> Thanks
> Karl
>