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 <[email protected]> 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 >
