Access Manager converges several SSO architectures (including Identity Federation for Partner Networks, and Service Oriented Architecture) and provides SSO through a common SSO Engine for consistent service across multiple protocols. The Oracle Identity Management Infrastructure stores user identities in the identity store referenced in the policy.
Note:
Contextual data is the information that is presented to or collected by Access Manager at various stages of user interaction. These stages include authentication, authorization, enterprise SSO, federation, adaptive authentication, token validation, session creation, and so on. The information itself might comprise a user's device fingerprints, IP address, antivirus and firewall protection, assertion and so on. Components that play the role of contextual data providers and asserters when integrated with Access Manager include Enterprise Single Sign-on, Identity Federation, Oracle Adaptive Access Manager.
Table 21-1 summarizes the components that support or enforce Access Manager policies, and where to find more information about these, if needed.
Note:
Default Access Manager behavior is to deny access when a resource is not protected by a policy that explicitly allows access. To delegate authentication tasks to Access Manager, agents must reside with the relying parties and must be registered with Access Manager. Registering an agent sets up the required trust mechanism between the agent and Access Manager SSO.
Table 21-1 Summary: SSO Components
| Component | Description |
|---|---|
|
Applications |
Applications can delegate 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. |
|
Non-administrative users first gain access by entering the URL of a protected resource, which returns the SSO login page. See Also: "Understanding Credential Collection and Login". Administrative users access the console to author policies by typing the URL: https://host:port/oamconsole. Although, default policies can be generated automatically during Agent registration, as described in Registering and Managing OAM 11g Agents. See Also: Managing Policies to Protect Resources and Enable SSO. |
|
Policy Enforcement Agents |
See Also: Introduction to Agents and Registration. |
|
Credential Collectors and Communication Channels |
See Also: Table 22-5 |
|
SSO Engine |
Manages the session lifecycle, facilitates global logout across all relying parties in the valid session, and provides consistent service across multiple protocols. See Also: Maintaining Access Manager Sessions and Configuring Centralized Logout for Sessions Involving 11g WebGates |
|
Proxy support for legacy systems |
See Also: About the Embedded Proxy Server and Backward Compatibility |
|
Access Policies |
Registered agents rely on Access Manager authentication, authorization, and token issuance policies to determine who gets access to protected applications (defined resources). Note: Default Access Manager behavior is to deny access when a resource is not protected by a policy that explicitly allows access. See Also: Managing Policies to Protect Resources and Enable SSO |
|
Policy Store |
Database in production environments (otherwise, oam-config.xml). See Also: Managing Data Sources |
|
Cryptographic keys and Key Storage |
One key is generated and used per registered mod_osso or 11g Webgate. However, one single key is generated for all 10g Webgates. See Also: Table 1-2. |
|
Cookies |
See: "Understanding SSO Cookies". |
Note:
Single Sign-on for the Oracle Access Management Console, and other Oracle Identity Management consoles deployed in a WebLogic container, is enabled using the pre-registered IAMSuiteAgent and companion policies. No further configuration is needed to protect the consoles.
Single sign-on can be implemented as introduced in Table 21-2, which includes pointers to additional information.
Table 21-2 Introduction to SSO Implementations
| SSO Type | Description |
|---|---|
|
Single Network Domain SSO |
You can set up Access Manager single sign-on for resources within a single network domain (example.com, for example). This includes protecting resources belonging to multiple WebLogic administration domains within a single network domain. Single Network Domain SSO is the subject of this book. |
|
Multiple Network Domain SSO |
Access Manager 11g supports cross-network-domain single sign-on out of the box. See Also:"Multiple Network Domain SSO". |
|
Application SSO |
Application single sign-on allows users who have been authenticated by Access Manager to access applications without being re-authenticated. See Also: "Application SSO and Access Manager" |
|
Multiple WebLogic Server Domain SSO |
The basic administration unit for WebLogic Server instances is known as a domain. You can define multiple WebLogic administration domains based on different system Administrators' responsibilities, application boundaries, or the geographical locations of WebLogic servers. However, all Managed Servers in a cluster must reside in the same WebLogic Server domain. See Also: "Multiple WebLogic Server Domain SSO" |
|
Reverse-Proxy SSO |
This SSO implementation type is supported with a few configuration differences. See Also: "Reverse-Proxy SSO" |
|
SSO with Mixed Release Agents |
Access Manager seamlessly supports registered 11g and 10g OAM gents (Webgates and programmatic access clients), as well as legacy OSSO Agents (mod_osso 10g), and legacy OpenSSO agents). These can be used in any combination. |
With Access Manager, this is a standard feature. When 11g WebGates are used exclusively all cookies in the system are host-based. However, you must have control over all the domains. If some domains are controlled by external entities (not part of the Access Manager deployment), Oracle recommends that you use Identity Federation.
Access Manager supports cross-network-domain single sign-on out of the box. During single sign-off with Access Manager:
The SSO cookie set by 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 Server for session clearing.
10g WebGates do not have a standalone Agent cookie; logout occurs only on the server side with no redirection required.
With 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:
Access Manager provides a proprietary multiple network domain SSO capability that predates Identity Federation 11.1.1. If this is implemented in your Oracle Access Manager 10g deployment, you can register 10g Agents with Access Manager 11g to continue this support.
See Also:
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 Access Manager 11g If the policy includes a redirect URL that is hosted by a Web server not protected by Access Manager, header responses are not applied.
For example, when a user authenticates, she might be redirected to a portal index page:
http://example.com/authnsuccess.htm
For authentication failure, an authentication action might redirect the user to an error page or a self-registration script:
http://example.com/authnfail.htm
Access Manager 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 Management 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.
Reverse-Proxy SSO is a supported configuration.
Following are certain caveats associated with this configuration:
Caveats
If you are going to use a reverse proxy in a single sign-on configuration, be sure to perform one of the following tasks. Otherwise, the reverse proxy hides the client's IP address:
Either to set the IPvalidation parameter to false
Or add the proxy IP address to the IPValidationExceptions list in the Webgate registration
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 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 filterOAMAuthnCookie parameter to false.