Introduction to OAM 11g Oracle Access Manager components and services

Introduction to OAM 11g and OAM Architecture, Components, Services

1 Oracle Product Introduction

This chapter provides a high-level overview of Oracle Access Manager 11g and Oracle Security Token Service with links to more information. This chapter contains the following sections:

• Introduction to Oracle Access Manager
• Introduction to Oracle Security Token Service

Introduction to Oracle Access Manager

Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration; auditing, and more.
Single sign-on (SSO) enables users, and groups of users, to access multiple applications after authentication. SSO eliminates multiple sign-on requests. Oracle Access Manager 11g is the Oracle Fusion Middleware 11g single sign-on solution. Oracle Access Manager 11g operates independently as described in this book and also operates with the Oracle Access Manager Authentication Provider as described in the Oracle Fusion Middleware Application Security Guide
Oracle Access Manager 11g is a Java Platform, Enterprise Edition (Java EE)-based enterprise-level security application that provides restricted access to confidential information and centralized authentication and authorization services. All existing access technologies in the Oracle Identity Management stack converge in Oracle Access Manager 11g.
A Web server, Application Server, or any third-party application must be protected by a Webgate or mod_osso instance that is registered with Oracle Access Manager as an agent. To enforce policies, the agent acts as a filter for HTTP requests. Oracle Access Manager enables administrators to define authentication and authorization policies.

Note:

Webgates are agents provided for various Web servers by Oracle as part of the product. Custom access clients, created using the Access Manager SDK, can be used with non-Web applications. Unless explicitly stated, information in this book applies equally to both.

You can also integrate with OAM 11g, any Web applications currently using Oracle ADF Security and the OPSS SSO Framework, as described in Appendix C.
The remainder of this section provides the following topics:

• Introduction to Oracle Access Manager Architecture
• Introduction to Oracle Access Manager Deployment Types and Installation
• Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g

There are several important differences between Oracle Access Manager 11g and Oracle Access Manager 10g,, and OSSO 10g, as described in "Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g".

Introduction to Oracle Access Manager Architecture

This topic provides an overview of Oracle Access Manager 11g, which sits on Oracle WebLogic Servers and is part of the Oracle Fusion Middleware Access Management architecture.
While providing backward compatibility and co-existence with existing solutions, Oracle Access Manager 11g replaces and converges the following earlier technologies:

• Oracle Access Manager 10g
• Oracle Application Server SSO (OSSO) 10g

Figure 1-1 illustrates the primary Oracle Access Manager 11g components and services. The Protocol Compatibility Framework interfaces with OAM Webgates, mod_osso agents, and custom Access Clients created using the Access Manager Software Developer Kit (SDK).

Figure 1-1 Oracle Access Manager 11g Components and Services

Description of "Figure 1-1 Oracle Access Manager 11g Components and Services"

Figure 1-2 illustrates the distribution of Oracle Access Manager components.

Figure 1-2 Oracle Access Manager 11g Component Distribution

Description of "Figure 1-2 Oracle Access Manager 11g Component Distribution"

The Oracle Access Manager Console resides on the Oracle WebLogic Administration Server (known as AdminServer). WebLogic Managed Servers hosting OAM runtime instances are known as OAM Servers.
Shared information consists of:

• Agent and server configuration data
• Oracle Access Manager policies
• User session data is shared among all OAM Servers

Introduction to Oracle Access Manager Deployment Types and Installation

This section provides a brief overview of OAM deployments and installation:

• About Deployment Types and OAM
• About Oracle Access Management Post-Installation Tasks

About Deployment Types and OAM

Table 1-1 describes the types of deployments you might have within your enterprise, even though these might be named differently in your enterprise.

Table 1-1 Deployment Types

Deployment Type	Description
Development Deployment	Ideally a sandbox-type setting where the dependency on the overall deployment is minimal
QA Deployment	Typically a smaller shared deployment used for testing
Pre-production Deployment	Typically a shared deployment used for testing with a wider audience
Production Deployment	Fully shared and available within the enterprise on a daily basis

