Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service
11g Release 1 (11.1.1)

Part Number E15478-06
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

11 Introduction to the OAM Policy Model, Single Sign-On

Login is the action the user takes to authenticate and gain access to a desired application. Single sign-on (SSO) is enabled by Oracle Access Manager to eliminate the need for additional or different logins to access other applications during the same user session.

This chapter provides an introduction to Oracle Access Manager 11g single sign-on to lay some ground work before developing policies and the components that these require. This chapter includes the following topics:

Note:

Unless explicitly stated, information in this chapter is the same for OAM Agents and OSSO Agents.

For details about single log-out, see Chapter 15, "Configuring Centralized Logout for OAM 11g".

Prerequisites

A fully functional Oracle Access Manager 11g system, including at least two registered Agents, is required.

This section identifies knowledge-based requirements for tasks in this chapter.

Comparing the OAM 11g Policy Model and OAM 10g Model

Oracle Access Manager 11g distills the policy models of both Oracle Access Manager and OSSO 10g into a single model that provides simplicity, flexibility, and a future growth path.

Table 11-1 compares the OAM 11g policy model with other models.

Table 11-1 Comparing OAM 11g Policy Model with OAM 10g

Policy Elements OAM 11g Policy Model OAM 10g Policy Model

Policy Authoring

Oracle Access Manager Console

OAM Policy Manager

Policy Store

Database

LDAP directory server

Domain

Application Domain

Policy Domain

Resources

  1. No URL prefixes. Resource definitions are treated as complete URLs.

  2. Pattern matching (with limited features) for:

    ' * ' and '...' are supported

  3. Resources need not be unique across domains.

  4. Query-string protection for HTTP URLs.

  5. Each HTTP resource is defined as a URL path, and associated with a host identifier. However, resources of other types are associated with a specific name (not a host identifier).

  6. Non-HTTP resource types are supported, without definition of specific operations. Non-HTTP resource types are never associated with a host identifier.

  7. Resources can designated as either Protected, Unprotected, or Excluded.

  1. URL prefixes are defined in domains

  2. Pattern matching for:

    { } * …

  3. Resources need not be unique across domains.

  4. http resources can be protected based on URL query string contents and/or HTTP operation.

  5. Non-HTTP resource types and operations can be defined.

Host identifiers

  1. Host Identifiers are defined outside of policies and are used while defining HTTP resources.

  2. Host Identifiers are mandatory for defining HTTP resources.

  1. Host Identifiers are defined outside of policies and are used while defining HTTP resources.

  2. Host Identifiers are not mandatory, for defining HTTP resources, till there are no Host Identifiers defined in the system.

