6 Configuring High Availability for Oracle Access Management Access Manager Components

This chapter provides an introduction to Oracle Access Management Access Manager (Access Manager) and describes how to design and deploy a high availability environment for Access Manager.

Access Manager provides a single authoritative source for all authentication and authorization services. The core service provided is the checking of valid session tokens, the requesting of credentials if the session token is invalid or missing, and the issuing of session tokens, intercepting resource requests and evaluating access control policies to control access to resources. Access Manager features a pure Java server while continuing to use Oracle Single Sign-On 10g and Oracle Access Manager 10g agent components. For more information on Access Manager, see Introduction to Oracle Access Management Access Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

This chapter includes the following topics:

Section 6.1, "Access Manager Component Architecture"
Section 6.2, "Access Manager High Availability Concepts"
Section 6.3, "Access Manager High Availability Configuration Steps"

6.1 Access Manager Component Architecture

Figure 6-1 shows the Access Manager component architecture.

Figure 6-1 Access Manager Single Instance Architecture

Description of "Figure 6-1 Access Manager Single Instance Architecture"

Figure 6-1 shows the following components:

User agents: These include web browsers, Java applications, and Web services applications. The user agents access the Access Server and the administration and configuration tools using HTTP.
Protected resources: A protected resource is an application or web page to which access is restricted. Access to protected resources is controlled by WebGates or Custom Agents.
Administration and configuration tools: Administer and configure Access Manager with the Oracle Access Management Console, the Oracle Enterprise Manager Fusion Middleware Control and the Oracle Enterprise Manager Grid Control, and the WebLogic Scripting Tool (WLST).
Access Server: The Access Server includes the Credential Collector, OSSO Proxy, and OAM Proxy components. The Coherence Distributed Object Cache is used to propagate configuration file changes between Access Servers

6.1.1 Access Manager Component Characteristics

An Access Manager deployment consists of these system entities:

Access Manager Agents - Access Manager agents are extensions of the Access Server that are responsible for ensuring that access is controlled according to policies that Access Server manages.

Agents require the Access Server component to perform their functions. If the Access Server is unavailable, access to protected servers is not permitted and users are locked out of the system.
Protected Resources (partnered applications) - Applications that are protected by Access Manager. Access to these resources is subject to the access control policies in Access Manager and is enforced by Access Manager agents that are deployed in the access path of the protected resource (for example, Access Manager agents deployed in the Web Server).
Access Server - The server side component that provides core runtime access management services.
JMX Mbeans - Runtime Mbeans are packaged as part of the Access Server package. Config Mbeans are packaged as standalone WAR files.
WebLogic 11g SSPI providers are composed of Java classes that implement the SSPI interface along with the Access Java Access JDK. AccessGates are built using the pure Java Access JDK.
Oracle Access Management Console - A J2EE application that hosts the Administration Console and provides services like Administration/Configuration to manage the Access Manager deployment.
WebLogic Scripting Tool (WLST) is composed of Java classes, which are included in the Access Server package. Limited administration of the Access Manager deployment is supported via the command line.
Fusion Middleware Control and Enterprise Manager Grid Control - Access Manager integrates with the Enterprise Manager Grid Control to display performance metrics and deployment topology.
Coherence Distributed Object Cache - Access Manager components rely on this infrastructure for real time change propagation.
The Access Manager Proxy is a customized version of the Apache MINA server (based on the JCA architecture), which includes MessageDrivenBeans and ResourceAdapters in addition to Java Server classes.
The Oracle Single Sign-On (OSSO) Proxy comprises Java classes, which are included in the Access Server package.
Data Repositories - Access Manager handles different types of information including Identity, Policy, Partner, Session and Transient data:
- LDAP for Identity data
- Files for Configuration and Partner data
- Coherence in-memory for Session and Transient Data
- Policy data will be stored in files or in an RDBMS
Oracle Access Manager 10g WebGates are C-based agents that are intended to be deployed in web servers.
Oracle Single Sign-On Apache modules are C-based agents that are intended to be deployed in Oracle HTTP Server web servers.
Access Manager 11g WebGates are C-based agents that are intended to be deployed in web servers.

6.1.1.1 Access Manager State Information

Authenticated user session information is persisted via the Coherence Distributed Object Cache. Use the Coherence Distributed Object Cache in-memory mode for Access Manager.

Access Manager may create a transient state for unauthenticated users during the login processing. This state is generally not replicated among Access Manager nodes. To protect against effects of node failures during the login processing, the state may be optionally stored in an encrypted client cookie.

To store the transient state for unauthenticated users during login processing, change the OAM server parameter RequestCacheType from BASIC to COOKIE by following these steps:

Set up the environment for WLST by running this command:
```
DOMAIN_HOME/bin/setDomainEnv.sh
```

Start WLST by issuing this command:

Start WLST by issuing this command:
ORACLE_HOME/common/bin/wlst.sh

Connect to your domain:

wls:/IDM_Domain/serverConfig> connect()

Enter the WebLogic Administration username and password, and enter the URL for the Administration Server in the format:
```
t3://OAMHOST1.example.com:7001
```

Issue this command:

wls:/IDM_Domain/serverConfig> configRequestCacheType(type="COOKIE")

Check that the command worked by issuing this command:

wls:/IDM_Domain/serverConfig> displayRequestCacheType()

Restart the Access Manager managed servers.

6.1.1.2 Access Manager Request Flow

The following list describes the steps in an Access Manager request flow:

The user tries to access a Access Manager protected Web Resource using a web browser.
The Access Manager agent^Foot 1 intercepts the request and tries to ascertain if the user has an authenticated session.
Because this is the user's first access, the user is redirected to the Access Manager 11g Access Server for authentication.
Access Server's credential collector^Foot 2 component shows a Login Form.^Foot 3 The user submits his credentials to the Access Server.
Access Server validates the user credentials and generates a security token (cookie). The user is redirected to the resource he tried to access in Step 1.
The Access Manager agent intercepts the request and extracts the security token (cookie).
The Access Manager agent makes a back channel call^Foot 4 to the Access Server (OAP over TCP) to validate the session and authorize the request.
Access server verifies the user's permissions against the configured policy for the web resource.
Access server responds to the WebGate request indicating that access is enabled.
The Access Manager agent allows the request to go through.^Foot 5
The user can now access the web resource he tried to access in Step 1.

