34 Introducing the Oracle Access Management Security Token Service
The Oracle Access Management Security Token Service provides the foundation for the security infrastructure, facilitating a consistent and streamlined model for token acquisition, renewal, and cancellation that is protocol and security infrastructure agnostic. It helps simplify the effort needed to bridge access to various systems by using a standardized set of interfaces. Security Token Service facilitates Federated SSO and Single Logout (SLO) for users accessing resources through a Web browser and across different security domains or administrative boundaries.
The following sections contain introductory material regarding the Security Token Service.
34.1 Understanding the Security Token Service
Security Token Service is a Web Service (WS) Trust-based token service that allows for policy-driven trust brokering and secure identity propagation and token exchange between Web Services. Security Token Service can be deployed as a Security and Identity Service and used to simplify the integration of distributed or federated Web services within an enterprise and its service providers.
Note:
Security Token Service is primarily based on the OASIS WS-Trust protocol but it also delegates the processing of other WS-* protocols present in the SOAP message.Security Token Service brokers trust between a Web Service Consumer (WSC) and a Web Service Provider (WSP) and provides security token lifecycle management services to both. It allows for the use of various federation protocols like SAML, WS-Federation, Liberty, or OpenID.The Oracle Access Management Security Token Service (Security Token Service) is deployed with Access Manager and must be activated as a service.
34.2 Using the Security Token Service
Security Token Service is installed with Oracle Access Management 11g on Managed Servers. 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
Note:
Security Token Service adopts the same frameworks, guidelines, and practices for diagnostics, monitoring, auditing, and high availability used by Oracle Access Management 11g. For more information, see Part VIII, "Logging, Auditing, Reporting and Monitoring Performance".The Security Token Service 11g infrastructure is described in Table 34-1.
Table 34-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: "About 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. |
|
Certificates |
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:
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:
|
34.3 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.
Note:
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 34-2 identifies common Security Token Service terminology.
Table 34-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:
|
|
ActAs |
An
|
|
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. |
|
WS-Security |
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). |
|
WS-Trust |
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. |
|
WS-Policy |
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. |
|
Certificates |
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: |
|
Keystore |
Security Token Service key stores include:
See Also: Chapter 37, "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:
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:
|
|
Kerberos |
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:
The Kerberos Token profile of WS-Security allows business partners to use Kerberos tokens in service-oriented architectures (SOAs). |
34.4 Integrating the Oracle Web Services Manager
In the 11g release, Oracle Web Services Manager (WSM) security and management has been integrated into the Oracle WebLogic Server along with Oracle WSM Agent functionality. Table 34-3 describes the WSM components.
Table 34-3 Integrated Oracle Web Services Manager
| Component | Description |
|---|---|
|
Java Keystore (JKS) |
Required to store the signature and encryption keys required by the X.509 token on the client. JKS the proprietary keystore format defined by Sun Microsystems. Trusted certificates and public and private keys are stored in the keystore. To create and manage the keys and certificates in the JKS, use the keytool utility. Keys are used for a variety of purposes, including authentication and data integrity. If the client and Web service are in the same domain with access to the same keystore, they can share the same private/public key pair:
|
|
Policy Interceptors |
In Oracle Fusion Middleware 11g, Oracle WSM Agents are managed by the security and management policy interceptors. Policy Interceptors enforce policies, including reliable messaging, management, addressing, security, and Message Transmission Optimization Mechanism (MTOM). The Oracle WSM Agent manages the enforcement of policies using the Policy Interceptor Pipeline. For complete Oracle Web Services Manager details, including the differences between release 10g and 11g, see Oracle Fusion Middleware Security and Administrator's Guide for Web Services. |
|
Oracle WSM Agent |
The OWSM agent is the certified WS-Trust client that can be used to communicate with Security Token Service. The OWSM agent is embedded and used by Security Token Service for message protection only (to publish WS Policy and to enforce message protection on inbound and outbound WS messages). Security Token Service performs token validation/request authentication.
Note: Embedded means that the OWSM Agent is available as part of the JRF layer on the WebLogic Server that Security Token Service uses: |
|
Message/Token Protection |
Security Token Service/Access Manager manages its own keystore and trust store. For Oracle WSM to enforce message protection for Security Token Service, the OWSM key store is seeded with its own self-signed certificate; passwords for its corresponding keys are stored in CSF. It does not work with Security Token Service keystore. Note: Conversely, Oracle WSM requires Access Manager/Security Token Service to store keys related to message protection in the OPSS Keystore. For cases where the client uses schemes such as SKI, Thumbprint, and so on to refer to its certificate, Oracle WSM requires that client certificate(s) are present in the OPSS Keystore. |
|
Token Signing Key |
Security Token Service has strong security requirements around its token signing key and uses the token signing key to broker trust between a client and a relying party. Therefore, this key must be stored in an exclusive partition that only Security Token Service can access. |
|
Security Key Pairs |
Security Token Service creates separate key pairs for issued token security and message security to provide security of token signing keys and eliminate the need for Oracle WSM agents to work with Access Manager/Security Token Service keystore:
|
|
OPSS Keystore |
The message security key pair is populated to OPSS Keystore. For special cases where clients use referencing schemes such as SKI (not a certificate token being received as part of the Web service request), Security Token Service populates OPSS Keystore with the requesting party's certificates. This is an uncommon scenario. Security Token Service can provide instructions on manually provisioning the keys to OPSS keystore to make it work. |
34.5 Architecting the Security Token Service
Security Token Service is a centralized token service that supports WS-Trust protocol. It also defines extensions to the WS-Security specification for issuing and exchanging security tokens and establishing trust relationships. The Security Token Service is hosted as a web service endpoint and coordinates security based interactions between a WSC and a WSP. All communication with the Security Token Service occurs through a WS_Trust client, as shown in Figure 34-1.
Figure 34-1 Security Token Service Architecture
Description of "Figure 34-1 Security Token Service Architecture"
When a WSC makes a call to the WSP, it gets the WS-Security policy that will indicate that a security token issued by Security Token Service should be presented. The policy will contain the location of the Security Token Service, and the WSC will use that location to contact the Security Token Service to retrieve the token 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, check with the Security Token Service to determine its security mechanisms). 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.
34.6 Security Token Service Supported Token Matrix
Figure 34-2 documents the token support matrix for Security Token Service.
Figure 34-2 Security Token Service Token Support
Description of "Figure 34-2 Security Token Service Token Support"
34.7 Deploying Security Token Service
This section provides overviews of different deployment options:
34.7.1 Centralized Token Authority Deployment
The need for a token exchange for security integration between Web SSO and Web service security tiers is in demand in a deployment where a Web application makes internal or external Web service calls. An example of this is an intranet portal integration with an external Web service provided by a partner or another organization within the same company. The portal needs a way to securely access the service but the difficulty of security integration in this case stems from the fact that the Web SSO tier and WS tier use different methods of user authentication.
In the Web SSO environment, the Web application can accept WAC-issued session tokens (SMSESSION, OBSSO), SAML assertions or proprietary tokens to authenticate the users. The WS* security tier also uses a variety of standard and proprietary tokens and, in most cases, local translation of token is required to achieve integration between the two tiers. Additionally, the WS performing the translation must contact the authority by which the token was issued (Oracle Adaptive Access Manager) to decompose the token before it can be translated. Decomposition requires every WS service to maintain trust with WAC systems; this is complex and not very secure because of multiple trust links that need to be maintained. With the introduction of Security Token Service, the translation of tokens can be done at the centralized authority as illustrated in Figure 34-3.
Figure 34-3 Token Translation at a Centralized Authority
Description of "Figure 34-3 Token Translation at a Centralized Authority"
34.7.2 Tokens Behind a Firewall Deployment
The situation when applications rely on special form of credentials for their business logic is very common in deployments of Oracle access products. Integrations of WAC systems with both Oracle and custom applications almost always require extensive coding for:
-
Decomposing tokens issued by one token authority (such as OAM or SiteMinder) by calling a proprietary vendor API (SM agent API or ASDK).
-
Composing a new token format (PSFT, Siebel), that the application requires for its internal business logic.
Although such translations are often handled through application coding, it introduces the risk of exposing user names and passwords when the code is deployed on multiple application instances in the DMZ. Thus, Security Administrators need an ability to control the translation process by externalizing it from the application. Introducing the Security Token Service provides significant relief in this situation. Security Token Service plays the role of a centralized token authority, performing token translation behind the firewall, as shown in Figure 34-4.
Figure 34-4 Translating Tokens Behind a Firewall
Description of "Figure 34-4 Translating Tokens Behind a Firewall"
Application 1 and Application 2 are protected by Access Manager. Application 2 relies on a different type of token for its internal business logic. It has a client-side connector that contacts Security Token Service for exchanging the OBSSO token for a username token. The Security Token Service relies on Access Manager for decomposing the OBSSO token and generates the new token required by Application 2. This is more secure, because the same authority (Access Manager) performs both operations (composing and decomposing the OBSSO token) thus, there is no need to decompose the token on the application side.
34.7.3 Web Services SSO Deployment
As in the Web SSO case, Web services SSO is a convenience feature. The difference is that in the case of Web SSO the party who benefits from the feature is a user; in the WS SSO environment, the Security Administrator benefits.
With Web services SSO different Web services have different token requirements (that change often). Externalizing the exchange to Security Token Service enables the application to simply supply the target and the current token in its possession. Security Token Service takes charge of determining the token type for each requested service. When one or more Web services change their authentication requirements, Security Token Service can seamlessly verify the token type submitted by the application. If the token is not of the requested type, the old token is revoked and the new one of the correct type is issued. Figure 34-5 illustrates Web services SSO.
34.8 Installing Security Token Service
This section provides an overview of the installation options:
34.8.1 Security Token Service Cluster in Single WLS Domain
This installation option leverages clustering across Security Token Service instances deployed in different managed servers within a single WebLogic domain. This deployment topology facilitates High Availability capabilities through a load balancer. By default, Access Manager co-exists on the same managed server as Security Token Service. However, Security Token Service is disabled by default and must be manually enabled before it can be used. This deployment topology supports:
-
Deploying multiple instances of Security Token Service through the suite installer.
-
Deploying a load balancer to support the High Availability and failover scenarios on the front of the Security Token Service cluster.
For more information, see the Oracle Fusion Middleware High Availability Guide.
34.8.2 Endpoint Exposure through a Web Server Proxy
This installation option provides inter-operability of Requester and Relying Party with Third-party STS Servers. At runtime, Security Token Service supports interoperability with Requesters and Relying Parties of third-party security token servers using the OPSS WS-Trust-Provider. For instance, a third-party Security Token Service can create a valid SAML Assertion that can be consumed by Security Token Service.
34.8.3 Interoperability of Requester and Relying Party with Other Oracle WS-Trust based Clients
All run-time scenarios for Requesters and Relying Parties are supported by other Oracle WS-Trust Clients, including WLSClient, MetroClient, and Oracle Web Services Manager (Oracle WSM). All Web services clients are supported with Security Token Service only through the WS-Trust binding.
34.8.4 Security Token Service Installation Overview
Access Manager and Security Token Service are installed together from a single EAR file and deployed on the same managed server in a WebLogic domain. The Oracle WSM Agent uses a keystore for various cryptographic operations. For those tasks, the Oracle WSM Agent uses the keystore configured for Oracle WSM tasks. During installation, if the Oracle WSM keystore service has not been configured, the installer:
-
Creates a new keystore in the $DOMAIN_HOME/config/fmwconfig folder (default name is default-keystore.jks
-
Creates a key entry with the corresponding certificate to be used by OWSM for signature and encryption operations. This key entry is stored in the OWSM Keystore under the
orakeyalias -
Stores the passwords of the key entry and of the keystore in CSF
Having access to the keystore is sometimes required to:
-
Extract the signing or encryption certificate to distribute to clients, if needed
-
Update or replace the signing or encryption key entry
-
Add trusted certificates
For more information, see the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
34.8.5 Post-Installation Tasks: Security Token Service
Any server hosting Security Token Service must be registered with Access Manager. This can occur automatically during installation, or manually after installation.
All Security Token Service system configuration is done using the Oracle Access Management Console. Elements in the Oracle Access Management Console enable Administrators to easily configure the Security Token Service to exchange WS Trust tokens with partners. Other Security Token Service elements provide for creation, viewing, modification, and removal of partners, endpoints, validation templates, issuance templates, and data store connections.
For more details on the Security Token Service, see Part VIII, "Managing Oracle Access Management Security Token Service".
34.9 Administrating the Security Token Service
During initial deployment, using the Oracle Fusion Middleware Configuration Wizard, the Administrator userID and password are set. Administrators can log in and use the Oracle Access Management Console (and WebLogic Server Administration Console). A single LDAP group, the WebLogic Server "Administrators" group, is set by default. For more information, see Chapter 2, "Getting Started with Oracle Access Management".