OAM architecture

OAM Architecture

Components

Oracle Access Manager is a typical 3 component model that consists of

1. Enforcement point (10g and 11g Webgate, 10g mod_osso, OpenSSO and other custom access gates based on Access SDK) that intercepts all the requests going to protected application and allows authenticated and authorized users to access the application. In addition to that enforcement points can, based on configuration, enhance the request being sent to protected application by adding HTTP Headers containing user information which can be consumed by the protected application.
2. Service point (Oracle Access Manager Server) - provides the various services that can be consumed by enforcement points, end users (e.g. federation, social), applications (e.g. Security Token Service, mobile)
3. Administration point (Oracle Access Administrator Server, wlst scripts, command line tools like rreg) - primarily a ADF based web application that is used to configure and manage the application.

In addition to that it leverages databases to store configuration (including keys) and policies along with runtime session and audit data. It typically leverages the Identity store like Directory (with LDAP interface) to read user details.

SSO Engine

It Manages the session lifecycle, facilitates global logout across all relying parties in the valid session, and provides consistent service across multiple protocols. It uses Agents registered with Access Manager 11g :

1. Authentication with the default embedded credential collector occurs across the HTTP (HTTPS) channel
2. Authentication with the optional detached credential collector occurs across the Oracle Access Protocol (OAP) channel
3. Authorization occurs across the Oracle Access Protocol (OAP) channel

SSO Engine enforces the global session specifications that are enabled for all Application Domains and resources. In addition, Application Domain-specific session overrides can be configured.

Proxy Server

Oracle Access Management server-side components include Proxy servers to maintain backward compatibility with Oracle Access Manager 10g policy-enforcement agents (10g Webgates and Access Clients) and OracleAS SSO 10g mod_osso (known as OSSO Agents in 11g), as well as OpenSSO Agents. 

OAM 10g : The OAM Proxy can accept requests from multiple Access clients concurrently and enables all Webgates and AccessGates (known as Access Clients in 11g) to interact with Access Manager. An Access Manager 11g ObSSOCookie created by OAM Proxy is compatible with the 10g ObSSOCookie created by Access Server..

Legacy OracleAS 10g (OSSO): The integrated OSSO proxy handles token generation and validation in response to token requests during authentication using OSSO Agents with Access Manager. The OSSO proxy needs no configuration. Simply register the OSSO agent as described in Chapter 15 and Chapter 16.

Stores

As shown above OAM uses the following stores 

#	Name	Supported	Default	Details	How to configure?	Content Managed through OAM?
1	Access Manager Policy	Database	Database oam-config.xml (Configuration)	Stores OAM Policy and configuration	Part of OAM server configuration. Can not be changed	Yes (OAM Console/Admin API)
2	Session Store	Memory Database	Memory	Stores active OAM sessions for failover	Common Settings → Sessions	Yes (OAM Server only)
3	Audit Data	File Database	File			No (write only)
4	User Identity	LDAP/Directory	Embedded Weblogic Directory (UserIdentityStore1)	User, Role and Group membership		No (read only)
5	Embedded Java Keystore
6	Security Token Keystore
7	Identity Federation Keystore

User Identity Store

There are two User Identity stores in the system that are special within the OAM. They are

1. System User Identity Store - This store is primarily used by OAM Server to identify OAM Administrators (that is users who can login and perform operations in OAM Administration Console i.e. /oamconsole) and associated information like group membership. This is used to authenticate Administrators signing in to use the Oracle Access Management Console, remote registration tools, and custom administrative commands in WLST.
2. Default User Identity Store - This store is designated as the Default Store and the automatic choice for use by LDAP authentication modules unless you configure use of a different store for the module or plug-in. Besides that this store is used by Identity Partners in case no identity store is defined for the same in Federation. In addition to that this is also used by the Security Token Service to map the Username token referencing the user to an LDAP User record, and thus use that record to populate the outgoing token.

During installation, the OAM server creates an identity store called UserIdentityStore1 which points to weblogic embedded LDAP server. This identity store is configured as the default and system user identity store.

Policy Store

The following data is maintained in the policy store database by default:

1. Policy data, including authentication modules and schemes, Application Domains, and policies.
2. Password Management data, which includes password policy type for each configured User Identity store as well as the policy that governs password requirements, expiry, notification,
3. Sessions, as a persistent backup to distributed in-memory storage

The Audit data, if configured, is stored in separate database.

Keystores

OAM uses multiple keystores as part of setup.

1. $DOMAIN_HOME/config/fmwconfig/.oamkeystore - used to store OAM Server's keys and STS (Security Token Service)'s private keys for signing and encryption. In addition to that it is also used to store the encryption and signing certificates for identity federation.
2. $DOMAIN_HOME/config/fmwconfig/amtruststore - used to validate keys and certificates presented by clients to establish trust in entities interacting with OAM Server instances
3. $DOMAIN_HOME/config/fmwconfig/amcrl.jar - zipped up Certificate Revocation List files in the DER format
4. $DOMAIN_HOME/config/fmwconfig/default-keystore.jks - used by Oracle Webservice Manager (OWSM) agent for various cryptographic operations
5. $DOMAIN_HOME/config/fmwconfig/.cohstore.jks - used by coherent to encrypt the communication between nodes.

More details are available here.

Interface

Oracle Access Manager Server

The following interfaces are provided by Oracle Access Manager Server

1. Front channel protocol (available on server port) - this HTTP/HTTPS based protocol is used by webgate to communicate with OAM Server. This protocol is primarily based on browser redirects
2. Back channel protocol (available on proxy port) - primarily extension of proprietary OAM protocol used to manage sessions by authenticated clients 
3. Proxy protocols (available on Proxy port) - are legacy protocols that are supported by OAM to allow interoperability with old enforcement points like 10g Webgate, mod_sso and OpenSSO agents)

Both back channel and proxy protocols are available through the single port identified as proxy port in the configuration process. The back channel/proxy interface can be established using open, simple, cert mode based on level of security required.