Policies

  1. Authentication policies include resources, success responses, and an authentication scheme.

  2. Authorization policies can also contain success responses, and time based, IP based and user-based constraints.

  3. Only one authentication policy and one authorization policy can be associated with any resource.

  4. Authentication and Authorization policies can evaluate to Success or Failure.

  5. No Query Builder and no support for LDAP filters for (for retrieving matches based on an attribute of a certain display type, for example).

  6. There is no notion of default policy in an application domain. However, you can define a policy for resource: /…/* which can be used as a default policy within a determined scope).

  7. Token Issuance Policies can be defined using resources and user- or partner-based constraints. See "About Token Issuance Policies".

  1. Authentication policies are simple and contain only authentication-scheme-based rule.

  2. One resource can be associated with a set of Authorization policies. Evaluation of these policies can be based on an expression that combines the policies within the set using logical operators as desired.

    A resource can also be associated with multiple authentication policies and authorization policy sets. However, only one set applies.

  3. An Authorization policy can evaluate to Success or Failure, or Inconclusive.

  4. Users can be specified using LDAP filters.

  5. Default authentication policy and authorization policy set can be defined for a policy domain. This policy is only applicable if there are no other applicable policies for a runtime resource in that domain.

  6. There is no support for Token Issuance Policies.

Responses

  1. Authentication and Authorization success Responses can be defined within the policies. These are applied after evaluation of policies.

  2. Cookie, Header, and Session responses are supported.

  3. URL redirection can be set.

  4. Response definitions are part of each policy. Response values can be literal strings or can contain additional embedded expressions that derive values from request, use,r and session attributes.

  1. Authentication and Authorization Responses can be defined within the policies for Success, Failure, and Inconclusive events. These are returned to the caller after evaluation of policies.

  2. HTTP_HEADER and Cookie based variables can be set.

  3. Redirect URLs can be set for Success and Failure events of authentication and authorization policy evaluations.

  4. Response values can contain literal strings and list of user attribute values.

Authentication Schemes

Authentication Schemes are defined globally and can be referenced within authentication policies.

The trust level is expressed as an integer value between 0 (no trust) and 99 (highest level of trust).

Note: Level 0 is unprotected. Only unprotected resources can be added to an Authentication Policy that uses an authentication scheme at protection level 0. For more information, see Table 12-3, "Authentication Scheme Definition".

Authentication Schemes can be defined outside of policies and can be referenced within authentication policies.

Cookies

See: "About Single Sign-On Cookies During User Login"

See: "About Single Sign-On Cookies During User Login"

Query String-based HTTP Resource Definitions

Supported within Access Policies.

The Policy Model supports query string-based HTTP resource definitions within Access Policies.

At run time, the OAM Proxy passes the Query String to the policy layer after URL encoding, just like for base resource URL. Only Query String that are part of HTTP GET requests are passed. Query String pattern does not apply to HTTP POST data.

See: Table 13-1, "Resource Definition Elements"


Introduction to the OAM 11g Policy Model

This section introduces the Oracle Access Manager 11g policy model and the global shared components within it.

The Oracle Access Manager 11g policy model supports both authentication and authorization services within the context of an OAM application domain. The policy model relies on external user identity stores and on authentication modules, which are a part of the overall system configuration.

Note:

Earlier releases of Oracle Access Manager provided authentication and authorization services within the context of an OAM policy domain. OracleAS SSO 10g provides only authentication.

Figure 11-1 illustrates the different elements within the Oracle Access Manager 11g policy model.

Figure 11-1 Oracle Access Manager 11g Policy Model and Shared Components

Policy Model and Shared Components
Description of "Figure 11-1 Oracle Access Manager 11g Policy Model and Shared Components"

Application Domains and Policies

The top-level construct of the Oracle Access Manager 11g policy model is the OAM application domain. Each application domain provides a logical container for resources, and the associated authentication and authorization policies that dictate who can access these.

The size and number of application domains is up to the administrator; the decision can be based on individual application resources or any other logical grouping as needed. An application domain is automatically created during Agent registration. Also, administrators can protect multiple application domains using the same agent by manually creating the application domain and adding the resources and policies. For details, see:

Shared Policy Components

Global policy components that can be used in one or more application domains. The following topics provide more information:

About Resource Types

A resource type describes the kind of resource to be protected.

Each resource is defined using a single resource type. However, you can define any number of resources using that type.

Before you can add resources to an application domain for protection, *their* resource type must be defined. Administrators typically use the default resource type, HTTP, but non-HTTP types can be defined.

For more information about resource types and management, see "Managing Resource Types".

About Host Identifiers

A host can be known by multiple names. To ensure that OAM recognizes the URL for a resource, OAM must know the various ways used to refer to that resource's host computer.

Table 11-2 illustrates the different host names under which a Web server might be accessible to employees. Creating a single Host Identifier using all of these names allows you to define a single set of policies to appropriately protect the application, regardless of how the user accesses it.

Table 11-2 Host Identifiers Examples

Host Identifier Description

hrportal.intranet.company.com

A friendly name employees can remember. This is a load-balanced proxy, and requests to this could actually utilize one of several servers hosting the HR application.

hr-sf-02.intranet.company.com

A single machine hosting the application, which can be accessed directly.

hrportal.company.com

The same application is also accessible externally to the corporate firewall, primarily for use by ex-employees to check benefits, 401k info, and so on. This is also a load-balanced reverse proxy.


With OAM, all possible variations are stored together. Administrators enter the canonical name for the host and every other name by which the host can be addressed by users. A request sent to any address on the list is mapped to the official host name.

Host identifiers are created automatically during Agent registration and are used to seed the Resource definition and default authentication and authorization policies in the new application domain. Alternatively: an administrator can create a host identifier definition for use in one or more application domains.

Authentication and authorization policies in an application domain protect resources based on host identifiers. Host identifiers are used to identify resources or an application at run time and can be used to formulate policies for application resources at design time.

For more information, see "About Host Identifiers".

See Also:

The following chapters for more information about registering agents and applications:

About Authentication, Schemes, and Modules

Authentication is the process of proving that a user is who he or she claims to be. Authenticating a user's identity with Oracle Access Manager refers to running a pre-defined set of processes to verify the digital identity of the user.

Each authentication policy can be assigned only one authentication scheme. However, one authentication scheme can be assigned to multiple authentication policies.

One authentication policy can protect many resources. However, each resource can be protected by only one authentication policy.

See the following topics:

Authentication Schemes and Modules

Using OAM, a resource or group of resources can be protected by a single authentication process known as an authentication scheme. Authentication schemes rely on pre-defined authentication modules.

Authentication Scheme: A named component that defines the challenge mechanism, level of trust, and the underlying authentication module required to authenticate a user. It also contains some general information about itself. Authentication schemes are defined globally, to ensure that a small number of Security Administrators define them in a consistent, secure way. There are several default authentication schemes provided with Oracle Access Manager 11g.

Authentication Modules: The smallest executable unit of an authentication scheme. Several pre-defined modules are provided. Each module contains standard plug-ins. The authentication module determines the exact procedure to be followed and the method for challenging the user for credentials. For more information about these modules, see "Managing Authentication Modules".

For more information, see "Managing Authentication Schemes".

Multi-level Authentication: Oracle Access Manager 11g enables administrators to assign different authentication levels to different authentication schemes, and then choose which scheme protects which application. A highly sensitive application might require a user certificate and a less sensitive application might require a user name and password. For example, if a user is granted access to a resource that has a Basic Over LDAP authentication scheme defined as having a level of 2, the user can access other resources that have schemes with the same or a lower level. However, if the user tries to access a resource with a more stringent authentication challenge, such as a scheme called Client Certificate with a level of 5, they must re-authenticate.

Windows Native Authentication: Integrated Windows Native Authentication is supported for both OSSO and Webgate protected applications, as described in Oracle Fusion Middleware Integration Guide for Oracle Access Manager.

Other Authentication Types: Authentication features required by Oracle Fusion Middleware applications are supported, including:

  • Weak authentication, typically a user name and password, no certificates

  • Auto-login with third-party self-service user provisioning

  • HTTP header support for user context information. For instance, host identifiers are used to create a host context for the resource. This is useful when adding resources that have the same URL paths on different computers.

If you use different authentication schemes for two WebGates, users can go from a higher authentication scheme to a lower one without re-authentication, but not from a lower level to a higher level.

Note:

During single sign-on, users might pass the authentication tests but might fail the authorization tests when attempting to access a second or third resource. Each resource in the domain might have a unique authorization policy.

For details about configuring and using authentication schemes with Oracle Access Manager11g, see "Managing Authentication Schemes".

Authentication Event Logging and Auditing

Authentication Success and Failure events are audited, in addition to administration events. Auditing covers creating, modifying, viewing, and deleting authentication schemes, modules, and policies. Information that is collected about the user who is authenticating includes:

  • IP address

  • User Login ID

  • Time of Access

During logging (or auditing), user information, user sensitive attributes are not recorded. Secure data (user passwords, for example) are removed to avoid misuse.

Several monitoring and diagnostic metrics are collected during authentication. For more information, see Chapter 25, "Monitoring Performance by Using Oracle Access Manager Console".

About Application Domains and Policies

OAM 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access. In contrast, OAM 10g default behavior allowed access when a resource was not protected by a rule or policy that explicitly specified access.

The Oracle Access Manager 11g policy model enables you to control who can access resources when you define an application domain that discriminates between authenticated users who are authorized and those who are not authorized for access to a particular resource.

There are several ways that users can attempt to access a resource that is protected by an application domain, for example, by entering a URL in a browser, by running an application, or by calling some other external business logic. When users request access to resources protected by an application domain, their requests are evaluated according to the domain's policies (for authentication and authorization).

An application domain logically groups resources and policies in a flexible way. Each Application domain can be made to contain policy elements related to an entire application deployment, a particular tier of the deployment, or a single host. Application domains do not have any hierarchical relationship to one another.

Within the application domain, specific resources are identified as well as the policies that govern each resource. Authentication and authorization policies include administrator-configured responses that are applied on successful evaluation. Authorization policies include administrator-configured constraints that define how evaluation is performed.

Each application domain must have a unique name (a brief description is optional). Each domain is seeded with a resource container and policy containers where administrators can define resources and policies.

About Resources and Resource Definitions

Resources represent a document, or entity, or pieces of content stored on a server and available for access by a large audience. Clients communicate with the server and request the resource using a particular protocol (HTTP or HTTPS, for example) that is defined by an existing Resource Type.

Note:

To protect pieces of content on a page, Oracle recommends using Oracle Entitlements Server.

With Oracle Access Manager, resource definitions are created within an application domain. Each resource is defined as a URL path. Every HTTP Resource Type must be associated with a host identifier. However, non-HTTP Resource Types (non-HTTP resources), are associated with a specific name (not a host identifier).

Note:

Only resources defined within an application domain can be associated with policies defined for the application domain.

For more information, see "Adding and Managing Resource Definitions for Use in Policies".

About Authentication Policies, Responses, and Resources

Authentication is the process of proving that a user is who he or she claims to be. To authenticate a user, Oracle Access Manager presents the user's browser with a request for authentication credentials in the form of a challenge. The challenge is referred to as a challenge method.

Administrators can create one or more authentication policies in an application domain to apply to specific resources within that domain.

Note:

Authentication is provided by OAM 11g Authentication Policies regardless of Agent type.

Authentication Policy Evaluation

Authentication policies specify the authentication methodology to be used for authenticating the user for whom the access must be provided on a given resource. Policies define the way in which the resource access is to be protected.

After a policy has been evaluated, two standard actions are performed:

  • The result is returned

  • The user is shown something based on that result: either the requested URL requested (on Success, allow) or the URL of a generic error page (on Failure, deny)

    Either or both results can be overridden on a policy-by-policy basis.

Policy Responses for SSO

Administrator-defined policy responses declare optional actions to be taken in addition to the above. Policy responses provide the ability to insert information into a session and pull it back out at any later point. This is more robust and flexible than OAM 10g, which provided data passage to (and between) applications by redirecting to URLs in a specific sequence. For details, see "Introduction to Policy Responses for SSO".

Note:

Policy responses must be configured by an administrator and applied to specific resources defined within the same application domain.

For more information, see "Anatomy of an Application Domain and Policies".

About Authorization Policies, Resources, Constraints, and Responses

Authorization is the process of determining if a user has a right to access a requested resource.

Administrators can create one or more authorization policies to specify the conditions under which a subject or identity has access to a resource. A user might want to see data or run an application program protected by a policy. The requested resource must belong to an application domain and be covered within that domain by a specific authorization policy.

Note:

OracleAS SSO 10g does not provide authorization; OSSO Agents do not use OAM 11g Authorization Policies.

Authorization Responses for SSO

Administrator-defined policy responses declare optional actions to be taken in addition to the above. Policy responses provide the ability to insert information into a session and pull it back out at any later point. This is more robust and flexible than OAM 10g, which provided data passage to (and between) applications by redirecting to URLs in a specific sequence.

For more information, see "Introduction to Policy Responses for SSO".

Authorization Constraints

An authorization constraint is a rule that grants or denies access to a particular resource based on the context of the request for that resource. Authorization constraints determine if the authorization succeeds or fails for the request.

Administrators must define the constraints that apply to the resources assigned to the authorization policy. For details, see "Introduction to Authorization Constraints".

Authorization Policy Evaluation

Evaluation of the authorization policy results in one of two outcomes: SUCCESS (allow) or FAILURE (deny). If the data is insufficient to evaluate the policy, the outcome is always FAILURE. For example, a constraint verifies that the user is a member of a group before allowing access; however, if the group does not actually exist in the LDAP, the outcome is FAILURE.

For more information, see "Defining Authorization Policies for Specific Resources".

Introduction to Configuring OAM Single Sign-On

To begin the introduction to OAM 11g SSO, the following task overview summarizes how to configure single sign-on with OAM 11g, and where to find additional information related to specific tasks.

Task overview: Configuring single sign-on with OAM 11g

  1. Review the following topics:

  2. Configure a single sign-on logout URL for each partner application using documentation for your application.

  3. Install an OAM policy-enforcement Agent on each Web server that is hosting an application that you want to protect:

    Note:

    Registering an Agent with OAM 11g automatically creates a default host identifier and application domain seeded with basic policies.
  4. Confirm that the desired resource type is available, (or create one yourself), as described in "Managing Resource Types".

  5. Confirm that you have the proper authentication modules and schemes, as described in:

  6. Confirm that a host identifier definition named for the agent was created automatically, (or create one yourself) as described in "Managing Host Identifiers".

  7. Add resource definitions and configure OAM 11g policies in the application domain as described in Chapter 13, "Managing Policies to Protect Resources and Enable SSO".

  8. Configure the SSO Engine, as described in "Managing SSO Tokens and IP Validation".

  9. Validate the configuration, as described in "Validating Global Sign-On and Centralized Logout".

Introduction to SSO Components

This section provides a brief overview of single sign-on with Oracle Access Manager 11g. It includes the following topics:

About Single Sign-On Components

This topic introduces key components to implementing and enforcing Oracle Access Manager 11g policies for single sign-on.

Table 11-3 summarizes key single sign-on components.

Table 11-3 OAM 11g SSO versus OSSO 10g Component Summary

Component Description OAM 11g OSSO 10g

Servers

Note: Non-administrative users first gain access to the single sign-on server by entering the URL of a partner application, which returns the SSO login page. See Also: "Introduction to OAM 11g SSO Processing".

  • OAM Server

  • Oracle Access Manager Console (installed on the WebLogic Administration Server)

Note: Administrative users access the console home page by typing the URL: https://host:port/oamconsole. See Also: "Logging In to and Signing Out of Oracle Access Manager Console".

  • OracleAS SSO server (OSSO server)

See Also: Oracle Application Server Single Sign-On Administrator's Guide.

Proxy

Provides support for legacy systems:

  • OAM Proxy supports legacy Oracle Access Manager implementations by acting as a legacy Access Server.

  • OSSO Proxy supports legacy SSO implementations by acting as the legacy OSSO Server.

Policy Enforcement Agents

Resides with the relying parties and delegate authentication and authorization tasks to OAM Servers.

  • 11g OAM Agents (Webgates)

  • 10g OAM Agents (Webgates/Access Clients)

  • 10g OSSO Agents (mod_osso)

  • mod_osso (partner)

    Note: The mod_osso module is an Oracle HTTP Server module that provides authentication to OracleAS applications.

Oracle Identity Management Infrastructure

Enables secure, central management of enterprise identities.

Enables secure, central management of enterprise identities.

Policy Store

Database

mod_osso and partner application

Partner Applications

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.

An application that delegates authentication and authorization to OAM and accepts headers from a registered Agent.

An application that delegates authentication to mod_osso and the OracleAS Single Sign-On server.

Note: After registering mod_osso with OAM 11g, mod_osso delegates authentication to OAM.

The mod_osso module enables partner applications to accept authenticated user information once the user is logged in. Re authenticating is avoided by accepting headers from the registered OSSO Agent.

The partner application is responsible for determining whether the authenticated user is authorized to use the application.

SSO Engine

Manages the user session life cycle, facilitates global logout across all relying parties in the valid user session, and provides consistent service across multiple protocols.

With OAM Agents:

  • Authentication (credential collection) occurs across the HTTP (HTTPS) channel

  • Authorization occurs across the Oracle Access Protocol (OAP) channel

  • mod_osso delegates authentication only and communicates exclusively through the HTTP channel.

Partner Keys

  • During 11g agent registration, a partner key is generated for the agent and also shared with the OAM Server

    The key is used for encrypting and decrypting SSO cookies

  • During 10g agent registration, a global shared secret key is generated across all of OAM 11g (all Webgates and OAM Server).

  • One key per partner shared between mod_osso and OSSO server

Server Keys

  • During OAM Server installation, one OAM Server key is generated

  • 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 Java Keystore on the server side

  • 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

Cookies

See Also: "About Single Sign-On 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.

  • 10g Webgate, One ObSSOCookie for all 10g Webgates.

  • One for the OAM Server: OAM_ID

  • 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

Policies

OAM Agents use OAM 11g authentication and authorization policies to determine who gets access to protected applications (defined resources).

mod_osso uses only OAM 11g authentication policies to determine who gets access to defined resources.

mod_osso provides authentication only.

Client IP

  • Maintain this client age, and include it in the host-based cookie: OAMAuthnCookie for 11g Webgate (or ObSSOCookie for 10g Webgate)

  • Include the original clientage 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


About Single Sign-On Cookies During User Login

Table 11-4 describes the cookies that can be set or cleared during user login.

Table 11-4 SSO Cookies

SSO Cookie Set at User Login Set By Description

OAM_ID cookie

OAM 11g Server

Protected with keys known to the OAM Server only.

When a user attempts to access a protected application, the request comes to the SSO Engine and the controller checks for the existence of the cookie:

  • If the cookie does not exist, user authentication begins. After successful authentication, the user context and token are set by the SSO Engine. The cookie is set with the global user ID (GUID), creation time, and idle timeout details. Information in the cookie is encrypted with the SSO Server key and can be decrypted only by the SSO Engine.

  • If the cookie exists, then the cookie is decrypted and the sign in flow completes with the authenticated user.

OAMAuthnCookie

11g Webgate

Set by each 11g Webgate that is contacted. Protected by the key known to the respective 11g Webgate and the OAM Server. A valid OAMAuthnCookie is required for a session.

Note: If the user accesses applications protected by different 11g Webgates, you will have multiple OAMAuthnCookies. See "OAMAuthnCookie for 11g OAM Webgates".

ObSSOCookie

10g Webgate

A domain-based cookie for 10g Webgates is set only when a 10g Webgate is contacted. Protected with keys known to the OAM Server only. One global shared secret key for all Webgates.

Note: This cookie enables backward compatibility and inter-operability between OAM 11g and older agents.

OAM_REQ

OAM 11g Server

A transient cookie that 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.

Note: This cookie is configured as a high availability option to store the state about user's original request to a protected resource while his credentials are collected and authentication performed.

OAMRequestContext

11g Webgate

A transient cookie that is set or cleared by the 11g Webgate. Protected by the key known to the respective 11g Webgate and the OAM Server.

Note: This cookie is configured as a high availability option to store the state about user's original request to a protected resource while his credentials are collected and authentication performed.

OHS-host-port

Oracle HTTP Server

Set only when OSSO Agents (mod_osso) are contacted on Oracle HTTP Server (OHS). Protected with the key known to the respective mod_osso agent and the OAM Server. See "mod_osso Cookies".

Note: This cookie enables backward compatibility and inter-operability between OAM 11g and older agents.

GITO cookie

OAM 11g Server

Provides backward compatibility and inter-operability between OSSO 10g and OAM 11g. The cookie is created by the OAM Server and accessed or modified by the OAM Server or mod_osso agent.


For details about configuring authentication and authorization policies, see Chapter 13, "Managing Policies to Protect Resources and Enable SSO".

About Single Sign-On Cookies

OAMAuthnCookie for 11g OAM Webgates

There is one OAMAuthnCookie_<host:port>_<random number> set by each 11g Webgate using the authentication token received from the OAM Server after successful authentication. A valid OAMAuthnCookie is required for a session.

SSL Connections: Administrators can ensure the ObSSOCookie is only sent over an SSL connection and prevents the cookie from being sent back to a non-secure Web server by configuring SSL and then specifying Simple or Cert mode for Agents and Servers. For details, see "About Communication Between OAM Servers and Webgates".

Cookie Expiration: For 11g Webgate and OAMAuthnCookie, expiration is controlled by the "tokenValidityPeriod" parameter, which controls the valid token (or cookie) time.

This key is known to both the 11g Webgate and SSO Engine and is used for encrypting OAMAuthnCookie. The SSO engine key (only known to the SSO Engine) is used for encrypting the OAM_ID OAM Server cookie.

Similar to ObSSOCookie, described next.

ObSSOCookie for 10g OAM Webgates

Oracle Access Manager 11g sets a key-based cookie ObSSOCookie for each user or application that accesses a resource protected by a 10g Webgate. The key is set up during agent registration and is known to both the agent and SSO Engine (shared between them). This key is different from the OAM Server (or SSO Engine) key.

Removing the ObSSOcookie causes the 10g Webgate to log the user out and requires the user to re-authenticate the next time he or she requests a resource that is protected by the Access System.

The Webgate sends the ObSSOCookie to the user's browser upon successful authentication. This cookie can then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication. When the user requests access to a browser or another resource, the request flows to the OAM Server. The user is logged in, and the ObSSOCookie is set. The OAM Server generates a session token with a URL that contains the ObSSOCookie. Single sign-on works when the cookie is used for subsequent authorizations in lieu of prompting the user to supply authorization credentials.

When the cookie is generated, part of the cookie is used as an encrypted session token. The single sign-on cookie does not contain user credentials such as user name and password.

SSL Connections: Administrators can ensure the ObSSOCookie is only sent over an SSL connection and prevents the cookie from being sent back to a non-secure Web server by configuring SSL and then specifying Simple or Cert mode for Agents and Servers. For details, see "About Communication Between OAM Servers and Webgates".

Cookie Expiration: Administrators can specify the desired Cookie Session Time in the OAM Agent registration. For more information, see "Registering and Managing OAM Agents Using the Console".

OAM_REQ Cookie

A transient cookie that 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 user's original request to a protected resource while his credentials are collected and authentication performed.

In high availability configurations, the Request Cache type must be changed from BASIC to COOKIE using Infrastructure Security custom WLST commands.

Note:

You must invoke the WLST script from the Oracle Common home. See "Using Custom WLST Commands" in the Oracle Fusion Middleware Administrator's Guide.

mod_osso Cookies

The mod_osso module is the Oracle HTTP Server module that provides authentication to OracleAS applications. This module resides on the Oracle HTTP Server that enables applications protected by OracleAS Single Sign-On to accept HTTP headers in lieu of a user name and password once the user has logged into the OracleAS Single Sign-On server. The values for these headers are stored in a mod_osso cookie.

Located on the application server, mod_osso simplifies the authentication process by serving as the sole partner application to the single sign-on server. In this way, mod_osso renders authentication transparent to OracleAS applications. The administrator for these applications is spared the burden of integrating them with an SDK. After authenticating a user, mod_osso transmits the simple header values that applications may use to authorize the user:

GITO Cookie: Needed in special cases to support timeout when multiple types of agents (mod_osso and Webgate) are working with OAM 11g. Server side session managers can check the validity of the cookie for expiry and timeout during session validation. Global logout is required for OSSO Agents (mod_osso) to ensure that logging out of a session on any entity propagates the logout to all entities.

When a user is authenticated by OSSO 10g, the OSSO Server sets GITO cookie. Once the partner cookie (OHS cookie) is set, OHS does not route the request to the server. Instead, on every access, OHS decrypts the GITO cookie and updates the last activity timestamp. During request processing, if any partner detects that current time has surpassed GITO timeout (last activity time + GITO timeout), the request is sent to OSSO 10g in forced authentication mode. When a request reaches OSSO server in forced authentication mode, server chooses to ignore SSO_ID cookie and challenges user for credentials, considering it as a fresh request. After successful authentication, SSO_ID and GITO cookie are updated.

This is enabled (using the editGITOValues WLST command), as described in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

OssoSecureCookies Directive: Add the OssoSecureCookies directive to set the Secure flag on all cookies. This tells the browser to only transmit those cookies on connections secured by HTTPS. An example of this directive in a mod_osso configuration (mod_osso.conf), is as follows:

<IfModule mod_osso.c>
OssoIpCheck off
OssoIdleTimeout off
OssoSecureCookies on
OssoConfigFile osso/osso.conf
<Location /j2ee/webapp>
require valid-user
AuthType Basic
</Location>
</IfModule>

For more information, see Oracle Application Server Single Sign-On Administrator's Guide.

Introduction to OAM 11g Single Sign-On Implementation Types

This section provides the following topics to introduce various single sign-on implementation types:

Application SSO

Oracle Access Manager enables administrators to create a web of trust in which a user's credentials are verified once and are provided to each application the user runs. Using these credentials, the application does not need to re-authenticate the user with its own mechanism.

Application single sign-on allows users who have been authenticated by Oracle Access Manager to access applications without being re-authenticated.

There are two ways to send a user's credentials:

  • Using Cookies: A specific value is set on the browser's cookie that the application must extract to identify a user.

  • Using Header Variables: An HTTP header set on the request by the agent and visible to the application.

Note:

Both forms require administrators to enter the appropriate responses within the policy. For more information, see "Introduction to Policy Responses for SSO".

Header response values are inserted into a request by an OAM Agent, and can only be applied on Web servers that are protected by an agent. registered with OAM 11g If the policy includes a redirect URL that is hosted by a Web server not protected by OAM, header responses are not applied.

For example, when a user authenticates, she might be redirected to a portal index page:

http://mycompany.com/authnsuccess.htm

For authentication failure, an authentication action might redirect the user to an error page or a self-registration script:

http://mycompany.com/authnfail.htm

Single Sign-On with OAM 11g

This section introduces single sign-on processing using OAM 11g.

Oracle Access Manager provides a proprietary multiple network domain SSO capability that predates Oracle Identity Federation. If this is implemented in your OAM 10g deployment, you can register OAM 10g Agents with OAM 11g to continue this support.

SSO with Mixed Release Agents

After registering agents with Oracle Access Manager 11g, OAM Servers provide seamless support for OAM 10g and 11g Agents and 10g OSSO Agents (mod_osso) in any combination.

Reverse-Proxy SSO

If you are going to use a reverse proxy in a single sign-on configuration, be sure either to set the IPvalidation parameter to false or to add the proxy IP address to the IPValidationExceptions list in the Webgate registration. Otherwise, the reverse proxy hides the client's IP address.

In some situations the Reverse Proxy does not pass the 10g Webgate ObSSOCookie to Oracle WebLogic after a successful authentication. To avoid this issue, use Form Based authentication instead of Basic Over LDAP when using Reverse Proxy with Oracle WebLogic. For 11g Webgate, a user-defined parameter (filterOAMAuthnCookie (default true)) can be used to prevent the OAMAuthnCookie from being passed to downstream applications for security consideration. If you do want to pass the cookie on, then set the parameter to false.

Multiple WebLogic Server Domain SSO

OAM 11g supports SSO in multiple WebLogic administration domains. You can define multiple WebLogic administration domains based on different system administrators' responsibilities, application boundaries, or the geographical locations of WebLogic servers. Conversely, you can use a single domain to centralize all WebLogic Server administration activities.

Note:

All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains. All Managed Servers in a domain must run the same version of the Oracle WebLogic Server software. The Administration Server can run either the same version as the Managed Servers in the domain, or a later service pack.

There are two basic types of WebLogic administration domains:

  • Domain with Managed Servers: A simple production environment can consist of a domain with several Managed Servers that host applications, and an Administration Server to perform management operations. In this configuration, applications and resources are deployed to individual Managed Servers; similarly, clients that access the application connect to an individual Managed Server.

    Production environments that require increased application performance, throughput, or availability may configure two or more of Managed Servers as a cluster. Clustering allows multiple Managed Servers to operate as a single unit to host applications and resources. For more information about the difference between a standalone and clustered Managed Servers, see Managed Servers and Clustered Managed Servers.

  • Standalone WebLogic Server domain: For development or test environments, you may want to deploy a single application and server independently from servers in a production domain. In this case, you can deploy a simple domain consisting of a single server instance that acts as an Administration Server and also hosts the applications you are developing. The examples domain that you can install with WebLogic Server is an example of a standalone WebLogic Server domain.

All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains. All Managed Servers in a domain must run the same version of the Oracle WebLogic Server software. The Administration Server can run either the same version as the Managed Servers in the domain, or a later service pack.

Each domain's configuration is stored in a separate configuration file (config.xml), which is stored on the Administration Server along with other files such as logs and security files. When you use the Administration Server to perform a configuration task, the changes you make apply only to the domain managed by that Administration Server. To manage another domain, use the Administration Server for that domain. For this reason, the servers instances, applications, and resources in one domain should be treated as being independent of servers, applications, and resources in a different domain.You cannot perform configuration or deployment tasks in multiple domains at the same time.

Each domain requires its own Administration Server for performing management activities. When you use the Oracle Access Manager Console to perform management and monitoring tasks, you can switch back and forth between domains, but in doing so, you are connecting to different Administration Servers.

If you have created multiple domains, each domain must reference its own database schema. You cannot share a configured resource or subsystem between domains. For example, if you create a JDBC data source in one domain, you cannot use it with a Managed Server or cluster in another domain. Instead, you must create a similar data source in the second domain. Furthermore, two or more system resources cannot have the same name.

Cross-Network Domains and Oracle Access Manager 11g

Unlike OAM 10g, OAM 11g supports cross-network-domain single sign-on out of the box. During single sign-off with OAM 11g:

  • The SSO cookie set by 11g OAM Server is a host cookie that works across the network domains. The Webgate clears its standalone Agent cookie and then redirects to the OAM 11g Server for session clearing.

  • In the case of OAM 10g Webgates, which do not have a standalone Agent cookie, logout occurs only on the server side with no redirection required.

  • In the case of 11g Webgates and OSSO agents that support a standalone agent cookie, the agent logout callback URL is called in parallel. The agents accessed in a session and agents from multiple domains are all called in parallel, depending on the number of concurrent connections supported in the browser.

Note:

Oracle recommends Oracle Identity Federation for a standards-based, multi-protocol, cross-network-domain single sign-on.

Introduction to OAM 11g SSO Processing

This section provides the following topics:

About SSO Log In Processing

Single Sign On login and logout processing determines whether the user is a valid user and whether the user state is valid or invalid (either a first time user OR the user session has expired). Session management support locates, persists, and cleans up the user session context and user token.

The following topics provide more information:

Login

The first time a user attempts to access a protected resource, she is prompted for her credentials based on the authentication scheme and level for the resource (typically a user id and password is needed).

Authentication fails if the wrong user ID or password is entered. In this case, the user is not authenticated and another prompt for credentials appears.

Following successful authentication, a check of authorization policies is made to confirm this user is authorized to access the particular resource. Upon successful authorization, information is passed to the application. The user is not asked to sign in again until her session expires or if she requests a resource with a higher level of authentication.

Login with Self-Service Provisioning Applications

Provisioning does not create the session in Oracle Access Manager. When a new user uses a self-service provisioning application to create an account, he is prompted for his user id and password again when accessing an application.

The protected application is directed to Oracle Access Manager 11g, which requests the user's credentials. For example if Oracle Identity Manager is protected by OAM 11g, the user request is redirected to Oracle Access Manager from which a request to enter credentials is made.

Login and Auto Login for Applications Using Oracle ADF Security

Oracle Platform Security Services (OPSS) comprise Oracle WebLogic Server's internal security framework. On the Oracle WebLogic Server, you can run a Web application that uses Oracles Application Development Framework (Oracle ADF) security, integrates with Oracle Access Manager 11g SSO, and uses OPSS SSO for user authentication.

For more information, see Appendix C, "Integrating Oracle ADF Applications with Oracle Access Manager 11g SSO".

About SSO Log In Processing with OAM Agents

Oracle Access Manager authenticates each user with a customer-specified authentication method to determine the identity and leverages information stored in the user identity store. Oracle Access Manager authentication supports several authentication methods and different authentication levels. Resources with varying degrees of sensitivity can be protected by requiring higher levels of authentication that correspond to more stringent authentication methods.

When a user tries to access a protected application, the request is received by OAM which checks for the existence of the SSO cookie.

After authenticating the user and setting up the user context and token, OAM sets the SSO cookie and encrypts the cookie with the SSO Server key (which can be decrypted only by the SSO Engine).

Depending on the actions (responses in OAM 11g) specified for authentication success and authentication failure, the user may be redirected to a specific URL, or user information might be passed on to other applications through a header variable or a cookie value.

Based on the authorization policy and results of the check, the user is allowed or denied access to the requested content. If the user is denied access, she is redirected to another URL (specified by the administrator in Webgate registration).

Figure 11-2 shows the processes involved in evaluating policies, validating a user's identity, authorizing the user for a protected resource, and serving the protected resource. This example shows the OAM Agent flow (Webgate/Access Client 10g or Webgate 11g). There are slight variations with 11g Webgates.

Figure 11-2 SSO Log-in Processing with OAM Agents

SSO Log-in Processing with OAM Agents
Description of "Figure 11-2 SSO Log-in Processing with OAM Agents"

Process overview: SSO Log-in Processing with OAM Agents

  1. The user requests a resource.

  2. Webgate forwards the request to OAM for policy evaluation.

  3. OAM:

    • Checks for the existence of an SSO cookie.

    • Checks policies to determine if the resource protected and if so, how?

  4. OAM Server logs and returns decisions.

  5. Webgate responds as follows:

    1. Unprotected Resource: Resource is served to the user.

    2. Protected Resource:

      Request is redirected to the credential collector.

      The login form is served based on the authentication policy.

      Authentication processing begins

  6. User sends credentials.

  7. OAM verifies credentials.

  8. OAM starts the session and creates the following host-based cookies:

    • One per partner: OAMAuthnCookie set by 11g Webgates (ObSSOCookie set by 10g Webgate) using the authentication token received from the OAM Server after successful authentication.

      Note: A valid cookie is required for a session.

    • One for OAM Server: OAM_ID

  9. OAM logs Success or Failure.

  10. Credential collector redirects to Webgate and authorization processing begins.

  11. Webgate prompts OAM to look up policies, compare them to the user's identity, and determine the user's level of authorization.

  12. OAM logs policy decision and checks the session cookie.

  13. OAM Server evaluates authorization policies and cache the result.

  14. OAM Server logs and returns decisions

  15. Webgate responds as follows:

    • If the authorization policy allows access, the desired content or applications are served to the user.

    • If the authorization policy denies access, the user is redirected to another URL determined by the administrator.

About SSO Login Log In Processing with OSSO Agents (mod_osso)

SSO login processing with registered OSSSO Agents (mod_osso) is similar to login processing with Webgates. However, mod_osso provides only authentication using OAM 11g authentication policies.

Note:

mod_osso does not support authorization either on its own or using OAM 11g policies.

Figure 11-3 illustrates the login processing with mod_osso and OAM 11g.

Figure 11-3 SSO Login Processing with OSSO Agents

SSO Login with OSSO Agents
Description of "Figure 11-3 SSO Login Processing with OSSO Agents"

Process overview: SSO Log-in Processing with OSSO Agents

  1. The user requests a resource.

  2. mod_osso forwards the request to OAM for policy evaluation.

  3. OAM:

    • Checks for the existence of an SSO cookie.

    • Checks policies to determine if the resource protected and if so, how?

  4. OAM Server logs and returns decisions.

  5. mod_osso responds as follows:

    1. Unprotected Resource: Resource is served to the user.

    2. Protected Resource:

      Request is redirected to the credential collector.

      The login form is served based on the authentication policy.

      Authentication processing begins

  6. User sends credentials.

  7. OAM verifies credentials.

  8. OAM starts the session, passes an authentication token to the application, and creates the following cookies:

    • One per partner: OHS_host_port

    • One for the OAM Server: OAM_ID

    • Global Inactivity Out: A domain-level cookie GITO

  9. OAM logs Success or Failure.

  10. Credential collector redirects to mod_osso, which transmits the simple header values that applications cab use to authorize the user:

  11. Resource is served upon authentication success and the OHS-host-port cookie is set.

About Single Sign-On Processing with Mixed Release Agents

OAM 11g Servers provide similar SSO run-time processing regardless of the Agent type or release.