ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colm O hEigeartaigh (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (WSS-238) Switch to wsse:KeyIdentifier instead of wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Date Thu, 18 Nov 2010 11:30:15 GMT

    [ 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: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message