dkulp wrote: > >> Stated another way, what is the purpose of WS-SecurityPolicy from a SOAP >> client perspective--is it just to specify the security requirements a >> client has to fulfill for the SOAP call to work, or does it imply that >> the >> web service stack should automatically create the SOAP header (with >> additional user-supplied parameters) for the web service call? If the >> former, a SOAP client should probably still work if WSS4J is manually >> used; if the latter, then manual usage of WSS4J to create another SOAP >> header (above and beyond the header created by the CXF WS-SecPol >> implementation) should perhaps raise an error somehow. > > For CXF, it's definitely the latter. The policies in the wsdl are used > to > control the runtime. The policies select which interceptors and features > to > activate which then manipulate how the message is constructed. > Currently, > there isn't any interaction between the older interceptors (that the user > would have added) and the newer interceptors (that the policy engine would > add). There probably could be, but there currently isn't. A simple > option could be to add a simple flag in WSS4J*Interceptor that said > "wssec- > done" = true or something and if that flag is set in the PolicyWSSJ4* > stuff, > they would just assert all the wss policies and return immediately. Not > ideal, but simple. The other next step up would be to add some policy > aware > stuff to WSS4J* which would examine the configuration and try and figure > out > which policies to assert. If they are already asserted in PolicyWSS4J* > stuff, just skip those sections. Not exactly sure how doable that is as > I'm > not sure how well the wss4j config would map onto the policies. The > OTHER > option (probably better option) is to update the WSS4J* interceptors to > detect > if the Policy aware versions are there and then just convert their config > into > properties that the policy aware versions would require. Set the ws- > security-* flags on the message so the PolicyAware versions can pick them > up. > > Definitely a bunch of options, just none of it is implemented that way. > The > only real option right now is to turn off the policy engine (see the 2.2 > migration guide) or migrate your configuration. > > Dan >
I see. I think the status quo--migrate config or deactivate policy engine--isn't that bad anyway. Thanks for the information. Glen -- View this message in context: http://www.nabble.com/WCF-Service-not-accepting-UsernameToken-in-security-header-along-with-SecurityContextToken-sent-by-CXF-client-tp22912335p25604979.html Sent from the cxf-user mailing list archive at Nabble.com.
