You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Glen Mazza <gl...@gmail.com> on 2010/07/14 03:34:53 UTC
Problem using SAML token profile to access a Metro web service
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#SAMLAssertionID</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-errata-os-SAMLTokenProfile.html
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-using-SAML-token-profile-to-access-a-Metro-web-service-tp1064848p1064848.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem using SAML token profile to access a Metro web service
Posted by Glen Mazza <gl...@gmail.com>.
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
> dkulp@apache.org
> 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.
Re: Problem using SAML token profile to access a Metro web service
Posted by Glen Mazza <gl...@gmail.com>.
Sure, I'll enter a JIRA ticket with a test case and test web service to make
it easy as possible to fix.
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
>
--
View this message in context: http://cxf.547215.n5.nabble.com/Problem-using-SAML-token-profile-to-access-a-Metro-web-service-tp1064848p1068820.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Problem using SAML token profile to access a Metro web service
Posted by Daniel Kulp <dk...@apache.org>.
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
dkulp@apache.org
http://dankulp.com/blog