An example of how to configure the CXF STS using the old configuration is available here. It involves a mixture of the STS Provider API that lives in the WS-Security module in CXF, and the concrete STS functionality that is available in the STS services module in CXF. The SecurityTokenServiceProvider in the CXF API is instantiated with implementations of the various Operations (Issue/Validate/etc.) that are available in the CXF STS. However, the flexibility of this approach leads to a slightly verbose configuration style, which is perhaps overly complicated for the most common use-cases.
An example of the simpler configuration approach is available here. Rather than use the SecurityTokenServiceProvider in the CXF API, it uses a sub-class in the CXF STS (DefaultSecurityTokenServiceProvider). This implementation supports the issue and validate bindings by default. It also supports the ability to issue and validate SAML Tokens, and to validate UsernameTokens and X.509 Tokens. Therefore, for any of these use-cases there is no need to use the old-style configuration, which involves explicitly instantiating each TokenProvider or TokenValidator instance and setting them on an IssueOperation/ValidateOperation instance. However, if you want to use the renew or cancel bindings, or do anything with SecurityContextTokens, it's necessary to use the old configuration.
The DefaultSecurityTokenServiceProvider can be configured with the following (optional) properties:
- boolean encryptIssuedToken - Whether to encrypt the issued token or not. The default is false.
- List<ServiceMBean> services - A list of service endpoints to support. See here for more information.
- boolean returnReferences - Whether to return references to an issued token or not. The default is true.
- TokenStore tokenStore - The TokenStore caching implementation to use. See here for more information.
- ClaimsManager claimsManager - The ClaimsManager to use if you want to be able to handle claims. See here for more information.
Post a Comment