9 Configuring High Availability for Identity and Access Management Components

Oracle Identity and Access Management enables enterprises to manage the end-to-end lifecycle of user identities across all enterprise resources. You can deploy applications faster, apply the most granular protection to enterprise resources, and much more. This chapter describes how to configure Identity and Access Management (IAM) products for high availability in an active-active configuration.

Oracle Identity and Access Management 11g Release 2 (11.1.2) includes the following components, which this chapter describes:

Oracle Identity Manager (OIM)
Oracle Access Management Access Manager (OAM)
Oracle Adaptive Access Manager (OAAM)
Oracle Access Management Security Token Service (STS)
Oracle Access Management Identity Federation (IF)
Oracle Entitlements Server (OES)
Oracle Access Management Mobile and Social
Oracle Privileged Account Manager (OPAM)
Oracle Identity Navigator (OIN)
Oracle Unified Directory (OUD)

This chapter includes the following topics:

Section 9.1, "Oracle Identity Manager High Availability"
Section 9.2, " Oracle Access Management Access Manager High Availability"
Section 9.3, "Oracle Adaptive Access Manager High Availability"
Section 9.4, "Oracle Access Management Security Token Service High Availability"
Section 9.5, "Oracle Access Management Identity Federation High Availability"
Section 9.6, "Oracle Entitlements Server High Availability"
Section 9.7, "Oracle Access Management Mobile and Social High Availability"
Section 9.8, "Oracle Privileged Account Manager High Availability"
Section 9.9, "Oracle Identity Navigator High Availability"
Section 9.10, "Oracle Unified Directory High Availability"

Chapter 8, "Configuring High Availability for Identity Management Components" describes 11g Release 1 Identity Management components that are available but not updated for 11g Release 2. These components include the following:

Oracle Internet Directory (OID)
Oracle Virtual Directory
Oracle Directory Integration Platform
Oracle Directory Services

9.1 Oracle Identity Manager High Availability

This section introduces Oracle Identity Manager and describes how to design and deploy a high availability environment for Oracle Identity Manager.

Oracle Identity Manager is a user provisioning and administration solution that automates the process of adding, updating, and deleting user accounts from applications and directories. It also improves regulatory compliance by providing granular reports that attest to who has access to what. Oracle Identity Manager is available as a stand-alone product or as part of Oracle Identity and Access Management Suite.

Automating user identity provisioning can reduce IT administration costs and improve security. Provisioning also plays an important role in regulatory compliance. Key features of Oracle Identity Manager include password management, workflow and policy management, identity reconciliation, reporting and auditing, and extensibility through adapters.

Oracle Identity Manager provides the following functionalities:

User Administration
Workflow and Policy
Password Management
Audit and Compliance Management
User Provisioning
Organization and Role Management

For details about Oracle Identity Manager, see the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

This section includes the following topics:

Section 9.1.1, "Oracle Identity Manager Component Architecture"
Section 9.1.2, "Oracle Identity Manager High Availability Concepts"
Section 9.1.3, "Oracle Identity Manager High Availability Configuration Steps"

9.1.1 Oracle Identity Manager Component Architecture

Figure 9-1 shows the Oracle Identity Manager architecture:

Figure 9-1 Oracle Identity Manager Component Architecture

Description of "Figure 9-1 Oracle Identity Manager Component Architecture"

9.1.1.1 Oracle Identity Manager Component Characteristics

Oracle Identity Manager Server is Oracle's self-contained, standalone identity management solution, based on Java EE standards. It provides User Administration, Workflow and Policy, Password Management, Audit and Compliance Management, User Provisioning and Organization and Role Management functionalities.

Oracle Identity Manager is a standard Java EE application that is deployed on Oracle WebLogic Sever and uses a database to store runtime and configuration data. The MDS schema contains configuration information; the runtime and user information is stored in the OIM schema.

Oracle Identity Manager connects to the SOA managed servers over RMI to invoke the SOA EJBs.

Oracle Identity Manager uses the human workflow module of the Oracle SOA Suite to manage its request workflow. Oracle Identity Manager connects to SOA using the T3 URL for the SOA server, which is the front end URL for SOA. Oracle recommends using the load balancer or web server URL for clustered SOA servers. When the workflow completes, SOA calls back Oracle Identity Manager web services using OIMFrontEndURL. Oracle SOA is deployed along with the Oracle Identity Manager.

Several Oracle Identity Manager modules use JMS queues. Each queue is processed by a separate Message Driven Bean (MDB), which is also part of the Oracle Identity Manager application. Message producers are also part of the Oracle Identity Manager application.

Oracle Identity Manager uses embedded Oracle Entitlements Server, which is also part of the Oracle Identity Manager engine. Oracle Entitlements Server (OES) is used for authorization checks inside Oracle Identity Manager. For example, one of the policy constraints determines that only users with certain roles are allowed to create users. This is defined using the Oracle Identity Manager user interface.

Oracle Identity Manager uses a Quartz based scheduler for scheduled activities. There are various scheduled activities that happen in the background. For example, one of the scheduled tasks is to disable users after the end date of the users.

Oracle Identity Manager links to Oracle BI Publisher for all the reporting features. BI Publisher is expected to be in a different domain or same domain, so the integration is only a simple static URL integration. There is no interaction between BI Publisher and Oracle Identity Manager runtime components. BI Publisher is configured to use the same OIM database schema for reporting purposes.

When you enable LDAPSync to communicate directly with external Directory Servers such as Oracle Internet Directory, ODSEE, and Microsoft Active Directory, support for high availability/failover features requires that you configure the Identity Virtualization Library (libOVD).

To configure libOVD, use the WLST command addLDAPHost. To manage libOVD, see Managing Identity Virtualization Library (libOVD) Adapters in Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for a list of WLST commands.

9.1.1.2 Runtime Processes

Oracle Identity Manager is a Java EE application that is deployed on WebLogic Server as a no-stage application. The Oracle Identity Manager server is initialized when the WebLogic Server it is deployed on starts up. As part of the application initialization, the quartz-based scheduler is also started. Once initialization is done, the system is ready to receive requests from clients.

Remote Manager and Design Console need to be started as standalone utilities separately.

9.1.1.3 Component and Process Lifecycle

Oracle Identity Manager is deployed to an Oracle WebLogic Server as an externally managed application. By default, the WebLogic Server starts, stops, monitors and manages other lifecycle events for the Oracle Identity Manager application.

Oracle Identity Manager is a standard Java EE application that starts after the application server components start. Also, Oracle Identity Manager uses the authenticator which is part of the Oracle Identity Manager component mechanism; it starts up before the WebLogic JNDI are initialized and the application is started. This is loaded from the OIM ORACLE_HOME.

Oracle Identity Manager uses a Quartz technology-based scheduler. Quartz starts the scheduler thread on all the WebLogic Server instances. It uses the database as the centralized storage for picking and running the scheduled activities. If one of the scheduler instances picks up a job, the other instances will not pick up that same job.

Oracle Identity Manager caches certain system configuration values in the cache in memory of the server instance from the database. These caches load independently and are not shared among the servers. Any changes to the system configuration triggers cache cleanup, which notifies all servers in the cluster. Oracle Identity Manager uses oscache, jgroups for this purpose. Jgroups use multicast addresses. A valid multicast address is randomly generated during installation and seeded to the Oracle Identity Manager metadata repository file.

WebLogic Node Manager can be configured to monitor the server process and restart it in case of failure.

The Oracle Enterprise Manager Fusion Middleware Control is used to monitor as well as to modify the configuration of the application.

9.1.1.4 Starting and Stopping Oracle Identity Manager

You can manage Oracle Identity Manager lifecycle events with one or more of the following command line tools and consoles:

Oracle WebLogic Scripting Tool (WLST)
WebLogic Server Administration Console
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Node Manager

9.1.1.5 Configuration Artifacts

The configuration for the Oracle Identity Manager server is stored in the MDS repository and is managed using MBeans. The oim-config.xml file is the main configuration file. Manage the OIM configuration using the MBean browser through the Oracle Enterprise Manager Fusion Middleware Control or through the command line MDS utilities. The oim-config.xml file is stored in the /db/oim-config.xml location of the MDS repository.

For more information about the MDS utilities, see the MDS utilities section of the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.

JMS is configured out-of-the-box by the installer. All the necessary JMS queues, connection pools, data sources and so on are configured on the WebLogic application servers. The following queues are created when Oracle Identity Manager deploys:

oimAttestationQueue
oimAuditQueue
oimDefaultQueue
oimKernelQueue
oimProcessQueue
oimReconQueue
oimSODQueue

The xlconfig.xml file stores Design Console and Remote Manager configuration.

9.1.1.6 External Dependencies

Oracle Identity Manager is a Java EE application that is deployed on an Oracle WebLogic Managed Server. Oracle Identity Manager uses the Worklist and Human workflow modules of the Oracle SOA Suite for request flow management. Oracle Identity Manager interacts with external repositories to store configuration and runtime data. Oracle Identity Manager requires these repositories to be available during initialization and during runtime. All Oracle Identity Manager credentials are stored in the OIM repository. The external components required for the Oracle Identity Manager server to function are listed below:

WebLogic Server
- Administration Server
- Managed Server
Data Repositories
- Configuration Repository (MDS Schema)
- Runtime Repository (OIM Schema)
- User Repository (OIM Schema)
- SOA Repository (SOA Schema)
External LDAP Stores (when using LDAP Sync)
BI Publisher

The Design Console is a tool used by the administrator for development and customization. The Design Console communicates directly with the Oracle Identity Manager engine, so it relies on the same components that the Oracle Identity Manager server relies on.

Remote Manager is an optional independent standalone application, which calls the custom APIs on the local system. So it needs the JAR files for those custom APIs in its classpath.

9.1.1.7 Oracle Identity Manager Log File Locations

Oracle Identity Manager is a Java EE application deployed on Oracle WebLogic Server. All server related logs messages are logged in the server log file and all Oracle Identity Manager specific messages are logged into the diagnostic log file of the WebLogic Server where the application is deployed.

The WebLogic Server log files are located under the following directory:

DOMAIN_HOME/servers/serverName/logs

The three main log files are serverName.log, serverName.out, and serverName-diagnostic.log, where serverName is the name of the WebLogic Server. For example, if the WebLogic Server name is wls_OIM1, then the diagnostic log file name would be wls_OIM1-diagnostic.log.

You can view the log files using the Oracle Enterprise Manager Fusion Middleware Control.

9.1.2 Oracle Identity Manager High Availability Concepts

This section provides an introduction to Oracle Identity Management high availability concepts and describes how to design and deploy a high availability environment for Oracle Identity Manager.

Note:

Be aware of the following when you deploy Oracle Identity Manager in a high availability configuration:

Oracle Identity Manager can be deployed on an Oracle RAC database, but Oracle RAC failover is not transparent for Oracle Identity Manager in this release. If an Oracle RAC failover occurs, end users may have to resubmit their requests.
Oracle Identity Manager always requires that at least one of the nodes in the SOA cluster be available. If the SOA cluster is not available, end user requests will fail. Oracle Identity Manager does not retry for a failed SOA call. Therefore, the end user must retry when a SOA call fails.

9.1.2.1 Oracle Identity Manager High Availability Architecture

Figure 9-2 shows Oracle Identity Manager deployed in a high availability architecture in an active-active configuration.

Figure 9-2 Oracle Identity Manager High Availability Architecture

Description of "Figure 9-2 Oracle Identity Manager High Availability Architecture"

On OIMHOST1, the following installations have been performed:

An Oracle Identity Manager instance has been installed in the WLS_OIM1 Managed Server and a SOA instance has been installed in the WLS_SOA1 Managed Server.
The Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle RAC node failure.
A WebLogic Server Administration Server has been installed. Under normal operations, this is the active Administration Server.

On OIMHOST2, the following installations have been performed:

An Oracle Identity Manager instance has been installed in the WLS_OIM2 Managed Server and a SOA instance has been installed in the WLS_SOA2 Managed Server.
The Oracle RAC database has been configured in a JDBC multi data source to protect the instance from Oracle RAC node failure.
The instances in the WLS_OIM1 and WLS_OIM2 Managed Servers on OIMHOST1 and OIMHOST2 are configured as the OIM_Cluster cluster.
The instances in the WLS_SOA1 and WLS_SOA2 Managed Servers on OIMHOST1 and OIMHOST2 are configured as the SOA_Cluster cluster.
A WebLogic Server Administration Server has been installed. Under normal operations, this is the passive Administration Server. You make this Administration Server active if the Administration Server on OIMHOST1 becomes unavailable.

The following virtual host names are used in the Oracle Identity Manager high availability configuration in Figure 9-2:

OIMVHN1 is the virtual hostname that maps to the listen address for the WLS_OIM1 managed server, and it fails over with server migration of the WLS_OIM1 managed server. It is enabled on the node where the WLS_OIM1 managed server is running (OIMHOST1 by default).
OIMVHN2 is the virtual hostname that maps to the listen address for the WLS_OIM2 managed server, and it fails over with server migration of the WLS_OIM2 managed server. It is enabled on the node where the WLS_OIM2 managed server is running (OIMHOST2 by default).
SOAVHN1 is the virtual hostname that is the listen address for the WLS_SOA1 managed server, and it fails over with server migration of the WLS_SOA1 managed server. It is enabled on the node where the WLS_SOA1 managed server is running (OIMHOST1 by default).
SOAVHN2 is the virtual hostname that is the listen address for the WLS_SOA2 managed server, and it fails over with server migration of the WLS_SOA2 managed server. It is enabled on the node where the WLS_SOA2 managed server is running (OIMHOST2 by default).
VHN refers to the virtual IP addresses for the Oracle Real Application Clusters (Oracle RAC) database hosts.

9.1.2.2 Starting and Stopping the Oracle Identity Manager Cluster

In a high availability architecture, Oracle Identity Manager is deployed on an Oracle WebLogic cluster that has at least two servers as members of the cluster.

By default, WebLogic Server starts, stops, monitors, and manages the various lifecycle events for the application. The Oracle Identity 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.

You can use one or more of the following command line tools and consoles to manage Oracle Identity Manager lifecycle events:

WebLogic Server Administration Console
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool (WLST)

9.1.2.3 Cluster-Wide Configuration Changes

For high availability environments, changing the configuration of one Oracle Identity Manager instance changes the configuration of all the other instances, because all the Oracle Identity Manager instances share the same configuration repository.

9.1.2.4 Considerations for Synchronizing with LDAP

Synchronization information between LDAP and the Oracle Identity Manager database is handled by a process called Reconciliation, which is a scheduled process that runs in the background primarily. It is also possible to manually run this process.

If an LDAP outage occurs during the Synchronization process, the data which did not get into Oracle Identity Manager will be picked up during the next run of the reconciliation task.

9.1.3 Oracle Identity Manager High Availability Configuration Steps

This section provides high-level instructions for setting up a high availability deployment for Oracle Identity Manager.

This section includes the following topics about configuring Oracle Identity Management for high availability:

Section 9.1.3.1, "Prerequisites for Oracle Identity Manager Configuration"
Section 9.1.3.2, "Creating and Configuring the WebLogic Domain for OIM and SOA on OIMHOST1"
Section 9.1.3.4, "Post-Installation Steps on OIMHOST1"
Section 9.1.3.5, "Configuring Oracle Identity Manager on OIMHOST1"
Section 9.1.3.6, "Post-Configuration Steps for the Managed Servers"
Section 9.1.3.7, "Validate the Oracle Identity Manager Instance on OIMHOST1"
Section 9.1.3.8, "Propagating Oracle Identity Manager to OIMHOST2"
Section 9.1.3.9, "Post-Installation Steps on OIMHOST2"
Section 9.1.3.10, "Validate the Oracle Identity Manager Instance on OIMHOST2"
Section 9.1.3.11, "Updating SOA Server Default Composite"
Section 9.1.3.12, "Configuring Oracle Internet Directory using the LDAP Configuration Post-setup Script"
Section 9.1.3.13, "Configuring Server Migration for the OIM and SOA Managed Servers"
Section 9.1.3.14, "Configuring a Shared JMS Persistence Store"
Section 9.1.3.15, "Configuring a Default Persistence Store for Transaction Recovery"
Section 9.1.3.16, "Install Oracle HTTP Server on WEBHOST1 and WEBHOST2"
Section 9.1.3.17, "Configuring Oracle Identity Manager to Work with the Web Tier"
Section 9.1.3.18, "Validate the Oracle HTTP Server Configuration"
Section 9.1.3.19, "Oracle Identity Manager Failover and Expected Behavior"
Section 9.1.3.20, "Troubleshooting Oracle Identity Manager High Availability"
Section 9.1.3.21, "Scaling Up and Scaling Out the Oracle Identity Manager Topology"

9.1.3.1 Prerequisites for Oracle Identity Manager Configuration

Before you configure Oracle Identity Manager for high availability, you must:

Run the Repository Creation Utility to create the OIM schemas in a database. See Section 9.1.3.1.1, "Running RCU to Create the OIM Schemas in a Database" for instructions.
Install WebLogic Server on OIMHOST1 and OIMHOST2. See Section 9.1.3.1.2, "Installing Oracle WebLogic Server" for instructions.
Install the Oracle SOA Suite on OIMHOST1 and OIMHOST2. See Section 9.1.3.1.3, "Installing the Oracle SOA Suite on OIMHOST1 and OIMHOST2" for instructions.
Install the Oracle Identity Management software on OIMHOST1 and OIMHOST2. See Section 9.1.3.1.4, "Installing the Oracle Identity Manager on OIMHOST1 and OIMHOST2" for instructions.
Ensure that a highly available LDAP implementation is available.

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Management.

If you are not planning to enable the LDAPSync option or to integrate with Oracle Access Management, you can skip this section.

For information about installing and configuring Oracle Internet Directory, see Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps." For information about installing and configuring Oracle Virtual Directory, see Section 8.4.3, "Oracle Virtual Directory High Availability Configuration Steps." Note that Oracle Identity Manager does not communicate directly with Oracle Internet Directory. It communicates with Oracle Virtual Directory, which communicates with Oracle Internet Directory.
Create the wlfullclient.jar file on OIMHOST1 and OIMHOST2.

Oracle Identity Manager requires the wlfullclient.jar library for certain operations. For example, the Design Console uses the library for server connections. Oracle does not ship this library; you must create it manually. Oracle recommends creating this library under the MW_HOME/wlserver_10.3/server/lib directory on all the machines in the application tier of your environment. You do not need to create this library on directory tier machines such as OIDHOST1, OIDHOST2, OVDHOST1 and OVDHOST2. See Developing a WebLogic Full Client in the guide Oracle Fusion Middleware Programming Stand-alone Clients for Oracle WebLogic Server for more information.

To create the wlfullclient.jar file:
1. Go to the MW_HOME/wlserver_10.3/server/lib directory.
2. Set your JAVA_HOME to MW_HOME/jdk160_18 and ensure that your JAVA_HOME/bin directory is in your path.
3. Create the wlfullclient.jar file by running:
  
  java -jar wljarbuilder.jar

9.1.3.1.1 Running RCU to Create the OIM Schemas in a Database

Before you can install the Oracle Identity Manager and SOA instances on OIMHOST1 and OIMHOST2, you must use the Repository Creation Utility (RCU) to create the collection of schemas used by Oracle Identity Manager.

RCU ships on its own CD as part of the Oracle Fusion Middleware 11g kit.

To run RCU and create the Oracle Identity Manager schemas in an Oracle RAC database repository:

Issue this command:
```
prompt> RCU_HOME/bin/rcu &
```
On the Welcome screen, click Next.
On the Create Repository screen, select the Create operation to load the component schemas into an existing database.

Click Next.
On the Database Connection Details screen, enter connection information for the existing database as follows:
- Database Type: Oracle Database
- Host Name: Name of the computer on which the database is running. For an Oracle RAC database, specify the VIP name or one node name. Example: OIMDBHOST1-VIP or OIMDBHOST2-VIP
- Port: The port number for the database. For example: 1521
- Service Name: The service name of the database. For example: oim.example.com
- Username: SYS
- Password: The SYS user password
- Role: SYSDBA
Click Next.
Click OK on the Checking Prerequisites screen after the Global Prerequisites complete successfully.
On the Select Components screen, create a new prefix and select the components to be associated with this deployment:

Create a New Prefix: ha

Components:
- Under Identity Management:
  - Oracle Identity Manager - OIM
  - Oracle Platform Security Services - OPSS
  - Note that Metadata Services - MDS is selected by default.
- Under SOA and BAM Infrastructure:
  - SOA Infrastructure - SOAINFRA is selected by default.
  - User Messaging Service - ORASDPM is selected by default.
Click Next.
Click OK on the Checking Prerequisites screen after the Component Prerequisites complete successfully.
On the Schema Passwords screen, enter the passwords for the mail and additional (auxiliary) schema users.

Click Next.
On Map Tablespaces screen, select the tablespaces for the components.
On the Summary screen, click Create.
On the Completion Summary screen, click Close.

9.1.3.1.2 Installing Oracle WebLogic Server

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

Start the installer, then perform these steps on OIMHOST1 and OIMHOST2:

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.
On the Register for Security Updates screen, 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.

9.1.3.1.3 Installing the Oracle SOA Suite on OIMHOST1 and OIMHOST2

Perform these steps to install Oracle Fusion Middleware Components on OIMHOST1 and OIMHOST2.

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 Component as follows:

HOST1> 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_14_<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 soa as the Oracle home directory name when installing the Oracle SOA Suite in the ORACLE_HOME
Click Next.
On the Installation Summary screen, click Install.
On the Installation Complete screen, click Finish.

9.1.3.1.4 Installing the Oracle Identity Manager on OIMHOST1 and OIMHOST2

Perform these steps to install Oracle Fusion Middleware Components on OIMHOST1 and OIMHOST2.

Start the installer for Oracle Fusion Middleware Component as follows:

HOST1> 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 iam as the Oracle home directory name when installing the Oracle Identity and Access Management Suite in the ORACLE_HOME
Click Next.
On the Installation Summary screen, click Install.
On the Installation Complete screen, click Finish.

9.1.3.2 Creating and Configuring the WebLogic Domain for OIM and SOA on OIMHOST1

To create the domain on OIMHOST1:

Start the Configuration Wizard by running this command:
```
MW_HOME/oracle_common/common/bin/config.sh
```
On the Welcome screen, select Create a WebLogic Domain.

Click Next.
On the Select Domain Source screen, select Generate a domain configured automatically to support the following added products.

From the list, select:
- Oracle Identity Manager
  
  Note that Oracle SOA Suite, Oracle Enterprise Manager, Oracle Platform Security Service, Oracle JRF, Oracle JRF WebServices Asynchronous services, and Oracle WSM Policy Manager are selected automatically.
- Oracle Enterprise Manager
  
  Note that Oracle JRF is selected automatically.
On the Specify Domain Name and Location screen, enter the name and location for the domain and all its applications.

Provide the following:
- Domain Name: IDMDomain
- Domain Location: Accept the default.
- Application Location: Accept the default.
Click Next.
On the Configure Administration Server Username and Password screen, provide the following:
- Name: weblogic
- User Password: Enter the password for the weblogic user.
- Confirm User Password: Enter the password for the weblogic user.
- Description: Provide a description for the user.
Click Next.
On the Configure Server Start Mode and JDK screen, select Production Mode and JRockit SDK 1.6.n.

Click Next.
On the Configure JDBC Component Schemas screen, select the Component Schemas shown below:
- SOA Infrastructure
- User Messaging Service
- OIM MDS Schema
- OWSM MDS Schema
- SOA MDS Schema
- OIM Infrastructure
- OPSS Schema
Select the check box next to Configure selected component schemas as RAC multi data source schemas in the next panel.

Note:

You can also use GridLink data sources. See Section 3.13, "GridLink Data Sources" for more information.

Click Next.

On the Configure RAC Multi Data Source Component Schemas screen, select all the multi data source schemas and enter the following:

Service Name: oim.example.com
For the first RAC node:
- Host Name: OIMDBHOST1-VIP.example.com
- Instance Name: oimdb1
- Port: 1521
For the second RAC node:
- Host Name: OIMDBHOST2-VIP.example.com
- Instance Name: oimdb2
- Port: 1521

Select each schema individually and enter the schema's username and password, as shown in Table 9-1:

Table 9-1 Entering the Schema Owner and Password for Each multi data Source Schema

Schema Name	Schema Owner	Password
SOA Infrastructure	HA_SOAINFRA	<enter the password>
User Messaging Service	HA_ORASDPM	<enter the password>
OIM MDS Schema	HA_MDS	<enter the password>
OWSM MDS Schema	HA_MDS	<enter the password>
SOA MDS Schema	HA_MDS	<enter the password>
OIM Schema	HA_OIM	<enter the password>
OPSS Schema	HA_OPSS	<enter the password>

Click Next.

On the Test Component Schema screen, select All the Schemas and then click Test Connections. Validate that the test for all the schemas completed successfully.

Click Next.
On the Select Optional Configuration screen, select:
- Administration Server
- JMS Distributed Destination (required only on the domain that has OIM)
- Managed Servers, Clusters and Machines
- JMS File Store (required only on the domain that has OIM)
Click Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen Address: oimhost1.example.com
- Listen Port: 7001
- SSL listen port: Not applicable
- SSL enabled: Leave unchecked
Click Next.
On the Select JMS Distributed Destination Type screen, ensure that all JMS System Resources listed are Uniform Distributed Destinations. If they are not, select UDD from the drop down box. Validate that the entries look like those in Table 9-2:

Table 9-2 Values to Choose for JMS System Resources

JMS System Resource Uniform/Weighted Distributed Destination

UMSJMSSystemResource

UDD

SOAJMSModule

UDD

OIMJMSModule

UDD

BPMJMSModule

UDD

Click Next.

An Override Warning box with the following message opens:

"CFGFWK-40915: At least one JMS system resource has been selected for conversion to a Uniform Distributed Destination (UDD). This conversion will take place only if the JMS System resource is assigned to a cluster."

Click OK on the Warning box.
When you first enter the Configure Managed Servers screen, the configuration wizard will have created two default managed servers (oim_server1 and soa_server1) for you. Change the details of the default managed servers and then add the second managed server. Follow the steps below:

For the oim_server1 entry, change the entry to the following values:
- Name: WLS_OIM1
- Listen Address: OIMVHN1
- Listen Port: 14000
For the soa_server1 entry, change the entry to the following values:
- Name: WLS_SOA1
- Listen Address: SOAVHN1
- Listen Port: 8001
For the second OIM Server, click Add and supply the following information:
- Name: WLS_OIM2
- Listen Address: OIMVHN2
- Listen Port: 14000
For the second SOA Server, click Add and supply the following information:
- Name: WLS_SOA2
- Listen Address: SOAVHN2
- Listen Port: 8001
Click Next.

Note:

Follow the steps for adding the second managed server to add additional managed servers.
On the Configure Clusters screen, create two clusters by clicking Add.

