1) Use-cases for custom Token Validation
Let's consider first of all the use-cases for specifying a custom Validator implementation in CXF. When a security header is being processed by WSS4J, it delegates each security token to a Processor implementation, depending on the QName of the token. In WSS4J 1.6, Processors do not do any validation of extracted credentials from a token, they merely process it, make sure it meets basic requirements, etc. Validation is delegated to a Validator interface which is associated with that Processor implementation.
However, there are many possible use-cases where a user may wish to replace or remove or extend the default validation behaviour associated with a particular security token. Some examples include:
- Validating a UsernameToken, where the CallbackHandler implementation does not have access to the password.
- Validating a BinarySecurityToken of some custom type.
- Validating the attributes of a received SAML Assertion
- Validating a Timestamp in a more tolerant manner than the default.
- Dispatching a received security token to a third-party security service for validation/authentication.
- "ws-security.ut.validator" - Override UsernameToken validation.
- "ws-security.saml1.validator" - Override SAML1 token validation.
- "ws-security.saml2.validator" - Override SAML2 token validation.
- "ws-security.timestamp.validator" - Override Timestamp validation.
- "ws-security.signature.validator" - Override trust verification on a signature
- "ws-security.bst.validator" - Override BinarySecurityToken validation.
3) Using Validators with WS-Trust
To see the power and flexibility of the approach of separating processing from validation, consider the STSTokenValidator that ships with CXF 2.4. This validator implementation has the ability to dispatch a received BinarySecurityToken, UsernameToken, or SAML Assertion to an STS (Security Token Service) for validation via WS-Trust. On invocation, it delegates the credential to another validator (STSSamlAssertionValidator). This validator essentially catches an exception caused by a signature validation failure of the SAML Assertion and sets a flag. Only if signature validation is unsuccessful does the STSTokenValidator dispatch the token to the STS for validation.
An example of how to configure the STSTokenValidator to validate a SAML1 Assertion against an STS in spring is as follows:
<property name="wsdlLocation" value="..."/>
<property name="serviceName" value=".../>
<property name="endpointName" value="..."/>
The STSTokenValidator also has the ability to obtain a transformed token from the STS and store it in the credential, where it is available as part of the WSSecurityEngineResult under the TAG_TRANSFORMED_TOKEN tag.