1 Introduction to Oracle Access Management

This book provides information to help Administrators manage Access Manager components and policies within one or more WebLogic administration domains. This chapter provides a high-level overview of Oracle Access Management with links to more information.

This chapter contains the following sections:

• Introduction to Oracle Access Management

• Introduction to Oracle Access Management Access Manager

• Summarizing Oracle Access Management Access Manager 11.1.2

• Introduction to Oracle Access Management Security Token Service

• System Requirements and Certification

1.1 Introduction to Oracle Access Management

Oracle Access Management is a Java Platform, Enterprise Edition (Java EE)-based enterprise-level security application that provides a full range of Web-perimeter security functions and Web single sign-on services including identity context, authentication and authorization; policy administration; testing; logging; auditing; and more.

Oracle Access Management leverages shared platform services including session management, Identity Context, risk analytics, and auditing; it also provides restricted access to confidential information. Many existing access technologies in the Oracle Identity Management stack converge in Oracle Access Management, as shown in Figure 1-1.

Figure 1-1 Oracle Access Management Overview

Starting with release 11.1.2, Oracle Access Management includes the following services:

• Oracle Access Management Access Manager (Access Manager), as described in "Introduction to Oracle Access Management Access Manager"

• Oracle Access Management Security Token Service (Security Token Service): Provides token validation and generation to facilitate access to services across security domains and beyond organizational boundaries. Essentially the service acts as a trust-broker that receives and validates client requests and generates appropriate tokens for a requested resource. For details, see "Introduction to Oracle Access Management Security Token Service"

• Oracle Access Management Identity Federation (Identity Federation): Provides cross-domain single sign-on support using open federation protocol standards such as SAML and OpenID. Beginning with release 11.1.2, Identity Federation is no longer a standalone product, but is instead tightly integrated with Oracle Access Management out of the box. This new Oracle Access Management service includes a streamlined user interface and administration experience. For more information, see Part VII, "Managing Oracle Access Management Identity Federation".

• Oracle Access Management Mobile and Social (Mobile and Social): A new intermediary between a user seeking access to protected resources, and the back-end Identity and Access Management services that protect the resources. Mobile and Social extends security and compliance to mobile platforms and simplifies integration with Social Identity services including Facebook and Google.Mobile and Social RESTful enables Identity and Access Management infrastructure and includes platform-specific developer kits for leading mobile platforms that enables developers to easily access security services and enable single sign-on across native and mobile browser-based applications. For more information, see Part IX, "Managing Oracle Access Management Mobile and Social".

• Identity Context: Provides context-aware security policy management that enables Administrators to control the level of security imposed in an application delivery environment through security frameworks provided by Oracle Identity Management. For details, see Part X, "Using Identity Context".

OpenSSO 8.0 and Sun Access Manager 7.1 are also converged into Oracle Access Management 11.1.2. For details, see:

• Chapter 21, "Registering and Managing Legacy OpenSSO Agents"

• Oracle Fusion Middleware Update, Upgrade, and Migration Guide for Oracle Identity and Access Management

1.1.1 About Oracle Access Management Installation

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

Using the Oracle Fusion Middleware Configuration Wizard, the following components are deployed for a new domain:

• WebLogic Administration Server

• Oracle Access Management Console deployed on the WebLogic Administration Server (sometimes referred to as the OAM Administration Server, or simply AdminServer)

• A Managed Server for Oracle Access Management

• An application deployed on the Managed Server

See Also:

• Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management

OracleAS 10g SSO deployments can be upgraded to use Oracle Access Management 11g SSO. After upgrading and registering OSSO Agents, authentication is based on Access Manager 11g Authentication Policies. However, only OAM Agents (Webgates/Access Clients) use Access Manager 11g Authorization Policies. Over time, all mod_osso agents in the upgraded environment should be replaced with Webgates to enable use of 11g Authorization policies.

For details about co-existence after the upgrade, see Oracle Fusion Middleware Update, Upgrade, and Migration Guide for Oracle Identity and Access Management:

1.1.2 About Oracle Access Management Post-Installation Tasks

Each WebLogic Server domain is a logically related group of Oracle WebLogic Server resources. WebLogic administration domains include a special Oracle WebLogic Server instance called the Administration Server. Usually, the domain includes additional Oracle WebLogic Server instances called Managed Servers, where Web applications and Web Services are deployed.

During initial deployment, the WebLogic Administrator userID and password are set for use when signing in to both the Oracle Access Management and WebLogic Server Administration Console. A different Administrator can be assigned for Oracle Access Management, as described in "Introduction to Oracle Access Management Administrators".

Administrators can log in and use the Oracle Access Management Console for the following post-installation tasks:

Table 1-1 Oracle Access Management Post-Installation Tasks

Service	Requirements
Access Manager	Enable Access Manager Service. Register: Data Sources OAM Server instances Agents for Access Manager Application domains and policies that protect resources Configure: Common Settings, including Session-timing Certificate Validation Common Password Policy Configure Access Manager Settings.
Identity Federation	Enable Identity Federation Service Configure Federation Settings Register Identity Providers
Security Token Service	Enable Security Token Service Service. Configure Security Token Service Settings. Register Endpoints Create Token Issuance and Validation Templates Register Partner Profiles and Partners
Mobile and Social	Enable Mobile and Social Service Configure Mobile and Social Settings Configure Mobile Services Internet Identity Services

1.2 Introduction to Oracle Access Management Access Manager

This section introduces Oracle Access Management Access Manager (formerly the standalone product named Oracle Access Manager).

Access Manager single sign-on (SSO) enables users, and groups of users, to access multiple applications after authentication. SSO eliminates multiple sign-on requests. Access Manager provides the Oracle Fusion Middleware 11g single sign-on solution. Access Manager operates independently as described in this book and also operates with the Access Manager Authentication Provider as described in the Oracle Fusion Middleware Application Security Guide.

A Web server, Application Server, or any third-party application must be protected by a Webgate or mod_osso instance that is registered with Access Manager as an agent. To enforce policies, the agent acts as a filter for HTTP requests. 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 Access Manager any Web applications currently using Oracle ADF Security and the OPSS SSO Framework, as described in Appendix A.

The remainder of this section provides the following topics:

• Introduction to Access Manager Architecture

• Introduction to Access Manager Deployment Types

See Also:

Differences between Access Manager 11g versus 10g, versus OSSO 10g, and versus OpenSSO:

• "Comparing Access Manager 11.1.2 and 10g"

• "Comparing Access Manager 11g SSO versus OSSO 10g"

• "Introduction to OpenSSO, Agents, Migration and Co-existence"

1.2.1 Introduction to Access Manager Architecture

This topic provides an overview of 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, Access Manager 11g replaces and converges the following earlier technologies:

• Access Manager 10g

• Oracle Application Server SSO (OSSO) 10g

Figure 1-2 illustrates the primary 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-2 Access Manager 11g Components and Services

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

Figure 1-3 illustrates the distribution of Access Manager components.

Figure 1-3 Access Manager 11g Component Distribution

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

The Oracle Access Management 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

• Access Manager policies

• Session data is shared among all OAM Servers

1.2.2 Introduction to Access Manager Deployment Types

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

Table 1-2 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.

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.

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

• WebLogic Administration Server

• Oracle Access Management Console deployed on the WebLogic Administration Server

• A WebLogic Managed Server for Oracle Access Management services

• Application deployed on the Managed Server

Note:

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

Policy Store: The default policy store is file based for development and demonstration purposes, and is not supported in production environments. All policy operation and configurations are directly performed on the database configured as the policy store in production environments.

See Also:

"Managing the Policy and Session Database"

Identity Store: The default Embedded LDAP is set as the primary user identity store for Access Manager.

See Also:

"Managing User Identity Stores"

Keystore: 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.

See Also:

"Managing the Policy and Session Database"

1.3 Summarizing Oracle Access Management Access Manager 11.1.2

