[WSS-290] Create Principals when processing SAML and BinarySecurityTokens

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.6
• Fix Version/s: 1.6.1
• Assignee: Colm O hEigeartaigh
• Reporter: Colm O hEigeartaigh
• Created: 31/May/11 11:22
• Updated: 02/May/13 02:29
• Resolved: 31/May/11 13:53

Description

This task involves creating Principals when processing SAML and BinarySecurityTokens. WSS4J currently creates principal objects when processing UsernameTokens, and also when using a token to verify a signature. The following rules will apply for principal creation:

1) A SAMLTokenPrincipal will be created by the SAMLTokenProcessor on a successful validation of a SAML Assertion.
2) A WSUsernameTokenPrincipal will be created by the UsernameTokenProcessor on a successful validation of a Username Token (current behaviour).
3) A X500Principal will be created by the BinarySecurityTokenProcessor on a successful validation of a BinarySecurityToken.

Two important points to note are:
1) Principals will only be created if the token has been explicitly validated. So for the BinarySecurityToken case, it is not validated by default and no principal is created.
2) If the token is transformed into a SAML Assertion by the validator, then a new principal is created and stored in the results set under WSSecurityEngineResult.TAG_PRINCIPAL. In other words, it replaces the principal that would have been created from the original token before it was transformed.

Issue Links

• is depended upon by: CXF-3521 WebServiceContext.getUserPrincipal() is null for incoming SAML Token or transformed token