During initial installation and configuration you can create a new WebLogic Server domain (or extend an existing domain) and define information for OAM Servers, Database Schemas, optional WebLogic Managed Servers and clusters, and the embedded LDAP Server.

See Also:

The "Understanding Oracle WebLogic Server Domains" chapter in the Oracle Fusion Middleware Understanding Domain Configuration for Oracle WebLogic Server guide provides information about Oracle WebLogic Server administration domains.

Regardless of the deployment size or type, in a new WebLogic Server domain the following OAM-related components are deployed using the Oracle Fusion Middleware Configuration Wizard:

• WebLogic Administration Server
• Oracle Access Manager Console deployed on the WebLogic Administration Server
• A WebLogic Managed Server for Oracle Access Management
• Application deployed on the Managed Server

Note:

In an existing WebLogic Server domain, the WebLogic Administration Server is already installed and operational.

While using the Oracle Fusion Middleware Configuration Wizard, the with-DB config template was chosen to set up the database for application domain metadata. The database must be extended with the OAM-specific schema using the Repository Creation Utility (RCU). The policy store bootstrap occurs on the initial AdminServer startup after running the Configuration Wizard. For more information, see the Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
The default Embedded LDAP is set as the primary user identity store for OAM 11g.
A Java keystore is set up to be used for certificates for Simple or Certificate-based communication between OAM Servers and Webgates during authorization. The keystore bootstrap also occurs on the initial AdminServer startup after running the Configuration Wizard.

About Oracle Access Management Post-Installation Tasks

