29.1 Understanding OSSO Agents with Access Manager

The following topics provide information about:

29.1.1 About OSSO Agents with Access Manager

The mod_osso module is an Oracle HTTP Server module that simplifies the authentication process by serving as the sole application to the single sign-on server. In this way, mod_osso renders authentication transparent to OracleAS applications. It 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 in. The values for these headers are stored in a mod_osso cookie.

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

29.1.2 Comparing Access Manager 11g SSO versus OSSO 10g

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.	11g OAM Agents 10g OAM Agents 10g OSSO Agents (mod_osso) OpenSSO Agents Note: Nine Administrator languages are supported.	mod_osso (partner) Note: The mod_osso module is an Oracle HTTP Server module that provides authentication to OracleAS applications.
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.	OAM Server Oracle Access Management Console (installed on the WebLogic Administration Server) See Also: "Understanding the Oracle Access Management Console" "Understanding Credential Collection and Login"	OracleAS SSO server (OSSO server) See Also: .
Proxy Provides support for legacy systems:	OAM Proxy supports legacy Access Manager implementations by acting as a legacy Access Server. OSSO Proxy supports OSSO Agents by acting as the legacy OSSO Server. Oracle-provided OpenSSO Proxy handles requests for resources protected by OpenSSO Agents	OSSO Proxy supports legacy SSO implementations by acting as the legacy OSSO Server.
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: 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.
Cryptographic keys	During 11g agent registration, a 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 Access Manager 11g (all Agents and OAM Servers). During OSSO agent registration, One key per partner shared between mod_osso and OSSO server. OpenSSO Agent: Host- or Domain-based key stored locally in bootstrap file on Agent host. During OAM Server installation, one OAM Server key is generated Note: One key is generated and used per registered mod_osso Agent. However, one single key is generated for all 10g Webgates.	One key per partner shared between mod_osso and OSSO server OSSO server's own key One global key per OSSO setup for the GITO domain cookie
Keys storage	Agent side: A per-agent key is stored locally in the Oracle Secret Store in a wallet file OAM Server side: A per- agent key, and server key, are stored in the credential store on the server side Security Token Service	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: Table 21-6 and "Single Sign-On Cookies During User Login"	Host-based authentication cookie: 11g Webgate, One per agent: OAMAuthnCookie_<host:port>_<random number> 10g Webgate, One ObSSOCookie for all 10g Webgates. One for the OAM Server: OAM_ID (Table 21-6)	Host-based authentication cookie: one per partner: OHS-host-port one for OSSO server: (not with Access Manager 11g) Domain-level session cookie for global inactivity timeout (GITO) if enabled
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	Maintain this Client IP, and include it in the host- based OAMAuthnCookie.	Include the original client IP inside the host cookie. In later authentication requests, when the cookie is presented, the original client IP is compared with the presenter's IP. Rejection occurs if there is no match
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: 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.	Cryptography is performed at both mod_osso and OSSO server: site2pstore token (request from mod_osso to server) is encrypted using the partner key locally at mod_osso. OSSO server decrypts site2pstore token, authenticates, and generates its own cookie. urlc token (the response from OSSO server to mod_osso) is encrypted using the partner key at the server. mod_osso decrypts the urlc token locally and re-encrypts using its own format to set in a host-based cookie.
Session Management	Session idle timeout behavior is supported through the 11g Session Management Engine (SME).	Single domain supported through a domain-level cookie for global inactivity timeout (GITO). Multi-domain SSO: After a user logs in to one domain, and then goes to a different domain, he is considered idle from the first domain. When the idle times out on the original domain, the user must re-authenticate on the original domain.
Response token replay prevention	Include RequestTime (the timestamp just before redirect) in obrareq.cgi and copy it to obrar.cgi to prevent response token replay.	Include RequestTime (timestamp just before redirect) in the site2pstore token and copy it to the urlc token to prevent 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.	N/A
Centralized log-out	The `logOutUrls` (10g Webgate configuration parameter) is preserved. 10g logout.html requires specific details for Access Manager 11g. 11g Webgate parameters are new: `Logout Redirect URL` `Logout Callback URL` `Logout Target URL` 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.