This section provides the following overviews:

• About Access Manager 11.1.2

• About Functionality Not Available with Access Manager 11g

1.3.1 About Access Manager 11.1.2

Table 1-3 provides an overview of Access Manager 11.1.2. For a list of names that have changed with 11.1.2, see "Product and Component Name Changes with 11.1.2".

Table 1-3 Introduction: Access Manager 11.1.2

Access Manager 11g	Description
Oracle Identity Management Infrastructure	Enables secure, central management of enterprise identities.
Policy Enforcement Agents	Resides with the relying parties and delegate authentication and authorization tasks to OAM Servers. 11g OAM Agents, Chapter 14 10g OAM Agents and the Pre-configured IAMSuiteAgent (10g OAM Agent), Chapter 23 OpenSSO Agents, Chapter 21 10g OSSO Agents (mod_osso), Chapter 22 Notes: Eight Administrator languages are supported. Unless explicitly stated, the term "Webgate" refers to both an out of the box Webgate or a custom Access Client. See Chapter 13 for an introduction to agents.
Server-side components	OAM Server (installed on a WebLogic Managed Sever),
Console	Oracle Access Management Console provides access to all services and configuration details. See Chapter 2.
Protocols for information exchange on the Internet	Front channel protocols exchanged between Agent and Server: HTTP/HTTPS. Back channel protocols: Authenticated clients can perform session operations using enhancements in the Oracle Access Protocol (OAP).
Proxy	Provides support for legacy systems OAM Proxy supports legacy Access Manager implementations by acting as a legacy Access Server. "Managing the Access Protocol for OAM Proxy Simple and Cert Mode Security" "Introduction to OAM Proxy Metrics and Tuning" OSSO Proxy supports OSSO Agents by acting as the legacy OSSO Server. See Chapter 22. Oracle-provided OpenSSO Proxy handles requests for resources protected by OpenSSO Agents. See Chapter 21. See Also: About the Embedded Proxy Server and Backward Compatibility
Cryptographic keys	Note: One key is generated and used per registered mod_osso or 11g Webgate. However, one single key is generated for all 10g Webgates. During 11g agent registration, one per-agent secret key shared is generated for encrypting and decrypting SSO cookies between 11g Webgate and OAM Server. See Chapter 14. During 10g agent registration, a global shared secret key is generated across all of Access Manager 11g (all Agents and OAM Servers). See Chapter 23. During OSSO agent registration, One key per partner shared between mod_osso and OSSO server. See Chapter 22. OpenSSO Agent Host- or Domain-based key stored locally in Agent bootstrap file on the Agent host. See Chapter 21. During OAM Server registration, one server key is generated.
Keys storage	Agent side: A per-agent key is stored locally in the Oracle Secret Store in a wallet file OAM Server side: Per- agent keys, and server keys, are stored in the credential store on the server side
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 Server to Webgate. Webgate decrypts obrar.cgi, extracts the authentication token, and sets a host-based cookie.
Policy Store	Database in production environments; file-based in demonstration and development environments, as described in "Managing the Policy and Session Database".
Applications	An application that delegates authentication and authorization to Access Manager and accepts headers from a registered Agent. Note: External applications do not delegate authentication. Instead, these display HTML login forms that ask for application user names and passwords. For example, Yahoo! Mail is an external application that uses HTML login forms.
SSO Engine	Manages the session lifecycle, facilitates global logout across all relying parties in the valid session, and provides consistent service across multiple protocols. Uses Agents registered with Access Manager 11g: Authentication with the default embedded credential collector occurs across the HTTP (HTTPS) channel Authentication with the optional detached credential collector occurs across the Oracle Access Protocol (OAP) channel Authorization occurs across the Oracle Access Protocol (OAP) channel See: Chapter 16
Session Management	Global session specifications are enabled for all Application Domains and resources. In addition, Application Domain-specific session overrides can be configured. See Chapter 15.
Policies	Registered agents rely on Access Manager authentication, authorization, and token issuance policies to determine who gets access to protected applications (defined resources). See: Chapter 18
Client IP	Maintains this client's age, and includes it in the host-based cookie: OAMAuthnCookie for 11g Webgate (or ObSSOCookie for 10g Webgate)
Response token replay prevention	Include RequestTime (the timestamp just before redirect) in obrareq.cgi and copy it to obrar.cgi (the authentication response string redirected from the OAM Server to Webgate) to prevent response token replay.
Multiple network domain support	Access Manager 11g supports cross-network-domain single sign-on out of the box. Oracle recommends you use Oracle Federation for this situation.
Cookies	Host-based authentication cookie: 11g Webgate, One per agent: OAMAuthnCookie_host:port_random_number set by Webgate using the authentication token received from the OAM Server after successful authentication. Note: A valid OAMAuthnCookie is required for a session. 11g Webgate, Transient: OAM_REQ is scoped to the OAM Server. OAM_REQ is set or cleared by the OAM Server if the Authentication request context cookie is enabled. Protected with keys known to the OAM Server only. This cookie is configured as a high availability option to store the state about the user's original request to a protected resource while his credentials are collected and authentication is performed. 10g Webgate, One ObSSOCookie for all 10g Webgates. One for the OAM Server: OAM_ID, which is scoped to the OAM Server. OAM_ID is generated by the OAM Server when the user is challenged for credentials and submitted to the server on every redirect to the server. See Chapter 16.
Centralized log-out	The logOutUrls (10g Webgate configuration parameter) is preserved. 10g logout.html requires specific details for Access Manager 11g. See Chapter 23. 11g Webgate parameters are new: Logout Redirect URL Logout Callback URL Logout Target URL See Chapter 20.