During initial deployment, the WebLogic Administrator userID and password are set for use when signing in to both the Oracle Access Manager Console and WebLogic Server Administration Console. A different administrator can be assigned for Oracle Access Management (Oracle Access Manager and Oracle Security Token Service, as described in "Introduction to Administrators".
Oracle Access Management administrators can log in and use the Oracle Access Manager Console to manage:

• User identity stores
• OAM Server registration
• Partner (agent and partner application) registration
• Application domains and policies to protect resources
• User sessions
• Common Server Properties
• Oracle Security Token Service Settings and configuration as introduced in "Introduction to Oracle Security Token Service".

About Installation versus Upgrading

The Oracle Fusion Middleware Supported System Configurations document provides certification information on supported installation types, platforms, operating systems, databases, JDKs, and third-party products related to Oracle Identity Management 11g. You can access the Oracle Fusion Middleware Supported System Configurations document by searching the Oracle Technology Network (OTN) Web site:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

Following installation, you can configure Oracle Access Manager in a new WebLogic Server domain or in an existing WebLogic Server domain. Using the Oracle Fusion Middleware Configuration Wizard, the following components are deployed for a new domain:

• WebLogic Administration Server
• Oracle Access Manager Console deployed on the WebLogic Administration Server (sometimes referred to as the OAM Administration Server, or simply AdminServer)
• A Managed Server for Oracle Access Manager
• An application deployed on the Managed Server

See Also:

• Patching Oracle Identity and Access Management 11.1.1.3.0 to 11.1.1.5.0 in the Oracle Fusion Middleware Patching Guide
• Oracle Fusion Middleware Installation Guide for Oracle Identity Management

OracleAS 10g SSO deployments can be upgraded to use Oracle Access Manager 11g SSO. After upgrading and provisioning OSSO Agents with OAM 11g, authentication is based on OAM 11g Authentication Policies. However, only OAM Agents (Webgates/Access Clients) use OAM 11g Authorization Policies. Over time, all mod_osso agents in the upgraded environment should be replaced with Webgates to enable use of OAM 11g Authorization policies.
For details about co-existence after the upgrade, see:

• Oracle Fusion Middleware Upgrade Planning Guide
• Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management (E10129-02)
• Appendix A, "Co-existence Overview: OAM 11g and OSSO 10g"

Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g

This section provides the following topics:

• Enhancements in Oracle Access Manager 11g
• Oracle Access Manager 10g Functionality Not Available with 11g
• Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g

Enhancements in Oracle Access Manager 11g

Oracle Access Manager 11g includes several important enhancements that were not available with Oracle Access Manager 10g. Enhancements are listed in Table 1-2.

See Also:

"What's New"

Table 1-2 Enhancements in Oracle Access Manager 11g

New Functionality for Oracle Access Manager 11g
Platform Support: Oracle WebLogic Server Application Server platform and server portability is available for any platform that runs the supported Oracle WebLogic Server. Installation: Simplified Oracle Access Manager installation using the Oracle Universal Installer and initial deployment using the WebLogic Configuration Wizard is described in the Oracle Fusion Middleware Installation Guide for Oracle Identity Management. Backward Compatibility: Support for mixed-release agents: Register and use Oracle Access Manager 10g agents (Webgates and Access Clients) and OracleAS 10g SSO agents (mod_osso) for SSO s provided. See Chapter 9, Chapter 10. Upgrading and Co-existence: Utilities to upgrade existing OSSO deployments are provided is described in Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management. Co-existence after upgrading OSSO is introduced in Appendix A.
Built-in support for OracleAS 10g SSO partner applications, and for single sign-on across OSSO 10g-protected applications and OAM 10g Webgate protected applications. See Part IV. Per-agent-based shared secret key increases security and performance by moving cookie encryption and description to the agent. See Chapter 9 and Chapter 11.
Embedded LDAP for user and group information is described in Chapter 5. Integration with Oracle Entitlement Server MicroSM to enable database storage of policies. See Chapter 5.
Usability and lifecycle improvements as described through out this guide Rich and intuitive graphical user interface is shown throughout this guide
A new OAM 11g Access Tester replaces the OAM 10g Access Tester for on-the-fly evaluation of Oracle Access Manager policies. See Chapter 14.
Session Management functions are provided, as described in Chapter 7: Webgate maximum user session timeout is now supported by Webgate through the host cookie See Table 1-4, "Comparison: OAM 11g versus OAM 10g versus OSSO 10g". Webgate idle session timeout is now supported using in-memory states through the Oracle Coherence-based Session Management Engine.
Events can be audited using the underlying Oracle Fusion Middleware Common Audit Framework, as described in Chapter 24.
Windows Native Authentication is supported with applications protected with either an OSSO Agent or OAM Agent. For more information, see Oracle Fusion Middleware Integration Guide for Oracle Access Manager.
Extensibility framework required for building custom authentication plug-ins. For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Access Manager and Oracle Security Token Service.
Complex policy constructs (AND, OR semantics for multiple rules)
Impersonation support

See Also:

"Oracle Access Manager 10g Functionality Not Available with 11g"

Oracle Access Manager 10g Functionality Not Available with 11g

Oracle Access Manager 10g provides several functions that are not included with Oracle Access Manager 11g. Table 1-3 provides an overview.

Table 1-3 OAM 10g Functionality Not Available with Oracle Access Manager 11g

Unavailable or Unsupported Functions
Extensibility framework required for building custom authorization plug-ins.
Application-domain-level delegated administration
LDAP filter-based authorization and response calculations
Authorization for mod_osso-protected resources
Identity Server, WebPass, Identity System Console, User Manager, Group Manager, Organization Manager. Replaced by Oracle Fusion Middleware Identity Manager.

Comparing Oracle Access Manager 11g, 10g, and OracleAS SSO 10g

This topic provides a comparison against the 10g architecture for Oracle Access Manager and OSSO. Included are the following topics:
Oracle Access Manager 11g differs from Oracle Access Manager 10g in that the identity administration features have been transferred to Oracle Identity Manager 11g (including user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration).
Oracle Access Manager 10g supported Single Sign-on using a single session cookie (the ObSSOCookie) that contained the user identity and user session information required to access target resources that had the same or lower authentication level. The ObSSOCookie was encrypted and decrypted using a global shared secret key, the value of which was stored in the directory server. The ObSSOCookie was consumed by Access System components to verify the user identity and allow or disallow access to protected resources.
To close any possible security gaps, Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with existing Oracle Access Manager 10g policy-enforcement agents (Webgates) and OSSO 10g agents (mod_osso). New Oracle Access Manager 11g Webgates are enhanced versions of 10g Webgates, that support a per-agent secret key for the Single Sign-on (SSO) solution. Thus, cookie-replay type of attack are prevented. The 11g Webgates are all trusted at the same level; a cookie specific for the Webgate is set and cannot be used to access any other Webgate-protected applications on a user's behalf.
Unless explicitly stated, the term "Webgate" refers to both an out of the box Webgate or a custom Access Client.
Oracle Access Manager 11g uses technology from Oracle Coherence to provide centralized, distributed, and reliable session management.
Table 1-4 provides a comparison of Oracle Access Manager 11g, OAM 10g, and OracleAS SSO 10g. For a list of names that have changed with Oracle Access Manager 11g, see "Product and Component Name Changes".

Table 1-4 Comparison: OAM 11g versus OAM 10g versus OSSO 10g

	OAM 11g	OAM 10g	OSSO 10g
Architecture Components	Agents: Webgate, Access Client, mod_osso, and IAMSuiteAgent OAM Server Oracle Access Manager Console (installed on WebLogic Administration Server) Note: Eight Administrator languages are supported.	Resource Webgate (RWG) Authentication Webgate (AWG) AccessGate Access Server Policy Manager Note: Eight Administrator languages are supported.	mod_osso (partner) OracleAS SSO server (OSSO server)
Cookies	Host-based authentication cookie: 11g Webgate, One per agent: OAMAuthnCookie__ set by Webgate using the authentication token received from the OAM Server after successful authentication. Note: A valid OAMAuthnCookie is required for a session. 10g Webgate, One ObSSOCookie for all 10g Webgates. One for the OAM Server: OAM_ID	Domain-based ObSSOCookie for Webgates (including the AWG), for both authentication and session management	Host-based authentication cookie: one per partner: OHS-host-port one for OSSO server: (but not with OAM 11g) Domain-level session cookie for global inactivity timeout (GITO) if enabled (for inter-operability with OAM 11g)
Cryptographic keys The protocols used to secure information exchange on the Internet.	One per agent secret key shared between Webgate and OAM Server One OAM Server key	One global shared secret key for all Webgates	One key per partner shared between mod_osso and OSSO server OSSO server's own key One global key per OSSO setup for the GITO domain cookie
Key storage	Agent side: A per agent key is stored locally in the Oracle Secret Store OAM 11g server side: A per agent key, and server key, are stored in the credential store on the server side	Global shared secret stored in the directory server only (not accessible to Webgate)	mod_osso side: partner keys and GITO global key stored locally in obfuscated configuration file OSSO server side: partner keys, GITO global key, and server key are all stored in the directory server
Encryption / Decryption (The process of converting encrypted data back into its original form)	Introduces client-side cryptography and ensures that cryptography is performed at both the agent and server ends: Webgate encrypts obrareq.cgi using the agent key. Note: obrareq.cgi is the authentication request in the form of a query string redirected from Webgate to OAM Server. OAM Server decrypts the request, authenticates, creates the session, and sets the server cookie. OAM Server also generates the authentication token for the agent (encrypted using the agent key), packs it in obrar.cgi with a session token (if using cookie-based session management), authentication token and other parameters, then encrypts obrar.cgi using the agent key. Note: obrar.cgi is the authentication response string redirected from the OAM 11g server to Webgate. Webgate decrypts obrar.cgi, extracts the authentication token, and sets a host-based cookie.	Token generation/ encryption, and validation/ decryption are delegated to the Access Server. Both obrareq.cgi and obrar.cgi are sent unencrypted, relying on the underlying HTTP(S) transport for security.	Cryptography is performed at both mod_osso and OSSO server: site2pstore token (request from mod_osso to server) is encrypted using the partner key locally at mod_osso. OSSO server decrypts site2pstore token, authenticates, and generates its own cookie. urlc token (the response from OSSO server to mod_osso) is encrypted using the partner key at the server. mod_osso decrypts the urlc token locally and re-encrypts using its own format to set in a host-based cookie.
Session Management	OAM 10g session idle timeout behavior is supported through the 11g Session Management Engine (SME). Session states are retained in memory	Single domain supported. Multi-domain: If a user idles out on one domain, but not on the authentication Webgate, the AWG cookie is still valid, re-authentication is not needed.A new cookie is generated with the refreshed timeout.	Single domain supported through a domain-level cookie for global inactivity timeout (GITO). Multi-domain SSO: After a user logs in to one domain, and then goes to a different domain, he is considered idle from the first domain, When the idle times out on the original domain, the user must re-authenticate on the original domain.
Client IP	Maintain this ClientIP, and include it in the host- based OAMAuthnCookie.	Include the original clientIP inside the ObSSOCookie. If IP validation is configured, when cookie presented in later authentication or authorization requests this original clientIP is compared with the presenter's IP. Rejection occurs if there is no match	Include the original clientIP inside the host cookie. In later authentication requests, when the cookie is presented, the original clientIP is compared with the presenter's IP. Rejection occurs if there is no match
Response token replay prevention	Include RequestTime (the timestamp just before redirect) in obrareq.cgi and copy it to obrar.cgi to prevent response token replay.	N/A	Include RequestTime (timestamp just before redirect) in the site2pstore token and copy it to the urlc token to prevent token replay.
Centralized log-out	The logOutUrls (OAM 10g Webgate configuration parameter) is preserved. New 11g Webgate parameters are provided: logoutRedirectUrl logoutCallbackUrl Logout Target URL For more information, see Chapter 15.	Single domain is supported. Once a user logs off from one Webgate, the domain cookie is cleared and the user is considered to be logged off the entire domain. Multi-domain SSO can be supported through chained customized logout pages.	The OSSO server cookie includes a list of partner IDs. When a user logs off from one partner application: OSSO server pulls a list of the logout URLs. OSSO server clears its own cookie. OSSO server redirects to a customized JSP page (hosted on the OSSO server), and passes the list of logout URLs in the request. The JSP page loads those logout URLs that contains some image tags of check marks, and as a result of the loading, the cookies for those mod_osso instances are cleared

Introduction to Oracle Security Token Service

Oracle Security Token Service is deployed with Oracle Access Manager and must be activated as a service.

See Also:

• Patching Oracle Identity and Access Management 11.1.1.3.0 to 11.1.1.5.0 in the Oracle Fusion Middleware Patching Guide
• "Enabling and Disabling Oracle Security Token Service"
• Part V, "Oracle Security Token Service"

Oracle Security Token Service provides the foundation to the current security infrastructure to facilitate a consistent and streamlined model for token acquisition, renewal, and cancellation that is protocol and security infrastructure agnostic.
Oracle 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. Oracle Security Token Service can be deployed as a Security and Identity Service needed to simplify the integration of distributed or federated Web services within an enterprise and its service providers.
Oracle Security Token Service is primarily based on the OASIS WS-Trust protocol. However, Oracle Security Token Service delegates the processing of other WS-* protocols present in the SOAP message.
Oracle 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 providers and consumers. Oracle Security Token Service can help simplify the effort needed to bridge access to various systems using a standardized set of interfaces.
Oracle Security Token Service (Oracle STS) augments Oracle Identity Federation (OIF), which facilitates Federated Single Sign-on (SSO) and Single Logout (SLO) for users coming through a Web browser to access resources across different security domains or across administrative boundaries through various federation protocols like SAML, WS-Federation, Liberty, or OpenID.
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 (STS). To provide interoperable security tokens, the STS 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 to facilitate SSO and application session management for Web applications. Additional tokens include Kerberos (primarily for Windows Native Authentication), Security Assertion Markup Language (SAML) assertions, and even digital certificates.
For more information, see the following topics:

• Oracle Security Token Service Key Terms and Concepts
• About Oracle Security Token Service with Oracle Access Manager
• About Integrated Oracle Web Services Manager
• About Oracle Security Token Service Architecture
• About Oracle Security Token Service Deployments
• About Oracle Security Token Service Administration

Oracle Security Token Service Key Terms and Concepts

Table 1-5 identifies common Oracle Security Token Service terminology.

Table 1-5 Oracle 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). Oracle 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 Oracle 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.
ActAs	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 Oracle 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 Oracle Security Token Service are self signed. The subject and the issuer field are identical. Out of the box, the OAM Server hosting Oracle Security Token Service is uniquely identified:
Keystore	Oracle Security Token Service key stores include: System Keystore Trust Keystore Partner Keystore See Also: Chapter 18, "Managing Oracle 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.
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: 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).