6.1.1.2.1 Access Manager Process Lifecycle

You can start Access Server and Administration Console from the user interface and command line tools that WebLogic Server provides.

The Access Server supports a health check request (a ping request over HTTP) that the load balancer can use for death detection.

Access Manager agents are native applications that reside in the protected application environment. No tools are provided as part of OAM but it is expected that environment specific tooling, where available, will be leveraged for the above purpose.

Access Manager is instrumented for server side metrics (using DMS) and this information is published to the WebLogic Administration Console. Using DMS metrics collection, you can monitor the agent and server component metrics as a proxy for component monitoring. In addition, Access Manager supports fine-grained real time activity tracing, which can also serve as a proxy for component monitoring.

On startup, Access Server initializes connections to the backend repositories. If the repository is not reachable, the Access Server retries the connections to the repositories, using a timeout that grows exponentially with a configurable upper bound.

Access Server will provide continuity of service based on locally cached data if the backend connections go down. This will continue until the caches grow stale or the backend connections become alive again.

6.1.1.2.2 Access Manager Configuration Artifacts

The Access Manager configuration artifacts include these files:

DOMAIN_HOME/config/fmwconfig/oam-config.xml

The configuration file, which contains instance specific information.
DOMAIN_HOME/config/fmwconfig/oam-policy.xml
DOMAIN_HOME/config/fmwconfig/.oamkeystore

This is used for storing symmetric and asymmetric keys.
DOMAIN_HOME/config/fmwconfig/component_events.xml

Used for audit definition.
DOMAIN_HOME/config/fmwconfig/jazn-data.xml

Used for Administration Console permissions
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml

Used for logging configuration. Do not edit this file manually.
DOMAIN_HOME/config/fmwconfig/servers/instanceName/dms_config.xml

Used for tracing logging. Do not edit this file manually.
DOMAIN_HOME/config/fmwconfig/cwallet.sso

Used to store passwords that OAM uses to connect to identity stores, database, and other entities. This is not for end user passwords.

6.1.1.2.3 Access Manager External Dependencies

Access Manager has external runtime dependencies on:

LDAP based Identity Store
- User Identity Repository
- LDAP access abstracted by User/Role API.
  
  Note:
  
  Access Manager always connects to one Identity store, which can be a physical server or a load balancer IP. If the primary is down, Access Manager reconnects and expects the load balancer to connect it to the secondary.
OCSP Responder Service
- Real-time X.509 Certification Validation
RDBMS Policy Store
- Policy (Authentication and Authorization) Repository
- RDBMS access abstracted by the OAM policy engine
Oracle Identity Manager (when OIM-based password management is enabled)
- Oracle Identity Manager provides Password Management Services and replaces the Oracle Access Manager 10g Identity Server
Oracle Identity Manager Policy Store (when Oracle Identity Manager-based password management is enabled)
- LDAP Repository containing Oblix Schema elements that are used to store Configuration, Metadata, and so on.
Oracle Adaptive Access Manager (when Oracle Adaptive Access Manager Advanced Authentication Scheme is selected)
Identity Federation (when Identity Federation Authentication Scheme is selected)

6.1.1.2.4 Access Manager Log File Location

Access Manager is deployed on WebLogic Server. All log messages log to the server log file of the WebLogic Server that the application is deployed on. The default server log location is:

WL_HOME/user_projects/domains/domainName/servers/serverName/logs/
serverName-diagnostic.log

6.2 Access Manager High Availability Concepts

This section provides conceptual information about using Access Manager in a high availability two-node cluster.

6.2.1 Access Manager High Availability Architecture

Figure 6-2 shows an Access Manager high availability architecture:

Figure 6-2 Access Manager High Availability Architecture

Description of "Figure 6-2 Access Manager High Availability Architecture"

In Figure 6-2, incoming authentication requests are received by the hardware load balancer, which routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed. The Oracle HTTP Server then forwards requests on to the WebLogic managed servers using the WebLogic plugin mod_wl_ohs.conf. A Distributed Credential Collector enables a WebGate to collect the credentials and send them to the Access Manager server by means of the OAP protocol.

The load balancing router should use session stickiness for HTTP traffic only. OAP traffic does not use a load balancing router, so session stickiness is not required for OAP traffic.

Applications that other Oracle HTTP Servers access that in turn have resources with restricted access must have a WebGate, Oracle Single Sign-On Server agent (mod_osso agent), OpenSSO Policy agent, or custom agent configured. The WebGate on WEBHOST3 communicates with the Access Servers on OAMHOST1 and OAMHOST2 in the application tier using OAP. WEBHOST3 is an application web server, and for authentication, HTTP redirect is used to route requests to the load balancer and to WEBHOST1 and WEBHOST2. For a high availability deployment, you can optionally configure another host (for example, WEBHOST4) with the same components as WEBHOST3.

OAMHOST1 and OAMHOST2 deploy managed servers which host the Oracle Access Server application. These managed servers are configured in a cluster which enables the Access Servers to work in an active-active manner.

The WebLogic Administration Server runs on OAMHOST1 and deploys the WebLogic Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and the Oracle Access Management Console. The Administration Server can be configured to run in active-passive mode on OAMHOST2, which means that if OAMHOST1 becomes unavailable, then Administration Server can be manually started on OAMHOST2.

In the directory tier, the virtual IP ovd.example.com is set up to route Oracle Virtual Directory requests to OVDHOST1 and OVDHOST2, which comprise an active-active Oracle Virtual Directory cluster. The virtual IP oid.example.com is set up to route Oracle Internet Directory requests to OIDHOST1 and OIDHOST2, which comprise an active-active Oracle Internet Directory cluster.

An Oracle RAC database provides high availability in the data tier.

In Access Manager 11g, only one Access Manager cluster is supported per WebLogic Server domain. Access Manager clusters cannot span WebLogic Server domains.

A single instance Access Manager deployment satisfies the following high availability requirements:

Load handling
External connection management and monitoring
Recovery
Fault containment
Fault diagnostics
Administration Server offline

A multiple instance Access Manager deployment satisfies the following additional high availability requirements:

