Oracle Access Manager 11g Architecture Explained

Below is the OAM 11g explained from Oracle documentation:

Introduction to Oracle Access Manager 11g Architecture

Oracle Access Manager 11g provides a full range of Web perimeter security functions that include Web single sign-on; authentication and authorization; policy administration; auditing, and more.

• About Oracle Access Manager 11g Architecture
• Comparing Oracle Access Manager 11g with OAM 10g and OSSO 10g

About Oracle Access Manager 11g Architecture

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

• Oracle Access Manager 10g
• Oracle Application Server SSO (OSSO) 10g
• Oracle Sun OpenSSO

As illustrated in Figure 2-1, all user identities, policies, and audit records reside in centrally managed data stores. Oracle WebLogic Server provides domain management, deployment management, and post-installation configuration. Oracle Access Manager manages all agents and policies centrally.

Figure 2-1 Oracle Fusion Middleware Access Management Architecture

Both Oracle WebLogic Server and Oracle Access Manager 11g rely on the Oracle Platform Security Services for authentication, authorization, secure communication (SSL), the common Audit Framework, as well as the credential store, and identity services.
Shared services for Access (SSA) include token processing, session management. Shared services for identity (SSI) include password reset, password policy, and delegated administration through Oracle Identity Manager.
Fraud prevention, security token service, identity federation, authentication and SSO, and authorization and Entitlements are integrated.
Figure 2-2 illustrates the primary Oracle Access Manager 11g components and services. The Protocol Compatibility Framework interfaces with OAM WebGates, mod_osso agents, and custom AccessGates created using the Access Manager Software Developer Kit (SDK).

Figure 2-2 Oracle Access Manager 11g Components and Services

Figure 2-3 illustrates the distribution of Oracle Access Manager components.

Figure 2-3 Component Distribution

The Oracle Access Manager Administration Console (sometimes referred to as the Oracle Access Manager Admin Server) 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
• Oracle Access Manager policies
• User session data is shared among all OAM Servers

For more information, see "Comparing Oracle Access Manager 11g with OAM 10g and OSSO 10g".

Comparing Oracle Access Manager 11g with OAM 10g and OSSO 10g

This topic introduces Oracle Access Manager 11g architecture and provides a comparison against the 10g architecture for Oracle Access Manager and OSSO. Included are the following topics:
Oracle Access Manager 11g differs from Oracle Access Manager 10g in that the identity administration features have been transferred to Oracle Identity Manager 11g (including user self-service and self registration, workflow functionality, dynamic group management, and delegated identity administration).
Oracle Access Manager 10g supported Single Sign-on using a single session cookie (the ObSSOCookie) that contained the user identity and user session information required to access target resources that had the same or lower authentication level. The ObSSOCookie was encrypted and decrypted using a global shared secret key, the value of which was stored in the directory server. The ObSSOCookie was consumed by Access System components to verify the user identity and allow or disallow access to protected resources.
To close any possible security gaps, Oracle Access Manager 11g provides new server-side components that maintain backward compatibility with existing Oracle Access Manager 10g policy-enforcement agents (WebGates) and OSSO 10g agents (mod_osso). New Oracle Access Manager 11g WebGates are enhanced versions of 10g WebGates, that support a per-agent secret key for the Single Sign-on (SSO) solution. Thus, cookie-replay type of attack are prevented. The 11g WebGates are all trusted at the same level; a cookie specific for the WebGate is set and cannot be used to access any other WebGate-protected applications on a user's behalf.
Unless explicitly stated, the term "WebGate" refers to both an out of the box WebGate or a custom AccessGate.
Oracle Access Manager 11g uses technology from Oracle Coherence to provide centralized, distributed, and reliable session management.
For a list of names that have changed with Oracle Access Manager 11g, see "Product and Component Name Changes". Table 2-1 provides a comparison of Oracle Access Manager 11g, OAM 10g, and OracleAS SSO 10g.

Table 2-1 Comparison: OAM 11g versus OAM 10g versus OSSO 10g

	OAM 11g	OAM 10g	OSSO 10g
Architecture Components	Agents: WebGate, AccessGate, mod_osso, and IDM Domain Agent OAM Server OAM Administration Console (installed on WebLogic Administration Server) Note: Eight Administrator languages are supported.	Resource WebGate (RWG) Authentication WebGate (AWG) Access Server Policy Manager Note: Eight Administrator languages are supported.	mod_osso (partner) OracleAS SSO server (OSSO server)
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	Domain-based ObSSOCookie for WebGates (including the AWG), for both authentication and session management	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 (for interoperability with OAM 11g)
Cryptographic keys The protocols used to secure information exchange on the Internet.	One per agent secret key shared between WebGate and OAM Server One OAM Server key	One global shared secret key for all 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
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 credential store on the server side	Global shared secret stored in the directory server only (not accessible to WebGate)	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
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 11g server to WebGate. WebGate decrypts obrar.cgi, extracts the authentication token, and sets a host-based cookie.	Token generation/ encryption, and validation/ decryption are delegated to the Access Server. Both obrareq.cgi and obrar.cgi are sent unencrypted, relying on the underlying HTTP(S) transport for security.	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	OAM 10g session idle timeout behavior is supported through the Session Management Engine (SME). Session states are retained in memory	Single domain supported. Multi-domain: If a user idles out on one domain, but not on the authentication WebGate, the AWG cookie is still valid, re-authentication is not needed.A new cookie is generated with the refreshed timeout.	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.
Client IP	Maintain this ClientIP, and include it in the host- based OAMAuthnCookie.	Include the original clientIP inside the ObSSOCookie. If IP validation is configured, when cookie presented in later authentication or authorization requests this original clientIP is compared with the presenter's IP. Rejection occurs if there is no match	Include the original clientIP 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
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.	N/A	Include RequestTime (timestamp just before redirect) in the site2pstore token and copy it to the urlc token to prevent token replay.
Centralized log-out	The logOutUrls (OAM 10g WebGate configuration parameter) is preserved. New 11g WebGate parameters are provided: logoutRedirectUrl logoutCallbackUrl Logout Target URL For more information, see Chapter 11.	Single domain is supported. Once a user logs off from one WebGate, the domain cookie is cleared and the user is considered to be logged off the entire domain. Multi-domain SSO can be supported through chained customized logout pages.	The OSSO server cookie includes a list of partner IDs. When a user logs off from one partner application: OSSO server pulls a list of the logout URLs. OSSO server clears its own cookie. OSSO server redirects to a customized JSP page (hosted on the OSSO server), and passes the list of logout URLs in the request. The JSP page loads those logout URLs that contains some image tags of check marks, and as a result of the loading, the cookies for those mod_osso instances are cleared