About Oracle Security Token Service with Oracle Access Manager

Oracle Security Token Service is compliant and co-exists with Oracle Access Manager (using Oracle Access Manager as the primary authenticator for Web clients requesting tokens).
Oracle Security Token Service is installed with Oracle Access Manager 11g on Managed Servers. Each Managed Server must be registered with Oracle Access Manager to open communication channels. All Oracle Security Token Service system configuration is done using the Oracle Access Manager Console. Oracle Security Token Service inter-operates with third party security token servers.
Oracle Security Token Service uses Oracle Web Services Manager Agents. Webgate is used as an Agent for identity propagation. The Webgate must be registered with Oracle Access Manager 11g to open a communication channel.
Oracle Security Token Service leverages the common infrastructure for shared services and the Oracle Access Manager 11g administration model. In addition, Oracle Security Token Service is integrated with the Oracle Access Manager Console to provide a unified and consistent administration experience.
Oracle Security Token Service adopts the same frameworks, guidelines, and practices for diagnostics, monitoring, auditing, and high availability used by Oracle Access Manager 11g. For more information, see Part VI, "Common Logging, Auditing, Performance Monitoring".
Oracle Security Token Service processing:

• Integrates with STS Audit events
• Publishes, in the Oracle Access Manager Console and WLST scripts, available Oracle Security Token Service methods to manage partner data
• Performs validation operations specific to the Oracle Security Token Service use cases and configuration model

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

