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