Supply the following information for the OIM Cluster:
- Name: oim_cluster
- Cluster Messaging Mode: unicast
- Cluster Address: oimhost1:14000,oimhost2:14000
Supply the following information for the SOA Cluster:
- Name: soa_cluster
- Cluster Messaging Mode: unicast
- Cluster Address: oimhost1:8001,oimhost2:8001
Leave all the other fields at the default settings and click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster. Click on the cluster name in the right window.

Click on the managed server under servers, then click on the arrow to assign it to the cluster.

Assign the WLS_OIM1 and WLS_OIM2 managed servers to be members of the oim_cluster.

Assign the WLS_SOA1 and WLS_SOA2 managed servers to be members of the soa_cluster.

Click Next.
On the Configure Machines screen, create a machine for each host in the topology.

Click on the Unix tab if your hosts use a Unix operating system or click Machines.

Provide the following information:
- Name: Name of the host. A good practice is to use the DNS name here.
- Node Manager Listen Address: Enter the DNS name of the machine here.
- Node Manager Port: Supply a port for Node Manager to use.
Click Next.

Note:

On UNIX, delete the default local machine entry under the Machines tab.
On the Assign Servers to Machines screen, you assign the managed servers that will run on the machines you just created. Follow these steps:

Click on a machine in the right hand window.

Click on the managed servers you want to run on that machine in the left window.

Click on the arrow to assign the managed servers to the machine.

Repeat these steps until all managed servers are assigned to the appropriate machine.

A typical example would be:
- Host1: Admin Server, WLS_OIM1, and WLS_SOA1
- Host2: WLS_OIM2 and WLS_SOA2
Click Next.

JMS System Resource	Uniform/Weighted Distributed Destination
UMSJMSSystemResource	UDD
SOAJMSModule	UDD
OIMJMSModule	UDD
BPMJMSModule	UDD

On the Configure JMS File Stores screen, update the directory locations for the JMS file stores. Enter the following values:

Name	Directory
UMSJMSFileStore_auto_1	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_1`
UMSJMSFileStore_auto_2	/u01/app/oracle/admin/domain_name/soa_cluster/jms/UMSJMSFileStore_auto_2
BPMJMSFileStore_auto_1	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_1`
BPMJMSFileStore_auto_2	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/BPMJMSFileStore_auto_2`
JRFWSAsyncFileStore_auto_1	/u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_1
JRFWSAsyncFileStore_auto_2	/u01/app/oracle/admin/domain_name/oim_cluster/jms/JRFWSAsyncFileStore_auto_2
SOAJMSFileStore_auto_1	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_1`
SOAJMSFileStore_auto_2	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/SOAJMSFileStore_auto_2`
OIMJMSFileStore_auto_1	`/u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_1`
OIMJMSFileStore_auto_2	`/u01/app/oracle/admin/domain_name/oim_cluster/jms/OIMJMSFileStore_auto_2`
PS6SOAJMSFileStore_auto_1	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_1`
PS6SOAJMSFileStore_auto_2	`/u01/app/oracle/admin/domain_name/soa_cluster/jms/PS6SOAJMSFileStore_auto_2`

On the Configuration Summary screen, click Create to create the domain.

9.1.3.3 Configuring the Database Security Store for the Domain

The Database Security Store contains security policies, audit meta-data, credentials, keys, and other security artifacts managed by OPSS. It facilitates high availability by serving as the single point of truth for policies in a topology, regardless of the domain organization (single, multiple, or extended).

You must configure the Database Security Store after you configure the domain but before you start the Administration Server. See Configuring Database Security Store for an Oracle Identity and Access Management Domain in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for more information.

9.1.3.4 Post-Installation Steps on OIMHOST1

This section describes the post-installation steps to perform on OIMHOST1. It includes these topics:

Section 9.1.3.4.1, "Update Node Manager on OIMHOST1"
Section 9.1.3.4.2, "Start Node Manager on OIMHOST1"
Section 9.1.3.4.3, "Start the Administration Server on OIMHOST1"

9.1.3.4.1 Update Node Manager on OIMHOST1

Before the managed servers can be started via the WebLogic Administration Console, Node Manager requires that the StartScriptEnabled property be set to true.

To do this, run the setNMProps.sh script located under the following directory:

MW_HOME/oracle_common/common/bin

9.1.3.4.2 Start Node Manager on OIMHOST1

Start the Node Manager on OIMHOST1 using the startNodeManager.sh script located under the following directory:

MW_HOME/wlserver_10.3/server/bin

9.1.3.4.3 Start the Administration Server on OIMHOST1

Follow these steps to start the Administration Server and validate its startup:

Start the Administration Server on OIMHOST1 by issuing the command:
```
DOMAIN_HOME/bin/startWebLogic.sh
```
Validate that the Administration Server started up successfully by opening a web browser and accessing the following pages:
- Administration Console at:
```
http://oimhost1.example.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oimhost1.example.com:7001/em
```
Log into these consoles using the weblogic user credentials.

9.1.3.5 Configuring Oracle Identity Manager on OIMHOST1

This section describes how to configure the Oracle Identity Manager and SOA managed servers before starting them.

This section includes the following topics:

Section 9.1.3.5.1, "Prerequisites for Configuring Oracle Identity Manager"
Section 9.1.3.5.2, "Updating the Coherence Configuration for the Coherence Cluster"
Section 9.1.3.5.3, "Running the Oracle Identity Management Configuration Wizard"

9.1.3.5.1 Prerequisites for Configuring Oracle Identity Manager

Before configuring Oracle Identity Manager, ensure that the following tasks have been performed:

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Management.

If you are not planning to enable the LDAPSync option or to integrate with Oracle Access Management, you can skip this section.

"Extending the Directory Schema for Oracle Identity Manager"
"Creating Users and Groups for Oracle Identity Manager"
"Creating Adapters in Oracle Virtual Directory"

Extending the Directory Schema for Oracle Identity Manager

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

To pre-configure the Identity Store, perform these steps on OIMHOST1:

Set the environment variables MW_HOME, JAVA_HOME and 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=example,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. If you are using a non-OID directory, then specify the Oracle Virtual Directory host (which should be IDSTORE.example.com.)
- 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.
- 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 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

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

Sample command output:

./preconfig_id.sh 
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 any errors or warnings and correct them.

Creating Users and Groups for Oracle Identity Manager

Follow the steps in the procedure to add the oimadmin user to the Identity Store and assign it to an Oracle Identity Manager administrative group. You must also create a user outside of the standard cn=Users location to perform reconciliation. Oracle recommends that you select this user as the bind DN when connecting to directories with Oracle Virtual Directory.

Note:

This command also creates a container in your Identity Store for reservations.

To add the xelsysadm user to the Identity Store and assign it to an administrative group, perform the following tasks on OIMHOST1:

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 oim.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
```
```
POLICYSTORE_SHARES_IDSTORE: true
```
```
IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
```
```
IDSTORE_OIMADMINUSER: oimadmin
```
```
IDSTORE_OIMADMINGROUP:OIMAdministrators
```
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_OIMADMINUSER is the name of the administration user you would like to use to log in to the Oracle Identity Manager console.
- IDSTORE_OIMADMINGROUP is the name of the group you want to create to hold your Oracle Identity Manager administrative users.
- 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_SYSTEMIDBASE is the location in your directory where the Oracle Identity Manager reconciliation user are placed.
- 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.

Configure the Identity Store by using the command idmConfigTool located at IAM_ORACLE_HOME/idmtools/bin:

idmConfigTool.sh -prepareIDStore mode=OIM input_file=configfile

For example:

idmConfigTool.sh -prepareIDStore mode=OIM input_file=oim.props

When the command runs, the system prompts you for the account password with which you are connecting to the Identity Store. The system also requests the passwords you want to assign to the accounts:

IDSTORE_OIMADMINUSER
oimadmin

Oracle recommends that you set oimadmin to the same value as the account you create as part of the Oracle Identity Manager configuration.

Sample command output:

Enter ID Store Bind DN password : 
*** Creation of oimadmin ***
Apr 5, 2011 4:58:51 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_user_template.ldif
Enter User Password for oimadmin: 
Confirm User Password for oimadmin: 
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_group_member_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_groups_acl_template.ldif
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFile
INFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oim_reserve_template.ldif
*** Creation of Xel Sys Admin User ***
Apr 5, 2011 4:59:01 AM oracle.ldap.util.LDIFLoader loadOneLdifFileINFO: -> LOADING:

/u01/app/oracle/product/fmw/IAM/idmtools/templates/oid/oam_user_template.ldif
Enter User Password for xelsysadm: 
Confirm User Password for xelsysadm: 
The tool has completed its operation. Details have been logged to /home/oracle/idmtools/oim.log

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

Creating Adapters in Oracle Virtual Directory

Oracle Identity Manager uses Oracle Virtual Directory to connect to external LDAP stores. You must create a user adapter and a change log adapter in Oracle Virtual Directory to enable Oracle Identity Manager to connect to the external LDAP store, such as Oracle Internet Directory. Follow these steps to create the adapters.

Note:

Creating adapters in Oracle Virtual Directory is not required if your implementation is Oracle Internet Directory only.

User Adapter

Create the user adapter on the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2 individually.

To create the User Adapter in Oracle Virtual Directory using Oracle Directory Services Manager:

Open a browser and bring up the ODSM console at http://admin.example.com/odsm.

Note:

Although Oracle Directory Services Manager is not shown in Figure 9-2, it is required to manage Oracle Internet Directory and Oracle Virtual Directory. Oracle Directory Services Manager must exist in your environment.
Create connections to each of the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2, if they do not already exist
Connect to each Oracle Virtual Directory instance by using the appropriate connection entry.
On the Home page, click the Adapter tab.
Start the New Adapter Wizard by clicking Create Adapter at the top of the adapter window.

Create a new adapter using the New Adapter Wizard, with the following parameters:

Note:

If you created a User Adapter previously, skip the steps to create the Adapter and follow the steps to edit the Adapter.

Screen	Field	Value/Step
Type	Adapter Type	`LDAP`
	Adapter Name	`User Adapter`
	Adapter Template	`User_OID`
Connection	Use DNS Setting	No
	Host	`oid.example.com`
	Port	`389`
	Server Proxy Bind DN	`cn=oimadmin,cn=systemids,dc=example,dc=com`
	Proxy Password	`oimadmin` password. This is the same password in "Extending the Directory Schema for Oracle Identity Manager".
Connection Test		Validate that the test succeeds.
Namespace	Remote Base	`dc=example,dc=com`
	Mapped Namespace	`dc=example,dc=com`
Summary		Verify that the summary is correct and then click Finish.

Edit the User Adapter as follows:
1. Select the OIM User Adapter.
2. Click the Plug-ins Tab.
3. Click the User Management Plug-in, then click Edit in the plug-ins table. The plug-in editing window appears.
4. In the Parameters table, update the parameter values as follows:
  
  Parameter value
  
  directoryType
  
  oid
  
  pwdMaxFailure
  
  10
  
  oamEnabled
  
  true
5. Click OK.
6. Click Apply.

Parameter	value
directoryType	oid
pwdMaxFailure	10
oamEnabled	true

Change Log Adapter

Create the change log adapter on the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2 individually. Follow these steps to create the Change Log Adapter in Oracle Virtual Directory using Oracle Directory Services Manager.

Open a browser and bring up the ODSM console at http://admin.example.com/odsm.
Create connections to each of the Oracle Virtual Directory instances running on OVDHOST1 and OVDHOST2, if they do not already exist.
Connect to an Oracle Virtual Directory instance by using the appropriate connection entry.
On the Home page click on the Adapter tab.
Start the New Adapter Wizard by clicking Create Adapter at the top of the adapter window.

Create a new adapter using the New Adapter Wizard and the following parameters:

Screen	Field	Value/Step
Type	Adapter Type	LDAP
	Adapter Name	OIM Change Log Adapter
	Adapter Template	`Changelog_OID`
Connection	Use DNS Setting	No
	Host	`oid.example.com`
	Port	`389`
	Server Proxy Bind DN	`cn=oimadmin,cn=systemids,dc=example,dc=com`
	Proxy Password	`oimadmin` password. This is the same password provided in "Extending the Directory Schema for Oracle Identity Manager".
Connection Test		Validate that the test succeeds.
Naming Space	Remote Base	`cn=changelog`
Mapped Namespace		`cn=changelog`
Summary		Verify that the summary is correct then click Finish.

To edit the change adapter, follow these steps.

Select the OIM Change Log Adapter.
Click the Plug-ins tab.
In the Deployed Plus-ins table, click the changelog plug-in, then click "Edit in the plug-ins table. The plug-in editing window appears.
In the Parameters table, update the parameter values.
Click OK.
Click Apply.

Edit the Change Log Adapter to either add or modify the properties so that they match the values shown in the following table. You must add the mapObjectclass, modifierDNFilter, sizeLimit, and targetDNFilter proprieties to the adapter.

Parameter	Value
directoryType	`oid`
mapAttribute	`targetGUID=orclguid`
requiredAttribute	`orclguid`
modifierDNFilter	`cn=oimadmin,cn=systemids,dc=example,dc=com`
sizeLimit	`1000`
targetDNFilter	`dc=example,dc=com` Search based from which reconciliation needs to happen. This value must be the same as the LDAP SearchDN that is specified during OIM installation.
mapUserState	`true`
oamEnabled	`true`

Stopping and Starting Oracle Internet Directory and Oracle Virtual Directory

Stop and Start:

The Oracle Virtual Directory instances running on both OVDHOST1 and OVDHOST2.
The Oracle Internet Directory instances running on both OIDHOST1 and OIDHOST2.

as Section 8.7, "Starting and Stopping Components" describes.

9.1.3.5.2 Updating the Coherence Configuration for the Coherence Cluster

Follow the steps below to update the Coherence configuration for the SOA managed servers:

Log into the Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers. The Summary of Servers page appears.
Click the name of the server (represented as a hyperlink) in the Name column of the table. The settings page for the selected server appears.
Click the Server Start tab.

Enter the following for WLS_SOA1 and WLS_SOA2 into the Arguments field.

For WLS_SOA1, enter the following (on a single line, without a carriage return):

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost1vhn1

For WLS_SOA2, enter the following (on a single line, without a carriage return):

-Dtangosol.coherence.wka1=soahost1vhn1 -Dtangosol.coherence.wka2=soahost2vhn1 -Dtangosol.coherence.localhost=soahost2vhn1

Click Save and activate the changes.

This change requires that you restart the SOA servers.

9.1.3.5.3 Running the Oracle Identity Management Configuration Wizard

You must configure the Oracle Identity Manager server instances before you can start the Oracle Identity Manager managed servers. You perform these configuration steps only once, for example, during the initial creation of the domain. The Oracle Identity Management Configuration Wizard loads the OIM metadata into the database and configures the instance.

Before running the Configuration Wizard, you must verify the following:

The administration server is up and running.
You have set coherence for wls_soa1.
wls_soa1 is running.
The environment variables DOMAIN_HOME and WL_HOME are not set in the current shell.

The Oracle Identity Management Configuration Wizard is located under the Identity Management Oracle home. Type:

IAM_ORACLE_HOME/bin/config.sh

Proceed as follows:

On the Welcome screen, click Next
On the Components to Configure screen, select OIM Server. Select OIM Remote Manager, if required in your topology.

Click Next.
On the Database screen, provide the following values:
- Connect String: The connect string for the OIM database. For example:
  
  oimdbhost1-vip.example.com:1521:oimdb1^oimdbhost2-vip.example.com:1521:oimdb2@oim.example.com
- OIM Schema User Name: HA_OIM
- OIM Schema password: password
- MDS Schema User Name: HA_MDS
- MDS Schema Password: password
Select Next.
On the WebLogic Administration Server screen, provide the following details for the WebLogic Administration Server:
- URL: The URL to connect to the WebLogic Administration Server. For example: t3://oimhost1.example.com:7001
- UserName: weblogic
- Password: Password for the weblogic user
Click Next.
On the OIM Server screen, enter the following values:
- OIM Administrator Password: Password for the OIM Administrator. This is the password for the xelsysadm user, the same password you entered earlier for idmconfigtool.
- Confirm Password: Confirm the password·
- OIM HTTP URL: Proxy URL for the OIM Server. This is the URL for the Hardware load balancer that is front ending the OHS servers for OIM. For example: http://oiminternal.example.com:80.
- Key Store Password: Key store password. The password must have an uppercase letter and a number. For example: MyPassword1
Click Next.
On the LDAP Sync and OAM screen, select Configure BI Publisher and provide the BI Publisher URL, if required in your environment. Enter the URL to connect to the BI Publisher in your environment.

Select Enable LDAP Sync.
Notes:
- Do not select Enable Identity Administration Integration with OAM.
- BI Publisher is not a part of the IDMDomain. For information about BI Publisher high availability, see Section 16.2, "High Availability for Oracle Business Intelligence Publisher."
Click Next.
On the LDAP Server screen, provide the following LDAP server details:
- Directory Server Type: The directory server type. Select OID, ACTIVE_DIRECTORY, IPLANET, or OVD. The default is OID.
- Directory Server ID: The directory server ID.
- Server URL: The URL to access the LDAP server. For example: ldap://ovd.example.com:389 if you use the Oracle Virtual Directory Server, ldap://oid.example.com:389 if you use Oracle Internet Directory.
- Server User: The username to connect to the server. For example: cn=orcladmin·
- Server Password: The password to connect to the LDAP server.
- Server SearchDN: The Search DN. For example: dc=example,dc=com.
Click Next.
On the LDAP Server Continued screen, enter the following LDAP server details:
- LDAP Role Container: The DN for the Role Container. This is the container where the OIM roles are stored. For example: cn=Groups,dc=example,dc=com ·
- LDAP User Container: The DN for the User Container. This is the container where the OIM users are stored. For example: cn=Users,dc=example,dc=com·
- User Reservation Container: The DN for the User Reservation Container.
  
  Note:
  
  Use the same container DN Values that idmconfigtool creates during the procedure "Creating Users and Groups for Oracle Identity Manager."
Click Next.
On the Remote Manager screen, provide the following values:

Note:

This screen appears only if you selected the Remote Manager utility in step 2.
- Service Name: HA_RManager
- RMI Registry Port: 12345
- Listen Port (SSL): 12346
On the Configuration Summary screen, verify the summary information.

Click Configure to configure the Oracle Identity Manager instance.
On the Configuration Progress screen, once the configuration completes successfully, click Next.
On the Configuration Complete screen, view the details of the Oracle Identity Manager Instance configured.

Click Finish to exit the Configuration Assistant.
Stop the WebLogic Administration Server, as described in Section 8.7, "Starting and Stopping Components."
Start the WebLogic Administration Server, as described in Section 8.7, "Starting and Stopping Components."

9.1.3.6 Post-Configuration Steps for the Managed Servers

This section describes post-configuration steps for the managed servers.

This section includes the following topic.

Section 9.1.3.6.1, "Start the WLS_SOA1 and WLS_OIM1 Managed Servers on OIMHOST1"

9.1.3.6.1 Start the WLS_SOA1 and WLS_OIM1 Managed Servers on OIMHOST1

Follow these steps to start the WLS_SOA1 and WLS_OIM1 managed servers on OIMHOST1:

Stop the WebLogic Administration Server on OIMHOST1. Use the WebLogic Administration Console to do this
Start the WebLogic Administration Server on OIMHOST1 using the startWebLogic.sh script under the DOMAIN_HOME/bin directory. For example:
```
/u01/app/oracle/admin/OIM/bin/startWebLogic.sh > /tmp/admin.out 2>1&
```
Validate that the WebLogic Administration Server started up successfully by bringing up the WebLogic Administration Console.
Restart the WLS_SOA1 managed server using the WebLogic Administration Console.
Start the WLS_OIM1 managed server using the WebLogic Administration Console.

9.1.3.7 Validate the Oracle Identity Manager Instance on OIMHOST1

Validate the Oracle Identity Manager Server instance on OIMHOST1 by bringing up the Oracle Identity Manager Console using a web browser.

The URL for the Oracle Identity Manager Console is:

http://identityvhn1.example.com:14000/identity

9.1.3.8 Propagating Oracle Identity Manager to OIMHOST2

Once the configuration has succeeded on OIMHOST1, the configuration can be propagated to OIMHOST2. This is done by packing the domain on OIMHOST1 and then unpacking it on OIMHOST2.

Follow these steps to pack the domain on OIMHOST1 and unpack it on OIMHOST2:

On OIMHOST1, invoke the pack utility in the MW_HOME/oracle_common/common/bin directory:

pack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template =/u01/app/oracle/admin/templates/oim_domain.jar -
template_name="OIM Domain" -managed=true

The previous step created the oim_domain.jar file in the following directory:
```
/u01/app/oracle/admin/templates
```
Copy the oim_domain.jar file from OIMHOST1 to a temporary directory on OIMHOST2.
On OIMHOST2, invoke the unpack utility in the MW_HOME/oracle_common/common/bin directory and specify the location of the oim_domain.jar file in its temporary directory:
```
unpack.sh -domain=MW_HOME/user_projects/domains/OIM_Domain -
template=/tmp/oim_domain.jar
```

9.1.3.9 Post-Installation Steps on OIMHOST2

This section describes the post-installation steps to perform on OIMHOST2. It includes these sections:

Section 9.1.3.9.1, "Update Node Manager on OIMHOST2"
Section 9.1.3.9.2, "Start Node Manager on OIMHOST2"
Section 9.1.3.9.3, "Start the WLS_SOA2 and WLS_OIM2 Managed Servers on OIMHOST2"

9.1.3.9.1 Update Node Manager on OIMHOST2

Before managed servers can be started via the WebLogic Administration Console, Node Manager requires that the StartScriptEnabled property be set to true.

To do this, run the setNMProps.sh script located under the following directory:

MW_HOME/oracle_common/common/bin

9.1.3.9.2 Start Node Manager on OIMHOST2

Start the Node Manager on OIMHOST2 using the startNodeManager.sh script located under the following directory:

MW_HOME/wlserver_10.3/server/bin

9.1.3.9.3 Start the WLS_SOA2 and WLS_OIM2 Managed Servers on OIMHOST2

Follow these steps to start the WLS_SOA2 and WLS_OIM2 managed servers on OIMHOST2:

Validate that the WebLogic Administration Server started up successfully by bringing up the WebLogic Administration Console.
Start the WLS_SOA2 managed server using the WebLogic Administration Console.
Start the WLS_OIM2 managed server using the WebLogic Administration Console. The WLS_OIM2 managed server must be started after the WLS_SOA2 managed server is started.

9.1.3.10 Validate the Oracle Identity Manager Instance on OIMHOST2

Validate the Oracle Identity Manager Server instance on OIMHOST2 by bringing up the Oracle Identity Manager Console using a web browser.

The URL for the Oracle Identity Manager Console is:

http://identityvhn2.example.com:14000/oim

9.1.3.11 Updating SOA Server Default Composite

In an integrated environment, Oracle Identity Manager is front ended by OHS. All SOA server default composites must be updated. See Updating SOA Server Default Composite in the Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite for the procedure to update SOA server default composites.

9.1.3.12 Configuring Oracle Internet Directory using the LDAP Configuration Post-setup Script

Note:

This section is required only for LDAPSync-enabled Oracle Identity Manager installations and for Oracle Identity Manager installations that integrate with Oracle Access Management.

If you do not plan to enable the LDAP-Sync option or to integrate with Oracle Access Management, you can skip this section.

In the current release, the LDAPConfigPostSetup script enables all the LDAPSync-related incremental Reconciliation Scheduler jobs, which are disabled by default. The LDAP configuration post-setup script is located under the IAM_ORACLE_HOME/server/ldap_config_util directory. To run the script, follow these steps:

Edit the ldapconfig.props file located under the IAM_ORACLE_HOME/server/ldap_config_util directory and provide the following values:

Parameter	Value	Description
`OIMProviderURL`	`t3://OIMHOST1VHN.example.com:14000,OIMHOST2VHN.example.com:14000`	List of Oracle Identity Manager managed servers.
`LDAPURL`	Specify the URL for the Oracle Virtual Directory instance, for example: `ldap://idstore.example.com:389`	Identity Store URL. Only required if IDStore is accessed using Oracle Virtual Directory.
`LDAPAdminUserName`	`cn=oimadmin,cn=systemids,dc=example,dc=com`	Name of user to connect to Identity Store. Only required if your Identity Store is in Oracle Virtual Directory. This user should not be located in `cn=Users,dc=example,dc=com`.
`LIBOVD_PATH_PARAM`	`MSERVER_HOME/config/fmwconfig/ovd/oim`	Required unless you access your identity store using Oracle Virtual Directory.

Note:

usercontainerName, rolecontainername, and reservationcontainername are not used in this step.

Save the file.
Set the JAVA_HOME, WL_HOME, APP_SERVER, OIM_ORACLE_HOME, and DOMAIN_HOME environment variables, where:
- JAVA_HOME is set to MW_HOME/jrockit_version
- WL_HOME is set to MW_HOME/wlserver_10.3
- APP_SERVER is set to weblogic
- OIM_ORACLE_HOME is set to IAM_ORACLE_HOME
- DOMAIN_HOME is set to MSERVER_HOME

Run LDAPConfigPostSetup.sh. The script prompts for the LDAP admin password and the Oracle Identity Manager admin password. For example:

IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh path_to_property_file

For example:

IAM_ORACLE_HOME/server/ldap_config_util/LDAPConfigPostSetup.sh IAM_ORACLE_HOME/server/ldap_config_util

9.1.3.13 Configuring Server Migration for the OIM and SOA Managed Servers

For this high availability topology, Oracle recommends that you configure server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 managed servers. See Section 3.9, "Whole Server Migration" for information on the benefits of using Whole Server Migration and why Oracle recommends it.

The WLS_OIM1 and WLS_SOA1 managed servers on OIMHOST1 are configured to restart automatically on OIMHOST2 if a failure occurs on OIMHOST1.
The WLS_OIM2 and WLS_SOA2 managed servers on OIMHOST2 are configured to restart automatically on OIMHOST1 if a failure occur on OIMHOST2.

In this configuration, the WLS_OIM1, WLS_SOA1, WLS_OIM2 and WLS_SOA2 servers listen on specific floating IPs that WebLogic Server Migration fails over.

The following steps enable server migration for the WLS_OIM1, WLS_SOA1, WLS_OIM2, and WLS_SOA2 managed servers, which in turn enables a managed server to fail over to another node if a server or process failure occurs:

Step 1: Setting Up a User and Tablespace for the Server Migration Leasing Table
Step 2: Creating a Multi Data Source Using the Oracle WebLogic Administration Console
Step 3: Editing Node Manager's Properties File
Step 4: Setting Environment and Superuser Privileges for the wlsifconfig.sh Script
Step 5: Configuring Server Migration Targets
Step 6: Testing the Server Migration

9.1.3.13.1 Setting Up a User and Tablespace for the Server Migration Leasing Table

The first step to set up a user and tablespace for the server migration leasing table:

Note:

If other servers in the same domain are already configured with server migration, you can use the same tablespace and data sources. In this case, you don't need to recreate the data sources and multi data source for database leasing, however, you must retarget them to the clusters you're configuring for server migration.