Table 1-6 Oracle Security Token Service 11g Infrastructure

Component	Description
Default Trust Keystore	Oracle Security Token Service private keys used for Signing/Encryption are stored in the common keystore used with Oracle Access Manager. Oracle Security Token Service and Oracle 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 Oracle Security Token Service configuration stores the OCSP/CDP settings. The token security key pair is populated to Oracle Access Manager/Oracle Security Token Service keystore. Note: When the Oracle WSM Agent is used as the WS_Trust client in the OSTS deployment, Oracle strongly recommends that the Oracle WSM Agent keystore and the OSTS/OAM keystore always be different. Do not merge the two. Otherwise, OAM/OSTS keys could be available to any modules authorized by OPSS to access the keystore and OAM keys might be accessed. See Also: "About Oracle Security Token Service Keystores".
Default User Identity Store	Oracle 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 Manager Console. Oracle Security Token Service maps the incoming token to user records and attributes in the default User Identity Store, which operates with both Oracle Access Manager and Oracle Security Token Service. See Also: "About Setting the Default Store and System Store".
Certificates	The certificates used by Oracle Security Token Service are self signed. The subject and the issuer field are identical. Out of the box, the OAM Server hosting Oracle Security Token Service is uniquely identified: The keys and certificates used in Oracle 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 Oracle Security Token Service, as well as the keys/certificates used by the OWSM Agent protecting OSTS. The OWSM Agent is the certified WS-Trust client that can be used to communicate with OSTS. 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	Oracle Security Token Service integrates with the Oracle Coherence module to store and share run time WS-Trust data across all the physical instances of Oracle Security Token Service. The UserNameToken Nonce are stored in the Coherence store. This implementation supports the following requirements, which might be specific to Oracle Security Token Service: Cleanup of timed out records Existence of the records limited to several minutes (< 30)

