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 On Mon April 6 2009 12:23:57 pm Ian Homer wrote: > Hi, > > We were connecting a CXF client to WCF as described in tutorial "WCF > Getting Started Sample Tutorial with Message Security User Name" @ > http://msdn.microsoft.com/en-us/library/ms752233.aspx and as reported in a > JIRA ticket (for another issue) @ > https://issues.apache.org/jira/browse/CXF-2158 > > We found that WCF was throwing the following exception ... > > Cannot find a token authenticator for the > 'System.IdentityModel.Tokens.UserNameSecurityToken' token type. > Tokens of that type cannot be accepted according to current > security settings. > > which we traced to being related to the WCF Service not accepting > UsernameToken in security header along with SecurityContextToken sent > by CXF client. CXF was sending both, i.e. > > <c:SecurityContextToken xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc > " > > xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit >y-utility-1.0.xsd " > u:Id="uuid-b7c16c8a-9816-4422-ac82-39ebbc64ae9e00"> > <c:Identifier>urn:uuid:1bfddc0c-944d-4c6b-99f9-9a1aa49f5700</ > c:Identifier> > </c:SecurityContextToken> > <wsse:UsernameToken > > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecu >rity-secext-1.0.xsd " > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur >ity-utility-1.0.xsd " > wsu:Id="UsernameToken-253884022"> > <wsse:Username>BART\myname</wsse:Username> > <wsse:Password > > Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-to >ken-profile-1.0#PasswordText ">password</wsse:Password> > </wsse:UsernameToken> > > Is there a way to configure the CXF client to only include the > UsernameToken once? > > The work around we applied was to create the following extension to > the WSS4JOutInterceptor > > public class JustOnceWSS4JOutInterceptor extends WSS4JOutInterceptor { > int count = 0; > > /** > * @param outProps > */ > public JustOnceWSS4JOutInterceptor(Map<String, Object> outProps) { > super(outProps); > } > > @Override > public void handleMessage(SoapMessage mc) throws Fault { > if (count == 0) { > super.handleMessage(mc); > } > count++; > } > } > > although I'm sure there's a better way of doing this. > > Ian -- Daniel Kulp [email protected] http://www.dankulp.com/blog
