You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "Glen Mazza (JIRA)" <ji...@apache.org> on 2010/07/30 03:22:15 UTC
[jira] Created: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
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
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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ 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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh updated WSS-238:
------------------------------------
Fix Version/s: 1.6
I'm marking this as fix for 1.6 for the backwards compatibility reasons outlined. The patch looks fine, but would you be able to write a test to verify the changes?
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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Glen Mazza updated WSS-238:
---------------------------
Attachment: EncryptedDataPatch.txt
Patch file.
> 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
> 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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Glen Mazza updated WSS-238:
---------------------------
Attachment: patch238.txt
New patch; ignore previous one.
> 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, patch238.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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12915556#action_12915556 ]
Glen Mazza commented on WSS-238:
--------------------------------
I'll see what I can do, I just typed up a blog entry on this issue: http://www.jroller.com/gmazza/entry/cxf_stsclient_with_metro_sts
> 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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Updated: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Glen Mazza updated WSS-238:
---------------------------
Attachment: TestWSSecuritySAMLKeyIdentifier.java
Requested test case.
> 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, patch238.txt, TestWSSecuritySAMLKeyIdentifier.java
>
>
> 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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
[jira] Commented: (WSS-238) Switch to wsse:KeyIdentifier instead of
wsse:Reference for SAML references within SOAP:body EncryptedData elements.
Posted by "Glen Mazza (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12914471#action_12914471 ]
Glen Mazza 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.
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.
Glen
> 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-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org