About Integrated 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 1-7 describes these components.

See Also:

"About Oracle Access Manager Security Keys and the Embedded Java Keystore"

Table 1-7 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: The client can use the private key orakey to endorse the signature of the request message and the public key orakey to encrypt the symmetric key. The Web service in turn uses the public key orakey to verify the endorsement, and the private key orakey to decrypt the symmetric key.
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 OSTS. The OWSM agent is embedded and used by Oracle Security Token Service for message protection only (to publish WS Policy and to enforce message protection on inbound and outbound WS messages). Oracle Security Token Service performs token validation/request authentication. Oracle Security Token Service embedded Oracle WSM Agent is used in the mode of "Message Protection Only" with authentication functionality disabled. This way all aspects related to authentication of incoming token are performed by Oracle Security Token Service only. Oracle WSM supports disabling of authentication using configuration overrides that Oracle Security Token Service must declare with each policy. Exception: The Kerberos token is handled by Oracle WSM and Oracle Security Token Service is involved in mapping only the identity. The OWSM Agent is one of the certified WS-Trust clients that can be used to communicate with OSTS. Other 3rd party WS-Trust clients can be used to interact with OSTS. Note: Embedded means that the OWSM Agent is available as part of the JRF layer on the WebLogic Server that OSTS uses:
Message/Token Protection	Oracle Security Token Service/Oracle Access Manager manages its own keystore and trust store. For Oracle WSM to enforce message protection for Oracle 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 OSTS keystore. Note: Conversely, Oracle WSM requires Oracle Access Manager/Oracle 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	Oracle 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 Oracle Security Token Service can access.
Security Key Pairs	Oracle 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 Oracle Access Manager/Oracle Security Token Service keystore: The message security key pair is populated to OPSS Keystore The token security key pair is populated to Oracle Access Manager/Oracle 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), Oracle Security Token Service populates OPSS Keystore with the requesting party's certificates. This is an uncommon scenario. Oracle Security Token Service can provide instructions on manually provisioning the keys to OPSS keystore to make it work.