Create a tablespace named leasing. For example, log on to SQL*Plus as the sysdba user and run the following command:

SQL> create tablespace leasing logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;

Create a user named leasing and assign to it the leasing tablespace:

SQL> create user leasing identified by welcome1;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;

Create the leasing table using the leasing.ddl script:
1. Copy the leasing.ddl file located in either the WL_HOME/server/db/oracle/817 or the WL_HOME/server/db/oracle/920 directory to your database node.
2. Connect to the database as the leasing user.
3. Run the leasing.ddl script in SQL*Plus:
```
SQL> @Copy_Location/leasing.ddl;
```

9.1.3.13.2 Creating a Multi Data Source Using the Oracle WebLogic Administration Console

You create a data source to each of the Oracle RAC database instances during the process of setting up the multi data source, both for these data sources and the global leasing multi data source. When you create a data source:

Ensure that this is a non-XA data source.
The names of the multi data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11.
Data sources do not require support for global transactions. Therefore, do not use any type of distributed transaction emulation/participation algorithm for the data source (do not choose the Supports Global Transactions option, or the Logging Last Resource, Emulate Two-Phase Commit, or One-Phase Commit options of the Supports Global Transactions option), and specify a service name for your database.
Target these data sources to the cluster(s).
Make sure the data source's connection pool initial capacity is set to 0 (zero). To do this, select Services, JDBC and then Datasources. In the Datasources screen, click the Datasource Name, click the Connection Pool tab, and enter 0 (zero) in the Initial Capacity field.

Creating a Multi Data Source

To create a multi data source:

Log into the Administration Console using the Admin credentials.
In the Domain Structure window, expand the Services node then expand the DataSource node.
Click Lock and Edit in the Change Center.
Click New then click Multi Data Sources.
Enter leasing as the name.
Enter jdbc/leasing as the JNDI name.
Select Failover as algorithm (default). Click Next.
Select the target cluster(s). Click Next.
Select non-XA driver (the default). Click Next.
Click Create New Data Source.
Enter leasing-rac0 as the name. Enter jdbc/leasing-rac0 as the JNDI name. Enter oracle as the database type. For the driver type, select Oracle Driver (Thin) for RAC server-Instance connection Version 10,11.

Note:

When you create multi data sources for the leasing table, enter names in the format <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Click Next.
Deselect Supports Global Transactions. Click Next.
Enter the service name, database name (the RAC Node instance name such as racdb1, racdb2), host port, and password for your leasing schema. Click Next.
Click Test Configuration and verify that the connection works. Click Next.

Note:

Do not click Finish until you are done creating all of the data sources that you want to make. If you do not see the data sources that you created, this indicates that you clicked Finish too soon. When you click Finish, the Administration Console does not show the screen in which you target the data sources.
Target the data source to the cluster(s).
Select the data source and add it to the right screen.
Click Create a New Data Source for the second instance of your Oracle RAC database, target it to the cluster(s), repeating the steps for the second instance of your Oracle RAC database.
Add the second data source to your multi data source.
Save and click Activate Changes.

9.1.3.13.3 Editing Node Manager's Properties File

You must edit the nodemanager.properties file to add the following properties for each node where you configure server migration:

Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true

Interface: Specifies the interface name for the floating IP (such as eth0).

Note:

Do not specify the sub interface, such as eth0:1 or eth0:2. This interface is to be used without the :0, or :1. The Node Manager's scripts traverse the different :X enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0, eth1, or, eth2, eth3, ethn, depending on the number of interfaces configured.
NetMask: Net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is an example. The actual value depends on your network.
UseMACBroadcast: Specifies whether or not to use a node's MAC address when sending ARP packets, that is, whether or not to use the -b flag in the arping command.

Verify in Node Manager's output (shell where Node Manager starts) that these properties are being used or problems may arise during migration. You should see an entry similar to the following in Node Manager's output:

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

Note:

The following steps are not required if the server properties (start properties) are properly set and Node Manager can start the servers remotely.

Set the following property in the nodemanager.properties file:
- StartScriptEnabled: Set this property to true to enable Node Manager to start the managed servers.
Start Node Manager on OIMHOST1 and OIMHOST2 by running the startNodeManager.sh script in the WL_HOME/server/bin directory.

Note:

When running Node Manager from a shared storage installation, multiple nodes start using the same nodemanager.properties file. However, each node may require different NetMask or Interface properties. In this case, specify individual parameters on a per-node basis using environment variables. For example, to use a different interface (eth3) in HOSTn, use the Interface environment variable as follows: HOSTn> export JAVA_OPTIONS=-DInterface=eth3 and start Node Manager after the variable is set in the shell.

9.1.3.13.4 Setting Environment and Superuser Privileges for the wlsifconfig.sh Script

To set environment and superuser privileges for the wlsifconfig.sh script for each node where you configure server migration:

Ensure that your PATH environment variable includes these files:

Table 9-3 Files Required for the PATH Environment Variable

File Located in this directory

wlsifconfig.sh

DOMAIN_HOME/bin/server_migration

wlscontrol.sh

WL_HOME/common/bin

nodemanager.domains

WL_HOME/common
Grant sudo configuration for the wlsifconfig.sh script.
- Configure sudo to work without a password prompt.
- For security reasons, Oracle recommends restricting to the subset of commands required to run the wlsifconfig.sh script. For example, perform the following steps to set the environment and superuser privileges for the wlsifconfig.sh script:
- Grant sudo privilege to the WebLogic user (oracle) with no password restriction, and grant execute privilege on the /sbin/ifconfig and /sbin/arping binaries.
- Ensure that the script is executable by the WebLogic user. The following is an example of an entry inside /etc/sudoers granting sudo execution privilege for oracle and also over ifconfig and arping:
```
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```
Note:

Ask the system administrator for the sudo and system rights as appropriate to this step.

File	Located in this directory
wlsifconfig.sh	DOMAIN_HOME/bin/server_migration
wlscontrol.sh	WL_HOME/common/bin
nodemanager.domains	WL_HOME/common

9.1.3.13.5 Configuring Server Migration Targets

You first assign all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration. To configure cluster migration in a migration in a cluster:

Log into the Administration Console.
In the Domain Structure window, expand Environment and select Clusters.
Click the cluster you want to configure migration for in the Name column.
Click the Migration tab.
Click Lock and Edit.
In the Available field, select the machine to which to enable migration and click the right arrow.
Select the data source to use for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
Set the candidate machines for server migration. You must perform this task for all managed servers as follows:
1. In the Domain Structure window of the Administration Console, expand Environment and select Servers.
  
  Tip:
  
  Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine that the server runs on. This will be different from the configuration if the server migrates automatically.
2. Select the server that you want to configure migration for.
3. Click the Migration tab.
4. In the Available field, located in the Migration Configuration section, select the machines you want to enable migration to and click the right arrow.
5. Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.
6. Click Save then Click Activate Changes.
7. Repeat the steps above for any additional managed servers.
8. Restart the administration server, Node Managers, and the servers for which server migration has been configured.

9.1.3.13.6 Testing the Server Migration

To verify that server migration works properly:

From OIMHOST1:

Stop the WLS_OIM1 managed server. To do this, run this command:
```
OIMHOST1> kill -9 pid
```
where pid specifies the process ID of the managed server. You can identify the pid in the node by running this command:
```
OIMHOST1> ps -ef | grep WLS_OIM1
```
Watch the Node Manager console. You should see a message indicating that WLS_OIM1's floating IP has been disabled.
Wait for Node Manager to try a second restart of WLS_OIM1. It waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should now log a message indicating that the server will not be restarted again locally.

From OIMHOST2:

Watch the local Node Manager console. After 30 seconds since the last try to restart WLS_OIM1 on OIMHOST1, Node Manager on OIMHOST2 should prompt that the floating IP for WLS_OIM1 is being brought up and that the server is being restarted in this node.
Access the soa-infra console in the same IP.

Follow the steps above to test server migration for the WLS_OIM2, WLS_SOA1, and WLS_SOA2 managed servers.

Table 9-4 shows the managed servers and the hosts they migrate to in case of a failure.

Table 9-4 WLS_OIM1, WLS_OIM2, WLS_SOA1, WLS_SOA2 Server Migration

Managed Server	Migrated From	Migrated To
WLS_OIM1	OIMHOST1	OIMHOST2
WLS_OIM2	OIMHOST2	OIMHOST1
WLS_SOA1	OIMHOST1	OIMHOST2
WLS_SOA2	OIMHOST2	OIMHOST1

Verification From the Administration Console

Migration can also be verified in the Administration Console:

Log into the Administration Console at http://oimhost1.example.com:7001/console using the Admin credentials.
Click Domain on the left console.
Click the Monitoring tab and then the Migration sub tab.

The Migration Status table provides information on the status of the migration.

Note:

After a server is migrated, to fail it back to its original node/machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.

9.1.3.14 Configuring a Shared JMS Persistence Store

Configure the location for all of the persistence stores as a shared directory that is visible from both OIMHOST1 and OIMHOST2. As JMS messages are persisted in the file system for each server's local file system, shared storage is necessary for the JMS persistence store for WebLogic server migration. Without shared storage, a migrated server cannot access pending JMS messages.

Note:

See Considerations for Using File Stores on NFS for information about JMS messages and transaction logs, as well as releasing locks on file stores.

To change all persistent stores to use a shared base directory:

Log into the Administration Console at http://oimhost1.example.com:7001/console using the Admin credentials.
In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page is displayed.
Select the hyperlink(s) for the persistence store from the Name column of the table: BPM, SOA, OIM, and UMS. The Settings page for the persistence store opens.
On the Configuration tab, in the Directory field, enter the location of a persistent storage solution (such as NAS or SAN) that is available to other servers in the cluster. Specifying this location enables pending JMS messages to be sent.
The location should follow this directory structure:
- For the WLS_SOA1 and WLS_SOA2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/soaClusterName/jms
```
- For the WLS_OIM1 and WLS_OIM2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/oimClusterName/jms
```
  Note:
  
  The WLS_OIM1 and WLS_OIM2 servers must be able to access this directory.
  
  The WLS_SOA1 and WLS_SOA2 servers must be able to access this directory.
  
  This directory must exist before you restart the server.
Click Save and Activate.
Restart the servers to make the change in the persistent stores take effect.

9.1.3.15 Configuring a Default Persistence Store for Transaction Recovery

Each Oracle WebLogic Managed Server has a transaction log that stores information about inflight transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system fails or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to all the servers in the cluster. Without shared storage, other servers in the cluster cannot do a transaction recovery in the case of a server failure, so the operation may need to be retried.

Note:

Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).

Perform these steps to set the location for the default persistence stores for the Oracle Identity Manager and SOA Servers:

