[
https://issues.apache.org/jira/browse/WSS-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933457#action_12933457
]
Glen Mazza commented on WSS-238:
--------------------------------
OK, I wouldn't want WSS4J to accommodate any Metro bugs (just as we just fixed
WSS4J when it was wrong so Metro wouldn't have to accommodate it.)
>From what you're saying, there's apparently two bugs in Metro's WSIT -- I can
>place these in their JIRA (http://java.net/jira/browse/WSIT) (or would you
>like to handle this?):
1.) Incorrect usage of a relative ("#") reference for the KeyIdentifier when
the SAML Assertion is not in the SOAP Envelope.
2.) *But* something may be wrong with your second assertion about
saml:AuthorityBinding needing to be included. Reading from the Assertions and
Protocol for the OASIS
Security Assertion Markup Language (SAML) V1.1 5 OASIS Standard, 2 September
2003:
2.4.3.2 Element <AuthorityBinding>
741 The <AuthorityBinding> element MAY be used to indicate to a SAML relying
party processing an
742 AuthenticationStatement that a SAML authority may be available to provide
additional information about
743 the subject of the statement. A single SAML authority may advertise its
presence over multiple protocol
744 bindings, at multiple locations, and as more than one kind of authority by
sending multiple elements as
745 needed.
746 NOTE: This element is deprecated; use of this element SHOULD be avoided
because it is planned to be
747 removed in the next major version of SAML.
Lines 746-747 say this element shouldn't be used, so it would strange for it to
be elsewhere required. I got this document from
http://saml.xml.org/saml-specifications under SAML 1.1. Where do you get your
quote about saml:Authoritybinding being required? I couldn't find it in that
document.
Question: What would be the point of the saml:AuthorityBinding anyway -- how
would that help.
Let me test the last two points you write and I'll get back to you on that
shortly.
> 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: [email protected]
For additional commands, e-mail: [email protected]