About Oracle Security Token Service Architecture

Oracle STS, is a centralized token service that supports WS-Trust protocol, which defines extensions to the WS-Security specification for issuing and exchanging security tokens and establishing trust relationships. The Oracle STS is hosted as a web service endpoint and coordinates security based interactions between a WSC and a WSP. All communication with the Oracle STS occurs through a WS_Trust client, as shown in Figure 1-3.

Figure 1-3 Oracle STS Architecture

Description of "Figure 1-3 Oracle STS 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 Oracle STS should be presented. The policy will contain the location of Oracle STS, and the WSC will use that location to contact Oracle STS, and get 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, could 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.
Figure 1-4 shows the token support matrix for Oracle STS.

Figure 1-4 Oracle STS Token Support

Description of "Figure 1-4 Oracle STS Token Support"

About Oracle Security Token Service Deployments

This section provides the following topics to introduce several different deployment options:

• Centralized Token Authority Deployment
• Tokens Behind a Firewall Deployment
• Web Services SSO Deployment

See Also:

"Scenario: Identity Propagation with the OAM Token"

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 such application is an intranet portal integration with external Web service provided by a partner or another organization within the same company. The portal needs a way to securely access the service.
The difficulty of security integration in this case stems from the fact that 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 tokes, standard and proprietary, and in most cases to achieve integration between the two tiers, local translation of token is required. In most cases, the WS performing the translation, needs to contact the authority by which the token was issued (Oracle Adaptive Access Manager) in order to decompose the token, before it can be translated. That 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 Oracle Security Token Service, the translation of tokens can be done at the centralized authority, as shown in Figure 1-5.

