[WSS-238] Switch to wsse:KeyIdentifier instead of wsse:Reference for SAML references within SOAP:body EncryptedData elements.

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.9
• Fix Version/s: 1.5.10, 1.6
• Component/s: WSS4J Core
• Assignee: Colm O hEigeartaigh
• Reporter: Glen Mazza
• Created: 30/Jul/10 01:22
• Updated: 22/Nov/10 12:45
• Resolved: 22/Nov/10 12:45

Description

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.