Log into the Administration Console at http://oimhost1.example.com:7001/console using the Admin credentials.
In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page is displayed.
Select the name of the server (represented as a hyperlink) in the Name column of the table. The Settings page for the selected server is displayed, and it defaults to the Configuration tab.
Click the Services tab.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store their data files. The directory structure of the path should be:
- For the WLS_SOA1 and WLS_SOA2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/soaClusterName/tlogs
```
- For the WLS_OIM1 and WLS_OIM2 servers, use a directory structure similar to:
```
ORACLE_BASE/admin/domainName/oimClusterName/tlogs
```
Click Save.

Note:

To enable migration of the Transaction Recovery Service, specify a location on a persistent storage solution that is available to the managed servers in the cluster. WLS_SOA1, WLS_SOA2, WLS_OIM1, and WLS_OIM2 must be able to access this directory.

9.1.3.16 Install Oracle HTTP Server on WEBHOST1 and WEBHOST2

For instructions on installing Oracle HTTP Server on WEBHOST1 and WEBHOST2, see Section 8.6.3.4.1, "Installing Oracle HTTP Server for the Web Tier."

9.1.3.17 Configuring Oracle Identity Manager to Work with the Web Tier

This section describes how to configure Oracle Identity Manager to work with the Oracle Web Tier.

9.1.3.17.1 Prerequisites

Verify that the following tasks have been performed:

Oracle Web Tier has been installed on WEBHOST1 and WEBHOST2.
Oracle Identity Manager has been installed and configured on OIMHOST1 and OIMHOST2.
The load balancer has been configured with a virtual hostname (sso.example.com) pointing to the web servers on WEBHOST1 and WEBHOST2.
The load balancer has been configured with a virtual hostname (oiminternal.example.com) pointing to web servers WEBHOST1 and WEBHOST2.
For details on configuring the VIPs on the load balancer, see Section 8.2.5.4, "Configuring Virtual Server Names and Ports for the Load Balancer."

9.1.3.17.2 Configuring Oracle HTTP Servers to Front End the OIM and SOA Managed Servers

On each of the web servers on WEBHOST1 and WEBHOST2, create a file called oim.conf in the directory ORACLE_INSTANCE/config/OHS/component/moduleconf. This file must contain the following information:

# oim admin console(idmshell based)
   <Location /admin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>
 
# oim self and advanced admin webapp consoles(canonic webapp)
 
  <Location /oim>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

  <Location /identity>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid 
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>

  <Location /sysadmin>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    </Location>

# SOA Callback webservice for SOD - Provide the SOA Managed Server Ports
  <Location /sodcheck>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
   </Location>

# Callback webservice for SOA. SOA calls this when a request is approved/rejected
# Provide the SOA Managed Server Port
  <Location /workflowservice>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# xlWebApp - Legacy 9.x webapp (struts based)
   <Location /xlWebApp>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# Nexaweb WebApp - used for workflow designer and DM
  <Location /Nexaweb>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# used for FA Callback service.
  <Location /callbackResponseService>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

# spml xsd profile
  <Location /spml-xsd>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

  <Location /HTTPClnt>
    SetHandler weblogic-handler
    WLCookieName    oimjsessionid
    WebLogicCluster oimvhn1.example.com:14000,oimvhn2.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>
 

  <Location /reqsvc>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicCluster slc00apd.us.example.com:14000,
    slc00dej.us.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>
 
 
  <Location /integration>
    SetHandler weblogic-handler
    WLCookieName oimjsessionid
    WebLogicCluster oimvhn1.example.com:8001,oimvhn2.example.com:8001
    slc00dej.us.example.com:14000
    WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oim_component.log"
    WLProxySSL ON
    WLProxySSLPassThrough ON
  </Location>

Create a file called virtual_hosts.conf in ORACLE_INSTANCE/config/OHS/component/moduleconf. The file must contain the following information:

NameVirtualHost *:7777
<VirtualHost *:7777>

  ServerName http://sso.example.com:7777
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
  </VirtualHost>

<VirtualHost *:7777>
  ServerName http://oiminternal.example.com:80
  RewriteEngine On
  RewriteOptions inherit
  UseCanonicalName On
</VirtualHost>

Save the file on both WEBHOST1 and WEBHOST2.
Stop and start the Oracle HTTP Server instances on both WEBHOST1 and WEBHOST2 as Section 8.7, "Starting and Stopping Components."

9.1.3.18 Validate the Oracle HTTP Server Configuration

To validate that Oracle HTTP Server is configured properly, follow these steps:

In a web browser, enter the following URL for the Oracle Identity Manager Console:
```
http://sso.example.com:7777/identity
```
The Oracle Identity Manager Console login page should display.
Log into the Oracle Identity Manager Console using the credentials for the xelsysadm user.

9.1.3.19 Oracle Identity Manager Failover and Expected Behavior

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

In a high availability environment, a hardware load balancer is used to load balance requests between the multiple Oracle Identity Manager instances. If one of the Oracle Identity Manager instances fails, the load balancer detects the failure and routes requests to the surviving instances.

In a high availability environment, the state and configuration information is stored in a database that is shared by all the members of the cluster.

The surviving Oracle Identity Manager instances will continue to seamlessly process any unfinished transactions started on the failed instance, since the state information is in the shared database and is available to all the members in the cluster.

When an Oracle Identity Manager instance fails, its database and LDAP connections are released. The surviving instances in the active-active deployment make their own connections to continue processing unfinished transactions on the failed instance.

Be aware of the following when you deploy Oracle Identity Manager in a high availability configuration:

Oracle Identity Manager can be deployed on an Oracle RAC database, but Oracle RAC failover is not transparent for Oracle Identity Manager in this release. If an Oracle RAC failover occurs, end users may have to resubmit their requests.
Oracle Identity Manager always requires that at least one of the nodes in the SOA cluster be available. If the SOA cluster is not available, end user requests will fail. Oracle Identity Manager does not retry for a failed SOA call. Therefore, the end user must retry when a SOA call fails.

9.1.3.20 Troubleshooting Oracle Identity Manager High Availability

If you are creating a user in Oracle Identity Manager (by logging into Oracle Identity Manager, clicking the Administration tab, clicking the Create User link, entering the required information in the fields, and clicking Save) in an active-active Oracle Identity Manager configuration, and the Oracle Identity Manager server that is handling the request fails, you may see a ResourceConnectionValidationxception in the Oracle Identity Manager log file, similar to:

[2010-06-14T15:14:48.738-07:00] [oim_server2] [ERROR] [] [XELLERATE.SERVER]
[tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: xelsysadm] [ecid:
004YGJGmYrtEkJV6u3M6UH00073A0005EI,0:1] [APP: oim#11.1.1.3.0] [dcid:
12eb0f9c6e8796f4:-785b18b3:12938857792:-7ffd-0000000000000037] [URI:
/admin/faces/pages/Admin.jspx] Class/Method:
PooledResourceConnection/heartbeat encounter some problems: Operation timed
out[[
com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception: Operation
timed out
        at
oracle.iam.ldapsync.impl.repository.LDAPConnection.heartbeat(LDAPConnection.ja
va:162)
        at
com.oracle.oim.gcp.ucp.PooledResourceConnection.heartbeat(PooledResourceConnec
tion.java:52)
         .
         .
         .

Although this exception is received, the user is created fine.

9.1.3.21 Scaling Up and Scaling Out the Oracle Identity Manager Topology

You can scale out or scale up the Oracle Identity Manager high availability topology. When you scale up the topology, you add new managed servers to nodes that are already running one or more managed servers. When you scale out the topology, you add new managed servers to new nodes.

9.1.3.21.1 Scaling Up Oracle Identity Manager

In this case, you already have a node that runs a managed server configured with SOA components. The node contains a Middleware home, an Oracle HOME (SOA), and a domain directory for existing managed servers.

You can use the existing installations (Middleware home and domain directories) for creating new WLS_OIM and WLS_SOA servers. You do not need to install the OIM and SOA binaries in a new location or run pack and unpack.

To scale up the topology:

Using the Administration Console, clone either WLS_OIM1 or WLS_SOA1 into a new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.

To clone a managed server:
1. Select Environment -> Servers from the Administration Console.
2. Select the managed server that you want to clone (WLS_OIM1 or WLS_SOA1).
3. Select Clone.
4. Name the new managed server WLS_OIMn or WLS_SOAn, where n is a number to identity the new managed server.
The rest of the steps assume that you are adding a new server to OIMHOST1, which is already running WLS_SOA1 and WLS_OIM1.
For the listen address, assign the hostname or IP to use for this new managed server. If you are planning to use server migration as recommended for this server, this should be the VIP (also called a floating IP) to enable it to move to another node. The VIP should be different from the one used by the managed server that is already running.
Create JMS Servers for SOA, OIM, BPM, UMS, JRFWSAsync, and PS6SOA on the new managed server.
1. Use the Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
2. Create a new JMS Server for SOA, for example, SOAJMSServer_n. Use the SOAJMSFileStore_n for this JMSServer. Target the SOAJMSServer_n Server to the recently created Managed Server (WLS_SOAn).
3. Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Use the UMSJMSFileStore_n for this JMSServer. Target the UMSJMSServer_n Server to the recently created managed server (WLS_SOAn).
5. Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
6. Create a new JMS Server for OIM, for example, OIMJMSServer_n. Use the OIMJMSFileStore_n for this JMSServer. Target the OIMJMSServer_n Server to the recently created Managed Server (WLS_OIMn).
7. Create a new persistence store for the new JRFWSAsyncJMSServer, for example, JRFWSAsyncJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
```
8. Create a new JMS Server for JRFWSAsync, for example, JRFWSAsyncJMSServer_n. Use the JRFWSAsyncJMSFileStore_n for this JMSServer. Target the JRFWSAsyncJMSServer_n Server to the recently created Managed Server (WLS_OIMn).
  
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new JRFWSAsync JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
9. Create a new persistence store for the new PS6JMSServer, for example, PS6JMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6JMSFileStore_n
```
10. Create a new JMS Server for PS6, for example, PS6JMSServer_n. Use the PS6JMSFileStore_n for this JMSServer. Target the PS6JMSServer_n Server to the recently created Managed Server (WLS_OIMn).
  
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new PS6 JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
11. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
12. Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_n to this subdeployment. Click Save.
13. Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of UMSJMSServerXXXXXX resulting from the Config Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
14. Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_n to this subdeployment. Click Save.
15. Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of OIMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).
16. Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_n to this subdeployment. Click Save.
17. Update the SubDeployment targets for the JRFWSAsyncJMSSystemResource to include the recently created JRFWSAsync JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click JRFWSAsyncJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for JRFWSAsyncJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for JRFWSAsyncJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of JRFWSAsyncJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).
18. Click the JRFWSAsyncJMSServerXXXXXX subdeployment. Add the new JMS Server for JRFWSAsync called JRFWSAsyncJMSServer_n to this subdeployment. Click Save.
19. Update the SubDeployment targets for the PS6SOAJMSSystemResource to include the recently created PS6SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click PS6SOAJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for PS6SOAJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for PS6SOAJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of PS6SOAJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
20. Click the PS6SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for PS6SOA called PS6SOAJMSServer_n to this subdeployment. Click Save.
Configure Oracle Coherence for deploying composites, as described inSection 5.13.8, "Configuring Oracle Coherence for Deploying Composites."

Note:

Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:

Dtangosol.coherence.localhost=SOAHOST1VHNn
Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable hostname verification for the new managed server. Before starting and verifying the WLS_SOAn managed server, you must disable hostname verification. You can re-enable it after you have configured server certificates for the communication between the Administration Server and the Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).

To disable hostname verification:
1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers. Select WLS_SOAn in the Names column of the table.
4. Click the SSL tab. Click Advanced.
5. Set Hostname Verification to None. Click Save.
Start and test the new managed server from the Administration Console.
1. Shut down the existing managed servers in the cluster.
2. Ensure that the newly created managed server, WLS_SOAn, is up.
3. Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional
Log in to the Administration Console. Select Services then the Foreign JNDI provider link. Select ForeignJNDIProvider-SOA then add the new server to the existing value.
Configure Server Migration for the new managed server.

Note:

Because this is a scale up operation, the node must already contain a Node Manager, an environment configured for server migration, and the floating IP for the new SOA managed server.

To configure server migration:
1. Log into the Administration Console.
2. In the left pane, expand Environment and select Servers.
3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.
4. Click the Migration tab.
5. In the Available field, in the Migration Configuration section, select the machines to which to enable migration and click the right arrow. Select the same migration targets as for the servers that already exist on the node.
  
  For example, for new managed servers on SOAHOST1, which is already running WLS_SOA1, select SOAHOST2. For new managed servers on SOAHOST2, which is already running WLS_SOA2, select SOAHOST1.
  
  Make sure the appropriate resources are available to run the managed servers concurrently during migration.
6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
7. Click Save.
8. Restart the Administration Server, managed servers, and Node Manager.
9. Repeat the steps in this list for configuring server migration for the newly created WLS_OIMn managed server.
To test server migration for this new server, follow these steps from the node where you added the new server:
1. Stop the WLS_SOAn managed server.
  
  To do this, run kill -9 pid on the PID of the managed server. To identify the PID of the node, enter ps -ef | grep WLS_SOAn
2. Watch the Node Manager Console for a message indicating that WLS_SOA1's floating IP is disabled.
3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
4. After Node Manager restarts the server, stop it again. Node Manager logs a message indicating that the server will not restart again locally.

9.1.3.21.2 Scaling Out Oracle Identity Manager

When you scale out the topology, you add new managed servers configured with SOA to new nodes.

Before performing the steps in this section, check that you meet these requirements:

There must be existing nodes running managed servers configured with SOA within the topology.
The new node can access the existing home directories for WebLogic Server and SOA. (Use the existing installations in shared storage for creating a new WLS_SOA or WLS_OIM managed server. You do not need to install WebLogic Server or SOA binaries in a new location but you do need to run pack and unpack to bootstrap the domain configuration in the new node.)

Note:

If there is no existing installation in shared storage, installing WebLogic Server and SOA in the new nodes is required as described in Section 5.13, "Configuring High Availability for Oracle SOA Infrastructure and Component Service Engines."

Note:

When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, Oracle recommends keeping the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and "attach" an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh. To update the Middleware home list to add or remove a WL_HOME, edit the user_home/bea/beahomelist file. See the following steps.

Follow these steps for scaling out the topology:

On the new node, mount the existing Middleware home, which should include the SOA installation and the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, run the following commands:
```
SOAHOSTn>cd ORACLE_BASE/product/fmw/soa/
SOAHOSTn>./attachHome.sh -jreLoc ORACLE_BASE/fmw/jrockit_160_<version>
```
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager's address to map the IP of the node that is being used for scale out.
Use the Administration Console to clone WLS_SOA1 into a new managed server. Name it WLS_SOAn, where n is a number.

Note:

These steps assume that you are adding a new server to node n, where no managed server was running previously.
Assign the hostname or IP to use for the new managed server for the listen address of the managed server.

If you are planning to use server migration for this server (which Oracle recommends), this should be the VIP (also called a floating IP) for the server. This VIP should be different from the one used for the existing managed server.
Create JMS servers for SOA, OIM (if applicable), UMS, BPM, JRFWSAsync, and PS6SOA on the new managed server.
1. Use the Administration Console to create a new persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/SOAJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
2. Create a new JMS Server for SOA, for example, SOAJMSServer_n. Use the SOAJMSFileStore_n for this JMSServer. Target the SOAJMSServer_n Server to the recently created Managed Server (WLS_SOAn).
3. Create a new persistence store for the new UMSJMSServer, for example, UMSJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/UMSJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new UMS JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
4. Create a new JMS Server for UMS, for example, UMSJMSServer_n. Use the UMSJMSFileStore_n for this JMSServer. Target the UMSJMSServer_n Server to the recently created managed server (WLS_SOAn).
5. Create a new persistence store for the new OIMJMSServer, for example, OIMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/OIMJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new OIM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
6. Create a new JMS Server for OIM, for example, OIMJMSServer_n. Use the OIMJMSFileStore_n for this JMSServer. Target the OIMJMSServer_n Server to the recently created Managed Server (WLS_OIMn).
7. Create a new persistence store for the new BPMJMSServer, for example, BPMJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/BPMJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new BPM JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
8. Create a new JMS Server for BPM, for example, BPMJMSServer_n. Use the BPMJMSFileStore_n for this JMSServer. Target the BPMJMSServer_n Server to the recently created managed server (WLS_SOAn).
9. Create a new persistence store for the new JRFWSAsyncJMSServer, for example, JRFWSAsyncJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/JRFWSAsyncJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new JRFWSAsync JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
10. Create a new JMS Server for JRFWSAsync, for example, JRFWSAsyncJMSServer_n. Use the JRFWSAsyncJMSFileStore_n for this JMSServer. Target the JRFWSAsyncJMSServer_n Server to the recently created managed server (WLS_SOAn).
11. Create a new persistence store for the new PS6SOAJMSServer, for example, PS6SOAJMSFileStore_n. Specify the path for the store. This should be a directory on shared storage.
```
ORACLE_BASE/admin/domain_name/cluster_name/jms/PS6SOAJMSFileStore_n
```
  Note:
  
  This directory must exist before the managed server is started or the start operation fails.
  
  You can also assign SOAJMSFileStore_n as store for the new PS6SOA JMS Servers. For the purpose of clarity and isolation, individual persistent stores are used in the following steps.
12. Create a new JMS Server for PS6SOA, for example, PS6SOAJMSServer_n. Use the PS6SOAJMSFileStore_n for this JMSServer. Target the PS6SOAJMSServer_n Server to the recently created managed server (WLS_SOAn).
13. Update the SubDeployment targets for the SOA JMS Module to include the recently created SOA JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click SOAJMSModule (represented as a hyperlink in the Names column of the table). The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment module for SOAJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of SOAJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
14. Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS Server for SOA called SOAJMSServer_n to this subdeployment. Click Save.
15. Update the SubDeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click UMSJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for UMSJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of UMSJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_SOA1 and WLS_SOA2).
16. Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS Server for UMS called UMSJMSServer_n to this subdeployment. Click Save.
17. Update the SubDeployment targets for OIMJMSModule to include the recently created OIM JMS Server. To do this, expand the Services node and then expand the Messaging node. Choose JMS Modules from the Domain Structure window of the Administration Console. The JMS Modules page appears. Click OIMJMSSystemResource (represented as a hyperlink in the Names column of the table). The Settings page for OIMJMSSystemResource appears. Click the SubDeployments tab. The subdeployment module for OIMJMS appears.
  
  Note:
  
  This subdeployment module name is a random name in the form of OIMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers (WLS_OIM1 and WLS_OIM2).
18. Click the OIMJMSServerXXXXXX subdeployment. Add the new JMS Server for OIM called OIMJMSServer_n to this subdeployment. Click Save.

Run the pack command on SOAHOST1 to create a template pack as follows:

SOAHOST1> cd ORACLE_COMMON_HOME/common/bin
SOAHOST1> ./pack.sh -managed=true/
-domain=MW_HOME/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar -template_name=soa_domain_templateScale

Run the following command on SOAHOST1 to copy the template file created to SOAHOSTn:

SOAHOST1> scp soadomaintemplateScale.jar oracle@SOAHOSTN:/
ORACLE_BASE/product/fmw/soa/common/bin

Run the unpack command on SOAHOSTn to unpack the template in the managed server domain directory as follows:

SOAHOSTn> cd ORACLE_BASE/product/fmw/soa/common/bin
SOAHOSTN> ./unpack.sh /
-domain=ORACLE_BASE/product/fmw/user_projects/domains/soadomain/
-template=soadomaintemplateScale.jar

Configure Oracle Coherence for deploying composites, as described in Section 5.13.8, "Configuring Oracle Coherence for Deploying Composites."

Note:

Only the localhost field needs to be changed for the server. Replace the localhost with the listen address of the new server added, for example:

Dtangosol.coherence.localhost=SOAHOST1VHNn
Configure the transaction persistent store for the new server. This should be a shared storage location visible from other nodes.

From the Administration Console, select Server_name > Services tab. Under Default Store, in Directory, enter the path to the folder where you want the default persistent store to store its data files.
Disable hostname verification for the new managed server. Before starting and verifying the WLS_SOAn 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 SOAHOSTn. If the source server from which the new one has been cloned had already disabled hostname verification, these steps are not required (the hostname verification settings is propagated to the cloned server).

To disable hostname verification:
1. In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console.
2. Expand the Environment node in the Domain Structure window.
3. Click Servers. The Summary of Servers page appears.
4. Select WLS_SOAn in the Names column of the table. The Settings page for the server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Start the Node Manager on the new node. To start the Node Manager, use the installation in shared storage from the existing nodes, and start Node Manager by passing the hostname of the new node as a parameter as follows:
```
SOAHOSTn> WL_HOME/server/bin/startNodeManager new_node_ip
```
Start and test the new managed server from the Administration Console.
1. Shut down the existing managed servers in the cluster.
2. Ensure that the newly created managed server, WLS_SOAn, is up.
3. Access the application on the newly created managed server (http://vip:port/soa-infra). The application should be functional
Configure Server Migration for the new managed server.

Note:

Since this new node is using an existing shared storage installation, the node is already using a Node Manager and environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges. The floating IP for the new SOA managed server is already in the new node.

Configure server migration by following these steps:
1. Log into the Administration Console.
2. In the left pane, expand Environment and select Servers.
3. Select the server (represented as a hyperlink) for which you want to configure migration. The Settings page for that server appears.
4. Click the Migration tab.
5. In the Available field, in the Migration Configuration section, select the machines to which to enable migration and click the right arrow.
  
  Note:
  
  Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.
6. Select the Automatic Server Migration Enabled option. This enables the Node Manager to start a failed server on the target node automatically.
7. Click Save.
8. Restart the Administration Server, managed servers, and Node Manager.
Test server migration for this new server. Follow these steps from the node where you added the new server:
1. Stop the WLS_SOAn managed server.
  
  To do this, run kill -9 pid on the PID of the managed server. You can identify the PID of the node using ps -ef | grep WLS_SOAn.
2. Watch the Node Manager Console: you should see a message indicating that WLS_SOA1's floating IP has been disabled.
3. Wait for the Node Manager to try a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
4. Once Node Manager restarts the server, stop it again. Now Node Manager should log a message indicating that the server will not be restarted again locally.

9.2 Oracle Access Management Access Manager High Availability

This section 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 section includes the following topics:

Section 9.2.1, "Access Manager Component Architecture"
Section 9.2.2, "Access Manager High Availability Concepts"
Section 9.2.3, "Access Manager High Availability Configuration Steps"

9.2.1 Access Manager Component Architecture

Figure 9-3 shows the Access Manager component architecture.

Figure 9-3 Access Manager Single Instance Architecture

Description of "Figure 9-3 Access Manager Single Instance Architecture"

Figure 9-2 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

9.2.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.

9.2.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.

9.2.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.

9.2.1.1.3 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.

9.2.1.1.4 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.

9.2.1.1.5 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)

9.2.1.1.6 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

9.2.2 Access Manager High Availability Concepts

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

9.2.2.1 Access Manager High Availability Architecture

Figure 9-4 shows an Access Manager high availability architecture:

Figure 9-4 Access Manager High Availability Architecture

Description of "Figure 9-4 Access Manager High Availability Architecture"

In Figure 9-4, 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.

9.2.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.

9.2.2.1.2 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.

9.2.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.

9.2.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.

9.2.2.2.2 Node Failure

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

9.2.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."

9.2.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 9.2.3.1, "Prerequisites for Access Manager Configuration"
Section 9.2.3.2, "Running the Repository Creation Utility to Create the Database Schemas"
Section 9.2.3.3, "Installing Oracle WebLogic Server"
Section 9.2.3.4, "Installing and Configuring the Access Manager Application Tier"
Section 9.2.3.5, "Configuring the Database Security Store"
Section 9.2.3.6, "Creating boot.properties for the Administration Server on OAMHOST1"
Section 9.2.3.7, "Starting OAMHOST1"
Section 9.2.3.8, "Validating OAMHOST1"
Section 9.2.3.9, "Configuring OAM on OAMHOST2"
Section 9.2.3.10, "Starting OAMHOST2"
Section 9.2.3.11, "Validating OAMHOST2"
Section 9.2.3.12, "Configure Access Manager to Work with Oracle HTTP Server"
Section 9.2.3.13, "Configuring Access Manager to use an External LDAP Store"
Section 9.2.3.14, "Validating the Access Manager Configuration"
Section 9.2.3.15, "Configuring Oracle Coherence to Keep Configuration Files in Sync"
Section 9.2.3.16, "Scaling Up and Scaling Out the Access Manager Topology"

9.2.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 9.2.3.2, "Running the Repository Creation Utility to Create the Database Schemas".
Install Oracle WebLogic Server on OAMHOST1 and OAMHOST2. See Section 9.2.3.3, "Installing Oracle WebLogic Server".
Install the Oracle Identity Management executables on OAMHOST1 and OAMHOST2. See the Section 9.2.3.4, "Installing and Configuring the Access Manager Application Tier".
Ensure that a highly available LDAP implementation is available. For information about installing and configuring Oracle Internet Directory, see Section 8.3.3, "Oracle Internet Directory High Availability Configuration Steps." For information about installing and configuring Oracle Virtual Directory, see Section 8.4.3, "Oracle Virtual Directory High Availability Configuration Steps."

9.2.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.

9.2.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.

9.2.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.

9.2.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.

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.

9.2.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

9.2.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 9.1.3.3, "Configuring the Database Security Store for the Domain" for more information.

9.2.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.

9.2.3.7 Starting OAMHOST1

This section describes the steps for starting OAMHOST1.

9.2.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

9.2.3.7.2 Start Node Manager

Start Node Manager by issuing the following command:

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

9.2.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.

9.2.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.

9.2.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

9.2.3.10 Starting OAMHOST2

This section describes the steps for starting OAMHOST2.

9.2.3.10.1 Create the Node Manager Properties File on OAMHOST2

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

9.2.3.10.2 Start Node Manager

Start Node Manager by issuing the following command:

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

9.2.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.

9.2.3.11 Validating OAMHOST2

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

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

The implementation is valid if the OAM login page is displayed. Note at this point it will show an "Action failed" error on the page. This is normal because you are accessing the page directly rather than as a login request.

9.2.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.

9.2.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>

9.2.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

9.2.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.

9.2.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.

9.2.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.

9.2.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.

9.2.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.

9.2.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.

9.2.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 9.2.3.13.3, "Create a User Identity Store."

9.2.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.

9.2.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.

9.2.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.

9.2.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

9.2.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 9.2.3.3, "Installing Oracle WebLogic Server."
Install Identity Management components on the new host. See Section 9.2.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>

9.3 Oracle Adaptive Access Manager High Availability

This section introduces Oracle Adaptive Access Manager and describes how to design and deploy a high availability environment for Oracle Adaptive Access Manager.

Oracle Adaptive Access Manager is built on a J2EE-based, multi-tier deployment architecture that separates the platform's presentation, business logic, and data tiers. Because of this separation of tiers, Oracle Adaptive Access Manager can rapidly scale with the performance needs of the customer. The architecture can leverage the most flexible and supported cross-platform J2EE services available: a combination of Java, XML and object technologies. This architecture makes Oracle Adaptive Access Manager a scalable, fault-tolerant solution.

This section includes the following topics:

Section 9.3.1, "Oracle Adaptive Access Manager Component Architecture"
Section 9.3.2, "Oracle Adaptive Access Manager High Availability Concepts"
Section 9.3.3, "Oracle Adaptive Access Manager High Availability Configuration Steps"

9.3.1 Oracle Adaptive Access Manager Component Architecture

Figure 9-5 shows the single instance architecture for Oracle Adaptive Access Manager.

Figure 9-5 Oracle Adaptive Access Manager Single Instance Architecture

Description of "Figure 9-5 Oracle Adaptive Access Manager Single Instance Architecture"

In the Oracle Adaptive Access Manager single instance architecture shown in Figure 9-5, end users access customer web applications, which communicate with the OAAM Server application and its policies using SOAP. Alternately, an OAAM proxy can be set up so that end users communicate with that machine, which then communicates with the OAAM_Server application using HTTP(S). Authorized end users can access the customer web application. The OAAM_ADMIN component is used for administration and configuration of the OAAM_SERVER application. The administrator responsible for administering and configuring the OAAM_Server application uses a web browser to access the OAAM_ADMIN application. An Oracle RAC database holds policy and configuration information.

9.3.1.1 Oracle Adaptive Access Manager Component Characteristics

Oracle Adaptive Access Manager consists of the following two components:

OAAM_ADMIN: This component is used for administration and configuration of OAAM_SERVER application. This component is developed using the Oracle JAVA ADF Framework the Identity Management shell and deployed as Web applications in a J2EE container. It is packaged as an EAR file.
OAAM_SERVER: This component contains the OAAM Admin and OAAM Server sub-components within a single web application. The OAAM_SERVER component is packaged as an EAR file and is composed of Servlets and JSPs in addition to Java classes. The subcomponents of OAAM_SERVER are described below by layer:
- Presentation Layer: typically a Web application serving JSPs, servlets, and so on. The presentation layer provides the strong authenticator functionality; it uses the interfaces provided by the business layer (SOAP or Java native) to access its services.
- Business Logic Layer: contains the core application logic that implements the risk analyzing engine. This layer provides Java and SOAP interfaces for the presentation layer. When the Java interface is used, the business logic layer and presentation layer can be part of a single web application. With the SOAP interface, these layers are deployed as different applications.
- Data Access Layer: contains data access components to connect to the supported relational databases. Oracle Adaptive Access Manager uses Oracle's TopLink, which provides a powerful and flexible framework for storing Java objects in a relational database.

You can also use the following components in an Oracle Adaptive Access Manager 11g deployment:

Fusion Middleware Control / Enterprise Manager Grid Control: Oracle Adaptive Access Manager integrates with the Enterprise Manager Grid Control to display performance metrics and deployment topology. Oracle Adaptive Access Manager uses DMS and Discovery Mbeans to integrate with Enterprise Manager. Enterprise Manager is also used to enhance component tracing and configure auditing.

Enterprise Manager can also be used to view log files for each Managed Server in the domain and increase the tracing to Debug, Trace, and Info levels.
Data repositories: Oracle Adaptive Access Manager uses the RDBMS database as its data store. Oracle Adaptive Access Manager supports and works on the following database technologies:
- Oracle Real Application Clusters
- Oracle Data Guard
- Replication Streams
- Database Partitioning
Oracle Adaptive Access Manager uses RCU to creates its schema in the database.

9.3.1.1.1 Oracle Adaptive Access Manager State Information

The OAAM_Server component includes the OAAM Server subcomponent and the OAAM Admin subcomponent.

OAAM Server is a stateful application that stores the state in HTTP session.
OAAM Admin is a stateful application that stores its session information in the database.

The OAAM_Admin component is an ADF and Identity Management UI shell-based application. It is a stateless application, and its application state is maintained by the ADF framework.

9.3.1.1.2 Oracle Adaptive Access Manager Runtime Processes

You can perform the following runtime tasks using the Oracle Adaptive Access Manager Administration Console:

Customer Care application tasks
System configuration tasks involving policies, groups, and properties
Viewing session data information
Viewing the System Statistics dashboard

For example, you can perform the following administration flows:

Recent user query:
1. View recent logins and session details.
2. Perform a query.
3. Click Session Details.
4. Log out.
Manual CSR and Agent Case creation:
1. To reset customer care, log in.
2. Create a case.
3. Reset the customer.
4. Log out.

You can also perform runtime processing with the Oracle Adaptive Access Manager Server.

9.3.1.1.3 Oracle Adaptive Access Manager Process Lifecycle

The following runtime processing occurs with Oracle Adaptive Access Manager Server:

Oracle Adaptive Access Manager is deployed and integrated with the customer's application.
The user will access the customer's application and enter user credentials.
Based on the system and rules configured in OAAM, different login flows will be presented, for example:

User Registration: Registration Flows
1. Flow R1: Login (New User), enter password, personalize device, skip Questions Registration, log out.
2. Flow R2: Login, enter password, skip Registration, log out.
3. Flow R3: Login, enter password, personalize device, continue Questions Registration, log out.
4. Flow R4: Login, enter password, personalize device, continue Questions Registration, enter invalid answers, validation, log out
5. Flow R5: Login (New Device and New User), enter password, personalize device, continue Questions Registration, log out.
Login Flow:
1. Flow L1: Login, enter wrong password, Login screen.
2. Flow L2: Login, enter correct password, Challenge On may be presented, answer correctly, logged in.
3. Flow L3: Login, enter correct password, Challenge On presented, answer incorrectly, Challenge On presented again, answer correctly, logged in.
4. Flow L4: Login, enter correct password, Challenge On presented, answer incorrectly, Challenge On presented again, answer incorrectly, Challenge On presented again, answer correctly, logged in.
5. Flow L5: Login, enter correct password, Challenge On presented, answer incorrectly, Challenge On presented again, answer incorrectly, login blocked.
6. Flow L6: Login, enter correct password, login blocked (login screen).
7. Flow L7: Login, enter correct password, logged in.
8. Flow LNU1Login as a new user: Login, enter correct password, logged in.
9. Flow LND1: Existing user, login with a new device, enter correct password, logged in.
10. Flow LNUD1: New user, login with a new device, enter correct password, logged in.
In Session Transaction Flow: Login, enter password, create transaction, update transaction, log out.
OAAM tracks and registers the following data elements:
1. User login
2. User names
3. Devices (cookies, browser headers, and flash data supplied)
4. IP addresses
5. Transaction data
OAAM will trigger the appropriate policy based on login behavior.

As J2EE applications, you can start the Oracle Adaptive Access Manager Server and Administration Console using the WebLogic Server user interface and command line tools.

The Oracle Adaptive Access Manager Server supports a health check request (a ping request over HTTP) that can be used by a load balancer for death detection.

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

9.3.1.1.4 Oracle Adaptive Access Manager Configuration Artifacts

Oracle Adaptive Access Manager stores its configuration information in the database. To change these configuration properties, use the Oracle Adaptive Access Manager Administration Console.

Oracle Adaptive Access Manager does not store any configuration information on the file system or in the exploded EAR file.

9.3.1.1.5 Oracle Adaptive Access Manager Deployment Artifacts

Oracle Adaptive Access Manager supports the no-stage mode of deployment staging. That is, all deployment files are local.

9.3.1.1.6 Oracle Adaptive Access Manager External Dependencies

Oracle Adaptive Access Manager has an external dependency on the RDBMS database, where it stores its configuration information.

Oracle Adaptive Access Manager uses WebLogic Server multi data sources for Oracle RAC databases.

Oracle Adaptive Access Manager uses the standard Oracle TopLink object caching mechanism.

Oracle Adaptive Access Manager follows standard session object serialization to maintain the persistent state of an object.

Oracle Adaptive Access Manager is not dependent on any hostname, IP address, or port. It will work on a container-specific port or hostname.

9.3.1.1.7 Oracle Adaptive Access Manager Log File Location

Oracle Adaptive Access Manager is a J2EE application deployed on WebLogic Server. All log messages are logged in the server log file of the WebLogic Server that the application is deployed on. The default location of the server log is:

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

9.3.2 Oracle Adaptive Access Manager High Availability Concepts

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

9.3.2.1 Oracle Adaptive Access Manager High Availability Architecture

Figure 9-6 shows the Oracle Adaptive Access Manager high availability architecture:

Figure 9-6 Oracle Adaptive Access Manager High Availability Architecture

Description of "Figure 9-6 Oracle Adaptive Access Manager High Availability Architecture"

In Figure 9-6, incoming 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 on OAAMHOST1 and OAAMHOST2 using the WebLogic plugin mod_wl_ohs.conf.

OAAMHOST1 and OAAMHOST2 contain managed servers which host the Oracle Adaptive Access Manager Server application and the Oracle Adaptive Access Manager Admin 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 OAAMHOST1 and contains the WebLogic Administration Console and the Oracle Enterprise Manager Fusion Middleware Control. The Administration Server can be configured to run in active-passive mode on OAAMHOST2, which means that if OAAMHOST1 becomes unavailable, then Administration Server can be manually started on OAAMHOST2.

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

Figure 9-6 shows the OAAM high availability configuration architecture. In the figure, a load balancer routes requests through two Oracle HTTP Server instances on WEBHOST1 and WEBHOST2 to OAAMHOST1 and OAAMHOST2. An OAAM Administration Server instance and an OAAM Managed Server instance is installed on OAAMHOST1 and on OAAMHOST2, and these installations are configured as an OAAM Server cluster (OAAM_Cluster) and an OAAM Admin Cluster (OAAM_Admin_Cluster). The OAAM Server cluster uses the OAAM Server data source and the OAAM Admin cluster uses the OAAM Admin data source to communicate with the Oracle RAC database.

Only one Oracle Adaptive Access Manager Server cluster and one Oracle Adaptive Access Manager Administration cluster is supported per WebLogic Server domain. In addition, Oracle Adaptive Access Manager-related clusters cannot span WebLogic Server domains.

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

Load handling
External connection management and monitoring
Recovery
Fault containment
Fault diagnostics
Oracle Adaptive Access Manager Admin / Server offline

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

Redundancy
Client connection failover / continuity
Client load balancing
State management

Oracle recommends using an external load balancing router for inbound HTTP connections.

Web sessions open persistent TCP connections to the Oracle Adaptive Access Manager Administration Console and servers. This requires that load balancing router and firewall connection timeouts are sufficiently large to avoid premature termination of TCP connections.

9.3.2.1.1 Starting and Stopping the Cluster

Each Oracle Adaptive Access Manager Administration Console and Server instance is a peer of other instances. Because all initialization happens before the Server is ready to receive requests and because of built in throttling capabilities, surge conditions are dealt with gracefully without any significant impact of the performance characteristics of the Oracle Adaptive Access Manager 11gR1 Access Server.

When the cluster stop, new requests are denied and existing requests can complete before the Oracle Adaptive Access Manager Administration Console and Server application shuts down. If a forced shutdown occurs, Oracle Adaptive Access Manager 11gR1 recovers any corrupted or invalid data that the shutdown causes.

Oracle Adaptive Access Manager components are pure J2EE applications and do not have any start or stop functionality of their own. Instead, they rely on container-specific startup and shutdown functionality.

Oracle Adaptive Access Manager components deploy to WebLogic Server Managed Server nodes. You restart the components using Node Manager.

9.3.2.1.2 Cluster-Wide Configuration Changes

Since Oracle Adaptive Access Manager stores the entire configuration in database, the propagation of configuration changes to all the cluster members transparent. All Oracle Adaptive Access Manager components are notified of change events from the internal layer, which are then taken up by the components. To ensure atomicity of the change, Oracle Adaptive Access Manager components reload their entire configuration every time a change happens.

Oracle Adaptive Access Manager configuration applies to every instance in a cluster.

Adding and removing Oracle Adaptive Access Manager Administration Console and Server instances is transparent to other Oracle Adaptive Access Manager instances in the cluster.

An Oracle Adaptive Access Manager cluster can have any number of instances. There is no restriction on the number of instances per cluster.

Online application redeployment does not cause any problems.

9.3.2.2 Protection from Failures and Expected Behaviors

The following features protect an Oracle Adaptive Access Manager high availability configuration from failure:

Session state for the cluster is maintained in memory, which provides replication and failover for all session state information.
Oracle Adaptive Access Manager Servers support a heartbeat check - a ping request over HTTP. In addition, the WebLogic Node Manager on the Managed Server can monitor the application and restart it if it is not running. Restarting an Oracle Adaptive Access Manager Server has no impact on any other running components or cluster members.
When a WebLogic Server node fails, external connection failover is based on the configuration and is based on the retry timeout as well as the number of retries.
When the load balancing router or proxy server detects a WebLogic Server node failure, subsequent client connections are routed to the active instance, which picks up the session state for further processing.
An Oracle Adaptive Access Manager session does not have a direct impact on an Oracle RAC database node failure, because WebLogic Server maintains the state of its database connections.

9.3.3 Oracle Adaptive Access Manager High Availability Configuration Steps

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

This section includes the following topics:

Section 9.3.3.1, "Prerequisites for Oracle Adaptive Access Manager Configuration"
Section 9.3.3.2, "Run the Repository Creation Utility to Create the OAAM Schemas in a Database"
Section 9.3.3.3, "Installing Oracle WebLogic Server"
Section 9.3.3.4, "Installing and Configuring the Oracle Adaptive Access Manager Application Tier"
Section 9.3.3.5, "Configuring the Database Security Store for the Domain"
Section 9.3.3.6, "Creating boot.properties for the Administration Server on OAAMHOST1"
Section 9.3.3.7, "Create the Oracle Adaptive Access Manager Administration User"
Section 9.3.3.8, "Start OAAMHOST1"
Section 9.3.3.9, "Validating OAAMHOST1"
Section 9.3.3.10, "Configure Oracle Adaptive Access Manager on OAAMHOST2"
Section 9.3.3.11, "Start OAAMHOST2"
Section 9.3.3.12, "Validating OAAMHOST2"
Section 9.3.3.13, "Configure Oracle Adaptive Access Manager to Work with Oracle HTTP Server"
Section 9.3.3.14, "Validating the Oracle Adaptive Access Manager Configuration"
Section 9.3.3.15, "Scaling Up and Scaling Out the Oracle Adaptive Access Manager Topology"

9.3.3.1 Prerequisites for Oracle Adaptive Access Manager Configuration

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

Run the Repository Creation Utility to create the OAAM schemas in a database. See Section 9.3.3.2, "Run the Repository Creation Utility to Create the OAAM Schemas in a Database".
Install Oracle WebLogic Server on OAAMHOST1 and OAAMHOST2. See Section 9.3.3.3, "Installing Oracle WebLogic Server"
Install and configure the Oracle Identity Management executables on OAAMHOST1 and OAAMHOST2. See Follow the steps in Section 9.3.3.4, "Installing and Configuring the Oracle Adaptive Access Manager Application Tier".

9.3.3.2 Run the Repository Creation Utility to Create the OAAM Schemas in a Database

9.3.3.3 Installing Oracle WebLogic Server

Before you install 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.

To install Oracle WebLogic Server on OAAMHOST1 and OAAMHOST2, start the installer then complete these steps:

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.
On the Register for Security Updates screen, 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.

9.3.3.4 Installing and Configuring the Oracle Adaptive Access Manager Application Tier

This section describes how to install Oracle Fusion Middleware components on OAAMHOST1 and OAAMHOST2.

9.3.3.4.1 Install Oracle Fusion Middleware for Identity Management

Perform these steps to install Oracle Fusion Middleware components on OAAMHOST1 and OAAMHOST2.

Start the installer for Oracle Fusion Middleware as follows:

OAAMHOST1> 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 as the Oracle Home directory name when installing the Oracle Identity Management Suite in the IDM_ORACLE_HOME.
  - Enter iam as the Oracle Home directory name when installing the Oracle Identity and Access Management Suite in the IAM_ORACLE_HOME.Enter soa as the Oracle Home directory name when installing the Oracle SOA Suite in the SOA_ORACLE_HOME.
Click Next.
On the Installation Summary screen, click Install.
On the Installation Complete screen, click Finish.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster, as follows:
- Click the cluster name OAAM_Cluster in the right window.
- Click the managed server WLS_OAAM1, then click the arrow to assign it to the cluster.
- Repeat for managed server WLS_OAAM2.
Then:
- Click the cluster name OAAM_Admin_Cluster in the right window.
- Click the managed server WLS_OAAM_ADMIN1, then click the arrow to assign it to the cluster.
- Repeat for managed server WLS_OAAM_ADMIN2.
Click Next.

9.3.3.4.2 Configure Oracle Access Manager on OAAMHOST1

This section creates the domain on OAAMHOST1.

Start the configuration wizard by running the command:

MW_HOME/oracle_common/common/bin/config.sh

Then continue with the following steps:

In the Welcome screen, select Create a New WebLogic Domain 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 Adaptive Access Manager - Server
- Oracle Adaptive Access Manager Admin Server
Click Next.
In the Specify Domain and Location screen enter:
- Domain name: IDM_Domain
- Domain Directory: 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, OAAM Admin Server, and enter the following:
- Data source: OAAM Admin Server
- Service Name: oaam.example.com
- User Name: OAAM_OAAM (assuming OAAM 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: OAAMDBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAAMDBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source. Select the next data source, OAAM Admin MDS Schema, and enter the following information:
- Data Source: OAAM Admin MDS Schema
- Service Name: oaam.example.com
- User Name: OAAM_MDS (assuming OAAM was used as the RCU prefix)
- Password: Password for the OAAM_MDS account.
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAAMDBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAAMDBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source. Select the next data source, OAAM Server, and enter the following information:
- Data Source: OAAM Server
- Service Name: oaam.example.com
- User Name: OAAM_OAAM (assuming OAAM was used as the RCU prefix)
- Password: Password for the OAAM_OAAM account.
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: OAAMDBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: OAAMDBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source. Select the next data source, OWSM MDS Schema, and enter the following information:
- Data Source: OWSM MDS Schema
- Service Name: oaam.example.com
- User Name: OAAM_MDS (assuming OAAM was used as the RCU prefix)
- Password: Password for the OAAM_MDS account.
In the top right box, click Add to add an Oracle RAC host. Enter the following information:
- Host Name: INFRADBHOST1
- Instance Name: oaamdb1
- Port: 1521
Click Add again to add the second database host and enter the following information:
- Host Name: INFRADBHOST2
- Instance Name: oaamdb2
- Port: 1521
Deselect this data source.

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: Enter the virtual hostname of the Administration Server, for example: OAAMHOST1.example.com
- Listen Port: 7001
- SSL listen port: Not applicable
- SSL enabled: leave unchecked
Click Next.
On the Configure Managed Servers screen, create two entries for each OAAMHOST in the topology, that is, one for the OAAM Server and one for the OAAM Admin Server.

Select the OAAM_SERVER entry and change the entry to the following values:
- Name: WLS_OAAM1
- Listen Address: OAAMHOST1.example.com
- Listen Port: 14300
- SSL Listen Port: 14301
- SSL Enabled: Selected
For the second OAAM_SERVER, click Add and supply the following information:
- Name: WLS_OAAM2
- Listen Address: OAAMHOST2.example.com
- Listen Port: 14300
- SSL Listen Port: 14301
- SSL Enabled: Selected
Select the OAAM_ADMIN_SERVER entry and change the entry to the following values:
- Name: WLS_OAAM_ADMIN1
- Listen Address: OAAMHOST1.example.com
- Listen Port: 14200
- SSL Listen Port: 14201
- SSL Enabled: Selected
For the second OAAM_ADMIN_SERVER, click Add and supply the following information:
- Name: WLS_OAAM_ADMIN2
- Listen Address: OAAMHOST2.example.com
- Listen Port: 14200
- SSL Listen Port: 14201
- SSL Enabled: Selected
Leave all other fields at the default settings.

Click Next.
In the Configure Clusters screen, create a cluster by clicking Add.

Enter name: OAAM_Cluster

Create a second cluster by clicking Add.

Enter name: OAAM_Admin_Cluster

Leave all other fields at the default settings.

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 (OAAMHOST1)
- Node Manager Listen Address: The DNS name of the machine (OAAMHOST1.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.

For OAAMHOST1:
- Click the machine OAAMHOST1 in the right window.
- Click the managed server WLS_OAAM1 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST1.
- Click the managed server WLS_OAAM_ADMIN1 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST1.
For OAAMHOST2:
- Click the machine OAAMHOST2 in the right window.
- Click the managed server WLS_OAAM2 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST2.
- Click the managed server WLS_OAAM_ADMIN2 in the left window.
- Click the arrow to assign the managed server to the host OAAMHOST2.
Click Next.
On the Configuration Summary screen, click Create to begin the creation process.

9.3.3.5 Configuring the Database Security Store for the Domain

9.3.3.6 Creating boot.properties for the Administration Server on OAAMHOST1

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

To create the boot.properties file:

Start the Admin Server.

On OAAMHOST1, 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 OAAMHOST1 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://oaamhost1.example.com:7001/console
```
- Oracle Enterprise Manager Fusion Middleware Control at:
```
http://oaamhost1.example.com:7001/em
```
Log into these consoles using the weblogic user credentials.

