41.3 About Security Token Service Key Terms and Concepts

Security tokens contain claims or statements that are used to assert trust. To secure communication between a Web service client and a Web service, the two parties must exchange security credentials. These credentials can be obtained from a trusted Security Token Service.


To provide interoperable security tokens, the Security Token Service must be trusted by both the Web service client and the Web service.

Modern IT environments have numerous types of security tokens (most of them based on browser cookies) for facilitating SSO and session management for Web applications. These token types include Kerberos (primarily for Windows Native Authentication), Security Assertion Markup Language (SAML) assertions, and even digital certificates.

Table 41-2 identifies common Security Token Service terminology.

Table 41-2 Security Token Service Terms

Term Description

Security Token

A security mechanism that protects messages using a token issued by a trusted Secure Token Service for message integrity and confidentiality protection. The issued tokens contain a key, which is encrypted for the server and which is used for deriving new keys for signing and encrypting.

Service providers and consumers in potentially different managed environments can use a single Security Token Service to establish a chain of trust. The service does not trust the client directly, but instead trusts tokens issued by a designated Security Token Service. The Security Token Service is taking on the role of a second service with which the client must securely authenticate.

Security Token Service

A trusted third party in an explicit trust relationship with the server (and a trust relationship with the client). Security Token Service is one example.

Secure Token Service

A shared Web service that provides a standards-based consolidated mechanism of trust brokerage between different identity domains and infrastructure tiers.

The service implements the protocol defined in the WS-Trust specification by making assertions based on evidence that it trusts, to whoever trusts it (or to specific recipients). This protocol defines message formats and message exchange patterns for issuing, renewing, canceling, and validating security tokens.

To communicate trust, a service requires something to prove knowledge of a security token or set of security tokens. An XML Signature binds the sender's identity (or "signing entity") to an XML document, for example. The document is signed using the sender's private key, the signature is verified using the sender's public key.

Request Security Token (RST)

Request for a security token.

Request Security Token Response (RSTR)

Response generated by Security Token Service in response to the Request for Security Tokens with claims for the requested user.

On Behalf Of (OBO)

An OBO Request Security Token (RST) is used when only the identity of the original client is important. An OBO RST indicates that the requestor wants a token containing claims about only one entity:

  • the external entity represented by the token in the OnBehalfOf element.


An ActAs RST requires composite delegation. The final recipient of the issued token can inspect the entire delegation chain (not just the client). An ActAs RST indicates that the requestor wants a token that contains claims about distinct entities:

  • The requestor

  • An external entity represented by the token in the ActAs element

Token Exchange

The exchange of one security token for another. The requestor (in order to invoke a web service) requires a particular token. It uses Security Token Service to exchange the incoming token with a token required by the service.


Web Services Security (WS-Security) specifies SOAP security extensions that provide confidentiality using XML Encryption and data integrity using XML Signature.

The most prevalent security tokens used with WS-Security are Username, X.509 Certificates, SAML assertions, and Kerberos tickets (all supported by Oracle Web Service Manager).

WS-Security also includes profiles that specify how to insert different types of binary and XML security tokens in WS-Security headers for authentication and authorization purposes:

WS-* specifications often depend on each other. For example, WS-Policy is used in conjunction with WS-Security. WS-* specifications also leverage non-WS-* specifications; for example, WS-Security uses XML Encryption and XML Signature.

For WS-Security, only SAML assertions are used. The protocols and bindings are provided by the WS-Security framework.

Note: WS-Security, WS-Trust, WS-Policy have been transferred over to standards bodies such as the Organization for the Advancement of Structured Information Standards (OASIS) or the World Wide Web Consortium (W3C).


Web Services Trust Language (WS-Trust) is a specification that uses the secure messaging mechanisms of WS-Security to facilitate trust relationships.

WS-Trust defines a request and response protocol that enables applications to construct trusted SOAP message exchanges. Trust is represented through the exchange and brokering of security tokens.

In a message exchange using WS-Security only, it is assumed that both parties involved in the exchange have a prior agreement on which type of security tokens they must use for sharing security information. However, there are cases where these parties do not have such an agreement, as a result trust must be established before exchanging messages. Trust between two parties exchanging SOAP / WS-Security-based messages is established by implementing the WS-Trust specification.


Web Services Policy (WS-Policy). Together with WS-Security, WS-Policy is another key industry standard for Oracle Fusion Middleware security.

WS-Policy is used in conjunction with WS-Security. A web service provider may define conditions (or policies) under which a service is to be provided. The WS-Policy framework enables one to specify policy information that can be processed by web services applications, such as Oracle Web Services Manager.

A policy is expressed as one or more policy assertions representing a web service's capabilities or requirements. For example, a policy assertion may stipulate that a request to a web service be encrypted. Likewise, a policy assertion can define the maximum message size that a web service can accept.


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:


Security Token Service key stores include:

  • System Keystore

  • Trust Keystore

  • Partner Keystore

See Also: Managing Security Token Service Certificates and Keys

User Name Token (UNT)

Identifies the requestor by their username, and optionally using a password (or shared secret, or password equivalent) to authenticate that identity. When using a username token, the user must be configured in the Default User Identity Store.,

X.509 Certificates

A signed data structure designed to send a public key to a receiving party. A certificate includes standard fields such as certificate ID, issuer's Distinguished Name (DN), validity period, owner's DN, owner's public key, and so on.

Certificates are issued by certificate authorities (CA), for example Verisign. A CA verifies an entity's identity and grants a certificate, signing it with the CA's private key. The CA publishes its own certificate which includes its public key.

Each network entity has a list of the certificates of the CAs it trusts. Before communicating with another entity, a given entity uses this list to verify that the signature of the other entity's certificate is from a trusted CA.

Security Assertion Markup Language (SAML)

SAML Assertion

An open framework for sharing security information on the Internet through XML documents. SAML provides:

  • Assertions that define authentication and authorization information.

  • Protocols to ask (SAML Request) and get (SAML Response) the assertions you need.

  • Bindings that define how SAML Protocols ride on industry-standard transport (HTTP for instance) and messaging frameworks (SOAP for instance).

  • Profiles that define how SAML Protocols and Bindings combine to support specific use cases.

For WS-Security, only SAML assertions are used. However, the protocols and bindings are provided by the WS-Security framework.

SAML assertions can include three types of statements:

  • Authentication statement: issued by an authentication authority upon successful authentication of a subject. It asserts that Subject S was authenticated by Means M at Time T.

  • Attribute statement: issued by an attribute authority, based on policies. It asserts that Subject S is associated with Attributes A, B, etc. with values a, b, and so on.

  • Authorization decision statement (deprecated in SAML 2.0, now supported by XACML): issued by an authorization authority which decides whether to grant the request by Subject S, for Action A (read, write, and so on.), to Resource R (e.g., a file, an application, a web service), given Evidence E.


A cross-platform authentication and single sign-on system. The Kerberos protocol provides mutual authentication between two entities relying on a shared secret (symmetric keys). Kerberos authentication requires a client, a server, and a trusted party to mediate between them called the Key Distribution Center (KDC). Also required:

  • A Principal: An identity for a user (a user is assigned a principal), or an identity for an application offering Kerberos services.

  • A Realm is a Kerberos server environment, which can be a domain name such as EXAMPLE.COM (by convention expressed in uppercase). Each Kerberos realm has at least one Web Services Security KDC.

The Kerberos Token profile of WS-Security allows business partners to use Kerberos tokens in service-oriented architectures (SOAs).