Redundancy
Client connection failover/continuity
Client load balancing
State management

Use of an external load balancing router is recommended for inbound HTTP connections. Outbound external connections to LDAP Servers (or OAM policy engine PDP/PIP) are load balanced with support for connection failover. Therefore, a load balancer is not required. Access Manager agents, typically WebGates, can load balance connections across multiple Access Servers.

Access Manager agents open persistent TCP connections to the Access Servers. This requires firewall connection timeouts to be sufficiently large to avoid premature termination of TCP connections.

The Access Server and Access Manager Administration Console interface with the OAM policy engine for policy evaluation and management. The OAM policy engine internally depends on a database as the policy repository. The database interactions are encapsulated within the OAM policy engine, with only the connectivity configuration information managed by Access Manager. The high availability characteristics of the interaction between Access Manager and the OAM policy engine are:

The database connection information is configured in the Access Manager configuration file synchronized among the Access Manager instances.
Database communication is managed within the OAM policy engine, and generally decoupled from Access Manager and OAM policy engine interactions. The very first startup of an OAM server instance will fail, however, if the database is unreachable. An OAM policy engine bootstrap failure is treated as fatal by Access Manager, and the startup operation is aborted.
Transient database unavailability is transparently tolerated by OAM policy engine policy evaluation services, enabling Access Manager server runtimes to continue functioning uninterrupted. After the initial OAM policy engine bootstrap, the Access Manager instances may restart while the database is unreachable; the OAM policy engine continues to operate against its locally cached policies.
Access Manager policy management interfaces (in the Oracle Access Management Console and the CLI tool) fail if the database is unreachable, as seen by the OAM policy engine management service interfaces. The operation may be retried at a later point in time, but no automated retry is provided for management operations.
Following a successful policy modification in the database repository, the OAM policy engine layer in the OAM server runtimes retrieves and activates the changes within a configurable OAM policy engine database poll interval (configured through Access Manager configuration). A positive acknowledgement of a policy change must be received from each OAM server runtime, otherwise the policy change cannot be considered successfully activated. The administrator can use the Oracle Access Management Console to remove any Access Manager instance with a policy activation failure from service.

6.2.1.1 Starting and Stopping the Cluster

In a high availability architecture, OAM server is deployed on an Oracle WebLogic Cluster, which has at least two servers as a part of the cluster.

By default, WebLogic Server starts stops, monitors and manages the various lifecycle events for the application. The Access Manager application leverages the high availability features of the underlying Oracle WebLogic Clusters. In case of hardware or other failures, session state is available to other cluster nodes that can resume the work of the failed node.

In a high availability environment, WebLogic Node Manager is configured to monitor the WebLogic Servers. In case of failure, Node Manager restarts the WebLogic Server.

6.2.1.1.1 Cluster-Wide Configuration Changes

The standard Java EE artifacts that Access Manager uses are configured as part of the Oracle WebLogic domain in which Access Manager is installed. Oracle WebLogic Clusters provide automatic configuration synchronization for artifacts, such as data sources, across the WebLogic Server domain. At the same time, the WebLogic Server cluster synchronizes the deployments and libraries used by the Access Manager components.

Additionally, Access Manager application level configuration is stored in the Access Manager repository. Propagation of Access Manager configuration changes to all the cluster members is based on a distribution mechanism that leverages the Coherence Distributed Object Cache. All Access Manager components are notified of change events from the coherence layer, which are then taken up by the components. To ensure atomicity of the change, Access Manager components reload their entire configuration every time a change happens.

Access Manager configuration applies to all instances in a cluster. The only exceptions to the above (instance-specific configuration) supported in Access Manager are the Access Manager proxy host, Access Manager proxy port, and the instance-specific Coherence configuration (when Well Known Addresses (WKA) is used). The IP address of the proxy host and proxy port are stored in a configuration file. The Access Manager proxy port is the endpoint for OAP requests from agents. The IP address of the Coherence WKA is also stored in a configuration file. The Coherence WKA is used to determine the Coherence nodes that are authorized to receive Access Manager-specific traffic. The oam-config.xml file is the configuration file that stores this configuration information.

Adding and removing Access Server instances is transparent to other Access Manager Access Server instances in the cluster. However, take care to ensure that the removal of a specific Access Server does not affect the load balancing and failover characteristics of the agents.

Restarting an Access Manager Access Server has no impact on any other running components or members of the cluster.

6.2.2 Protection from Failures and Expected Behaviors

This section describes how an Oracle Identity Management high availability cluster deployment protects components from failure and expected behavior if component failure occurs.

The WebLogic Server infrastructure protects the Identity Management Service Infrastructure system from all process failures.

The following features protect the Access Manager high availability configuration from failure:

Back channel OAP bindings use a primary/secondary model for failover. Front Channel HTTP bindings use a load balancing router for failover.
Session state is maintained in the Coherence Distributed Object Cache, which provides replication and failover for all session state information. Data stored in the Coherence cache is written asynchronously to a database. This data should survive a restart of all access servers, however, a small amount of data can be lost due to the asynchronous nature of the write through.
If an Access Server fails, a WebGate with a persistent connection to that server waits for the connection to timeout, then it switches over to the secondary (backup) Access Server. Outstanding requests fail over to the secondary server.
Access Manager Access Servers support a heartbeat check. Also, the WebLogic Node Manager on the Managed Server can monitor the application and restart it.
If a WebLogic Server node fails, external connection failover is based on the configuration, the retry timeout, and the number of retries. Access Manager Agent-Access Server failover is based on a timeout.
If the load balancing router or proxy server detects a WebLogic Server node failure, subsequent client connections route to the active instance, which picks up the session state and carries on with processing.
When the lifetime of a connection expires, pending requests complete before the connection terminates. The connection object returns to the pool.
When it receives an exception from another service, Access Manager retries external connection requests. You can configure the number of retries.

6.2.2.1 WebLogic Server Crash

If a WLS_OAMx server fails, Node Manager attempts to restart it locally

Ongoing requests from the HTTP Server timeout and new requests are directed to the other WLS_OAMx server. Once the server's restart completes on the failed node, Oracle HTTP Server resumes routing any incoming requests to the server.

Note:

Access Manager servers support a heartbeat check to determine if the access server can service its requests. It checks:

Whether the LDAP store can be accessed
Whether the policy store can be accessed

If the heartbeat succeeds, the Access Server can service requests and requests are sent to it. If the heartbeat fails, requests do not route to the Access Server.

6.2.2.2 Node Failure

Node failures are treated in the same way as WebLogic Server fails.

6.2.2.3 Database Failure

The Access Manager service Infrastructure is protected against failures in the database by using multi data sources. These multi-data sources are typically configured during the initial set up of the system (Oracle Fusion Middleware Configuration Wizard enables you to define these multi-pools directly at installation time). They guarantee that when an Oracle RAC database instance fails, the connections are reestablished with available database instances. The multi data source enables you to configure connections to multiple instances in an Oracle RAC database.

For information about multi data source configuration with Oracle RAC and the MDS repository, see Section 4.1.3, "Using Multi Data Sources with Oracle RAC."

6.3 Access Manager High Availability Configuration Steps

This section provides high-level instructions for setting up a high availability deployment for Access Manager. This deployment includes two Oracle HTTP Servers, which distribute requests to two OAM servers. These OAM servers interact with an Oracle Real Application Clusters (Oracle RAC) database and, optionally, an external LDAP store. If any single component fails, the remaining components continue to function.

This section includes the following topics:

Section 6.3.1, "Prerequisites for Access Manager Configuration"
Section 6.3.2, "Running the Repository Creation Utility to Create the Database Schemas"
Section 6.3.3, "Installing Oracle WebLogic Server"
Section 6.3.4, "Installing and Configuring the Access Manager Application Tier"
Section 6.3.5, "Configuring the Database Security Store"
Section 6.3.6, "Creating boot.properties for the Administration Server on OAMHOST1"
Section 6.3.7, "Starting OAMHOST1"
Section 6.3.8, "Validating OAMHOST1"
Section 6.3.9, "Configuring OAM on OAMHOST2"
Section 6.3.10, "Starting OAMHOST2"
Section 6.3.11, "Validating OAMHOST2"
Section 6.3.12, "Configure Access Manager to Work with Oracle HTTP Server"
Section 6.3.13, "Configuring Access Manager to use an External LDAP Store"
Section 6.3.14, "Validating the Access Manager Configuration"
Section 6.3.15, "Configuring Oracle Coherence to Keep Configuration Files in Sync"
Section 6.3.16, "Scaling Up and Scaling Out the Access Manager Topology"

6.3.1 Prerequisites for Access Manager Configuration

Before you configure Access Manager for high availability, you must:

Run the Repository Creation Utility to create the Access Manager schemas in a database. See Section 6.3.2, "Running the Repository Creation Utility to Create the Database Schemas".
Install Oracle WebLogic Server on OAMHOST1 and OAMHOST2. See Section 6.3.3, "Installing Oracle WebLogic Server".
Install the Oracle Identity Management executables on OAMHOST1 and OAMHOST2. See the Section 6.3.4, "Installing and Configuring the Access Manager Application Tier".
Ensure that a highly available LDAP implementation is available.

6.3.2 Running the Repository Creation Utility to Create the Database Schemas

The schemas you create depend on the products you want to install and configure. Use the Repository Creation Utility (RCU) that is version compatible with the product you are installing. See the Oracle Fusion Middleware Installation Planning Guide for Oracle Identity and Access Management and Oracle Fusion Middleware Repository Creation Utility User's Guide to run RCU.

6.3.3 Installing Oracle WebLogic Server

Prior to installing the Oracle WebLogic Server, ensure that your machines meet the system, patch, kernel, and other requirements as specified in Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.

Start the installer, then proceed as follows:

On the Welcome screen, click Next.
On the Choose Middleware Home Directory screen, select Create a New Middleware Home.

For Middleware Home Directory, enter:

ORACLE_BASE/product/fmw

Note:

ORACLE_BASE is the base directory under which Oracle products are installed. The recommended value is /u01/app/oracle.

Click Next.
Enter your contact information so that you can be notified of security updates.

Click Next.
On the Choose Install Type screen, select Custom.

Click Next.
On the Choose Products and Components screen, select only Oracle JRockit SDK, and click Next.
On the Choose Product Installation Directories screen, accept the directory ORACLE_BASE/product/fmw/wlserver_10.3.

Click Next.
On the Installation Summary screen, click Next.
On the Installation Complete screen, deselect Run Quickstart.

Click Done.

6.3.4 Installing and Configuring the Access Manager Application Tier

This section describes how to install and configure Oracle Fusion Middleware components on OAMHOST1 and OAMHOST2.

6.3.4.1 Install Oracle Fusion Middleware for Identity Management

This section includes the steps for installing the Oracle Identity Management software into the previously created Middleware Home directory. Perform the steps on OAMHOST1 and OAMHOST2.

If the /etc/oraInst.loc file exists, verify that its contents are correct. Specifically, check that the inventory directory is correct and that you have write permissions for that directory. If the /etc/oraInst.loc file does not exist, you can skip this step.

Start the installer for Oracle Fusion Middleware as follows:

OAMHOST1> runInstaller

When the installer prompts you for a JRE/JDK location, enter the Oracle SDK location created in the WebLogic Server installation, for example, ORACLE_BASE/product/fmw/jrockit_160_<version>.

Then proceed as follows:

On the Welcome screen, click Next.
On the Prerequisite Checks screen, verify that the checks complete successfully, then click Next.
On the Specify Installation Location screen, enter the following values:
- Oracle Middleware Home: Select the previously installed Middleware home from the list for MW_HOME, for example:
```
/u01/app/oracle/product/fmw
```
- Oracle Home Directory: Enter idm.
Click Next.
On the Installation Summary screen, click Install.
On the Installation Complete screen, click Finish.

6.3.4.2 Configure Oracle Access Manager on OAMHOST1

This section creates the domain on OAMHOST1.

Start the configuration wizard by running the command:

MW_HOME/oracle_common/common/bin/config.sh

Then proceed as follows:

In the Welcome screen, select Create a New WebLogic Domain, and then click Next.
In the Select Domain Source Screen:

Select Generate a domain configured automatically to support the following products:

And select the following products:
- Oracle Enterprise Manager
- Oracle JRF (selected by default)
- Oracle Access Management
- Oracle Platform Security Service
Click Next.
In the Specify Domain and Location screen enter:
- Domain name: IDM_Domain
- Domain Location: Accept the default.
- Application Directory: Accept the default.
Click Next.
In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator, and click Next.
In the Configure Server Start Mode and JDK screen, make the following selections:
- WebLogic Domain Startup Mode: Select Production Mode.
- JDK Selection: Select JROCKIT SDK1.6.0_<version>.
In the Configure JDBC Component Schema screen, select all of the data sources, then select Configure selected data sources as RAC multi data sources.

Click Next.
In the Configure RAC Multi Data Source Component Schema screen, select the first data source, OAM Infrastructure, and enter the following:
- Data source: OAM
- Service Name: oam.example.com
- User Name: OAM_OAM (assuming OAM was used as the RCU prefix)
- Password: The password for above account
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAMDBHOST1
- Instance Name: oamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAMDBHOST2
- Instance Name: oamdb2
- Port: 1521
Click Next.
In the Test Component Schema screen, the configuration wizard attempts to validate the data source.

If the data source validation succeeds, click Next.

If it fails, click Previous, correct the issue, and try again.
In the Select Optional Configuration screen, select:
- Administration Server
- Managed Server Clusters and Machines
Click Next.
In the Customize Server and Cluster Configuration screen, select Yes, and click Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen Address: OAMHOST1.example.com
- Listen Port: 7001
- SSL listen port: Not applicable
- SSL enabled: leave unchecked
Click Next.
On the Configure Managed Servers screen, create an entry for each OAMHOST in the topology, that is, one for the OAM Server running on OAMHOST1 and one for the OAM Server running on OAMHOST2.

Select the OAM_SERVER entry and change the entry to the following values:
- Name: WLS_OAM1
- Listen Address: OAMHOST1.example.com
- Listen Port: 14100
For the second OAM_SERVER, click Add and supply the following information:
- Name: WLS_OAM2
- Listen Address: OAMHOST2.example.com
- Listen Port: 14100
Click Next.
In the Configure Clusters screen, create a cluster by clicking Add.

Enter name: OAM_Cluster

Leave all other fields at the default settings.

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster, as follows:
- Click the cluster name OAM_Cluster in the right window.
- Click the managed server WLS_OAM1, then click the arrow to assign it to the cluster.
- Repeat for managed server WLS_OAM2.
Click Next.
On the Configure Machines screen, create a machine for each host in the topology. Click the UNIX tab if your hosts use a UNIX-based operating system. Otherwise, click the Machines tab. Supply the following information:
- Name: Name of the host. The best practice is to use the DNS name (OAMHOST1)
- Node Manager Listen Address: The DNS name of the machine (OAMHOST1.example.com)
- Node Manager Port: A port for Node Manager to use.
Repeat the steps for OAMHOST2:
- Name: Name of the host. The best practice is to use the DNS name (OAMHOST2)
- Node Manager Listen Address: The DNS name of the machine (OAMHOST2.example.com)
- Node Manager Port: A port for Node Manager to use.
Click Next.
In the Assign Servers to Machines screen, indicate which managed servers will run on the machines just created.
- Click the machine OAMHOST1 in the right window.
- Click the managed server WLS_OAM1 in the left window.
- Click the arrow to assign the managed server to the host OAMHOST1.
- Click the machine OAMHOST2 in the right window.
- Click the managed server WLS_OAM2 in the left window.
- Click the arrow to assign the managed server to the host OAMHOST2.
Click Next.
On the Configuration Summary screen, click Create to begin the creation process.

Note:

You cannot run the config.sh script twice to make configuration changes, you must use another tool such as using the MBeans Browser in Fusion Middleware Control

6.3.5 Configuring the Database Security Store

You must configure the database security store after you configure the domain but before you start the Administration Server. See Section 5.3.4, "Configuring the Database Security Store for the Domain" for more information.

6.3.6 Creating boot.properties for the Administration Server on OAMHOST1

This section describes how to create a boot.properties file for the Administration Server on OAMHOST1. The boot.properties file enables the Administration Server to start without prompting for the administrator username and password.

To create the boot.properties file:

On OAMHOST1, go the following directory:

MW_HOME/user_projects/domains/domainName/servers/AdminServer/security

For example:

cd /u01/app/oracle/product/fmw/user_projects/domains/IDMDomain/servers/AdminServer/security

Use a text editor to create a file called boot.properties under the security directory. Enter the following lines in the file:
```
username=adminUser
password=adminUserPassword
```
Note:

When you start the Administration Server, the username and password entries in the file get encrypted.

For security reasons, minimize the time the entries in the file are left unencrypted. After you edit the file, you should start the server as soon as possible so that the entries get encrypted.
Stop the Administration Server if it is running.

See the "Starting and Stopping Oracle Fusion Middleware" chapter of the Oracle Fusion Middleware Administrator's Guide for information on starting and stopping WebLogic Servers.
Start the Administration Server on OAMHOST1 using the startWebLogic.sh script located under the MW_HOME/user_projects/domains/domainName/bin directory.
Validate that the changes were successful by opening a web browser and accessing the following pages:
- WebLogic Server Administration Console at:
```
http://oamhost1.example.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oamhost1.example.com:7001/em
```
Log into these consoles using the weblogic user credentials.

6.3.7 Starting OAMHOST1

This section describes the steps for starting OAMHOST1.

6.3.7.1 Create the Node Manager Properties File on OAMHOST1

Before you can start managed servers from the console, you must create a Node Manager property file. You do this by running the script setNMProps.sh, which is located in the MW_HOME/oracle_common/common/bin directory. For example:

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

6.3.7.2 Start Node Manager

Start Node Manager by issuing the following command:

OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

6.3.7.3 Start Access Manager on OAMHOST1