9.3.3.7 Create the Oracle Adaptive Access Manager Administration User

To create an Administrative user, which will be used to access the OAAM console:

Log into the WebLogic Administration Console using this URL:
```
http://oaamhost1.example.com:7001/console
```
From the Domain Structure menu, click Security Realms and then myrealm.
Click the Users and Groups tab.
Click the Users sub tab.
Click New.
Enter these values:
- Name: Name for the user, for example: oaamadmin
- Provider: Default Authenticator
- Password/Confirmation: Password for user
Click OK.
After the user is created, click the user name.
Click on the Groups sub tab.
Assign the user to the following groups:
- OAAMCSRGroup
- OAAMCSRManagerGroup
- OAAMInvestigatorGroup
- OAAMInvestigationManagerGroup
- OAAMRuleAdministratorGroup
- OAAMEnvAdminGroup
- OAAMSOAPServicesGroup
Click Save.

9.3.3.8 Start OAAMHOST1

This section describes the steps for starting OAAMHOST1.

9.3.3.8.1 Create the Node Manager Properties File on OAAMHOST1

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

9.3.3.8.2 Start Node Manager

Start Node Manager by issuing the following command:

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

9.3.3.8.3 Start Oracle Adaptive Access Manager on OAAMHOST1

To start Oracle Adaptive Access Manager on OAAMHOST1, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oaamhost1.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 servers WLS_OAAM1 and WLS_OAAM_ADMIN1.
Click Start.
Click OK to confirm that you want to start the servers.

9.3.3.9 Validating OAAMHOST1

Validate the implementation by connecting to the OAAM Administration Server at the following URL:

http://OAAMHOST1.example.com:14200/oaam_admin

The implementation is valid if the OAAM Admin console login page is displayed and you can login using the oaamadmin account you created in Section 9.3.3.7, "Create the Oracle Adaptive Access Manager Administration User."

Validate the implementation by connecting to the OAAM Server at:

http://OAAMHOST1.example.com:14300/oaam_server

The implementation is valid if the OAAM Server login page is displayed.

9.3.3.10 Configure Oracle Adaptive Access Manager on OAAMHOST2

Once the configuration has succeeded on OAAMHOST1, you can propagate it to OAAMHOST2. You do this by packing the domain using the pack script on OAAMHOST1, and unpacking the domain using the unpack script on OAAMHOST2.

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

On OAAMHOST1, enter:

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

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

On OAAMHOST2, enter:

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

9.3.3.11 Start OAAMHOST2

Now you will start OAAMHOST2.

This section describes the steps for starting OAAMHOST2.

9.3.3.11.1 Create the Node Manager Properties File on OAAMHOST2

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

9.3.3.11.2 Start Node Manager

Start Node Manager by issuing the following command:

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

9.3.3.11.3 Start Oracle Adaptive Access Manager on OAAMHOST2

To start Oracle Adaptive Access Manager on OAAMHOST2, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://oaamhost2.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 servers WLS_OAAM2 and WLS_OAAM_ADMIN2.
Click Start.
Click OK to confirm that you want to start the servers.

9.3.3.12 Validating OAAMHOST2

Validate the implementation by connecting to the OAAM Administration Server at the following URL:

http://OAAMHOST2.example.com:14200/oaam_admin

The implementation is valid if OAAM Admin console login page is displayed and you can login using the oaamadmin account you created in Section 9.3.3.7, "Create the Oracle Adaptive Access Manager Administration User."

Validate the implementation by connecting to the OAAM Server at:

http://OAAMHOST2.example.com:14300/oaam_server

The implementation is valid if the OAAM Server login page is displayed.

9.3.3.13 Configure Oracle Adaptive Access Manager to Work with Oracle HTTP Server

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

9.3.3.13.1 Update Oracle HTTP Server Configuration

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

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

Create the file with the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName oaam.example.com:7777
    ServerAdmin you@your.address
    RewriteEngine On
    RewriteOptions inherit
 
    <Location /oaam_server>
       SetHandler weblogic-handler
       WebLogicCluster oaamhost1.example.com:14300,oaamhost2.example.com:14300
    </Location>
 
    <Location /oaam_admin>
       SetHandler weblogic-handler
       WebLogicCluster oaamhost1.example.com:14200,oaamhost2.example.com:14200
       WebLogicPort 7001
    </Location>
 
</VirtualHost>

9.3.3.13.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

9.3.3.13.3 Change Host Assertion in WebLogic

Because the Oracle HTTP Server acts as a proxy for WebLogic, by default certain CGI environment variables are not passed through to WebLogic. These include the host and port. You must tell WebLogic that it is using a virtual site name and port so that it can generate internal URLs appropriately.

To do this, log into the WebLogic Administration Console at:

http://oaamhost1.example.com:7001/console

Then perform these steps:

Select Clusters from the home page, or select Environment > Clusters from the Domain Structure menu.
Click Lock and Edit in the Change Center window to enable editing.
Click the Cluster Name (oaam_cluster).
In the General tab, set WebLogic Plug in to Enabled by checking the box in the Advanced Properties section.
Click Save.
Select HTTP and enter the following values:
- Frontend Host: oaam.example.com
- Frontend HTTP Port: 7777
- Frontend HTTPS Port: Set to SSL port on the load balancer or the Oracle HTTP Server SSL port if using SSL communication.
This ensures that any HTTPS URLs created from within WebLogic are directed to port 443 or 80 on the load balancer.
Click Save.
Select Clusters from the home page, or select Environment > Clusters from the Domain Structure menu.
Click the Cluster Name (oaam_admin_cluster).
In the General tab, set WebLogic Plug in to Enabled by checking the box in the Advanced Properties section.
Click Save.
Select HTTP and enter the following values:
- Frontend Host: oaam.example.com
- Frontend HTTP Port: 7777
- Frontend HTTPS Port: Set to SSL port on the load balancer or the Oracle HTTP Server SSL port if using SSL communication.
Click Save.
Click Activate Changes in the Change Center window to save the changes.
Restart managed servers WLS_OAAM1, WLS_OAAM2, WLS_OAAM_ADMIN1 and WLS_OAAM_ADMIN2 as follows:
1. Log into the WebLogic Administration Console using this URL:
```
http://oaamhost1.example.com:7001/console
```
2. Supply the WebLogic administrator username and password.
3. Select Environment - Servers from the Domain Structure menu.
4. Click the Control tab.
5. Click the servers WLS_OAAM1, WLS_OAAM2, WLS_OAAM_ADMIN1, and WLS_OAAM_ADMIN2.
6. Click Shutdown - Force shutdown now.
7. Click Yes to confirm that you want to stop the servers.
8. Select Environment - Servers from the Domain Structure menu.
9. Click the Control tab.
10. Click the servers WLS_OAAM1, WLS_OAAM2, WLS_OAAM_ADMIN1, and WLS_OAAM_ADMIN2.
11. Click Start.
12. Click Yes to confirm that you want to start the servers.
Restart the Administration Server.

9.3.3.14 Validating the Oracle Adaptive Access Manager Configuration

Log into the Oracle Adaptive Access Manager Administration Console at http://oaam.example.com:7777/oaam_admin using the oaamadmin account you created.

Also, log into the Oracle Adaptive Access Manager server at http://oaam.example.com:7777/oaam_server using the oaamadmin account and the password test.

Complete the steps that the 7.7 Post-Installation Steps section of the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management describes.

9.3.3.15 Scaling Up and Scaling Out the Oracle Adaptive Access Manager Topology

This section describes how to scale up and scale out an Oracle Adaptive Access Manager high availability topology. Perform a scale up operation to add a new Oracle Adaptive 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 Oracle Adaptive Access Manager managed server instance to a new node.

9.3.3.15.1 Scaling Up Oracle Adaptive Access Manager

To scale up OAAM, use the same procedure for both the OAAM server and the OAAM Administration Server.

From the Domain Structure window of the Oracle WebLogic Server Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host that you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAAM3.
- 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_OAAM3.
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_OAAM3 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 OAAMHOSTn.

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 the Oracle Fusion Middleware Enterprise Manager Console, 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_OAAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Click Activate configuration from the Change Center menu.

9.3.3.15.2 Scaling Out Oracle Adaptive Access Manager

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

Install Oracle WebLogic Server on the new host as described in Section 9.3.3.3, "Installing Oracle WebLogic Server."
Install Oracle Fusion Middleware Identity Management components on the new host. See Section 9.3.3.4, "Installing and Configuring the Oracle Adaptive Access Manager Application Tier."
Log in to the WebLogic console at http://oaamhost1.example.com:7001/console.
From the Domain Structure pane of the Administration Console, expand the Environment node and then Servers. The Summary of Servers page appears.
Click Lock & Edit from the Change Center menu.
Select an existing server on the host you want to extend, for example: WLS_OAAM1 or WLS_OAAM_ADMIN1.
Click Clone.
Enter the following information:
- Server Name: A new name for the server, for example: WLS_OAAM3
- 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_OAAM3.
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_OAAM3 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 OAAMHOSTn.

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 the Oracle Fusion Middleware Enterprise Manager Console, 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_OAAM3 in the Names column of the table. The Settings page for server appears.
5. Click the SSL tab.
6. Click Advanced.
7. Set Hostname Verification to None.
8. Click Save.
Click Activate configuration from the Change Center menu.

Pack the domain on OAAMHOST1 using the command:

pack.sh -domain=ORACLE_BASE/admin/IDM_Domain/aserver/IDM_Domain -template =/tmp/idm_domain.jar -template_name="OAAM 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="OAAM 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 OAAMHOST2 by running the script setNMProps.sh. The setNMProps.sh script is located in MW_HOME/oracle_common/common/bin. Type:
```
OAAMHOST2> $MW_HOME/oracle_common/common/bin/setNMProps.sh
```
Start Node Manager and the new managed server on the new host
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 oaam.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 /oaam_admin>
    SetHandler weblogic-handler
    WebLogicCluster oaamhost1.example.com:14200,oaamhost2.example.com:14200
</Location>
```
to:
```
<Location /oaam_admin>
    SetHandler weblogic-handler
    WebLogicCluster