Figure 1-5 Token Translation at a Centralized Authority

Description of "Figure 1-5 Token Translation at a Centralized Authority"

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 (1) decomposing token issued by one token authority (such as OAM or SiteMinder) by calling a proprietary vendor API (SM agent API or ASDK) and (2) composing a new token format (PSFT, Siebel), that the application requires for its internal business logic.
Such translations are often handled through application coding, which introduces an element of risk of exposing user names and passwords when the code is deployed on multiple application instances in the DMZ.
Security administrators need an ability to control the translation process by externalizing it from the application. Introduction of Oracle Security Token Service provides significant relieve in this situation. Oracle Security Token Service plays a role of a centralized token authority, performing a translation of tokens behind the firewall, as shown in Figure 1-6.

Figure 1-6 Translating Tokens Behind a Firewall

Description of "Figure 1-6 Translating Tokens Behind a Firewall"

Application 1 and Application 2 are protected by Oracle Access Manager. The Application 2 relies on a different type of token for its internal business logic. It has a client-side connector that contacts Oracle Security Token Service for exchanging the OBSSO token for a username token. The Oracle Security Token Service relies on Oracle Access Manager for decomposing the OBSSO token and generates a new token, required by Application 2.
This is more secure, because the same authority (Oracle Access Manager) performs both operations (composing and decomposing the OBSSO token). There is no need to decompose the token on the application side.

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 environment:

• Web SSO: The user benefits
• Web Services SSO: Security administrators benefit.

With Web services SSO different Web services have different token requirements, which change often. Externalizing the exchange to Oracle Security Token Service, however, enables the application to simply supply the target and the current token in its possession. Oracle Security Token Service takes charge of determining the token type for each requested service.
When one or more Web services change their authentication requirements, Oracle 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 1-7 illustrates Web services SSO.

Figure 1-7 Web Services SSO

Description of "Figure 1-7 Web Services SSO"

About Installation Options

This section provides the following topics as a brief overview to various installation options:

• Oracle Security Token Service Cluster in Single WLS Domain
• Endpoint Exposure through a Web Server Proxy
• Oracle Security Token Service Installation Overview
• Post-Installation Tasks: Oracle Security Token Service

Oracle Security Token Service Cluster in Single WLS Domain

You can leverage clustering across Oracle 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, Oracle Access Manager co-exists on the same managed server as Oracle Security Token Service. However, Oracle Security Token Service is disabled by default and must be manually enabled before it can be used.
This deployment topology means that you:

• Deploy multiple instances of Oracle Security Token Service through the suite installer.
• Deploy a load balancer to support the High Availability and failover scenarios on the front of the Oracle Security Token Service cluster.

For more information, see the Oracle Fusion Middleware High Availability Guide.

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, Oracle 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 Oracle Security Token Service.

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 Oracle Security Token Service only through the WS-Trust binding.

Oracle Security Token Service Installation Overview

Oracle Access Manager and Oracle Security Token Service are installed together from a single ear file. Oracle Access Manager and Oracle Security Token Service are 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 orakey alias
• 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 Management.

Post-Installation Tasks: Oracle Security Token Service

Any server hosting Oracle Access Manager with Oracle Security Token Service must be registered with Oracle Access Manager. This can occur automatically during installation, or manually after installation.
Elements in the Oracle Access Manager Console enable administrators to easily configure the Token Service to exchange WS Trust tokens with partners. Token Service elements provide for creation, viewing, modification, and removal of partners, endpoints, validation templates, issuance templates, and data store connections.
All Oracle Security Token Service system configuration is done using the Oracle Access Manager Console. This includes the following previously covered topics:
Look for information through out this manual. Pay close attention to Oracle Security Token Service details in Part V, "Oracle Security Token Service".

About Oracle Security Token Service Administration

A single default LDAP group, the WebLogic Server "Administrators" group, is set by default.
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 Manager Console (and WebLogic Server Administration Console).
For more information, see Chapter 3, "Getting Started with Common Administration and Navigation".