Security Token Service

Because of the use of tokens in Web Services Security, there is a need for a centralized token service; the Security Token Service serves this purpose for OpenSSO Enterprise. The Security Token Service was developed from the WS-Trust protocol which defines extensions to the WS-Security specification for issuing and exchanging security tokens and establishing and accessing the presence of trust relationships. The Security Token Service is hosted as a servlet endpoint and coordinates security based interactions between a WSC and a WSP. The Security Token Service is a standalone service that any third party client can use without implementing Web Services Security. The Security Token Service:

• Issues, renews, cancels, and validates security tokens.

• Allows customers to write their own plug-ins for different token implementations and for different token validations.

• Provides a WS—Trust based API for client and application access. For more information, see Web Services Security and Security Token Service Interfaces.

• Provides security tokens including Kerberos, Web Services-Interoperability Basic Service Profile (WS-I BSP), and Resource Access Control Facility (RACF).

When a WSC makes a call to the WSP, it first connects with the Security Token Service to determine the security mechanism and optionally obtain the security tokens expected by the WSP. (Alternately, the WSP could register its acceptable security mechanisms with the Security Token Service and, before validating the incoming SOAP request, could check with the Security Token Service to determine its security mechanisms.) Figure 14–5 illustrates the internal architecture of the Security Token Service.

Figure 14–5 Security Token Service Architecture

When an authenticated WSC (carrying credentials that confirm either the identity of the end user or the application) requests a token for access to a WSP, the Security Token Service verifies the credentials and, in response, issues a security token that provides proof that the WSC has been authenticated. The WSC presents the security token to the WSP which verifies that the token was issued by a trusted Security Token Service. Figure 14–6 illustrates the design of the Security Token Service.

Figure 14–6 Security Token Service Design

The Security Token Service supports the following tokens.

• Tokens that can be authenticated with the Security Token Service:

  1. UserName

  2. X509

  3. SAML 1.1

  4. SAML 2.0

  5. Kerberos

• Tokens that can be issued with the Security Token Service:

  1. UserName

  2. X509

  3. SAML 1.1

  4. SAML 2.0

• End user tokens that can be converted or validated out of the box:

  1. OpenSSO Enterprise SSOToken to SAML 1.1 or SAML 2.0 token

  2. SAML 1.1 or SAML 2.0 token to OpenSSO Enterprise SSOToken

Additionally, end user tokens can be converted or validated after customization. In this case, the new token is an On Behalf Of token (WS-Trust protocol element) carried in the WS-Trust request as part of the SOAP body and not as an authentication token carried as part of the SOAP header. Custom tokens can also be created and sent On Behalf Of an end user token for conversion or validation by Security Token Service. To do this, implement the com.sun.identity.wss.sts.ClientUserToken interface and put the implemented class name in AMConfig.properties on the client side and the global Security Token Service configuration using the OpenSSO console.

You can configure a WSC's agent profile to retrieve tokens from the Security Token Service (using the WS-Trust protocol) or from the Discovery Service (using the Liberty Alliance Project protocol). Based on this configuration, either the Security Token Service client API or the Discovery Service client API (both available through the Client SDK) will take over. For more information, see the Sun OpenSSO Enterprise 8.0 Administration Guide.