[
https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933801#action_12933801
]
Colm O hEigeartaigh commented on WSS-238:
-----------------------------------------
Thanks for logging that issue with WSIT Glen. It looks like the error you
report above is another bug in Metro. The response to the client from the Metro
web service contains a reference to the SAML Assertion like this:
<wsse:SecurityTokenReference
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true" />
This is a clear bug, as the policy specifies to "Always" include the Token.
Would it be possible to try to duplicate the Metro endpoint using CXF? I'm
curious to know if a) the CXF endpoint correctly includes the SAML Assertion
back to the client if "Always" is specified in the policy, and b) if the Metro
client can correctly parse the response the CXF endpoint sends back for the
"AlwaysToRecipient" case?
I will apply the WSS4J patch as it fixes the main problem here anyway.
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, WSS238_CXFClient_ALWAYS.txt, WSS238_MetroClient_ALWAYS.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]