To start Access Manager on OAMHOST1, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oamhost1.example.com:7001/console
```
Supply the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the server WLS_OAM1.
Click Start.
Click OK to confirm that you want to start the server.

6.3.8 Validating OAMHOST1

To validate the implementation, connect to the Oracle Access Management Console at the following URL:

http://OAMHOST1.example.com:7001/oamconsole

The implementation is valid if the OAM Admin console login page opens and you can login using the WebLogic administrator account.

6.3.9 Configuring OAM on OAMHOST2

After the configuration succeeds on OAMHOST1, you can propagate it to OAMHOST2. You do this by packing the domain using the pack script on OAMHOST1, and unpacking the domain using the unpack script on OAMHOST2.

Both scripts reside in the MW_HOME/oracle_common/common/bin directory.

On OAMHOST1, enter:

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

This creates a file called idm_domain.jar in the /tmp directory. Copy this file to OAMHOST2.

On OAMHOST2, enter:

unpack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar

6.3.10 Starting OAMHOST2

This section describes the steps for starting OAMHOST2.

6.3.10.1 Create the Node Manager Properties File on OAMHOST2

OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh

6.3.10.2 Start Node Manager

Start Node Manager by issuing the following command:

OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh

6.3.10.3 Start Access Manager on OAMHOST2

To start Access Manager on OAMHOST2, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oamhost2.example.com:7001/console
```
Supply the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the server WLS_OAM2.
Click Start.
Click OK to confirm that you want to start the server.

6.3.11 Validating OAMHOST2

Validate the implementation by connecting to the OAM server using the following URL:

http://OAMHOST2.example.com:14100/oam/server/logout

The implementation is valid if an OAM logout successful page opens.

6.3.12 Configure Access Manager to Work with Oracle HTTP Server

This section provides steps for configuring Access Manager to work with the Oracle HTTP Server.

6.3.12.1 Update Oracle HTTP Server Configuration

On WEBHOST1 and WEBHOST2, create a file named oam.conf in the following directory:

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

Create the file with the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName sso.example.com:7777
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit

    <Location /oam>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
    </Location>

    <Location /oamfed>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WebLogicCluster oamhost1.example.com:14100,oamhost2.example.com:14100
        
    </Location>

</VirtualHost>

6.3.12.2 Restart Oracle HTTP Server

Restart the Oracle HTTP Server on WEBHOST1 and WEBHOST2:

WEBHOST1>opmnctl stopall
WEBHOST1>opmnctl startall

WEBHOST2>opmnctl stopall
WEBHOST2>opmnctl startall

6.3.12.3 Make OAM Server Aware of the Load Balancer

By default, Access Manager sends requests to the login page located on the local server. In a high availability deployment, you must change this setup so that login page requests go to the load balancer.

To make Access Manager aware of the load balancer:

Log into the Oracle Access Management Console at this URL as the weblogic user:
```
http://OAMHOST1.example.com:7001/oamconsole
```
Click on the Configuration tab.
Click the Access Manager Settings link.
Enter the following information:
- OAM Server Host: sso.example.com
- OAM Server Port: 7777
- OAM Server Protocol: http
Click Apply.
Restart managed servers WLS_OAM1 and WLS_OAM2.

6.3.13 Configuring Access Manager to use an External LDAP Store

By default, Access Manager uses its own in built-in LDAP server. In a highly available configuration, it is recommended that an external LDAP directory be used as the directory store. This section describes how to set up an external LDAP store.

Note:

Oracle recommends that you back up the environment and LDAP store before performing the subsequent steps in this section.

6.3.13.1 Extending Directory Schema for Access Manager

Pre-configuring the Identity Store extends the schema in the backend directory regardless of directory type.

To extend the directory schema for Access Manager, perform the following tasks on OAMHOST1:

Set the Environment Variables: MW_HOME, JAVA_HOME, IDM_HOME and ORACLE_HOME.

Set IDM_HOME to IDM_ORACLE_HOME

Set ORACLE_HOME to IAM_ORACLE_HOME
Create a properties file extend.props that contains the following:
```
IDSTORE_HOST : idstore.example.com
```
```
IDSTORE_PORT : 389
```
```
IDSTORE_BINDDN : cn=orcladmin
```
```
IDSTORE_USERNAMEATTRIBUTE: cn
```
```
IDSTORE_LOGINATTRIBUTE: uid
```
```
IDSTORE_USERSEARCHBASE:cn=Users,dc=example,dc=com
```
```
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=us,dc=oracle,dc=com
```
```
IDSTORE_SEARCHBASE: dc=example,dc=com
```
```
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
```
Where:
- IDSTORE_HOST and IDSTORE_PORT are, respectively, the host and port of your Identity Store directory. Specify the back-end directory here, rather than OVD.)
- IDSTORE_BINDDN Is an administrative user in the Identity Store Directory
- IDSTORE_USERSEARCHBASE is the location in your Identity Store where users are placed.
- IDSTORE_GROUPSEARCHBASE is the location in your Identity Store where groups are placed.
- IDSTORE_SEARCHBASE is the location in the directory where Users and Groups are stored.
- IDSTORE_SYSTEMIDBASE is the location in your directory where the Oracle Identity Manager reconciliation user are placed.
- IDSTORE_SYSTEMIDBASE is the location of a container in the directory where users can be placed when you do not want them in the main user container. This happens rarely but one example is the Oracle Identity Manager reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.

Configure the Identity Store by using the command idmConfigTool, which is located at: IAM_ORACLE_HOME/idmtools/bin.

The command syntax is:

idmConfigTool.sh -preConfigIDStore input_file=configfile

For example:

idmConfigTool.sh -preConfigIDStore input_file=extend.props

When the command runs, the system prompts you for the account password with which you are connecting to the Identity Store.

Sample command output:

Enter ID Store Bind DN password : 
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idm_idstore_groups_acl_template.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/systemid_pwdpolicy.ldif
Apr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/idstore_tuning.ldifApr 5, 2011 3:39:25 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oid_schema_extn.ldif
The tool has completed its operation. Details have been logged to automation.log

Check the log file for errors and warnings and correct them.

6.3.13.2 Create Users and Groups in LDAP

To add users that Access Manager requires to the Identity Store, follow these steps:

Set the Environment Variables MW_HOME, JAVA_HOME, IDM_HOME, and ORACLE_HOME.
- Set IDM_HOME to IDM_ORACLE_HOME.
- Set ORACLE_HOME to IAM_ORACLE_HOME.
Create a properties file oam.props that contains the following:
```
IDSTORE_HOST : idstore.example.com
```
```
IDSTORE_PORT : 389
```
```
IDSTORE_BINDDN : cn=orcladmin
```
```
IDSTORE_USERNAMEATTRIBUTE: cn
```
```
IDSTORE_LOGINATTRIBUTE: uid
```
```
IDSTORE_USERSEARCHBASE: cn=Users,dc=example,dc=com
```
```
IDSTORE_GROUPSEARCHBASE: cn=Groups,dc=example,dc=com
```
```
IDSTORE_SEARCHBASE: dc=example,dc=com
```
```
POLICYSTORE_SHARES_IDSTORE: true
```
```
OAM11G_IDSTORE_ROLE_SECURITY_ADMIN:OAMAdministrators
```
```
IDSTORE_OAMSOFTWAREUSER:oamLDAP
```
```
IDSTORE_OAMADMINUSER:oamadmin
IDSTORE_SYSTEMIDBASE:cn=systemids,dc=example,dc=com 
```
Where:
- IDSTORE_HOST and IDSTORE_PORT are, respectively, the host and port of your Identity Store directory.
- IDSTORE_BINDDN is an administrative user in the Identity Store Directory.
- IDSTORE_USERSEARCHBASE is the location in the directory where Users are Stored.
- IDSTORE_GROUPSEARCHBASE is the location in the directory where Groups are Stored.
- IDSTORE_SEARCHBASE is the location in the directory where Users and Groups are stored.
- POLICYSTORE_SHARES_IDSTORE is set to true if your Policy and Identity Stores are in the same directory. If not, it is set to false.
- IDSTORE_OAMADMINUSER is the name of the user you want to create as your Access Manager Administrator.
- IDSTORE_OAMSOFTWAREUSER is a user that gets created in LDAP that is used when Access Manager is running to connect to the LDAP server.

Configure the Identity Store using the command idmConfigTool which is located at IAM_ORACLE_HOME/idmtools/bin.

The command syntax is:

idmConfigTool.sh -prepareIDStore mode=OAM input_file=configfile

For example:

idmConfigTool.sh -prepareIDStore mode=OAM input_file=oam.props

After the command runs, the system prompts you to enter the password for the account with which you are connecting to the ID Store.

Sample command output:

Enter ID Store Bind DN password : 
Apr 5, 2011 3:53:28 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

 /u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_add.ldif
Apr 5, 2011 3:54:12 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_schema_index_add.ldif
Apr 5, 2011 3:55:10 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

 /u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oblix_pwd_schema_add.ldif
Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/oam/server/oim-intg/schema/OID_oim_pwd_schema_add.ldif
*** Creation of Oblix Anonymous User ***
Apr 5, 2011 3:55:11 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_10g_anonymous_user_template.ldif
Enter User Password for oblixanonymous: 
Confirm User Password for oblixanonymous: 
Apr 5, 2011 3:55:53 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_group_member_template.ldif
The tool has completed its operation. Details have been logged to automation.log

Check the log file for any errors or warnings and correct them.

See Oracle Fusion Middleware Integration Overview for Oracle Identity Management Suite for more information about the idmConfigTool command.

6.3.13.3 Create a User Identity Store

To create a user identity store:

Go to the Oracle Access Management Console at the URL:
```
http://adminvhn.example.com:7001/oamconsole
```
Log in using the WebLogic administration user.
Select System Configuration then Data Sources.
Select User Identity Stores then click Add. Enter the following information:
- Store Name: LDAP_DIR
- Store Type: OVD
- Description: Enter a description of the Directory Store
- Enable SSL: Select this if you communicate with your directory over SSL
- Location: Enter the location, for example ovd.example.com:389
- Bind DN: Enter the user permitted to search the LDAP store. For example, cn=orcladmin
- Password: Enter the oracleadmin password
- User Name Attribute: For example: uid
- User Search Base: Enter the location of users in the LDAP store. For example, cn=Users,dc=example,dc=com
- Group Name Attribute: For example: orclguid
- Group Search Base: Enter the location of groups in the LDAP store. For example, cn=Groups,dc=example,dc=com
- OAM Administrator Role: OAMAdministrators
Click Apply.
Click Test Connection to validate the connection to the LDAP server.

6.3.13.4 Set LDAP to System and Default Store

Now that you have defined the LDAP identity store, you must set it as the primary authentication store. To do this, follow these steps in the Oracle Access Management Console:

Click the System Configuration tab.
Select Data Sources - User Identity Stores from the navigation pane.
Click LDAP_DIR.
Select Open from the Actions menu.
Click Set as Default Store.
Click Set as System Store.
Click the Add [+] icon in Access System Administrators.
Enter OAM* in the search name field and click Search.
Select OAMAdministrators from the search results and click Add Selected.
Click Apply.
In the Validate System Administrator window, enter the username and password of the OAM administrator, for example, oamadmin.
Click Validate.
Test the connection by clicking Test Connection.

6.3.13.5 Set Authentication to Use External LDAP

By default, Access Manager uses the integrated LDAP store for user validation. You must update the LDAP authentication module so that it can validate users against the new external LDAP store.

To update the LDAP authentication module to use external LDAP:

Click the System Configuration tab.
Select Access Manager Settings - Authentication Modules - LDAP Authentication Modules.
Click LDAP.
Select Open from the Actions menu.
Set User Identity Store to LDAP_DIR.
Click Apply.
Restart the managed servers Admin Server, WLS_OAM1 and WLS_OAM2.

Note:

If you use oamadmin to manage OIF, you must add the OAM Administrator Role. For more information, see Section 6.3.13.3, "Create a User Identity Store."

6.3.14 Validating the Access Manager Configuration

Validate the configuration by logging into the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole as oamadmin.

6.3.15 Configuring Oracle Coherence to Keep Configuration Files in Sync

In a highly available environment, Oracle uses Oracle Coherence to keep configuration files in sync. Oracle Coherence uses port 9095 by default, but this can be changed through the Oracle Access Management Console.

Click on the System Configuration tab.
Expand Servers in the navigator.
Double-click on the Managed Server whose port you wish to change.
Click on the Coherence tab.
Change the value of Local Port to the desired value.
Click Apply.
Restart the Administration Server and all the managed servers residing in the same cluster as the managed server that has been updated.

6.3.16 Scaling Up and Scaling Out the Access Manager Topology

