The following topics provide information about:
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:
User name
User GUID (global user identity)
Language and territory
After registration with Access Manager, OSSO 10g Agents can communicate directly with Access Manager 11g services through the OSSO proxy. The OSSO proxy supports existing OSSO agents when upgrading to Access Manager. The proxy handles requests from OSSO Agents and translates the OSSO protocol into a protocol for Access Manager 11g authentication services.
The OSSO Proxy supports inter-operability between Access Manager and OSSO agents (using an OSSO agent to access a valid SSO session created for a Webgate or Access Client and vice versa).
OSSO Proxy Supports | Description |
---|---|
SSO login |
From an OSSO Agent to the OAM Server (and OSSO-specific tokens) |
SSO logout |
From the OSSO Agent to the OAM Server |
OSSO Agent requests and protocols |
OSSO Proxy translates the OSSO protocol into a protocol for Access Manager. |
After registering 10g mod_osso as an agent, Access Manager gives mod_osso the redirect URL for the user based on the authentication scheme associated with the OAM policy defined for the resource (Table 29-1).
Table 29-1 OSSO Agents with Access Manager
OSSO Agents | Access Manager |
---|---|
Checks for an existing valid Oracle HTTP Server cookie |
Redirects to the OAM Server if needed to contact the directory during authentication |
Decrypts the encrypted user identity populated by the OSSO server |
Sets the headers with user attributes |
This topic introduces key components for implementing and enforcing Access Manager 11g single sign-on policies as compared to OSSO 10g. Access Manager 11g default behavior is to deny access when a resource is not protected by a policy that explicitly allows access. OracleAS SSO 10g provides only authentication.
Table 29-2 summarizes the differences.
Table 29-2 11g Access Manager SSO versus OSSO 10g Component Summary
Component Description | 11g Access Manager | OSSO 10g |
---|---|---|
Oracle Identity Management Infrastructure |
Enables secure, central management of enterprise identities. |
Enables secure, central management of enterprise identities. |
Agents Resides with the relying parties and delegate authentication and authorization tasks to OAM Servers. |
Note: Nine Administrator languages are supported. |
|
Servers Notes: Administrative users access the console home page by typing the URL: https://host:port/oamconsole. Non-administrative users first gain access to the single sign-on server by entering the URL of an application, which returns the SSO login page. |
See Also: |
|
Proxy Provides support for legacy systems: |
|
|
Console |
Oracle Access Management Console |
No console equivalent before Access Manager 11g. |
Protocols that secure information exchange on the Internet |
Front channel protocols exchanged between Agent and Server: HTTP/HTTPS. 11g Webgate secures information exchange using the Agent key. -See Also: Cryptographic keys. |
N/A |
Policy Store |
Database |
mod_osso and partner application |
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. |
An application that delegates authentication to mod_osso and the OracleAS Single Sign-On server. Note: After registering mod_osso with Access Manager 11g, mod_osso delegates authentication to OAM. The mod_osso module enables the 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 application is responsible for determining whether the authenticated user is authorized to use the application. |
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:
|
|
Cryptographic keys |
Note: One key is generated and used per registered mod_osso Agent. However, one single key is generated for all 10g Webgates. |
|
Keys storage |
|
|
Cookies See Also: Table 21-6 and |
Host-based authentication cookie:
|
|
Policies |
Registered agents rely on Access Manager authentication, authorization, and token issuance policies to determine who gets access to protected applications (defined resources). |
mod_osso uses only Access Manager 11g authentication policies to determine who gets access to defined resources. mod_osso provides authentication only. |
Client IP |
|
|
Encryption / Decryption (converting encrypted data back into original form) |
Introduces client-side cryptography and ensures that cryptography is performed at both the agent and server ends:
|
Cryptography is performed at both mod_osso and OSSO server:
|
Session Management |
|
|
Response token replay prevention |
|
|
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. |
N/A |
Centralized log-out |
See Configuring Centralized Logout for Sessions Involving 11g WebGates. |
There is no change required for Access Manager 11g with mod_osso (OSSO Agents). Applications that use dynamic directives require no entry in mod_osso.conf. Instead, protection is written into the application as one or more dynamic directives. See Configuring Centralized Logout for Sessions Involving 11g WebGates. |
See Also: