[
https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932977#action_12932977
]
Colm O hEigeartaigh commented on WSS-238:
-----------------------------------------
Hi Glen,
Apologies for not looking at this issue sooner. Please see attached for a
revised patch (and test-case) for this issue.
On the outbound side, the patch gives the ability to create EncryptedData and
EncryptedKey tokens where the key used to encrypt the token is referenced using
a KeyIdentifier with a custom token value and id. I changed things around a bit
from the patch you submitted. WSSecEncryptedKey has two new methods to set both
the value and id. These methods already exist in WSSecEncrypt, so it was just a
matter of supporting the SAML specific case. The current CXF code should work
fine with this patch without any code changes.
The reason I did not move the setCustomReferenceValue method from WSSecEncrypt
to WSSecEncryptedKey as per your patch, was a) for backwards compatibility, and
b) To accomodate the use-case, where the EncryptedData element points to the
EncryptedKey, and the EncryptedKey points to the SAML assertion. I changed the
test-case to illustrate this scenario.
I also added support to the EncryptedKeyProcessor to support processing an
EncryptedKey that points to a SAML Assertion containing an X509Certificate, and
the ReferenceListProcessor, to support processing an EncryptedData token that
points to a SAML Assertion containing an EncryptedKey.
Could you apply this patch to 1_5_x-fixes and test with CXF to see whether it's
producing an EncryptedData of the right format, which can be processed by
Metro? The good news is that this patch is 100% backwards compatible, and so I
will fix it for 1.5.10 if you ok the patch.
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.6
>
> Attachments: EncryptedDataPatch.txt, patch238.txt,
> TestWSSecuritySAMLKeyIdentifier.java, wss-238-revised.patch
>
>
> 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]