This section describes how to scale up and scale out an Access Manager high availability topology. Perform a scale up operation to add a new Access Manager managed server instance is added to a node already running one or more server instances. Perform a scale out operation to add a new Access Manager managed server instance to a new node.

6.3.16.1 Scaling Up Access Manager

Scale up OAM as follows:

From the Domain Structure window of the Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
In the Change Center, click Lock & Edit.
Select a server on the host you want to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAM3.
- Server Listen Address: The name of the host on which the managed server will run.
- Server Listen Port: The port the new managed server will use, this port must be unique within the host.
Click OK.
Click on the newly created server WLS_OAM3
Set the SSL listen port. This should be unique on the host that the managed server will be running on.
Click Save.
Disable hostname verification for the new managed server. Before starting and verifying the WLS_OAM3 managed server, you must disable hostname verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAMHOSTn.

If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings were propagated to the cloned server. To disable hostname verification:
1. In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers. Select WLS_OAM3 in the Names column of the table.
4. Click the SSL tab. Click Advanced.
5. Set Hostname Verification to None. Click Save.
Click Activate configuration from the Change Center menu.

Register the new managed server with OAM. You must now configure the new managed server as an OAM server from the Oracle Access Management Console:

Log in to the Oracle Access Management Console as the oamadmin user at http://oamhost1.example.com:7001/oamconsole
Click the System Configuration tab. Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
- Server Name: WLS_OAM3
- Host: Host that the server will run on
- Port: Listen port that was assigned when the managed server was created
- OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host
- Proxy Server ID: AccessServerConfigProxy
- Mode: Open
Click Coherence tab.

Set Local Port to a unique value on the host.

Click Apply.
Click Apply.

You can now start the Access server. To use the Access server, you must inform any Webgates of its existence. You do that as follows:

Log in to the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab.
From Launch Pad, under Application Management, click and open SSO Agents. Click Search on the SSO Agents page.
Double click the WebGate you want to change.
Add the new server to either the primary or secondary server list by clicking the Add + icon.
Select the server name from the list.
Click Apply

6.3.16.2 Scaling Out Access Manager

Scale out is very similar to scale up, but first requires the software to be installed on the new node.

Install Oracle WebLogic Server on the new host as described in Section 6.3.3, "Installing Oracle WebLogic Server."
Install Identity Management components on the new host. See Section 6.3.4, "Installing and Configuring the Access Manager Application Tier."
Log in to the Oracle WebLogic Server Administration Console at http://oamhost1.example.com:7001/oamconsole.
From the Domain Structure window of the Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
In the Change Center, click Lock & Edit.
Select a server on the host you want to extend, for example: WLS_OAM1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAM3.
- Server Listen Address: The name of the host on which the managed server will run.
- Server Listen Port: The port the new managed server will use. This port must be unique within the host.
Click OK.
Click the newly created server WLS_OAM3.
Set the SSL listen port. This should be unique on the host that the managed server will run on.
Click Save.
Disable hostname verification for the new managed server. Before starting and verifying the WLS_OAM3 managed server, you must disable hostname verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and the Node Manager in OAMHOSTn.

If the source server from which the new one was cloned had already disabled hostname verification, these steps are not required, as the hostname verification settings was propagated to the cloned server. To disable hostname verification:
1. In Oracle Enterprise Manager Fusion Middleware Control, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure pane.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_OAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab. Click Advanced.
6. Set Hostname Verification to None.
7. Click Save.
Click Activate Configuration from the Change Center menu.

Pack the domain on OAMHOST1 using the command:

pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAM Domain" -managed=true

The pack.sh script is located in MW_HOME/oracle_common/common/bin.

Unpack the domain on the new host using the command:

unpack.sh -domain=ORACLE_BASE/admin/IDM_Domain/mserver/IDM_Domain -template=/tmp/idm_domain.jar -template_name="OAM Domain" -app_dir=ORACLE_BASE/admin/IDM_Domain/mserver/applications

The unpack.sh script is located in MW_HOME/oracle_common/common/bin.

Before you can start managed servers from the console, you must create a node manager properties file on OAMHOST3. You do this by running the script setNMProps.sh, which is located in MW_HOME/oracle_common/common/bin. Type:
```
MW_HOME/oracle_common/common/bin/setNMProps.sh
```

Register the new managed server with OAM. You must now configure the new managed server as an OAM server from the Oracle Access Management Console:

Log in to the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab. Click Server Instances.
Select Create from the Actions menu.
Enter the following information:
- Server Name: WLS_OAM3
- Host: Host that the server will be running on, OAMHOST3.
- Port: Listen port that was assigned when the managed server was created.
- OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host.
- Proxy Server ID: AccessServerConfigProxy
- Mode: Open
Click Apply.

Start the Access Server. To use the server, you must inform any Webgates of its existence:

Log in to the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole as the oamadmin user.
Click the System Configuration tab.
Expand Agents -> OAM Agents ->10g Agents.
Double click the WebGate you want to change.
Add the new server to either the primary or secondary server list by clicking the Add [+] icon.
Select the server name from the list.
Click Apply.

Update the Web Tier. Now that the new managed server has been created and started, the web tier will start to direct requests to it. Best practice, however, is to inform the web server that the new managed server has been created.

You do this by updating the file OAM.conf on each of the web tiers. This file resides in the directory: ORACLE_INSTANCE/config/OHS/component name/moduleconf.

Add the new server to the WebLogicCluster directive in the file, for example, change:

<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.example.com:14200,OAMhost2.example.com:14200
</Location>

to:

<Location /OAM_admin>
    SetHandler weblogic-handler
    WebLogicCluster
 OAMhost1.example.com:14200,OAMhost2.example.com:14200,OAMhsot3.example.com:14300
</Location>

Footnote Legend

Footnote 1: The agent in use is specific to a deployment and different types of agents (with different features) can be used in a deployment.
Footnote 2: In addition to the built-in Credential Collector, Access Manager is capable of supporting external credential collectors.
Footnote 3: The credential collection will be different for non-username and password authentication schemes.
Footnote 4: Only WebGates support back channel communication.
Footnote 5: The agent may perform some housekeeping tasks, such as session refresh, before enabling the request to go through to the web resource.