I identified the precise section of the SOAP client call to the web service provider that's raising the error. It's the SecurityTokenReference child to the ds:Signature element shown here: https://issues.apache.org/jira/secure/attachment/12450127/CXF2894Example.txt (Other STR elements, Metro is OK with our present choice of wsse:Reference and/or wsse:KeyIdentifier.)
Questions: 1.) What CXF class generates that ds:Signature element (with its STR child element)? I can trace the CXF source code in Eclipse while the client is running, and see the output in Wireshark after the call is made, but am having trouble identifying the precise location of this element's generation prior to the call being made. 2.) Is there an easy way, while debugging a SOAP client call in Eclipse, that you can see the SOAP request message being built, as it's being built? Right now in the Eclipse debugger I use the Variables tab and open up the "first child" and/or "next sibling" elements of the SOAPMessage to see the individual elements, which works but is a little clumsy. Is there a better way? 3.) To confirm again (now that I zeroed on on the problem element), we can indeed switch to KeyIdentifier within STR's within the ds:Signature element--I ask this because ds:Signature is presumably used in many situations besides the subsequent SOAP client call to a web service provider after the client has gotten a SAML token from the STS. Thanks, Glen Daniel Kulp wrote: > > It definitely sounds like a bug in CXF. Probably not WSS4J. For the > IssuedTokens, I specifically had to add code in wss4j to output the # in > the > URI so it's most likely, in this case, need to check the places it's > setting > to CUSTOM_* and change it to the appropriate KEY_IDENTIFIER version. Not > really sure though. > > A test case with the policies and such would be useful. :-) > > Dan > > On Tuesday 13 July 2010 9:34:53 pm Glen Mazza wrote: >> Hello, using the CXF's STSClient[1] I've successfully been able to >> request >> a token against a Metro STS[2], but when I subsequently call the web >> service (also [2]) using that token I get an error back from the Metro >> web >> service: >> >> <S:Fault> >> <faultcode>wsse:InvalidSecurityToken</faultcode> >> <faultstring>unsupported directreference ValueType >> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAsserti >> onID</faultstring>... </S:Fault> >> >> It seems Metro doesn't like how CXF constructs the >> wsse:SecurityTokenReference of the SOAP request: >> >> <wsse:SecurityTokenReference >> wsu:Id="STRId-92A0C6CB3AAFA718FD12790621940816"> >> <wsse:Reference URI="#uuid-893daf04-8ea1-4d32-8b6f-05903e8d7e34" >> >> ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0# >> SAMLAssertionID"/> </wsse:SecurityTokenReference> >> >> It's expecting this format instead (see [3] for the full example): >> >> <wsse:SecurityTokenReference> >> <wsse:KeyIdentifier >> >> ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0# >> SAMLAssertionID">uuid-7a6d6259-af70-466f-b6c6-fd89c44bea71 >> </wsse:KeyIdentifier> >> </wsse:SecurityTokenReference> >> >> Somebody has already asked about this[4] on the Metro User's List -- >> Kumar >> of the Metro team wrote that they support just the latter as that's >> what's >> given in the SAML Token Profile for 1.1[5]--and he seems to be correct, >> Section 3.4 of [5] states: "This profile does not describe the use of >> Direct or URI references to reference V1.1 SAML assertions." and provides >> many examples of the above ValueType being used within wsse:KeyIdentifier >> elements. >> >> I'm not sure how to get this fixed. Is this: >> 1.) A WS-SecurityPolicy configuration issue, i.e., I can change the >> policy >> to force CXF to send the KeyIdentifier type to the Metro web service >> instead of the Reference type? >> 2.) A CXF bug for which I should submit a JIRA ticket? >> 3.) A WSS4J bug to JIRA? (I don't think so, but don't know). >> 4.) Or, indeed a Metro/XWSS bug -- is there some documentation we can >> point >> to which would indicate the wsse:Reference is kosher and correct here? >> >> Finally, if [2], would the fix be to switch to the former to the latter >> for >> all SAML token references (I'm not sure if making this change to enable >> me >> to access a Metro web service would end up breaking everyone else's >> code), >> or to provide a configuration option to allow for either type to be sent >> to >> the Metro web service? >> >> Thanks, >> Glen >> >> [1] https://cwiki.apache.org/CXF20DOC/ws-trust.html >> [2] http://www.jroller.com/gmazza/entry/metro_and_wstrust >> [3] http://www.jroller.com/gmazza/entry/metro_wstrust_analysis (Step #3 >> at >> the bottom, upper portion showing the traced SOAP request) >> [4] http://forums.java.net/jive/thread.jspa?threadID=63505 >> [5] >> http://www.oasis-open.org/committees/download.php/21206/wss-v1.1-spec-errat >> a-os-SAMLTokenProfile.html > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog > > -- View this message in context: http://cxf.547215.n5.nabble.com/Problem-using-SAML-token-profile-to-access-a-Metro-web-service-tp1064848p1842300.html Sent from the cxf-user mailing list archive at Nabble.com.
