[
https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933394#action_12933394
]
Colm O hEigeartaigh edited comment on WSS-238 at 11/18/10 6:29 AM:
-------------------------------------------------------------------
Hi Glen,
Thanks for confirming that the patch fixes the (first) problem.
The next problem is caused by the fact that the service endpoint is sending
back a reference in the EncryptedData to the SAML assertion like this:
<wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID";>#uuid-526391a2-929e-49db-b890-54812517062b</wsse:KeyIdentifier>
There are a couple of things to consider here. First off, I think it is a bug
that Metro is constructing a KeyIdentifier that uses a relative reference to
the SAML Assertion ID, as the SAML Assertion in question is not in the SOAP
request. Secondly, even if it were an absolute reference, it is not
spec-compliant as the following piece from the SAML 1.1 spec says:
"When a key identifier is used to reference a V1.1 SAML assertion that is not
contained in the same
message as the key identifier, a <saml:AuthorityBinding> element MUST be
contained in the
<wsse:SecurityTokenReference> element containing the key identifier. "
The problem WSS4J has, is that it can't find the SAML Assertion that is
referenced, as it is not in the message. There are two things to think about
here:
1) Could you try changing the WSDL of the Metro service endpoint, so that the
IssuedToken is included "Always" instead of "AlwaysToRecipient"? Is it a
requirement that the Assertion should not be sent to the initiator?
2) If it is a requirement, then I could look at finding a SAML Assertion via a
CUSTOM_TOKEN callback. Something similar is done for the SecurityContextToken
case.
Colm.
was (Author: coheigea):
Hi Glen,
Thanks for confirming that the patch fixes the (first) problem.
The next problem is caused by the fact that the STS endpoint is sending back a
reference in the EncryptedData to the SAML assertion like this:
<wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0#SAMLAssertionID";>#uuid-526391a2-929e-49db-b890-54812517062b</wsse:KeyIdentifier>
There are a couple of things to consider here. First off, I think it is a bug
that Metro is constructing a KeyIdentifier that uses a relative reference to
the SAML Assertion ID, as the SAML Assertion in question is not in the SOAP
request. Secondly, even if it were an absolute reference, it is not
spec-compliant as the following piece from the SAML 1.1 spec says:
"When a key identifier is used to reference a V1.1 SAML assertion that is not
contained in the same
message as the key identifier, a <saml:AuthorityBinding> element MUST be
contained in the
<wsse:SecurityTokenReference> element containing the key identifier. "
The problem WSS4J has, is that it can't find the SAML Assertion that is
referenced, as it is not in the message. There are two things to think about
here:
1) Could you try changing the WSDL of the Metro service endpoint, so that the
IssuedToken is included "Always" instead of "AlwaysToRecipient"? Is it a
requirement that the Assertion should not be sent to the initiator?
2) If it is a requirement, then I could look at finding a SAML Assertion via a
CUSTOM_TOKEN callback. Something similar is done for the SecurityContextToken
case.
Colm.
> Switch to wsse:KeyIdentifier instead of wsse:Reference for SAML references
> within SOAP:body EncryptedData elements.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WSS-238
> URL: https://issues.apache.org/jira/browse/WSS-238
> Project: WSS4J
> Issue Type: Improvement
> Components: WSS4J Core
> Affects Versions: 1.5.9
> Reporter: Glen Mazza
> Assignee: Colm O hEigeartaigh
> Fix For: 1.5.10, 1.6
>
> Attachments: EncryptedDataPatch.txt, patch238.txt,
> TestWSSecuritySAMLKeyIdentifier.java, wss-238-revised.patch,
> WSS-238Results.txt
>
>
> Per CXF bug CXF-2894: http://tinyurl.com/23jx6cx
> Within the soap:body/EncryptedData/SecurityTokenReference element, Glassfish
> Metro is requiring wsse:KeyIdentifiers instead of wsse:Reference elements
> when referring to SAML Assertions. Metro appears correct because the SAML
> Token Profile does not define usage of wsse:Reference for SAML Assertions,
> only KeyIdentifier or EmbeddedReference. (Section 3.3 of SAML Token Profile
> of 1 Dec. 2004 pdf lines 250-272.)
> The attached patch will switch SecurityTokenReference from wsse:Reference to
> wsse:KeyIdentifier when handling SAML Assertions. I've confirmed Metro web
> service providers will now work with this patch. However, backwards
> compatibility issues with systems expecting the current wsse:Reference may
> need to be taken into account.
> WSS4J has another problem with not being able to decrypt SOAP responses that
> use wsse:KeyIdentifier instead of wsse:Reference for SAML Assertions.
> Namely, org.apache.ws.security.processor.ReferenceListProcessor's
> getKeyFromSecurityTokenReference() method will need changing to be able to
> work with SAML Assertions coming from a wsse:KeyIdentifier element instead of
> wsse:Reference. I was not immediately successful in getting this second part
> to work because I could not see how a SAMLTokenProcessor can be initialized
> from a KeyIdentifier instead of the Reference element within this method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
