Dan, tough issue here, but wouldn't you say that SOAP clients programmed to use the WSS4JOutInterceptor for UsernameToken security should ideally continue to work even if the web service provider's security requirements are defined using WS-SecurityPolicy? (I.e., the client code should not have to change)? For example, let's say I have a CXF client configured using the traditional WSS4JIn/OutInterceptor method[1] calling a CXF-based web service, but then I switch to a Metro web service requiring the same UT security but instead with it configured via WS-SecPol. I would guess the CXF client should still be able to work without code changes--after all, the client is still sending the security header, even if coded using WSS4JOutInterceptor.
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. Thanks, Glen [1] http://www.jroller.com/gmazza/entry/using_cxf_and_wss4j_to Thanks for setting up the test endpoint. Definitely helped. I can now invoke on that endpoint fine. These should now be fixed on trunk. Tonights snapshots should have them. I need you to double check your setup though. From the information you sent, it LOOKS like you are kind of combinding the WS-SecurityPolicy stuff with the older WSS4JOutInterceptor. I THINK that's where the second UsernameToken is coming from. If using WS-SecurityPolicy, there is no-need to configure any of the WSS4J stuff. The policy runtime does that for you according to the policy. All you need to do is provide the extra information. In your case, all you need is the information of the UsernameToken for obtaining the SecureConversationToken. Thus, you just need: ((BindingProvider)port).getRequestContext() .put("ws-security.username.sct", "username"); ((BindingProvider)port).getRequestContext() .put("ws-security.password.sct", "password"); or use: "ws-security.callback-handler.sct", new MyPasswordHandler(...) to provide the callback instead of passing the password directly. Please let me know if that works out ok so I can close off CXF-2158. Thanks! Dan On Mon April 6 2009 1:36:13 pm Daniel Kulp wrote: > Ok.... thanks for reporting these. The TransportBinding stuff in > relation to WS-SecConv is definitely the least tested as the "live" https > endpoints at MS interop plugfest site have not been working for a couple > months now. :-( > > So, I see three issues that you've reported: > 1) The UsernameToken being sent along with the SecCont token. According > to the policies, the UsernameToken should just be sent to obtain the > SecCont token. Once that is obtained, it shouldn't be sent. Not sure > why > it is yet. > > > 2) Using the wrong Id to reference the SecCont token. The fix here is to > use: > sig.setKeyIdentifierType(WSConstants.CUSTOM_SYMM_SIGNING_DIRECT); > instead of: > sig.setKeyIdentifierType(WSConstants.CUSTOM_SYMM_SIGNING); > OR use: > sig.setCustomTokenId(secTok.getWsuId()); > I'll get that fixed in the code. That was updated in the Asym and Sym > binding handlers when testing/implementing the WS-SecConv stuff. (it > required some fixes to WSS4J as well) As mentioned above, the https > endpoint as MS isn't working so we didn't catch that change in the > transport binding. :-( > > > 3) Some validation thing that something should be signed.... I still > need > to look at that more... > > BTW: is there any way you could put this on a "live" site temporarily? I > don't have any Windows boxes and my .NET folks are busy for the next > couple > days. I'll try and get something similar setup in the cxf test suites > using a cxf endpoint, but if I could hit a live site for testing, that > would be great. > > Dan > -- View this message in context: http://www.nabble.com/WCF-Service-not-accepting-UsernameToken-in-security-header-along-with-SecurityContextToken-sent-by-CXF-client-tp22912335p25531202.html Sent from the cxf-user mailing list archive at Nabble.com.
