41.2 Using the Security Token Service

Each Managed Server must be registered with Access Manager to open communication channels. Security Token Service leverages the common infrastructure for shared services and the Access Manager 11g administration model. All Security Token Service system configuration is done using the Oracle Access Management Console, providing a unified and consistent administration experience. Security Token Service also inter-operates with third party security token servers.

Security Token Service is compliant and co-exists with Access Manager (using Access Manager as the primary authenticator for Web clients requesting tokens). Security Token Service also uses Oracle Web Services Manager Agents. WebGate is used as an Agent for identity propagation. The WebGate must be registered with Access Manager 11g to open a communication channel. Security Token Service processing:

  • Integrates with STS Audit events

  • Publishes, in the Oracle Access Management Console and WLST scripts, available Security Token Service methods to manage partner data

  • Performs validation operations specific to the Security Token Service use cases and configuration model


Security Token Service adopts the same frameworks, guidelines, and practices for diagnostics, monitoring, auditing, and high availability used by Oracle Access Management 11g.

See Logging, Auditing, Reporting and Monitoring Performance.

The Security Token Service 11g infrastructure is described in Table 41-1.

Table 41-1 Security Token Service 11g Infrastructure

Component Description

Default Trust Keystore

Security Token Service private keys used for Signing/Encryption are stored in the common keystore used with Access Manager. Security Token Service and Access Manager use the common infrastructure certification validation module. Trusted Certificates and Certificate Revocation Lists (CRLs) used during certificate validation are stored in Trust Keystore and CRL ZIP file. The Security Token Service configuration stores the OCSP/CDP settings.

The token security key pair is populated to Access Manager/Security Token Service keystore.

Note: When the Oracle WSM Agent is used as the WS_Trust client in the Security Token Service deployment, Oracle strongly recommends that the Oracle WSM Agent keystore and the Security Token Service/Access Manager keystore always be different. Do not merge the two. Otherwise, Access Manager/Security Token Service keys could be available to any modules authorized by OPSS to access the keystore and Access Manager keys might be accessed.

See Also: Access Manager Keystores.

Default User Identity Store

Security Token Service authenticates and maps users against the User Identity stores configured through the Common Configuration section of System Configuration in the Oracle Access Management Console. Security Token Service maps the incoming token to user records and attributes in the default User Identity Store, which operates with both Access Manager and Security Token Service.

See Also: About using the System Store for User Identities.


The certificates used by Security Token Service are self signed. The subject and the issuer field are identical. Out of the box, the OAM Server hosting Security Token Service is uniquely identified:

  • The keys and certificates used in Security Token Service are generated during installation. The subject and issuer fields are linked to the host name. This applies to the signing and encryption keys and certificates used by Security Token Service, as well as the keys/certificates used by the OWSM Agent protecting Access Manager. The OWSM Agent is the certified WS-Trust client that can be used to communicate with Security Token Service.

  • The SAML Issuer settings are configured to refer to the host name of the local computer.

This ensures that two servers are not identical in terms of cryptographic materials and identifiers. The trust granted to one server by third-party modules is not granted to the other server because the identifiers and cryptographic keys differ. There are no identical keys, no identical identifiers, and authorization policies are in denial mode.

Oracle Coherence

Security Token Service integrates with the Oracle Coherence module to store and share run time WS-Trust data across all the physical instances of Security Token Service. The UserNameToken Nonce are stored in the Coherence store. This implementation supports the following requirements, which might be specific to Security Token Service:

  • Cleanup of timed out records

  • Existence of the records limited to several minutes (< 30)