On Wed September 23 2009 11:44:23 am Glen Mazza wrote: > 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)?
Hmm... well... no. At least it currently wouldn't work. The older WSS4JOutInterceptor is not policy aware at all and there really isn't a way for the newer policy aware interceptors to know what the WSS4JOutInterceptor has already done. Lets use your UsernameToken case as an example. For a TransportBinding/UsernameToken, the policy based out interceptor could easily look into the message to see if a UsernameToken is there and just assert the policy and continue. Not a big deal. However, lets assume a SymetricBinding with an encrypted UsernameToken. The policy based out interceptor really couldn't look into the message to see what's there. It would be encrypted. Thus, we would need to update the WSS4J*Interceptors to start recording more about what they did so the policy aware versions could skip themselves or similar. > 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. 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 > > 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 > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