1.3.2 About Functionality Not Available with Access Manager 11g

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

Table 1-4 10g Functionality Not Available with Access Manager 11g

Unavailable or Unsupported Functions
Extensibility framework required for building custom authorization plug-ins.
Application-domain-level delegated administration
Authorization for mod_osso-protected resources

1.4 Introduction to Oracle Access Management Security Token Service

Security Token Service is deployed with Access Manager and must be activated as a service. The 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.

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 Security Token Service"

• Part VIII, "Managing Oracle Access Management 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 needed to simplify the integration of distributed or federated Web services within an enterprise and its service providers.

Security Token Service is primarily based on the OASIS WS-Trust protocol. However, Security Token Service 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 providers and consumers. Security Token Service can help simplify the effort needed to bridge access to various systems using a standardized set of interfaces. Oracle Access Management Security Token Service augments Oracle Access Management Identity Federation, 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 Oracle Access Management 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, 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:

• Security Token Service Key Terms and Concepts

• About Security Token Service

• About Integrated Oracle Web Services Manager

• About Security Token Service Architecture

• About Security Token Service Deployments

• About Security Token Service Administration

1.4.1 Security Token Service Key Terms and Concepts

Table 1-6 identifies common Security Token Service terminology.

Table 1-5 Security Token Service Terms and Concepts

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.
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 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: System Keystore Trust Keystore Partner Keystore See Also: Chapter 34, "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.
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).

Table 1-6 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.
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 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: System Keystore Trust Keystore Partner Keystore See Also: Chapter 34, "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.
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).

1.4.2 About Security Token Service

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 is installed with Oracle Access Management 11g on Managed Servers. Each Managed Server must be registered with Access Manager to open communication channels. All Security Token Service system configuration is done using the Oracle Access Management Console. Security Token Service inter-operates with third party security token servers.

Security Token Service 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 leverages the common infrastructure for shared services and the Access Manager 11g administration model. In addition, Security Token Service is integrated with the Oracle Access Management Console to provide a unified and consistent administration experience.

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 III, "Common Logging, Auditing, Performance Monitoring and Tuning".

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

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

