[
https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915349#action_12915349
]
Colm O hEigeartaigh commented on WSS-238:
-----------------------------------------
> I can only supply code patches for the 1.5.x series because CXF presently
> won't compile with WSS4J 1.6. But it may not be a big deal for you to make >
> the change to the 1.6 series once CXF is coded for it.
Yup, just write the patch for 1.5.x and I can port it.
> When you say a "test" do you mean a JUnit test that will be incorporated into
> the WSS4J source code or a ZIP file consisting of a Metro STS, web
> service etc., that one can run to see the results? If the former, can you
> point to me a test already in WSS4J that I can leverage/learn from while
> making
> this JUnit test? It would be helpful for me to see something similar that I
> can copy from.
I meant the former. This just involves writing a test to make sure that the
generated XML has the correct field, i.e. KeyIdentifier instead of Reference,
and that WSS4J can process the document on the inbound side. Something like
this...
http://svn.apache.org/viewvc/webservices/wss4j/branches/1_5_x-fixes/test/wssec/TestWSSecurityNewST3.java?revision=998471&view=markup
Thanks,
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: Ruchith Udayanga Fernando
> Fix For: 1.6
>
> Attachments: EncryptedDataPatch.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: wss4j-dev-unsubscr...@ws.apache.org
For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