oaamhost1.example.com:14200,oaamhost2.example.com:14200,oaamhost3.example.com:14300
</Location>
```

9.4 Oracle Access Management Security Token Service High Availability

This section describes Oracle Access Management Security Token Service high availability.

Security Token Service is a shared Web Service (JAX-WS) that provides a standards-based consolidated mechanism of trust brokerage between different identity domains and infrastructure tiers. Security Token Service brokers trust between a Web Service Consumer (WSC) and a Web Service Provider (WSP) and provides security token lifecycle management services to providers and consumers. Security Token Service can help simplify the effort needed to bridge access to various systems using a standardized set of interfaces.

A Security Token Service high availability deployment depends on Oracle Access Management Access Manager; the Access Manager application contains the Security Token Service server runtime. A Security Token Service high availability deployment cannot occur independent of Access Manager. Access Manager and Security Token Service are bundled together in the OAM J2EE Application EAR file, installed together, and deployed on the same managed server in a WebLogic domain. Security Token Service is also integrated with the Oracle Access Management Console.

For more details on administering and configuring Security Token Service, see one of the following topics in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

For information on patching, see Migrating Oracle Access Manager 11.1.1.3.0 to 11.1.1.6.0

This section includes the following topics:

Section 9.4.1, "Security Token Service High Availability Architecture"
Section 9.4.2, "Security Token Service Component Characteristics"
Section 9.4.3, "Security Token Service High Availability Configuration Steps"
Section 9.4.4, "Validating Security Token Service High Availability"
Section 9.4.5, "Security Token Service Failover and Expected Behavior"
Section 9.4.6, "Disabling and Enabling Security Token Service"
Section 9.4.7, "Troubleshooting Security Token Service"
Section 9.4.8, "Log File Location"
Section 9.4.9, "Additional Considerations"

9.4.1 Security Token Service High Availability Architecture

The following figure shows Security Token Service in a high availability architecture:

Figure 9-7 Security Token Service High Availability Architecture

Description of "Figure 9-7 Security Token Service High Availability Architecture"

This figure shows a two-node deployment of Access Manager/Security Token Service components. This section provides details about an Security Token Service high availability deployment. For more details about the overall Access Manager high availability architecture, which is deployed as part of, see Section 9.2.2.1, "Access Manager High Availability Architecture".

Security Token Service is the server side component that implements the WS-Trust protocol support.

The load balancer receives token requests and routes them to the Security Token Service (STS).

The RAC Database is the same database that Access Manager uses as the Coherence backend store.

The Oracle Access Management Console is a J2EE application that provides services to manage the Security Token Service deployment. As part of the OAM deployment, Administration Console must deploy to the Weblogic AdminServer.

In Security Token Service, each WebLogic Server domain supports one Security Token Service cluster. OAM/Security Token Service clusters cannot span WebLogic Server domains.

Security Token Service is primarily based on the OASIS WS-Trust protocol. However, Security Token Service delegates the processing of other WS-* protocols in the SOAP message to the JAX-WS stack.

Oracle recommends using external load balancers for inbound HTTP/SOAP connections. Outbound external connections to LDAP servers are load balanced with support for connection failover.

9.4.1.1 Clients and Client Connections

Web Service clients that implement the WS-Trust protocol interact with Security Token Service to issue or validate tokens. Clients designed to interact with an STS server, such as OWSM Client, as part of a Web Service call to a Relying Party can invoke Security Token Service.

The client connection process is as follows:

The Web Service client sends a SOAP message over http or https.

The WSS protocol protects the message. The payload contains a WS-Trust request (RST) indicating the operation to perform, which kind of token to issue or validate, and additional information about the token characteristics.
The server processes the request and sends a response over the same channel the server received it on.

The WSS protocol protects the message. The payload contains a WS-Trust response (RSTRC) if the processing was successful or a SOAP fault if an error occurs.

9.4.1.2 Cluster Wide Configuration Changes

Each Security Token Service Access Server instance is a peer of other instances with no inter-instance communication. Because all initialization happens before the Server is ready to receive requests combined with built in throttling capabilities, the WebLogic Server handles surge conditions gracefully without any significant effect on Security Token Service Access Server performance characteristics.

When the cluster stops, the Security Token Service denies new requests and permits existing requests to complete before the Access Server application shuts down. If a forced shutdown occurs, Security Token Service can recover for any corrupted/invalid data that the shutdown causes.

Propagation of configuration changes to all the cluster members is based on a distribution mechanism that leverages the Coherence distributed object cache. The coherence layer notifies all Security Token Service components of change events. The components then uptake these change events. Access Manager components reload their entire configuration every time a change happens.

Note:

The addition/removal of Access Server instance(s) is transparent to other Security Token Service instances in the cluster. Verify that removing a specific Security Token Service server does not affect the load.

9.4.2 Security Token Service Component Characteristics

This section describes Security Token Service component characteristics and includes the following topics:

Section 9.4.2.1, "Security Token Service Component Lifecycle"
Section 9.4.2.2, "Runtime Processes"
Section 9.4.2.2.1, "Starting and Stopping Security Token Service"
Section 9.4.2.2.2, "J2EE Components and Subcomponents"
Section 9.4.2.2.3, "Session State Information"
Section 9.4.2.3, "Configuration Artifacts"
Section 9.4.2.4, "External Dependencies"

9.4.2.1 Security Token Service Component Lifecycle

On startup, the Access Manager/Security Token Service Server initializes connections to the backend repositories. If the repository is not reachable, the Access Manager/Security Token Service server retries the connections to the repositories using a timeout that grows exponentially with a configurable upper limit.

The Access Manager/Security Token Service Server provides continuity of service based on locally cached data if the backend connections go down. Service continues until the caches grow stale or the backend connections come up again.

9.4.2.2 Runtime Processes

The following graphic shows the Security Token Service runtime process.

Figure 9-8 Security Token Service Runtime Process

Description of "Figure 9-8 Security Token Service Runtime Process"

The Security Token Service runtime process works as described below:

A Web Service Consumer (WSC) sends a Web Services-Trust Request Security Token (RST)) message for a security token type that the WSP requires. Authentication of the client occurs by using the transport layer authentication, or by binding the WSS Token to the RST message.
The Security Token Service (STS) validates the RST message, authenticates the request, then authorizes the requested operation.
The appropriate security token is generated in accordance with the metadata that the RST message specifies. For the policy driven exchange use-case, the STS looks up the appropriate token generation policy to generate the appropriate security token.
STS generates an RST message that contains the generated security token; it sends the message to the WSC as a response.

Note:

WSP validation of the security token depends on the token type. When STS acts as a trust intermediary only, validation is performed against the underlying security infrastructure, such as Kerberos.

9.4.2.2.1 Starting and Stopping Security Token Service

Because they are J2EE applications, you can start the Access Server (where Security Token Service is deployed) and the Administration Console from the user interface and Command Line tool that the Application Server provides.

9.4.2.2.2 J2EE Components and Subcomponents

J2EE Components and sub-components include the following:

STS - An event based design pattern that implements the core Security Token Service 11g-PS1. It is packaged as a WAR application in the Access Manager EAR file and comprises a WS Provider Servlet and Java classes. The STS Web Application is bound to the /sts root path
Admin Console - A stand-alone console based on ADF/IDM Shell, and packaged as an .EAR file.
JMX Mbeans - Packaged with the Access Server package. Config Mbeans are packaged as standalone JAR files.
WSLT Command - Consists of Java classes that are in the Access Manager/Security Token Service package.
OWSM Agent - Web Service interceptor providing support for WSS protocol, part of JRF.
ORAProvider - JRF Web Service Provider

9.4.2.2.3 Session State Information

Security Token Service is a stateless J2EE application with the exception of the Nonce caching for Username Tokens, where Security Token Service keeps track of presented username tokens when the nonce is present, to prevent replay attacks.

9.4.2.3 Configuration Artifacts

Access Manager and Security Token Service are built together and use the same modules for configuration, logging, and other processes. The Security Token Service configuration artifacts include the following files.

DOMAIN_HOME/config/fmwconfig/oam-config.xml — Configuration file, which contains instance-specific information.
DOMAIN_HOME/config/fmwconfig/oam-policy.xml — Present only when OES Micro SM is not being used.
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — Logging config
DOMAIN_HOME/config/fmwconfig/cwallet.sso — stores passwords that are used to connect to identity stores, database, and other entities. This is not for end user passwords.
DOMAIN_HOME/config/fmwconfig/.oamkeystore — keystore containing keys and certificates Access Manager/Security Token Service owns
DOMAIN_HOME/config/fmwconfig/amtruststore — keystore containing the trust anchors used for X509 cert validation
DOMAIN_HOME/config/fmwconfig/amcrl.jar — zip file containing CRLs used for certificate revocation
DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSM keystore used to store keys and certificates used by the OWSM Agent, as well as trusted anchors used to validate X.509 certificates for WSS operations
DOMAIN_HOME/config/fmwconfig/.cohstore.jks - trust store that Coherence SSL communication uses

9.4.2.4 External Dependencies

Security Token Service has external dependencies on the:

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/Coherence Store
- Policy (Authentication and Authorization) Repository
- RDBMS access abstracted by the OAM policy engine
- OPSS Security Store

9.4.3 Security Token Service High Availability Configuration Steps

Security Token Service High Availability is configured as part of Access Manager. All Security Token Service system configuration is done using the Oracle Access Management Console. See Section 9.2.3, "Access Manager High Availability Configuration Steps" for more information.

9.4.4 Validating Security Token Service High Availability

You can verify that Security Token Service endpoints are up and running on the different Security Token Service servers. To do so, access the WSDL document of an Security Token Service endpoint directly: http(s)://[hostname:port]/sts/[ENDPOINT]/WSDL

Replace [ENDPOINT] with the existing published endpoint.

9.4.5 Security Token Service Failover and Expected Behavior

This section describes Security Token Service failover characteristics in a high availability environment.

Access Manager Access Servers support a heartbeat check--a ping request over HTTP. In addition, the WebLogic Node Manager on the Managed Server can monitor the application and restart it if necessary.

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.

When 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 from the Coherence Distributed Object Cache and continues processing.

Front Channel HTTP bindings use a load balancing router for failover.

When it receives an exception from another service, Access Manager retries external connection requests. The number of retries is configurable and includes a no retries option.

See the following topics for more information:

Section 9.2.2.2.1, "WebLogic Server Crash"
Section 9.2.2.2.2, "Node Failure"
Section 9.2.2.2.3, "Database Failure"

9.4.5.1 Death Detection and Restart

Access Manager/Security Token Service Access Servers support a heartbeat check in the form of a ping request sent over HTTP. Also, the WebLogic Node Manager on the managed server can monitor the application and restart if the event isn't running. Restarting an Access Manager Access Server does not affect any other cluster components or members.

9.4.5.2 Node Failure

External Connection failover is based on the configuration, retry timeout, and the number of retries. The load balancer or Proxy Server detects node failure and subsequent client connections are routed to the active instance, which picks up the session state from the Coherence DOC and continues with the processing.

9.4.6 Disabling and Enabling Security Token Service

Security Token Service is enabled by default. To disable Security Token Service, you use the Oracle Access Management Console. See Enabling or Disabling Available Services in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

9.4.7 Troubleshooting Security Token Service

Security Token Service logs are logged to the Managed Servers log files. However, you can edit the logging.xml so that it logs Security Token Service information to a separate log file, diagnostic.log, in the folder <DomainHome>/config/fmwconfig/servers/<servername>/sts/log/.

To create an Security Token Service log file to troubleshoot Security Token Service:

Open the file DomainHome/config/fmwconfig/servers/servername/logging.xml

Add the following in the appropriate sections:

<log_handler name='sts-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
      <property name='path' value='sts/log'/>
      <property name='maxFileSize' value='10485760'/>
      <property name='maxLogSize' value='104857600'/>
    </log_handler>
 
<logger name='oracle.security.fed' level='TRACE:32'>
      <handler name='sts-handler'/>
    </logger>

9.4.8 Log File Location

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

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

9.4.9 Additional Considerations

The Security Token Service server can detect fake requests, such as replay attacks, that can occur if a user tries to steal token data from a request and send another request with the same token. In this case, the server detects the second fake request. The second issuance request with the same token in <Env: Body> goes to the Security Token Service server. The server denies the request after checking its UNT token cache, which indicates a replay attack.

9.5 Oracle Access Management Identity Federation High Availability

This section describes Oracle Access Management Identity Federation 11gR2 high availability. See Integration with Access Manager 11gR2 in the Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite for additional details on Identity Federation.

This section includes the following topics:

Section 9.5.1, "Identity Federation Component Architecture"
Section 9.5.2, "Identity Federation High Availability Concepts"
Section 9.5.3, "Identity Federation High Availability Configuration"
Section 9.5.4, "Identity Federation Failover and Expected Behavior"
Section 9.5.5, "Troubleshooting Identity Federation High Availability"

9.5.1 Identity Federation Component Architecture

Identity Federation service provides single sign-on capabilities to Oracle Access Management Access Manager in a multiple-domain identity network. It supports the broadest set of federation standards, enabling users to federate in heterogeneous environments and business associations, whether or not they implement other Oracle Identity Management products in their solution set.

Only Identity Federation 11g Release 2 supports the Service Provider (SP) functionality. For Identity Provider (IDP) support, use Identity Federation 11g Release 1.

Acting as an SP, Identity Federation enables you to manage your resources while offloading user authentication to an IDP, without having to synchronize users across security domains out of band. Once authenticated at the IDP, the SP can enable or deny access to users for the SP's applications, depending on local access policies.

If a user no longer has an account with the IDP, the federation is terminated and cross-domain single sign-on for that user is automatically disabled.

Key features of Identity Federation include support for:

Multiple leading federation protocols such as SAML 1.x and SAML 2.0
Cross-protocol single sign-on and sign-out
X.509 certificate validation
Native Integration with Access Manager
Integration with any LDAP Directory supported by Access Manager

Figure 9-9 Identity Federation Architecture

Description of "Figure 9-9 Identity Federation Architecture"

For more details about how Identity Federation integrates with Access Manager, see Integration with Access Manager 11gR2 in Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite.

9.5.1.1 Identity Federation Component Characteristics

Identity Federation is an Oracle Access Management component providing SP functionality for Cross Domain Single Sign-On. It enables Oracle Access Management to delegate user authentication to a remote Identity Provider partner. It supports a broad set of federation standards such as SAML 1.x, SAML 2.0.

Section 9.5.1.1.1, "Runtime Processes"
Section 9.5.1.1.2, "Process Lifecycle"
Section 9.5.1.1.3, "Request Flow"
Section 9.5.1.1.4, "Configuration Artifacts"
Section 9.5.1.1.5, "External Dependencies"
Section 9.5.1.1.6, "Identity Federation Log File Location"

9.5.1.1.1 Runtime Processes

Identity Federation is part of the Access Manager J2EE application deployed on the WebLogic Server.

Because Identity Federation runs within the Access Server, it has the same runtime processes as Access Manager. For more information, see Section 9.2.1.1.3, "Access Manager Process Lifecycle".

9.5.1.1.2 Process Lifecycle

Identity Federation follows the same process lifecycle as Access Manager. See Section 9.2.1.1.3, "Access Manager Process Lifecycle" for more information.

9.5.1.1.3 Request Flow

See Architecture in Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite for information on the Identity Federation request flow.

9.5.1.1.4 Configuration Artifacts

The Identity Federation configuration artifacts include the following files.

DOMAIN_HOME/config/fmwconfig/oam-config.xml — configuration file containing instance-specific information.
DOMAIN_HOME/config/fmwconfig/oam-policy.xml — present only when OES Micro SM is not being used.
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml — Logging config
DOMAIN_HOME/config/fmwconfig/cwallet.sso — stores passwords that are used to connect to identity stores, database, and other entities. This is not for end user passwords.
DOMAIN_HOME/config/fmwconfig/.oamkeystore — keystore containing keys and certificates OAM/Identity Federation owns
DOMAIN_HOME/config/fmwconfig/amtruststore — keystore containing the trust anchors used for X509 cert validation
DOMAIN_HOME/config/fmwconfig/amcrl.jar — zip file containing CRLs used for certificate revocation
DOMAIN_HOME/config/fmwconfig/default-keystore.jks — OWSM keystore used to store keys and certificates used by the OWSM Agent, as well as trusted anchors used to validate X.509 certificates for WSS operations
DOMAIN_HOME/config/fmwconfig/servers/servername/dms_config.xml — eventing configuration file
DOMAIN_HOME/config/fmwconfig/component_events.xml — audit definition
DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml — Administration Console permissions
DOMAIN_HOME/config/fmwconfig/cacerts.jks — keystore containing Certificate Authority certificates.

9.5.1.1.5 External Dependencies

The following external components are required for Identity Federation server to function:

WebLogic Server
- Administration Server
- Managed Server
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/Coherence Store
- Policy (Authentication and Authorization) Repository
- RDBMS access abstracted by the Access Manager policy engine
Oracle Entitlements Server (though OAM)
Federation Data Cache
- For session and runtime information. You can configure Identity Federation to use the memory store or RDBMS store for this. However, in a high availability environment you must use a RDBMS store.

Data Repositories

The session information related to federation, partners where the user is signed in, and protocol data is stored in the session and cache. You can configure Identify Federation to use either a memory store or an RDBMS store for this data. For high availability environments, you must use a RDBMS store.

9.5.1.1.6 Identity Federation Log File Location

The default location of the WebLogic Server log file is:

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

Use the Oracle Enterprise Manager Fusion Middleware Control to view the log files.

9.5.2 Identity Federation High Availability Concepts

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

This section includes the following topics:

Section 9.5.2.1, "Identity Federation High Availability Architecture"
Section 9.5.2.2, "Identity Federation Prerequisites"

9.5.2.1 Identity Federation High Availability Architecture

Figure 9-10 shows the Identity Federation high availability architecture in an active-active configuration.

Figure 9-10 Identity Federation in a High Availability Architecture

Description of "Figure 9-10 Identity Federation in a High Availability Architecture"

In Figure 9-10,the hardware load balancer receives incoming authentication requests and routes them a web server in the web tier. These hosts have Oracle HTTP Server installed. The Oracle HTTP Server forwards requests to the WebLogic managed servers using WebLogic plugin mod_wl_ohs.conf.

The load balancing router should use session stickiness for HTTP traffic only.

The two managed servers that host the Oracle Access Server application are configured in a cluster which enables the Access Servers to work in active-active mode.

If a federation scheme protects the resource being accessed, OAM uses the Federation Engine to authenticate the user.

The LDAP directories that the Federation Engine uses are deployed in a cluster.

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

The WebLogic Administration Server runs on the same host as one of the managed servers and deploys the WebLogic Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and the Oracle Access Management Console. You can configure the Administration Server to run in active-passive mode on the host machine that runs the second managed server. In this configuration, if the first Administration Server becomes unavailable, you can start the Administration Server manually on the second host.

9.5.2.1.1 Starting and Stopping the Cluster

Identity Federation clusters start and stop in the same manner as OAM clusters. For more information, see Section 9.2.2.1.1, "Starting and Stopping the Cluster."

9.5.2.1.2 Cluster-Wide Configuration Changes

Configuration changes made through one cluster member propagate automatically to all others because the configuration is stored in the shared database. See Section 9.2.2.1.2, "Cluster-Wide Configuration Changes" for additional information.

9.5.2.2 Identity Federation Prerequisites

Because Identity Federation is part of OAM, it has the same prerequisites as OAM. See Section 9.2.3.1, "Prerequisites for Access Manager Configuration" for more information.

Note:

Oracle requires that you synchronize the system clocks on the cluster nodes when you are using Identity Federation in a high availability deployment.

9.5.3 Identity Federation High Availability Configuration

As a feature that runs on OAM servers, you configure Identity Federation high availability as part of OAM high availability. To configure OAM high availability, see Section 9.2.3, "Access Manager High Availability Configuration Steps". Note the following special considerations as you configure Identity Federation for high availability.

Section 9.5.3.1, "Setting the Hostname and Port"
Section 9.5.3.2, "Changing the ProviderID Value"
Section 9.5.3.3, "Tuning Identity Federation Parameters"

9.5.3.1 Setting the Hostname and Port

Oracle recommends that you set the host name and port in the OAM/Identity Federation configuration to the load balancer host and port. If you do not, errors occur during Single Sign-On/Logout operation. Oracle also recommends that you use virtualized hostnames in OAM configuration so that, after a restore on a different host, the corresponding agent configuration does not require updates.

9.5.3.2 Changing the ProviderID Value

The ProviderId is a string that uniquely identifies the SP. The ProviderId for all servers in a cluster must be identical. The ProviderId defaults to http://host:port/oam/fed/ at installation. If necessary, change or set this value after installation; do not change it during operation.

9.5.3.3 Tuning Identity Federation Parameters

You can tune the connection to the RAC database that stores session data.

If you use the artifact profile, use WLST to tune SOAP connection details.

Identity Federation parameters that you can set include the following:

"Outgoing SOAP connection"
"RDBMS Transient Store Asynchronous Settings"
"RDBMS Artifact memory cache settings"
"RDBMS Memory cache settings"
"Interval for the RDBMS cleanup thread"

Outgoing SOAP connection

Outgoing SOAP connection parameters that you can tune include:

Max connections total
Max connections per host

RDBMS Transient Store Asynchronous Settings

Table 9-5 describes RDBMS transient store asynchronous settings.

Table 9-5 RDBMS Transient Store Asynchronous Settings

Setting	Description
rdbmsasynchronousmanagerinterval	Execution interval for the asynchronous thread manager
rdbmsasynchronousmanagersleep	Sleep interval for the asynchronous thread manager, to check if execution should occur
rdbmsasynchronousqueuesize	Size of the queue containing RDBMS operations of the same type (create session, create artifact)
rdbmsasynchronousqueuesleep	Sleep time before the calling thread can retry adding an operation to a queue if the queue is full
rdbmsasynchronousqueueretries	Number of retries when attempting to add an operation to the queue if the queue is full
rdbmsasynchronousthreadcore	Number of default threads in the RDBMS thread executor module for RDBMS asynchronous operations
rdbmsasynchronousthreadkeepalive	Maximum amount of time to keep the extra threads in the RDBMS thread executor module for RDBMS asynchronous operation
rdbmsasynchronousthreadmax	Maximum number of threads in the RDBMS thread executor module for RDBMS asynchronous operation
rdbmsasynchronousthreadpolicy	Thread policy of the RDBMS thread executor module for RDBMS asynchronous operation
rdbmsasynchronousthreadqueuesize	Thread queue size of the of the RDBMS thread executor module for RDBMS asynchronous operation

RDBMS Artifact memory cache settings

Table 9-6 describes RDBMS Artifact memory cache settings, used in conjunction with the RDBMS asynchronous module.

Table 9-6 RDBMS Artifact memory cache settings

Setting	Description
artifactrdbmscachetimeout	Time to live in the memory cache
artifactrdbmsretries	Maximum number of time to retry to locate an entry in RDBMS before returning a failure
artifactrdbmssleep	Sleeping time between retrying lookup operations

RDBMS Memory cache settings

Table 9-7 describes RDBMS Memory cache setting, with the exception of artifact settings (see Table 9-6).

Table 9-7 RDBMS Memory Cache Settings

Setting	Description
transientrdbmscachesize	Cache size
transientrdbmscachetimeout	Time to live for cache objects before becoming invalid and forcing an RDBMS lookup operation when an object is searched

Interval for the RDBMS cleanup thread

The setting for the RDBMS cleanup thread interval is rdbmscleanupinterval, which indicates the sleep interval of the thread that removes expired entries from Identity Federation database tables.

9.5.4 Identity Federation Failover and Expected Behavior

This section describes steps for performing failover operations on Identity Federation instances deployed in a high availability environment and their expected behavior.

To perform a test of a failover of an Identity Federation instance and to check the status of Identity Federation:

Log in to the Administration Server console. Go to Home, Summary of Security Realms, myrealm, Users and Groups, Realm Roles, then Edit Global Role. Add the group OAMAdminstrators.
Log in to the OAM Administration Console. Go to System Configuration, Common Settings, Available Services then enable Identity Federation.
Set up Identity Federation between an IDP instance (which can be an Oracle Identity Federation 11g Release 1 instance) and this Identity Federation 11gRelease 2 instance that is functioning as an SP.
Integrate with OAM 11gR2 and protect a resource with OIFScheme. Follow the steps in Integration with Access Manager 11gR2 in Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite.
Shut down one of the two managed servers and try to access the protected resource.
When the IDP login page appears, restart the managed server that you stopped in the previous step, shut down the managed server that was running, and try to complete the operation.

9.5.5 Troubleshooting Identity Federation High Availability

Use the following tips to troubleshoot Identity Federation issues:

Identity Federation logs its messages in the Managed Server log files, for example:

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

Verify that the hostname and port in the Identity Federation server configuration are set to the load balancer host and port, otherwise errors occur during Single Sign-On operation.
If system clocks on the computers which IDP and SP run on have different times, errors occur during Single Sign-On. Fix this by setting the system clocks to have the same time or by adjusting the server drift using the Server Properties page in Oracle Enterprise Manager Fusion Middleware Control.
The ProviderId string uniquely identifies the IDP/SP and must be identical for all servers in a cluster. The ProviderId string defaults to: http://host:port/oam/fed at installation. If you must change ProviderId, change it after installation, not during an operation.

9.6 Oracle Entitlements Server High Availability

This section introduces Oracle Entitlements Server and describes how to set up a high availability environment for Oracle Entitlements Server components.

Oracle Entitlements Server is a fine-grained authorization product that allows an organization to protect its resources by defining and managing policies that control access to, and usage of, these resources. A policy defines access privileges by specifying who can do what to which resource, when it can be done, and how. The policy can enforce controls on all types of resources including software components and business objects.

See Overview of the Oracle Entitlements Server Architecture in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for an illustration and description of the Oracle Entitlements Server component architecture.
See Features of Oracle Entitlements Server 11gR2 in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information on Oracle Entitlements Server features.

This section includes the following topics:

Section 9.6.1, "Oracle Entitlements Server High Availability Concepts"
Section 9.6.2, "Configuring Oracle Entitlements Server High Availability"

9.6.1 Oracle Entitlements Server High Availability Concepts

This section provides conceptual information about using Oracle Entitlements Server in a high availability two-node cluster.

This section includes the following topics:

Section 9.6.1.1, "Oracle Entitlements Server High Availability Architecture"
Section 9.6.1.2, "Oracle Entitlements Server Security Module High Availability"
Section 9.6.1.3, "Load Balancing"
Section 9.6.1.4, "Failover Considerations"
Section 9.6.1.5, "Protection from Failures and Expected Behaviors"
Section 9.6.1.6, "Starting and Stopping the Oracle Entitlements Server Cluster"
Section 9.6.1.7, "Cluster-Wide Configuration Changes"
Section 9.6.1.8, "Considerations for Synchronizing with LDAP"

9.6.1.1 Oracle Entitlements Server High Availability Architecture

This section describes the following high availability architecture scenarios for Oracle Entitlements Server components.

This section includes the following topics:

Section 9.6.1.1.1, "Oracle Entitlements Server Administration Server High Availability"
Section 9.6.1.1.2, "Security Module (OES Client)/Policy Information Point High Availability"
Section 9.6.1.1.3, "Security Module in Proxy Mode Working Against Web Service / RMI Security Module in Controlled-Push Mode High Availability"
Section 9.6.1.1.4, "Security Module in Proxy Mode Working Against Web Service / RMI Security Module in Controlled Pull Mode High Availability"
Section 9.6.1.1.5, "Oracle Entitlements Server WebLogic Server Security Module High Availability"

9.6.1.1.1 Oracle Entitlements Server Administration Server High Availability

Figure 9-11 shows the Oracle Entitlements Server Administration Server deployed in a high availability architecture in an active-active configuration.

Figure 9-11 Oracle Entitlements Server Administration Server High Availability Architecture

Description of "Figure 9-11 Oracle Entitlements Server Administration Server High Availability Architecture"

On OESHOST1, you see the following installations:

An Oracle Entitlements Server instance is installed in the WLS_OES1 Managed Server and a APM instance is installed in the WLS_OES1 Managed Server.
The Oracle RAC database is configured in a JDBC multi data source or GridLink Data source to protect the instance from Oracle RAC node failure.
A WebLogic Server Administration Server is installed. Under normal operations, this is the active Administration Server.

On OESHOST2, you see the following installations:

An Oracle Entitlements Server instance is installed in the WLS_OES2 Managed Server and an APM instance is installed in the WLS_OES2 Managed Server.
The Oracle RAC database is configured in a JDBC multi data source to protect the instance from Oracle RAC node failure.
The instances in the WLS_OES1 and WLS_OES2 Managed Servers on OESHOST1 and OESHOST2 are configured as the OES_CLUSTER cluster.
A WebLogic Server Administration Server is installed. Under normal operations, this is the passive Administration Server. You make this Administration Server active if the Administration Server on OESHOST1 becomes unavailable.

You can configure Oracle Entitlements Server Security Modules in controlled-push mode so that two Oracle Entitlements Server Administration Servers function as a registration server and backup registration server. The Oracle Entitlements Server Security Modules can switch to a backup server and get distributed policy from the Oracle Entitlements Server Administration Server if the registration server is down. See Section 9.6.1.4, "Failover Considerations" for information about failover scenarios and behavior.

9.6.1.1.2 Security Module (OES Client)/Policy Information Point High Availability

You can deploy the Security Module so that it is embedded and configure it to failover between different Policy Information Points (PIP). A PIP is a data repository, a source from which information can be retrieved for use when evaluating policies for an authorization decision. For more information on PIP, see The Policy Information Point in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

See the following topics for deployment options:

"Oracle Entitlements Server PIP with Multiple LDAP/JDBC URLs"
"Oracle Entitlements Server PIP with RAC and Load Balancer"

Oracle Entitlements Server PIP with Multiple LDAP/JDBC URLs

Figure 9-12 shows an embedded Security Module instance in a high availability deployment. With both LDAP and DB-based PIP, you can configure multiple endpoints for external sources to failover between them. For DB-based PIP, you can also configure a multi-source datasource.

Figure 9-12 Security Module / Policy Information Point Configuration

Description of "Figure 9-12 Security Module / Policy Information Point Configuration"

Figure 9-12 shows an Oracle Entitlements Server deployment in which the Security Module (PDP) uses LDAP 1 or Database 1 as its primary PIP. In the case of failover, the Security Module fails over to LDAP2 and Database 2.

Oracle Entitlements Server PIP with RAC and Load Balancer

Another high availability deployment option for Oracle Entitlements Server is one in which the Security Module (PDP) uses the RAC database or LDAP servers with a load balancer. In the case of failover, the Security Module fails over to the RAC, as Figure 9-13 shows.

Figure 9-13 Oracle Entitlements Server PIP with RAC and Load Balancer

Description of "Figure 9-13 Oracle Entitlements Server PIP with RAC and Load Balancer"

9.6.1.1.3 Security Module in Proxy Mode Working Against Web Service / RMI Security Module in Controlled-Push Mode High Availability

Oracle Entitlements Server supports a proxy mode that allows clients to invoke authorization services remotely. See Using the Security Module Proxy Mode of the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.There are three deployment options for deploying Security Module in proxy mode:

"Web Service Security Module on WebLogic Server Deployment"
"Standalone Web Service Security Module Deployment"
"RMI Security Module Deployment"

Web Service Security Module on WebLogic Server Deployment

Figure 9-14 shows a Web Service Security Module on WebLogic Server.

Figure 9-14 Web Service Security Module on WebLogic Server Deployment

Description of "Figure 9-14 Web Service Security Module on WebLogic Server Deployment"

Standalone Web Service Security Module Deployment

Figure 9-15 shows a standalone Web Service Security Module deployment.

Figure 9-15 Standalone Web Service Security Module Deployment

Description of "Figure 9-15 Standalone Web Service Security Module Deployment"

RMI Security Module Deployment

Figure 9-16 shows a RMI Security Module deployment.

Figure 9-16 RMI Security Module Deployment

Description of "Figure 9-16 RMI Security Module Deployment"

9.6.1.1.4 Security Module in Proxy Mode Working Against Web Service / RMI Security Module in Controlled Pull Mode High Availability

Options to deploy Security Module in proxy mode working against Web Service/RMI Security Modules in controlled-pull mode include the following:

"Web Service Security Module on WebLogic Server"
"Standalone Web Service Security Module"
"RMI Security Module"

Web Service Security Module on WebLogic Server

Figure 9-17 shows Web Service Security Module on WebLogic Server.

Figure 9-17 Web Service Security Module on WebLogic Server

Description of "Figure 9-17 Web Service Security Module on WebLogic Server "

Standalone Web Service Security Module

Figure 9-18 shows a standalone Web Service Security Module deployment.

Figure 9-18 Standalone Web Service Security Module

Description of "Figure 9-18 Standalone Web Service Security Module"

RMI Security Module

Figure 9-19 shows a RMI Security Module deployment.

Figure 9-19 RMI Security Module

Description of "Figure 9-19 RMI Security Module"

See PDP Proxy in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information on configuring the Web Services Security Module proxy client and the RMI Security Module proxy client.

9.6.1.1.5 Oracle Entitlements Server WebLogic Server Security Module High Availability

There are two deployment options for OES WebLogic Server high availability:

"Oracle Entitlements Server WebLogic Server Security Module, Controlled-push Mode"
"Oracle Entitlements Server WebLogic Server Security Module High Availability, Controlled-pull or Non-Controlled Mode"

Oracle Entitlements Server WebLogic Server Security Module, Controlled-push Mode

The following graphic shows Oracle Entitlements Server WebLogic Server Security Module in controlled-push mode.

Figure 9-20 Oracle Entitlements Server WebLogic Server Security Module, Controlled-push Mode

Description of "Figure 9-20 Oracle Entitlements Server WebLogic Server Security Module, Controlled-push Mode"

Oracle Entitlements Server WebLogic Server Security Module High Availability, Controlled-pull or Non-Controlled Mode

The following figure shows an Oracle Entitlements Server with WebLogic Server Security Module in controlled-pull/non-controlled mode.

Figure 9-21 Oracle Entitlements Server WebLogic Server Security Module Controlled-pull/Non-Controlled Mode

Description of "Figure 9-21 Oracle Entitlements Server WebLogic Server Security Module Controlled-pull/Non-Controlled Mode"

9.6.1.2 Oracle Entitlements Server Security Module High Availability

When the Security Module reads policy from the OPSS security store for controlled-pull or non-controlled distribution, use Oracle-recommended high availability methods for an application accessing a database.

9.6.1.3 Load Balancing

For all high availability scenarios, you can deploy the load balancer:

In front of Authorization Policy Manager (APM) for user-to-APM communication. Oracle recommends a sticky connection to avoid losing data that does not persist to the policy store.
In front of the Web Service Security Module for client-to-Security Module communication. Oracle recommends a sticky connection to maximize cache usage.

Note:

Oracle Entitlements Server does not have any timeout requirements for the load balancer.

9.6.1.4 Failover Considerations

This section describes Oracle Entitlements Server failover considerations.

Table 9-8 Oracle Entitlements Server Failover Scenarios and Behavior

Failover Scenario	Failover Behavior
OES Policy Store fails	APM and Security Module in controlled-pull and uncontrolled mode switch to a working instance if multi-source data source is used. If the policy store instance is lost while the transaction is being processed: APM returns an error to the user, who can repeat the request. Security Module retries the transaction. Security Module uses only read operations. If Security Module is in controlled-pull mode, it uses the locally-persisted copy of the policy store.
OES Admin Server fails	User-to-APM communication - If a load balancer is present, it redirects the user to another APM instance. All unsaved data in the user session is lost, however, the user has full access to persisted policy data. Security Module-to-APM communication - In controlled push distribution, Security Module registers with OES Admin on startup and retries the request to back-up instance if primary one is down. Retries continues until working instance is detected. While trying to reach OES Admin, Security Module uses a locally-persisted copy of the policy store.
Web Service Security Module or RMI Security Module fails	Security Module Proxy retries requests until it reaches the configured number of retries.
DB or LDAP attribute source fails	Security Module (OES Client) continues to try to read data until it reaches the configured number of retries.

9.6.1.5 Protection from Failures and Expected Behaviors

This section describes protection from different types of failure in an Oracle Entitlements Server active-active cluster.

Section 9.6.1.5.1, "Expected Client Application Behavior When Failure Occurs"
Section 9.6.1.5.2, "Node failure"
Section 9.6.1.5.3, "Database failure"

9.6.1.5.1 Expected Client Application Behavior When Failure Occurs

Oracle Entitlements Server failover is not transparent. You must reestablish the connection during a WebLogic Server instance failover using Oracle Entitlements Server.

9.6.1.5.2 Node failure

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

9.6.1.5.3 Database failure

Oracle Entitlements Server is protected against failures in the database by using multi data sources, which you configure during the initial system set up. The multi data sources guarantee that when an Oracle RAC database instance fails, the connections reestablish with available database instances. The multi data source allows you to configure connections to multiple instances in an Oracle RAC database.

9.6.1.6 Starting and Stopping the Oracle Entitlements Server Cluster

In a high availability architecture, you deploy Oracle Entitlements Server on a WebLogic cluster, which has at least two servers as part of the cluster.

Use one or more of the following command line tools and consoles to manage Oracle Entitlements Server lifecycle events:

WebLogic Server Administration Console
Oracle Enterprise Manager Fusion Middleware Control
Oracle WebLogic Scripting Tool (WLST)

9.6.1.7 Cluster-Wide Configuration Changes

For high availability environments, changing the configuration of one Oracle Entitlements Server instance changes the configuration of all the other instances, because all the Oracle Entitlements Server instances share the same configuration repository. Nearly all Oracle Entitlements Server deployments use cluster configurations. The only exception is Oracle Entitlements Server Administration Server, which is usually not clustered.

9.6.1.8 Considerations for Synchronizing with LDAP

Synchronization between LDAP and the Oracle Entitlements Server database is handled by a process called Reconciliation, which is a scheduled process that runs in the background primarily. You can also run this process manually.

If an LDAP outage occurs during the Synchronization process, the data which did not get into Oracle Entitlements Server is picked up during the next run of the reconciliation task.

9.6.2 Configuring Oracle Entitlements Server High Availability

This section provides high-level instructions for setting up a high availability deployment for Oracle Entitlements Server.

The Oracle Entitlements Server Administration Server high availability deployment is the same as a typical Oracle application.

To set up high availability for users accessing the Oracle Entitlements Server Administration Server user interface, use a WebLogic cluster.

To set up a high availability database for Administration Server user interface, you use multi source data source, Oracle RAC, and other typical elements.

This section includes the following topics:

Section 9.6.2.1, "Prerequisites for Oracle Entitlements Server Configuration"
Section 9.6.2.2, "Configure Weblogic Domain for OES Administration Server on OESHOST1"
Section 9.6.2.3, "Post-Configuration and Verification"
Section 9.6.2.4, "Configure OES Security Module in Controlled-push Mode with Oracle Entitlements Server Administration Server High Availability"
Section 9.6.2.5, "Configure Oracle Entitlements Server Security Module in Proxy Mode with PDP High Availability"
Section 9.6.2.6, "Configure Oracle Entitlements Server Policy Information Point with High Availability"
Section 9.6.2.7, "Configuring Oracle Entitlements Server Web Service Security Module on WebLogic High Availability"
Section 9.6.2.8, "Configuring Oracle Entitlements Server WebLogic Security Module High Availability"
Section 9.6.2.9, "Using RAC Datasource for Security Module in Controlled-pull Mode and Non-controlled Mode"
Section 9.6.2.10, "Configuring Oracle Entitlements Server to Work with the Web Tier"

9.6.2.1 Prerequisites for Oracle Entitlements Server Configuration

Complete the following steps before you configure Oracle Entitlements Server high availability:

Use the Repository Creation Utility to create the Oracle Entitlements Server schemas in the Oracle RAC database. See Installation and Configuration Roadmap for Oracle Entitlements Server in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for information on creating schemas.
Install Weblogic Server on OESHOST1 and OESHOST2. See Section 9.1.3.1.2, "Installing Oracle WebLogic Server" for more information.
Install the Oracle Entitlements Server Administration software on OESHOST1 and OESHOST2. See Installing Oracle Entitlements Server Administration Server in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for more information.
Install the Oracle Entitlements Server Client. See Installing Oracle Entitlements Client in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for more information.

9.6.2.2 Configure Weblogic Domain for OES Administration Server on OESHOST1

To configure a WebLogic domain for the OES Administration Server on OESHOST1, perform these steps:

Run the <MW_HOME>/oracle_common/common/bin/config.sh script.
On the Welcome screen, select Create a new WebLogic domain and click Next. The Select Extension Source screen appears.
On the Select Extension Source screen, select Oracle Entitlements Server for Managed Server - 11.1.1.0[Oracle_IDM1. The Configuration Wizard automatically selects Oracle JRF, Oracle Platform Security Service, and Basic WebLogic Server Domain.

Click Next.
In the Specify Domain Name and Location screen, enter the domain name for the domain you are creating and the domain location. Click Next. The Configure Administrator User Name and Password screen appears.
Configure a user name and a password for the administrator. The default user name is weblogic. Click Next.
Choose the Weblogic domain startup mode and JDK in the Configure Server Start Mode and JDK screen.
In the Configure JDBC Component Schema screen, configure JDBC properties for all of the schemas then click Next.
On the Test JDBC Component Schema screen, click Select All then Test Connections. Click Next.

If the data source validation succeeds, click Next.

If the data source validation fails, click Previous, correct the issue, then try again.
On the Select Optional Configuration screen, select Administration Server and Managed Servers, Clusters and Machines. Click Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen address: All Local Addresses
- Listen port: 7001
- SSL listen port: 7002
- Select SSL enabled
Click Next.
On the Configure Managed Servers screen, when you first enter the screen, one managed server called oes_server1 is created automatically. You can rename oes_server1 and update its attributes for this entry.

For example:
- Name: oes_server1
- Listen Address: OESHOST1.example.com
- Listen Port: 14600
- SSL Port: 14601
For the second OES_SERVER, click Add and enter the following values:
- Name: oes_server2
- Listen Address: OESHOST2.example.com
- Listen Port: 14600
- SSL Port: 14601
- Select SSL enabled
Click Next.
In the Configure Clusters screen, click Add to create a cluster.

Enter the name oes_cluster. Select unicast for Cluster messaging mode, then enter the Cluster address in the format listen address or DNS name of oes_server1:port,listen address or DNS name of oes_server2:portmanaged server1:port,managed server2: port.

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster:

Click on the cluster name oes_cluster in the right window.

Click on the managed server oes_server1 then click the arrow to assign it to the cluster.

Repeat the preceding steps for the managed server oes_server2.

Click Next.
On the Configure Machines screen, create a machine for each host in the topology.

Click on the Unix tab.

For Admin Server Host:
- Name: Name of your host. Use the DNS name here.
- Node Manager Listen Address: Oracle recommends that the machine IP address be identical to the DNS name of the machine.
- Node Manager Listen Port: Enter a port for Node Manager to use.
Leave all other values at the default settings.

Repeat the preceding steps for OESHOST1 and OESHOST2 and enter the following values. Leave all other values at the default settings.
- Name: Name of the host. A good practice is to use the DNS name.
- Node Manager Listen Address: Oracle recommends that the machine IP address be identical to the DNS name of the machine.
- Node Manager Listen Port: Enter a port for Node Manager to use.
For Unix operating systems, delete the default local machine entry under the Machines tab.

Click Next.
On the Assign Servers to Machines screen, you assign the managed servers that will run on the machines you just created. Follow these steps:

Click on a machine in the right hand window.

Click on the managed servers you want to run on that machine in the left window.

Click on the arrow to assign the managed servers to the machine.

Repeat these steps until you assign all managed servers to the appropriate machine.

Assign servers to machines as follows:
- ADMINHOST: Admin Server
- OESHOST1: oes_server1
- OESHOST2: oes_server2
Click Next.
On the Configuration Summary screen, click Create.
Verify that the first RAC database instance in the OPSS security store configuration is running.
Configure the OPSS Security Store. See Configuring Security Store for OES Administration Server in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

9.6.2.3 Post-Configuration and Verification

This section includes the following topics:

Section 9.6.2.3.1, "Starting Node Manager"
Section 9.6.2.3.2, "Validating the WebLogic Administration Server"
Section 9.6.2.3.3, "Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server"
Section 9.6.2.3.4, "Propagate Changes to Remote Server"
Section 9.6.2.3.5, "Start Node Manager on Remote Hosts"
Section 9.6.2.3.6, "Stop and Start the WebLogic Administration Server and start oes_server1 and oes_server2"

9.6.2.3.1 Starting Node Manager

Perform these steps to start Node Manager on the administration host, for example, OESHOST1.

Run the startNodeManager.sh script located in the MW_HOME/wlserver_10.3/server/bin/ directory.
Run the setNMProps.sh script to set the StartScriptEnabled property to true:

cd MW_HOME/oracle_common/common/bin
Stop the Node Manager by killing the Node Manager process.
Start Node Manager.

9.6.2.3.2 Validating the WebLogic Administration Server

Perform the following steps to verify that the Administration server is configured properly.

Start Weblogic Administration Server by using ./startWeblogic.sh in the new domain.
In a browser, enter the URL for the Oracle WebLogic Server Administration Console, for example:

http://<OESHOST1>:7001/console
Log in as the WebLogic administrator, for example, weblogic.

9.6.2.3.3 Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server

Use the pack and unpack commands to separate the domain directory used by the Administration Server from the domain directory used by the managed server in OESHOST1.

To create a separate domain directory on OESHOST1:

Run the pack command to create a template pack as follows:

cd MW_HOME/oracle_common/common/bin

./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=domaintemplate.jar -template_name=domain_template
Run the unpack command to unpack the template in the managed server domain directory as follows:

cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar

9.6.2.3.4 Propagate Changes to Remote Server

Perform an unpack on remote hosts before you start managed servers on remote hosts, for example, OESHOST2.

Copy the file domaintemplate.jar created in Section 9.6.2.3.3, "Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server" to OESHOST2.
Run unpack on the host on OESHOST2 using the following commands:

cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=domaintemplate.jar

9.6.2.3.5 Start Node Manager on Remote Hosts

To start Node Manager on remote hosts, follow these steps:

On OESHOST2, start the Node Manager to create the nodemanager.properties file by using the startNodemanager.sh script located in the MW_HOME/wlserver_10.3/server/bin directory.
Run the setNMProps.sh script to set the StartScriptEnabled property to true:

cd MW_HOME/oracle_common/common/bin

./setNMProps.sh
Stop and start the Node Manager.

9.6.2.3.6 Stop and Start the WebLogic Administration Server and start oes_server1 and oes_server2

Restart the WebLogic Administration Server.
In a browser, enter the URL for the Oracle WebLogic Server Administration Console, for example:

http://<OESHOST1>:7001/console
Log in as the WebLogic administrator, for example, weblogic.
Start oes_server1 and oes_server2 managed servers from the WebLogic Server Admin console.

Note:

You can also start the managed server by using the startManagedWebLogic.sh script in the domain directory subfolder bin. For example:

./startManagedWebLogic.sh oes_server1 http://localhost:7001
Validate the OES Admin Server instance on OESHOST1 by opening the APM console at the URL http://<OESHOST1>:14600/apm

Log in with the WebLogic username and password.
Validate the OES Admin Server Instance on OESHOST2 by opening up the APM Console in a web browser at http://<OESHOST2>:14600/apm

9.6.2.4 Configure OES Security Module in Controlled-push Mode with Oracle Entitlements Server Administration Server High Availability

To configure the Oracle Entitlements Server Security Module in controlled-push mode with high availability, you set high availability parameters using the OES Security Module configuration user interface:

Change to the bin directory in the appropriate Security Module instance directory and run the following script on the command line.

cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin
Run oessmconfig.sh to start the SMConfig UI.

See Starting the SMConfig UI in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information.
Set the following parameters in the jps-config.xml file:
- oracle.security.jps.runtime.pd.client.backupRegistrationServerURL
- oracle.security.jps.runtime.pd.client.registrationRetryInterval
  
  The following example shows the backupRegistrationServerURL used as a backup when the RegistrationServerURL fails.
```
<property name="oracle.security.jps.runtime.pd.client.backupRegistrationServerURL" value="https://slc00bqz:14601/pd-server"/>
```
  See Configuring the Java Security Module in Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information.

9.6.2.5 Configure Oracle Entitlements Server Security Module in Proxy Mode with PDP High Availability

To configure the Security Module in proxy mode with PDP high availability:

See Using the Security Module Proxy Mode in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server to configure the Security Module in proxy mode.
Change the PDP address by adding a comma-separated value as oracle.security.jps.pdp.proxy.PDPAddress

For example:

oracle.security.jps.pdp.proxy.PDPAddress=http://ws1:9410,http://ws2:9410

See PDP Proxy Client Configuration in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information.

9.6.2.6 Configure Oracle Entitlements Server Policy Information Point with High Availability

To configure the Policy Information Point high availability:

Change to the bin directory in the appropriate Security Module instance directory and run the following script on the command line:

cd $OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin
Run oessmconfig.sh to start the SMConfig UI.

See Starting the SMConfig UI in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information.
Set attribute retriever parameters for Policy Information Point high availability. See Configuring Attribute Retrievers in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server for more information.

Note:

You can set multiple values for the ldap.url or jdbc.url attribute retriever parameter. Separate values with a comma; the first value is treated as the primary value. See Configuring the LDAP Repository Attribute Retriever Parameters in the Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

9.6.2.7 Configuring Oracle Entitlements Server Web Service Security Module on WebLogic High Availability

You can configure Oracle Entitlements Server Web Service Security Module on WebLogic for high availability by means of a WebLogic cluster.

To configure Oracle Entitlements Server Web Service Security Module on WebLogic:

On OESHOST1

Run OESCLIENT_HOME/oessm/bin/config.sh to create a Web Service Security Module and a WebLogic Server domain.

For example:

./config.sh -smType ws -onWLS -smConfigId <ws_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port>

On the Welcome screen, select Create a WebLogic Domain then click Next.
On the Select Domain Source screen, select Generate a domain configured automatically to support the following added products. From the list, select Oracle Entitlements Server Web Service Security Module on Weblogic For Managed Server.

Click Next.
On the Specify Domain Name and Location screen, enter the name and location for the domain and all its applications:
- Domain Name: <domain name>
- Domain Location: Accept the default entry.
On the Configure Administration Server Username and Password screen, enter the following:
- Name: weblogic
- User Password: Password for the WebLogic user
- Confirm User Password: Password for the WebLogic user
- Description: Description for the WebLogic user.
On the Configure Server Start Mode and JDK screen, select Production Mode and JDK.
On the Select Optional Configuration screen, select AdminServer and Managed Servers. Click Next.
On the Configure Administration Server screen, enter the following:
- Name: AdminServer
- Listen address: All Local Addresses
- Listen port: 7001
- SSL Listen port: 7002
Select SSL Enabled then click Next.
On the Configure Managed Servers screen, the default managed server wsonwls_server1 is created. Change the details of wsonwls_server1 and then add the second managed server:

For wsonwls_server1, enter these values:
- Name: wsonwls_server1
- Listen address: WSSMHOST1
- Listen port: 14610
- SSL listen port: 14611
For the second managed server, click Add and enter these values:
- Name: wsonwls_server2
- Listen address: WSSMHOST2
- Listen port: 14610
- SSL listen port: 14611
In the Configure Clusters screen, click Add and enter wssm_cluster. Select unicast for Cluster messaging mode then enter the Cluster address as managed_ server1:port,managed_server2: port

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster:
- Click on the cluster wssm_cluster in the right window.
- Click on the managed server wsonwls_server1 then click the arrow to assign it to the cluster.
  
  Repeat the preceding steps for the managed server wsonwls_server2.
  
  Click Next.
On the Configure Machines screen, create a machine for each host in the topology.

Click on the Unix tab for a Unix operating system.

For Admin Server Host:
- Name: Name of your host. A good practice is to use the DNS name here.
- Node Manager Listen Address: Oracle recommends that the machine IP address be identical to the DNS name of the machine.
- Node Manager Listen Port: Enter a port for Node Manager to use.
Leave all other values at the default settings.

Repeat the preceding steps for WSSMHOST1 and WSSMOESHOST2 and enter the following values. Leave all other values at the default settings.
- Name: Name of the host. A good practice is to use the DNS name.
- Node Manager Listen Address: Oracle recommends that the machine IP address be identical to the DNS name of the machine.
- Node Manager Listen Port: Enter a port for Node Manager to use.
For Unix operating systems, delete the default local machine entry under the Machines tab.

Click Next.
On the Assign Servers to Machines screen, assign the managed servers that will run on the machines you just created:

Click on a machine in the right hand window.

Click on the managed servers you want to run on that machine in the left window.

Click on the arrow to assign the managed servers to the machine.

Repeat these steps until you assign all managed servers to the appropriate machine.

Assign servers to machines as follows:
- ADMINHOST: Admin Server
- WSSMHOST1: wsonwls_server1
- WSSMHOST2: wsonwls_server2
Click Next.
On the Configuration Summary screen, click Create.
Start Weblogic Administration Server by using ./startWeblogic.sh in the new domain.
Start Managed Server. Switch to created domain directory subfolder bin and type ./startManagedWebLogic.sh managed server name http://wlsadminserver host:wls_adminserver_port

For example:

./startManagedWeblogic.sh wsonwls_server1 http://localhost:7001

On OESHOST2:

Use the pack and unpack commands to separate the domain directory that the OES WebService SM uses from the domain directory that the managed server in OESHOST1 uses.

See the procedure to separate the domain directory in Section 9.6.2.8, "Configuring Oracle Entitlements Server WebLogic Security Module High Availability."

9.6.2.8 Configuring Oracle Entitlements Server WebLogic Security Module High Availability

You can configure Oracle Entitlements Server WebLogic Security Module for high availability by means of a WebLogic cluster.

To configure Oracle Entitlements Server WebLogic Security Module:

On OESHOST1

Run OESCLIENT_HOME/oessm/bin/config.sh to create a WebLogic Security Module and a WebLogic Server domain.

For example:

./config.sh -smType wls -smConfigId <wls_name> -serverLocation <wls_home> -pdServer <oes_admin_server> -pdPort <oes_admin_ssl_port>

On the Welcome screen, select Create a WebLogic Domain then click Next.
On the Select Domain Source screen, select Generate a domain configured automatically to support the following added products. From the list, select Oracle Entitlements Server WebLogic Security Module on Weblogic For Managed Server.

Click Next.
On the Specify Domain Name and Location screen, enter the name and location for the domain and all its applications:
- Domain Name: <domain name>
- Domain Location: Accept the default entry.
On the Configure Administration Server Username and Password screen, enter the following:
- Name: weblogic
- User Password: Password for the WebLogic user
- Confirm User Password: Password for the WebLogic user
- Description: Description for the WebLogic user.
On the Configure Server Start Mode and JDK screen, select Production Mode and JDK.
On the Select Optional Configuration screen, select AdminServer and Managed Servers. Click Next.
On the Configure Administration Server screen, enter the following:
- Name: AdminServer
- Listen address: All Local Addresses
- Listen port: 7001
- SSL listen port: 7002
Select SSL Enabled then click Next.
On the Configure Managed Servers screen, the default managed server wlssm_server1 is created. Change the default managed server details and then add the second managed server:

For the default managed server, enter these values:
- Name: wlssm_server1
- Listen address: WLSSMHOST1
- Listen port: 14610
- SSL listen port: 14611
For the second managed server, click Add and enter these values:
- Name: wlssm_server2
- Listen address: WLSSMHOST2
- Listen port: 14610
- SSL listen port: 14611
In the Configure Clusters screen, click Add and enter wlssm_cluster. Select unicast for Cluster messaging mode then enter the Cluster address as managed_ server1:port,managed_server2: port

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster:
- Click on the cluster wlssm_cluster in the right window.
- Click on the managed server wlssm_server1 then click the arrow to assign it to the cluster.
  
  Repeat the preceding steps for the managed server wlssm_server2.
  
  Click Next.
On the Configure Machines screen, create a machine for each host in the topology.

Click on the Unix tab for a host that uses a Unix operating system.

For Admin Server Host:
- Name: Name of your host. A good practice is to use the DNS name here.
- Node Manager Listen Address: Oracle recommends that the machine IP address be identical to the DNS name of the machine.
- Node Manager Listen Port: Enter a port for Node Manager to use.
Leave all other values at the default settings.

Repeat the preceding steps for WLSSHOST1 and WLSSMOESHOST2 and enter the following values. Leave all other values at the default settings.
- Name: Name of the host. A good practice is to use the DNS name.
- Node Manager Listen Address: Oracle recommends that the machine IP address be identical to the DNS name of the machine.
- Node Manager Listen Port: Enter a port for Node Manager to use.
For Unix operating systems, delete the default local machine entry under the Machines tab.

Click Next.
On the Assign Servers to Machines screen, you assign the managed servers that will run on the machines you just created. Follow these steps:

Click on a machine in the right hand window.

Click on the managed servers you want to run on that machine in the left window.

Click on the arrow to assign the managed servers to the machine.

Repeat these steps until you assign all managed servers to the appropriate machine.

Assign servers to machines as follows:
- ADMINHOST: Admin Server
- WLSSMHOST1: wlssm_server1
- W:SSMHOST2: wlssm_server2
Click Next.
On the Configuration Summary screen, click Create.
Start Weblogic Administration Server by using ./startWeblogic.sh in the new domain.
Start Managed Server. Switch to created domain directory subfolder bin and type ./startManagedWebLogic.sh managed server name http://wlsadminserver host:wls_adminserver_port

For example:

./startManagedWeblogic.sh wlssm_server1 http://localhost:7001

Use the pack and unpack commands to separate the domain directory that WebLogic Server Security Module uses from the one that the managed server in OESHOST1 uses.

To create a separate domain directory on OESHOST1:

Run the pack command to create a template pack as follows:

cd MW_HOME/oracle_common/common/bin

./pack.sh -managed=true -domain=domain_path -template==domaintemplate.jar -template_name=domain_template
Run the unpack command to unpack the template in the managed server domain directory as follows:

cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=new_domain_path -template=domaintemplate.jar

Run the unpack operation on the remote hosts before you start the managed server, for example, OESHOST2.
Copy the file domaintemplate.jar from step 1. to OESHOST2.
Run unpack on the host on OESHOST2 using these commands:

cd MW_HOME/oracle_common/common/bin

./unpack.sh -domain=domain_path -template==domaintemplate.jar
Start the managed server then switch to the domain directory subfolder bin that you created. Enter ./startManagedWebLogic.sh managed_server_name http://wlsadminserver host:wls_adminserver_port

For example:

./startManagedWeblogic.sh wlssm_server2 http://localhost:7001

9.6.2.9 Using RAC Datasource for Security Module in Controlled-pull Mode and Non-controlled Mode

Connection to policy store is used for Oracle Entitlements Server Security Modules in controlled-pull mode and non-controlled mode. Due to an SMConfig UI limitation, you must configure JDBC properties at the time that you create Security Module instances.

To use a RAC datasource in WebLogic Server Security Modules or Web Service Security Modules on WebLogic Server, run the following steps after you create a Security Module instance:

Log in to Weblogic Administrator Console of the domain that Security Module is deployed in. Configure the RAC datasource with database information identical to that of the Oracle Entitlements Server Administration Server.
Edit the Security Module configuration with the SMConfig UI:
- Run OES_CLIENT_HOME/oes_sm_instances/SM_Name/bin
- Run oessmconfig.sh.
- Select Database Configuration through JNDI Name and enter the RAC datasource JNDI name into the Data source JNDI Name field. Click Save & Close.

9.6.2.10 Configuring Oracle Entitlements Server to Work with the Web Tier

This section describes how to configure Oracle Entitlements Server to work with the Oracle Web Tier and includes the following topics:

Section 9.6.2.10.1, "Prerequisites"
Section 9.6.2.10.2, "Configuring Oracle HTTP Servers to Front End the OES Managed Servers"
Section 9.6.2.10.3, "Validate the Oracle HTTP Server Configuration"

9.6.2.10.1 Prerequisites

Verify that the following tasks have been performed:

Oracle Web Tier has been installed on WEBHOST1 and WEBHOST2.

For instructions on installing Oracle HTTP Server on WEBHOST1 and WEBHOST2, see Section 8.5.3.5.1, "Installing Oracle HTTP Server for the Web Tier."
Oracle Entitlements Server has been installed and configured on OESHOST1 and OESHOST2.
The load balancer has been configured with a virtual hostname (sso.example.com) pointing to the web servers on WEBHOST1 and WEBHOST2.
The load balancer has been configured with a virtual hostname (oesinternal.example.com) pointing to web servers WEBHOST1 and WEBHOST2.

9.6.2.10.2 Configuring Oracle HTTP Servers to Front End the OES Managed Servers

On each of the web servers on WEBHOST1 and WEBHOST2, create a file oes.conf in the directory ORACLE_INSTANCE/config/OHS/component/moduleconf. This file must contain the following information:

NameVirtualHost *:7777 
<VirtualHost *:7777> 
ServerName http://sso.example.com:7777 
RewriteEngine On 
RewriteOptions inherit 
UseCanonicalName On 

# OES admin console 
 <Location /apm>
SetHandler weblogic-handler 
WebLogicCluster oeshost1.example.com:14600,
oeshost2.example.com:14600 
</Location>

Save the file on both WEBHOST1 and WEBHOST2.
Stop and start the Oracle HTTP Server instances on both WEBHOST1 and WEBHOST2 as Section 8.7, "Starting and Stopping Components" describes.

9.6.2.10.3 Validate the Oracle HTTP Server Configuration

To validate that Oracle HTTP Server is configured properly:

In a web browser, enter the following URL for the Oracle Identity Manager Console:

http://sso.example.com:7777/apm
In the APM login page, use weblogic user credentials to log in.

9.7 Oracle Access Management Mobile and Social High Availability

This section describes the Oracle Access Management Mobile and Social high availability framework. Topics include the following:

Section 9.7.1, "Oracle Access Management Mobile and Social Component Architecture"
Section 9.7.2, "Mobile and Social Component Characteristics"
Section 9.7.3, "Mobile and Social High Availability Concepts"
Section 9.7.4, "Configuring Mobile and Social High Availability"

9.7.1 Oracle Access Management Mobile and Social Component Architecture

Oracle Access Management Mobile and Social (Mobile and Social) is a lightweight security and identity solution that opens your existing Identity Management infrastructure to mobile and social networks. With Mobile and Social, you can securely expose a controlled view to the external world. Mobile and Social provides mechanisms for enterprise applications and portals to consume social media user identities inside the managed enterprise perimeter. Mobile and Social integrates with existing IDM products including OAM and IGF. See Oracle Access Management Mobile and Social in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management for more information on Mobile and Social.

Figure 9-22 shows the Mobile and Social component architecture.

Figure 9-22 Mobile and Social Component Architecture

Description of "Figure 9-22 Mobile and Social Component Architecture"

The Oracle Access Management Mobile and Social service acts as an intermediary between a user who wants to access protected resources, and the back-end Access Management and Identity Management services that protect the resources. Mobile and Social provides simplified client libraries that allow developers to quickly add feature-rich authentication, authorization, and Identity capabilities to registered applications. On the back-end, the Mobile and Social server's pluggable architecture lets system administrators add, modify, and remove Identity and Access Management services without having to update user installed software.

9.7.1.1 Session State Information

No session state is recorded for the Mobile Services component. For Internet Identity Services, short-lived tokens are kept in memory and discarded as soon as they expire.

9.7.1.2 Component Lifecycle

Mobile and Social is a component in Access Suite J2EE application. You deploy and configure Mobile and Social as part of the Access Suite; the install, configuration, server instances are associated with the Access Suite.

As part of Mobile Services and Internet Identity Services, Mobile and Social provides HTTP interfaces for the clients to invoke. Mobile and Social processes those requests and returns a response, which the client may use to make additional requests. Mobile and Social is stateless, it can handle all requests sent by the client independently. Mobile and Social provides mobile device registration service and user authentication services using products like OAM, or by using social networks authentication and user profile services using Directory Servers.

Mobile and Social starts up as part of Access Suite server startup. MBean Server loads the Mobile and Social configuration.

9.7.1.3 Component Configuration Artifacts

Use the Administration Console or WLST commands to edit configuration files. Table 9-9 shows Mobile and Social configuration files and their location.

Table 9-9 Mobile and Social Component Configuration Files

File	Location
`Idaas.xml`	`<DOMAIN_HOME>/config/fmwconfig`
`oic_rp.xml`	`<DOMAIN_HOME>/config/fmwconfig`

9.7.1.4 Mobile and Social Deployment Artifacts

A Mobile and Social installation deploys the following components as part of oam-server.ear:

oic_rest.war
oic_rp.war

Table 9-10 shows Mobile and Social services deployment locations:

Table 9-10 Mobile and Social Product Deployment Locations

Mobile and Social Product	Deployment Location
Administration Server	Administration Server user interface deploys as part of the OAM Admin .ear, `oam-admin.ear`
Managed Server, REST, and Internet Identity Services runtime	Deploy as part of the OAM Server .ear file, `oam-server.ear`

9.7.2 Mobile and Social Component Characteristics

Mobile and Social services consists of two subcomponents, Mobile Services and Internet Identity Services. Mobile Services provide Representational state transfer (REST) interfaces for authentication, user profile, and authorization services. Internet Identity Services provides integration with social network authentication.

See Introduction to Mobile Services in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management for more information on Mobile and Social.

9.7.3 Mobile and Social High Availability Concepts

This section describes the Mobile and Social high availability architecture and its elements. Topics include the following:

Section 9.7.3.1, "Mobile and Social High Availability Architecture"
Section 9.7.3.2, "Mobile and Social High Availability and Node Failover"

9.7.3.1 Mobile and Social High Availability Architecture

Figure 9-23 shows Mobile and Social deployed in a high availability architecture in an active-active configuration.

Figure 9-23 Mobile and Social High Availability Architecture

Description of "Figure 9-23 Mobile and Social High Availability Architecture"

Figure 9-23 shows a typical client server architecture that supports multi-instance deployments. In most cases, requests are stateless, requiring no persistence. Mobile and Social services relies on other products, such as OAM/OID, that may have their own high availability capability. For the cases where state is maintained (Internet Identity authentication requests), high availability is achieved through sticky load balancing.

Requests can go to either server because there is no database persistence for sessions or runtime data. The load balancer returns requests to either Mobile and Social service 1 or 2 based on the policy set, such as Round Robin.

When an application invokes Internet Identity Services, control goes to a social network site such as Google, Facebook, or an Internet identity provider to process the request. When the response returns from the identity provider, it must return to the same server that initiates the request. With multiple Mobile and Social node deployments and when access is through the load balancer, requests to Mobile and Social must be pinned to the same server using the load balancer sticky sessions feature. Mobile and Social can further process the request after the Mobile and Social server that initiates the request to an IDP receives the IDP response.

You deploy Mobile and Social applications to all members in a cluster. The Mobile and Social application does not notify other cluster members when it successfully deploys on a cluster.

9.7.3.2 Mobile and Social High Availability and Node Failover

This section describes elements of the Mobile and Social architecture that provide protection from node failure.

Note that if a node failover occurs, Mobile and Social follows standard WebLogic Server failover procedures. If node failure occurs before Mobile and Social completes a request that it receives from a client, the client receives an error through HTTP connections timeouts.

This section includes the following topics:

Section 9.7.3.2.1, "Load Balancing Requirements and Characteristics"
Section 9.7.3.2.2, "Session State Replication and Failover"
Section 9.7.3.2.3, "Client Application Startup"
Section 9.7.3.2.4, "Death Detection / Restart"

9.7.3.2.1 Load Balancing Requirements and Characteristics

Mobile and Social components are standard J2EE applications deployed on WebLogic Server 10.3, and conform to the standard for load balancing. Note the following:

You must use sticky session routing for Mobile and Social/RP requests, however, external load balancers are supported.
There is no intra-component load balancing.
There are no timeout requirements because there are no persistent connections.

9.7.3.2.2 Session State Replication and Failover

The Mobile and Social high availability architecture relies on standard WebLogic Server clustering support for failover requirements. This architecture does not replicate the session state.

9.7.3.2.3 Client Application Startup

When an Mobile and Social instance starts up, it does not affect the running system state. The Mobile and Social instance does not affect other running components or cluster members other than becoming a participant in WebLogic Server clustering scenarios.

9.7.3.2.4 Death Detection / Restart

Use the Node Manager for Java EE components and OPMN for system components for death detection and component restart.

9.7.4 Configuring Mobile and Social High Availability

Mobile and Social is part of the same managed server as Oracle Access Manager.

You can deploy Mobile and Social independently or with other components such as OAM, STS, and Identity Federation.

Note the following Mobile and Social configuration prerequisites:

You must enable Mobile and Social if it is not enabled. Log into the Oracle Access Management Console, select the System configuration tab, open Available Services, and verify that the Mobile and Social status shows a green check.

You must configure OHS for oic_rest and oic_rp by adding the following mapping to the oam.conf file in ORACLE_INSTANCE/config/OHS/ohs1/moduleconf:

 <Location /oic_rest>
   SetHandler weblogic-handler
   WebLogicCluster 
   oamhost1.example.com:14100,oamhost2.example.com:14100 
 </Location>

 <Location /oic_rp>
   SetHandler weblogic-handler
   WebLogicCluster 
   oamhost1.example.com:14100,oamhost2.example.com:14100 
 </Location>

9.8 Oracle Privileged Account Manager High Availability

Oracle Privileged Account Manager manages privileged accounts that are not being managed by any other Oracle Identity Management components. Accounts are considered privileged if they can access sensitive data, can grant access to sensitive data, or can both access and grant access to that data.

For a more detailed overview of Oracle Privileged Account Manager and its features, see Understanding Oracle Privileged Account Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Privileged Account Manager.

This section includes the following topics:

Section 9.8.1, "Oracle Privileged Account Manager Component Architecture"
Section 9.8.2, "Oracle Privileged Account Manager High Availability Concepts"
Section 9.8.3, "Oracle Privileged Account Manager High Availability Architecture"
Section 9.8.4, "Oracle Privileged Account Manager High Availability and Node Failure"
Section 9.8.5, "Oracle Privileged Account Manager High Availability Configuration"

9.8.1 Oracle Privileged Account Manager Component Architecture

Oracle Privileged Account Manager (OPAM) consists of a server, user interface, and session manager component that run as web applications. The server and user interface are web applications. Session Manager is a standard J2EE application with no web interface at this time. The OPAM server runs in a WebLogic Managed Server. The OPAM user interface is part of Oracle Identity Navigator (OIN) and also runs on the OPAM WebLogic Managed Server. OPAM Session Manager also runs on the Managed Server

The default and most simple configuration of OPAM deployment involves running a single OPAM managed server in a WebLogic domain. OPAM uses its own schema to store passwords to targets, accounts, and other items.

The following diagram illustrates Oracle Privileged Account Manager's architecture and topology:

Figure 9-24 Oracle Privileged Account Manager Component Architecture

Description of "Figure 9-24 Oracle Privileged Account Manager Component Architecture"

Note the following features of this architecture:

All of Oracle Privileged Account Manager's core logic resides on the Oracle Privileged Account Manager Server. This functionality is exposed through a Representational state transfer (REST or RESTful) service, where the data is encoded as JavaScript Object Notation (JSON).

Note:

Oracle Privileged Account Manager provides a Web-based user interface in Oracle Identity Navigator and an Oracle Privileged Account Manager Command Line Tool. Both interfaces are essentially clients of the Oracle Privileged Account Manager Server.

However, third parties can write their own clients, such as custom applications, by leveraging the open RESTful service. For more information, refer to Working with Oracle Privileged Account Manager's RESTful Interface in Oracle Fusion Middleware Administrator's Guide for Oracle Privileged Account Manager.
OPAM Session Manager is an OPAM sub-component that empowers OPAM Session Management capabilities. It is a J2EE application that interacts with the OPAM server by means of the OPAM RESTful interfaces, and shares the same database that OPAM Server uses. In addition, the OPAM Session Manager listens and responds to SSH traffic to establish privileged sessions against SSH capable OPAM targets.
Oracle Privileged Account Manager authentication relies on Java Authentication & Authorization Service (JAAS) support in WebLogic. Refer to "WebLogic Security Service Architecture" in Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server for more information about JAAS support in WebLogic.
All communication with, and between, Oracle Privileged Account Manager-related components (including Oracle Privileged Account Manager's Web-based user interface, command-line interface, and server) all occur over SSL
Oracle Privileged Account Manager relies on and transparently uses the ID Store and Policy Store configured for the WebLogic domain in which Oracle Privileged Account Manager is deployed.

See How Oracle Privileged Account Manager is Deployed in Oracle Fusion Middleware in Oracle Fusion Middleware Administrator's Guide for Oracle Privileged Account Manager for more information.
The Oracle Privileged Account Manager Web-based user interface leverages, and is rendered by, Oracle Application Development Framework (ADF).
Oracle Privileged Account Manager connects to targets by using Identity Connector Framework (ICF) connectors. For additional information, see Understanding the Identity Connector Framework in the Oracle® Fusion Middleware Developer's Guide for Oracle Identity Manager.

This section includes the following topics:

Section 9.8.1.1, "Runtime Processes"
Section 9.8.1.2, "Process Lifecycle"
Section 9.8.1.3, "Session State"
Section 9.8.1.4, "External Dependencies"
Section 9.8.1.5, "Deployment Artifacts"
Section 9.8.1.6, "Log File Locations"

9.8.1.1 Runtime Processes

OPAM server is the server component that runs WebLogic Managed Server. The OPAM Session Manager is a component that also runs on the OPAM Weblogic Managed Server. The OPAM user interface is a component that runs on the OPAM WebLogic Managed Server. OPAM server uses the REST protocol to communicate with clients including OPAM user interface and command line client. OPAM server uses the OPAM database as its data store. You can deploy OPAM server and the user interface in a WebLogic cluster with multiple servers and use WebLogic Console to manage the processes.

9.8.1.2 Process Lifecycle

OPAM server and OPAM Session Manager are J2EE applications deployed in WebLogic server.

During startup, the OPAM Lifecycle Listener checks whether the keystore is present for that domain.

If the keystore is not present, OPAM Lifecycle Listener creates a keystore using a randomly-generated keystore password, creates a keystore entry with domain name as alias, and updates the CSF with the keystore password.
If the keystore is present, it retrieves the keystore password from CSF and checks whether an entry is present with domain name as alias.

Because there is no operation if the keystore and required keystore CSF entry are present, a high availability environment for OPAM does not affect the process lifecycle.

OPAM Server uses a servlets model in which RESTful interfaces service clients. Therefore, the component lifecycle does not affect other running instances.

For more information on CSF, see Oracle Privileged Account Manager-Managed CSF Credentials in the Oracle Fusion Middleware Administrator's Guide for Oracle Privileged Account Manager.

9.8.1.3 Session State

OPAM server uses the REST-based communication; clients use HTTPS URLs. Session state information is not stored. Each communication completes an operation; sessions are not preserved.

OPAM Session Manager maintains the session state for each privileged session that it facilitates. After a session is established, the OPAM Session Manager instance used at session initiation time must continue it. If the OPAM Session Manager fails mid-session, a background thread cleans up orphaned sessions periodically.

9.8.1.4 External Dependencies

OPAM server dependencies include the following:

ICF Connectors, for communication with target systems
External ID stores, for authentication (configurable in WebLogic)

The OPAM user interface and OPAM Command Line tool depend on the OPAM server. Client connections, which are REST using HTTPS URL, are short lived.

9.8.1.5 Deployment Artifacts

When you deploy OPAM to a managed server, Oracle Identity Navigator deploys to the Administration Server. The Oracle JRF deploys to both the Administration Server and Managed Server. Table 9-11 describes where OPAM product artifacts deploy.

Table 9-11 OPAM Deployment Artifacts

Location	Product Artifact
Administration Server	Oracle JRF
Managed Server	OPAM server .ear file, OPAM session manager .ear file, Oracle Identity Navigator .ear file, Oracle JRF

9.8.1.6 Log File Locations

WebLogic Server Logs and Audit Logs save to the DOMAIN_HOME.

Audit Logs, if configured in WebLogic, save to the Audit database.

9.8.2 Oracle Privileged Account Manager High Availability Concepts

At the cluster level, you can change OPAM properties such as connector directory and time limits.

All servers connect to a common domain OPAM data store, where configuration is maintained. Therefore, all connected servers pick up the shared data.

9.8.3 Oracle Privileged Account Manager High Availability Architecture

Figure 9-25 shows Oracle Privileged Account Manager deployed in a high availability architecture in an active-active configuration.

Figure 9-25 Oracle Privileged Account Manager in a High Availability Architecture

Description of "Figure 9-25 Oracle Privileged Account Manager in a High Availability Architecture"

In the configuration shown in Figure 9-25, the Oracle Privileged Account Manager Servers are part of the same domain and use the same OPSS security store. Because multiple servers interact with the OPSS security store, Oracle recommends using the database as the OPSS backend.

In this cluster configuration, the same data is available from the different servers in the cluster. Each managed server has its own port configuration. The configuration in Figure 9-25 includes a load balancer.

OPAMHOST1 has the following installations

An Oracle Privileged Account Manager instance in the WLS_OPAM1 Managed Server. The Oracle RAC database has been configured in a JDBC multi data source or GridLink data source to protect the instance from Oracle RAC node failure.
A WebLogic Server Administration Server. Under normal operations, this is the active Administration Server.

OPAMHOST2 has the following installations:

An Oracle Privileged Account Manager in the WLS_OPAM2 Managed Server. The Oracle RAC database is configured in a JDBC multi data source tor GridLink data source to protect the instance from Oracle RAC node failure.

The instances in the WLS_OPAM2 Managed Server and the instances in the WLS_OPAM1 Managed Server are configured as the CLUSTER_OPAM cluster.
A WebLogic Server Administration Server. Under normal operations, this is the passive Administration Server. You make this Administration Server active if the Administration Server on HOST1 becomes unavailable. See Section 12.4, "Transforming the Administration Server in an Existing Domain for Cold Failover Cluster" for more information on the active-passive Administration Server configuration.

9.8.3.1 Starting and Stopping the Cluster

By default, WebLogic Server starts stops, monitors, and manages lifecycle events for the application. The Oracle Privileged Account 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.

In high availability environments, the state and configuration information is stored a database that is shared by all the members of the cluster.

9.8.4 Oracle Privileged Account Manager High Availability and Node Failure

Note the following characteristics about Oracle Privileged Account Manager node failure in a high availability configuration:

Node failure does not affect clients.
If a server fails, ongoing REST-based operations stop; they do not fail over. Clients can connect to available servers and retry or continue with their requests. If you include a load balancer in the deployment, it directs requests to available servers.

9.8.5 Oracle Privileged Account Manager High Availability Configuration

This section provides high-level instructions for setting up a maximum high availability deployment for Oracle Privileged Account Manager High Availability. Topics in this section include the following:

Section 9.8.5.1, "Appropriate Development Environment"
Section 9.8.5.2, "Components Deployed"
Section 9.8.5.3, "Dependencies"
Section 9.8.5.4, "High Availability Configuration Procedure"
Section 9.8.5.5, "OHS Load Balancer Configuration"

9.8.5.1 Appropriate Development Environment

Perform the configuration in this topic if you want to configure Oracle Privileged Account Manager with Oracle Identity Navigator in a new WebLogic domain and then run the Oracle Identity Navigator discovery feature. This feature populates links to the product consoles for Oracle Identity Manager, Oracle Access Management, Oracle Adaptive Access Manager, and Oracle Privileged Account Manager. You can then access those product consoles from within the Oracle Identity Navigator interface, without having to remember the individual console URLs.

9.8.5.2 Components Deployed

Performing the configuration in this section deploys the Oracle Privileged Account Manager and Oracle Identity Navigator applications on a new WebLogic Administration Server.

9.8.5.3 Dependencies

The configuration in this section depends on the following:

Oracle WebLogic Server
Installation of the Oracle Identity and Access Management 11g software

For more information, see Installing and Configuring Oracle Identity and Access Management (11.1.2.0.0) in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

9.8.5.4 High Availability Configuration Procedure

This section includes the following steps:

Section 9.8.5.4.1, "Configuring Oracle Identity and Access Management on OPAMHOST1"
Section 9.8.5.4.3, "Starting Administration Server on OPAMHOST1"
Section 9.8.5.4.4, "Starting OPAMHOST1"
Section 9.8.5.4.5, "Starting Oracle Privileged Account Manager on OPAMHOST1"
Section 9.8.5.4.6, "Configuring OPAM on OPAMHOST2"
Section 9.8.5.4.7, "Starting OPAMHOST2"

9.8.5.4.1 Configuring Oracle Identity and Access Management on OPAMHOST1

To configure Oracle Privileged Account Manager and Oracle Identity Navigator for maximum high availability:

Install Oracle WebLogic Server and create a Middleware Home. See WebLogic Server and Middleware Home Requirements in Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for more information.
Install the Oracle Identity and Access Management 11g software. See Installing Oracle Identity and Access Management (11.1.2.0.0) in Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management for more information.
Start the Configuration Wizard by running this command:
```
MW_HOME/oracle_common/common/bin/config.sh
```
Note:

You must run the config.sh script from your Oracle Identity and Access Management Home directory that contains Oracle Identity Manager, Access Manager, Oracle Adaptive Access Manager, Oracle Entitlements Server, Oracle Privileged Account Manager, Mobile and Social, and Oracle Identity Navigator.
On the Welcome screen, select Create a new WebLogic domain and click Next. The Select Domain Source screen appears.
On the Select Domain Source screen, ensure that the Generate a domain configured automatically to support the following products: option is selected. Select Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home].

Note:

When you select the Oracle Privileged Account Manager - 11.1.2.0.0 [IAM_Home] option, the Oracle Identity Navigator, Oracle JRF, and Oracle Platform Security Service options are also selected by default.

Click Next. The Specify Domain Name and Location screen appears.
Enter the domain name IDM_Domain. Keep the default Domain Location and Application Directory. Click Next. The Configure Administrator User Name and Password screen appears.
Configure a user name and a password for the administrator. The default user name is weblogic. Click Next.
Choose JRockit SDK 1.6.0_<version> and Production Mode in the Configure Server Start Mode and JDK screen of the Oracle Fusion Middleware Configuration Wizard.
In the Configure JDBC Component Schema screen, enter the database schema details for the OPAM and OPSS schema.

Note:

You can also use GridLink data sources. See Section 3.13, "GridLink Data Sources" for more information.

(Optional) Select an option for RAC configuration for component schemas.

Click Next.
On the Test Component Schema screen, the Configuration Wizard tries to validate the data sources. Validate that the test for all schemas completes successfully

If the data source validation succeeds, click Next.

If the data source validation fails, click Previous, correct the issue, then try again.
On the Select Optional Configuration screen, select the following:
- Administration Server
- Managed Servers, Clusters, and Machines
- Deployments and Services
Click Next.
In the Customize Server and Cluster configuration screen, select Yes then Next.
In the Configure the Administration Server screen, enter the following values:
- Name: AdminServer
- Listen address: OPAMHOST1.example.com
- Listen port: 7001
  
  Do not set or change the following parameters:
- SSL listen port: Not applicable
- SSL enabled or disabled
Click Next.
On the Configure Managed Servers screen, create an entry for each OPAMHOST in the topology, that is, one entry for the OPAM server running on OPAMHOST1 and one entry for the OPAM server running on OPAMHOST2.

Select the OPAM_SERVER entry and change the entry to the following values:
- Name: opamserver1
- Listen Address: OPAMHOST1.example.com
- Listen Port: 18101
- SSL Port: 18102
For the second OPAM_SERVER, click Add and enter the following values:
- Name: opam_server2
- Listen Address: OPAMHOST2.example.com
- Listen Port: 18101
- SSL Port: 18102
Click Next.
In the Configure Clusters screen, click Add to create a cluster.

Enter a name for the cluster, such as OPAM_Cluster. Leave all other fields at their default setting.

Click Next.
On the Assign Servers to Clusters screen, associate the managed servers with the cluster:

Click on the cluster name OPAM_Cluster in the right window.

Click on the managed server opam_server1 then click the arrow to assign it to the cluster.

Repeat the preceding steps for the managed server opam_server2.

Click Next.
On the Configure Machines screen, create a machine for each host in the topology.

Click on the Unix tab if your hosts use a Unix operating system or click Machines.

Provide the following information:
- Name: Name of the host. A good practice is to use the DNS name here.
- Node Manager Listen Address: Enter the DNS name of the machine here.
- Node Manager Port: Enter a port for Node Manager to use.
Repeat the preceding steps for OPAMHOST2 and enter the following values:
- Name: Name of the host. A good practice is to use the DNS name, OPAMHOST2
- Node Manager Listen Address: Enter the DNS name of the machine, OPAMHOST.example.com
- Node Manager Port: Enter a port for Node Manager to use.
Click Next.
On the Assign Servers to Machines screen, assign the managed servers that will run on the machines you just created. Follow these steps:

Click on a machine in the right hand window.

Click on the managed servers you want to run on that machine in the left window.

Click on the arrow to assign the managed servers to the machine.

Repeat these steps until all managed servers are assigned to the appropriate machine.

For example:
- Host1: Admin Server, OPAMHOST1, and opam_server1
- Host2: OPAMHOST2 and opam_server2
Click Next.
On the Configuration Summary screen, click Create.

9.8.5.4.2 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 9.1.3.3, "Configuring the Database Security Store for the Domain" for more information.

9.8.5.4.3 Starting Administration Server on OPAMHOST1

To start the Administration Server:

Go to DOMAIN_HOME/bin directory. Run startWeblogic.sh.
At the prompt, enter the WebLogic administrator username and password.

Note:

You perform the following steps when you start the Administration Server for the first time only.

Note:

Before proceeding to the next step to run opam-config.sh, you must set the ORACLE_HOME, JAVA_HOME and ANT_HOME environment variables. ANT_HOME must point to a location that contains Ant and JAR binary files such as middleware_home/modules/org.apache.ant_1.7.1.
After the Administration Server is running, go to ORACLE_HOME/opam/bin directory. Run opam-config.sh.
At the prompt, enter the WebLogic username, password, URL, domain name, and middleware home.
Restart the Administration Server after opam-config.sh.

9.8.5.4.4 Starting OPAMHOST1

This section describes the steps for starting OPAMHOST1:

Before you can start managed servers from the console, you must create a Node Manager property file. Run setNMProps.sh located in the MW_HOME/oracle_common/common/bin directory.

MW_HOME/oracle_common/common/bin/setNMProps.sh
Start Node Manager with the command MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh.

9.8.5.4.5 Starting Oracle Privileged Account Manager on OPAMHOST1

To start Oracle Privileged Account Manager on OPAMHOST1, follow these steps:

Log into the WebLogic Administration Console using this URL:
```
http://opamhost1.example.com:7001/console
```
Enter the WebLogic administrator username and password.
Select Environment - Servers from the Domain Structure menu.
Click the Control tab.
Click the server opam_server1.
Click Start.
Click OK.

9.8.5.4.6 Configuring OPAM on OPAMHOST2

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

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

Verify that MW_HOME and ORACLE_HOME directory structure is identical to the OPAMHOST1 directory structure.

Enter the following on OPAMHOST1 to create the file idm_domain.jar in the /tmp directory:

pack.sh -domain=$MW_HOME/user_projects/domains/IDM_Domain

 -template=/tmp/idm_domain.jar -template_name="OPAM Domain" -managed=true

The previous step created the idm_domain.jar file in the /tmp directory.

Copy the idm_domain.jar file from OPAMHOST1 to a temporary directory on OPAMHOST2.

To copy idm_domain.jar to OPAMHOST2, enter the following:

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

Copy jps-wls-trustprovider.jar from MW_HOME/oracle_common/modules/oracle.jps_11.1.1 to WLS_SERVER_HOME/server/lib/mbeantypes.

9.8.5.4.7 Starting OPAMHOST2

This section describes the steps for starting OPAMHOST2.

Before you can start managed servers from the console, you must create a Node Manager property file. Run the script setNMProps.sh located in the directory MW_HOME/oracle_common/common/bin.
Start Node Manager with the command MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
Start Oracle Privileged Account Manager on OPAMHOST2. See Section 9.8.5.4.5, "Starting Oracle Privileged Account Manager on OPAMHOST1" and replace HOST1 and server1 with HOST2 and server2.

9.8.5.5 OHS Load Balancer Configuration

You can load balance OPAM servers using Oracle HTTP Server (OHS). This section provides the steps to configure OPAM to work with OHS. Topics include the following:

Section 9.8.5.5.1, "Configure SSL"
Section 9.8.5.5.2, "Update the Oracle HTTP Server Configuration"
Section 9.8.5.5.3, "Restart the Oracle HTTP Server"

9.8.5.5.1 Configure SSL

Because OPAM servers use SSL for communication, you must configure SSL options in the OHS Load Balancer. Follow these steps:

Enable the outbound SSL connections from OHS so that they can communicate with the OPAM managed/Administration servers. To do this, see Enable SSL for Outbound Requests from Oracle HTTP Server in the Oracle Fusion Middleware Administrator's Guide.
Enable inbound SSL connections into the OPAM managed/Administration servers. See Inbound SSL to Oracle WebLogic Server in the Oracle Fusion Middleware Administrator's Guide.

9.8.5.5.2 Update the Oracle HTTP Server Configuration

On the host where OHS is installed, create a file named opam.conf in the following directory:

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

Create the file with the following lines:

NameVirtualHost *:4443
<VirtualHost *:44443>

  ServerName http://opam.example.com:4443
  ServerAdmin user@example.com
  RewriteEngine On
  RewriteOptions inherit

   <Location /opam>
    SetHandler weblogic-handler
    WebLogicCluster opamhost1.example.com:18102,opamhost2.example.com:18102
    WLCookieName OPAMSESSIONID
    WlSSLWallet "${ORACLE_INSTANCE}/config/${COMPONENT_TYPE}/${COMPONENT_
    NAME}/keystores/ohs_wallet"
    WLProxySSL ON
    WLProxySSLPassThrough ON
    SecureProxy On
  </Location>

</VirtualHost>

To configure OHS for the OPAM console, update the opam.conf file with the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>

  ServerName http://opam.example.com:7777
  ServerAdmin user@example.com
  RewriteEngine On
  RewriteOptions inherit

   <Location /oinav>
    SetHandler weblogic-handler
    WebLogicCluster opamhost1.example.com:18101,opamhost2.example.com:18101
    WLCookieName OPAMSESSIONID
   </Location>  

</VirtualHost>

9.8.5.5.3 Restart the Oracle HTTP Server

To restart Oracle HTTP Server, run the following commands from ORACLE_INSTANCE/bin:

opmnctl stopall
opmnctl startall

9.9 Oracle Identity Navigator High Availability

Oracle Identity Navigator is an administrative portal designed to act as a launch pad for Oracle Identity Management products. It does not replace the individual product consoles. Rather, it enables you to access the Oracle Identity Management consoles from one site. For more details on Oracle Identity Navigator, refer to Oracle Fusion Middleware Administrator's Guide for Oracle Identity Navigator.

Oracle Identity Navigator is deployed on the OPAM managed server (opam_server1) in an out-of-the-box scenario.

You can configure Oracle Identity Navigator in a clustered configuration same as Oracle Privileged Account Manager. However, you do not need to run the opam-config.sh script when configuration is complete.

To configure OHS for Oracle Identity Navigator, complete the following steps:

Section 9.9.1, "Update the Oracle HTTP Server Configuration"
Section 9.9.2, "Restart the Oracle HTTP Server"

9.9.1 Update the Oracle HTTP Server Configuration

On the host where OHS is installed, create a file named oinav.conf in the following directory:

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf

Create the file with the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>

  ServerName http://oinav.example.com:7777
  ServerAdmin user@example.com
  RewriteEngine On
  RewriteOptions inherit

   <Location /oinav>
    SetHandler weblogic-handler
    WebLogicCluster oinavhost1.example.com:18101,oinavhost2.example.com:18101
    WLCookieName OPAMSESSIONID
  </Location>

</VirtualHost>

9.9.2 Restart the Oracle HTTP Server

To restart Oracle HTTP Server, run the following commands from ORACLE_INSTANCE/bin:

opmnctl stopall
opmnctl startall

9.10 Oracle Unified Directory High Availability

Oracle Unified Directory is Oracle's comprehensive, next-generation directory service that is designed to address large deployments, provide high performance, and be highly extensive. Oracle Unified Directory is also designed to be easy to deploy, manage, and monitor.

For more information on Oracle Unified Directory High Availability Deployments, see "Understanding Oracle Unified Directory High Availability Deployments" in the Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.

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.