Table 1-7 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. See Also: "About Setting the Default Store and System Store".
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: The keys and certificates used in Security Token Service are generated during installation. The subject and issuer fields are linked to the host name. This applies to the signing and encryption keys and certificates used by Security Token Service, as well as the keys/certificates used by the OWSM Agent protecting Access Manager. The OWSM Agent is the certified WS-Trust client that can be used to communicate with Security Token Service. The SAML Issuer settings are configured to refer to the host name of the local computer. This ensures that two servers are not identical in terms of cryptographic materials and identifiers. The trust granted to one server by third-party modules is not granted to the other server because the identifiers and cryptographic keys differ. There are no identical keys, no identical identifiers, and authorization policies are in denial mode.
Oracle Coherence	Security Token Service integrates with the Oracle Coherence module to store and share run time WS-Trust data across all the physical instances of Security Token Service. The UserNameToken Nonce are stored in the Coherence store. This implementation supports the following requirements, which might be specific to Security Token Service: Cleanup of timed out records Existence of the records limited to several minutes (< 30)

1.4.3 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-8 describes these components.

See Also:

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

Table 1-8 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 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. 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 Security Token Service only. Oracle WSM supports disabling of authentication using configuration overrides that Security Token Service must declare with each policy. Exception: The Kerberos token is handled by Oracle WSM and 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 Security Token Service. Other 3rd party WS-Trust clients can be used to interact with Security Token Service. 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: The message security key pair is populated to OPSS Keystore The token security key pair is populated to 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.

1.4.4 About 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-4.

Figure 1-4 Oracle STS Architecture

Description of "Figure 1-4 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-5 documents the token support matrix for Oracle STS.

Figure 1-5 Oracle STS Token Support

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

1.4.5 About Security Token Service Deployments

This section provides overviews of different deployment options:

• Centralized Token Authority Deployment

• Tokens Behind a Firewall Deployment

• Web Services SSO Deployment

See Also:

"Scenario: Identity Propagation with the Access Manager Token"

1.4.5.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 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 Security Token Service, the translation of tokens can be done at the centralized authority, as shown in Figure 1-6.

Figure 1-6 Token Translation at a Centralized Authority

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

1.4.5.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 (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 Security Token Service provides significant relieve in this situation. Security Token Service plays a role of a centralized token authority, performing a translation of tokens behind the firewall, as shown in Figure 1-7.

Figure 1-7 Translating Tokens Behind a Firewall

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

Application 1 and Application 2 are protected by 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 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 a 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). There is no need to decompose the token on the application side.

1.4.5.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 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 Security Token Service, however, 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 1-8 illustrates Web services SSO.

Figure 1-8 Web Services SSO

Description of "Figure 1-8 Web Services SSO"

1.4.6 About Installation Options

This section provides an overview of the installation options:

• Security Token Service Cluster in Single WLS Domain

• Endpoint Exposure through a Web Server Proxy

• Security Token Service Installation Overview

• Post-Installation Tasks: Security Token Service

1.4.6.1 Security Token Service Cluster in Single WLS Domain

You can leverage 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 means that you:

• Deploy multiple instances of Security Token Service through the suite installer.

• Deploy 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.

1.4.6.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.

1.4.6.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.

1.4.6.4 Security Token Service Installation Overview

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

1.4.6.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.

Elements in the Oracle Access Management 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 Security Token Service system configuration is done using the Oracle Access Management Console. This includes the following previously covered topics:

Look for information through out this manual. Pay close attention to Security Token Service details in Part VIII, "Managing Oracle Access Management Security Token Service".

1.4.7 About Security Token Service Administration

A single 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 Management Console (and WebLogic Server Administration Console).

For more information, see Chapter 2, "Getting Started with Oracle Access Management Administration and Navigation".

1.5 System Requirements and Certification

Refer to the system requirements and certification documentation on Oracle Technology Network (OTN) for information about hardware and software requirements, platforms, databases, and other information.

The system requirements document covers information such as hardware and software requirements, minimum disk space and memory requirements, and required system libraries, packages, or patches:

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html

The certification document covers supported installation types, platforms, operating systems, databases, JDKs, and third-party products:

http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html