7 Configuring High Availability for Oracle Access Manager Components

An introduction to Oracle Access Manager and description of 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. See Introduction to Oracle Access Manager in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

• Access Manager Component Architecture
  An introduction to primary Access Manager components and architecture.
• Access Manager High Availability Concepts
  
• High Availability Directory Structure Prerequisites
  
• Access Manager High Availability Configuration Steps
  
• Deploying Oracle Identity and Access Management Cluster with Unicast Configuration
  If multicast IP is disabled in deployment environment then you can deploy Oracle Identity and Access Management cluster with Unicast configuration.

Access Manager Component Architecture

An introduction to primary Access Manager components and architecture.

Figure 7-1 shows the Access Manager component architecture.

Figure 7-1 Access Manager Single Instance Architecture

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

Following are the components discussed in the Access Manager Single Instance Architecture:

• User agents: Include web browsers, Java applications, and Web services applications. User agents access the Access Server and administration and configuration tools using HTTP.

• Protected resources: Application or web page to which access is restricted. WebGates or Custom Agents control access to protected resources.

• Administration and configuration tools: Administer and configure Access Manager with Oracle Access Management Console, Oracle Enterprise Manager Fusion Middleware Control and Oracle Enterprise Manager Grid Control, and WebLogic Scripting Tool (WLST).

• Access Server: Includes Credential Collector and OAM Proxy components.

• Access Manager Component Characteristics
  A typical Access Manager deployment consists of system entities such as user agents, protected resources, and access server.
• Access Manager Configuration Artifacts
  
• Access Manager External Dependencies
  

Access Manager Component Characteristics

A typical Access Manager deployment consists of system entities such as user agents, protected resources, and access server.

A list of system entities and the characteristics required for an Access Manager deployment:

• Access Manager Agents - Access Server extensions that ensure access is controlled according to policies that Access Server manages. Agents require the Access Server component to perform their functions. If Access Server is unavailable, access to protected servers is denied; users are locked out of the system.

• Protected Resources (partnered applications) - Applications that Access Manager protects. Access to these resources depends on access control policies in Access Manager and enforced by Access Manager agents deployed in the protected resource's access path.

• Access Server - Server side component. 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 12c SSPI providers consist of Java classes that implement the SSPI interface along with Access Java Access JDK. AccessGates are built using pure Java Access JDK.

• Oracle Access Management Console - Application that hosts Administration Console and provides services to manage Access Manager deployment.

• WebLogic Scripting Tool - Java classes included in Access Server package. Limited administration of Access Manager deployment is supported via the command line.

• Fusion Middleware Control and Enterprise Manager Grid Control - Access Manager integrates with Enterprise Manager Grid Control to show performance metrics and deployment topology.

• Access Manager Proxy - Custom version of Apache MINA server. Includes MessageDrivenBeans and ResourceAdapters in addition to Java Server classes.

• 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

  • Policy data will be stored in files or in an RDBMS

• Oracle Access Manager 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 Configuration Artifacts

Access Manager configuration artifacts include:

Table 7-1 Access Manager Configuration Artifacts

Configuration Artifact	Description
DOMAIN_HOME/config/fmwconfig/oam-config.xml	Configuration file which contains instance specific information.
DOMAIN_HOME/config/fmwconfig/oam-policy.xml	Policy store information.
DOMAIN_HOME/config/fmwconfig/.oamkeystore	Stores symmetric and asymmetric keys.
DOMAIN_HOME/config/fmwconfig/component_events.xml	Used for audit definition.
DOMAIN_HOME/config/fmwconfig/jazn-data.xml	Administration Console permissions
DOMAIN_HOME/config/fmwconfig/servers/instanceName/logging.xml	Logging configuration. Do not edit this file manually.
DOMAIN_HOME/config/fmwconfig/servers/instanceName/dms_config.xml	Tracing logging. Do not edit this file manually.
DOMAIN_HOME/config/fmwconfig/cwallet.sso	Stores passwords that OAM uses to connect to identity stores, database, and other entities. This is not for end user passwords.
DOMAIN_HOME/output	Stores agent configuration files.

Access Manager External Dependencies

The following table describes Access Manager external runtime dependencies.

Table 7-2 Access Manager External Dependencies

Dependency	Description
LDAP based Identity Store	User Identity Repository LDAP access abstracted by User/Role API. Access Manager always connects to one Identity store: a physical server or a load balancer IP. If the primary 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 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
Identity Federation	Dependency when Identity Federation Authentication Scheme is selected
OCSP Responder Service	Real-time X.509 Certification Validation

• Access Manager Log File Location
  

Access Manager Log File Location

You deploy Access Manager on WebLogic Server. Log messages go to the server log file of the WebLogic Server that you deploy it on. The default server log location is:

Domain_HOME/servers/serverName/logs/ serverName-diagnostic.log

Access Manager High Availability Concepts

This following sections provide conceptual information about using Access Manager in a high availability two-node cluster.

• Access Manager High Availability Architecture
  
• Protection from Failures and Expected Behaviors
  

Access Manager High Availability Architecture

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

Figure 7-2 Access Manager High Availability Architecture

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

In Figure 7-2, the hardware load balancer receives incoming authentication requests and routes them to WEBHOST1 or WEBHOST2 in the web tier. These hosts have Oracle HTTP Server installed. Oracle HTTP Server then forwards requests on to the WebLogic managed servers using the WebLogic plugin mod_wl_ohs.conf. See Oracle HTTP Server Configuration.

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 and a 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 routes requests to the load balancer and WEBHOST1 and WEBHOST2. For a high availability deployment, you can 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 Administration Server runs on OAMHOST1 and deploys the WebLogic Administration Console, Oracle Enterprise Manager Fusion Middleware Control, and the Oracle Access Management Console.

In the directory tier, the virtual IP idstore.example.com routes the IDstore requests to LDAPHOST1 and LDAPHOST2, which comprise an active-active IDStore cluster. For example the virtual IP oud.example.com is set up to route Oracle Unified Directory requests to OUDHOST1 and OUDHOST2, which comprise an active-active Oracle Unified Directory cluster.

An Oracle RAC database provides high availability in the data tier. 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.

In Access Manager 12c, 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

Oracle recommends using an external load balancing router 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.

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

Protection from Failures and Expected Behaviors

The WebLogic Server infrastructure protects the Identity Management Service Infrastructure system from all process failures. These features protect an 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.

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

• WebLogic Server Crash
  
• Node Failure
  
• Database Failure
  

WebLogic Server Crash

If a Managed Server fails, Node Manager attempts to restart it locally

Ongoing requests from Oracle HTTP Server timeout and new requests are directed to the other Managed Server. After 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.

Node Failure

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

Database Failure

Multi data sources protect Access Manager service Infrastructure against failures. When an Oracle RAC database instance fails, 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 more on multi data source configuration, see Section 4.1.3, "Using Multi Data Sources with Oracle RAC".

High Availability Directory Structure Prerequisites

A high availability deployment requires product installations and files to reside in specific directories. A standard directory structure facilitates configuration across nodes and product integration.

The following table describes high availability directory structure prerequisites.

Table 7-3 Directory Structure Prerequisites

Directory	Requirements
ORACLE_HOME	Each product must have its own ORACLE_HOME. For example, OAM and OIM must go in separate ORACLE_HOME locations. ORACLE_HOME contents must be identical across all nodes. Across all nodes, ORACLE_HOME must: Reside in the file system at the same path Contain identical products Contain identical versions of those products Have identical ORACLE_HOME names Have identical patches installed
DOMAIN_HOME and APPLICATION_DIRECTORY	These directories must have the same path on all nodes. Put these directories in a separate file system location from ORACLE_HOME; do not put these directories in the ORACLE_HOME/user_projects directory
wlsserver_10.n	Each OAM and OIM installation requires its own, separate WebLogic Server installation.

You have three options to set up the high availability directory structure:

• Use shared storage to store ORACLE_HOME directories. Oracle recommends this option. Use a NFS exported by a NAS, or a cluster file system pointing to a SAN/NAS.

• Use local storage and run all installation, upgrade, and patching procedures on one node, then replicate to other nodes (using rsync, for example.)

• Use local storage and repeat all installation and patch procedures on each node.

Access Manager High Availability Configuration Steps

This section provides high-level instructions to set 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.

See Using Dynamic Clusters.

• Access Manager Configuration Prerequisites
  
• Running the Repository Creation Utility to Create the Database Schemas
  
• Installing Oracle WebLogic Server
  
• Installing and Configuring the Access Manager Application Tier
  
• Creating boot.properties for the Administration Server on OAMHOST1
  
• Starting OAMHOST1
  
• Validating OAMHOST1
  
• Configuring OAM on OAMHOST2
  
• Starting OAMHOST2
  
• Validating OAMHOST2
  
• Configuring Access Manager to Work with Oracle HTTP Server
  
• Configuring Access Manager to use an External LDAP Store
  
• Validating the Access Manager Configuration
  
• Scaling Up Access Manager Topology
  
• Scaling Out Access Manager
  

Access Manager Configuration Prerequisites

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

• Install Oracle WebLogic Server on OAMHOST1 and OAMHOST2. See Installing Oracle WebLogic Server.

• Install the Oracle Identity Management executables on OAMHOST1 and OAMHOST2. See the Installing and Configuring the Access Manager Application Tier.

• Run the Repository Creation Utility to create the Access Manager schemas in a database. See Running the Repository Creation Utility to Create the Database Schemas.

• Ensure that a highly available LDAP implementation is available.

For example,

• Install the Infrastructure jar, jdk8/bin/java -jar fmw_12.2.1.4.0_infrastructure.jar and change the default installation directory path manually from /tmp/Middleware/ORACLE_HOME to /tmp/Middleware/

• Install IDM jar, jdk8/bin/java -jar fmw_12.2.1.4.0_idm.jar and choose /tmp/Middleware/ as the installation directory.

• Run RCU located at /tmp/Middleware/oracle_common/bin/rcu

Running the Repository Creation Utility to Create the Database Schemas

The schemas you create depend on the products you want to install and configure. See Starting the Repository Creation Utility to run RCU.

For more information, see Planning an Installation of Oracle Fusion Middleware and Creating Schemas with the Repository Creation Utility.

Installing Oracle WebLogic Server

To install Oracle WebLogic Server, see Installing and Configuring Oracle WebLogic Server and Coherence.

Note:

On 64-bit platforms, when you install Oracle WebLogic Server using the generic jar file, JDK is not installed with Oracle WebLogic Server. You must install JDK separately, before installing Oracle WebLogic Server.

Installing and Configuring the Access Manager Application Tier

See Installing and Configuring the Oracle Access Management Software in Installing and Configuring Oracle Identity and Access Management.

Creating boot.properties for the Administration Server on OAMHOST1

The boot.properties file enables the Administration Server to start without prompting for the administrator’s username and password.

To create the boot.properties file:

1. On OAMHOST1, go to:

   ORACLE_HOME/user_projects/domains/domainName/servers/AdminServer/security
   

   For example:

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

2. 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 Administration Server, 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, start the server as soon as possible to encrypt the entries.

3. Stop the Administration Server if it is running.

   See Starting and Stopping Oracle Fusion Middleware in Administering Oracle Fusion Middleware to start and stop WebLogic Servers.

4. Start Node Manager by using the following commands:

   cd WL_HOME/server/bin ./startNodeManager.sh

5. Start the Administration Server on OAMHOST1 with the startWebLogic.sh script in the ORACLE_HOME/user_projects/domains/domainName/bin directory.
6. Validate that changes are successful. Open a browser and log into these consoles using the weblogic user credentials:

   • WebLogic Server Administration Console at:

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

   • Oracle Enterprise Manager Fusion Middleware Control at:

     http://oamhost1.example.com:7001/em
     

Starting OAMHOST1

The following sections describe the steps for starting OAMHOST1.

• Start Node Manager
  
• Start Access Manager on OAMHOST1
  

Start Node Manager

• Start Node Manager by issuing the following command:

  OAMHOST1>ORACLE_HOME/user_projects/domains/domainName/bin/startNodeManager.sh
  

Start Access Manager on OAMHOST1

To start Access Manager on OAMHOST1, follow these steps:

1. Log into the WebLogic Administration Console using this URL using WebLogic administrator credentials:

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

2. Start the WLS_OAM1 Managed Server using the WebLogic Server Administration Console, as follows:
   1. Expand the Environment node in the Domain Structure tree on the left.
   2. Click Servers.
   3. On the Summary of Servers page, open the Control tab.
   4. Select WLS_OAM1, and then click Start.
   5. Click YES to confirm that you want to start the server.
   6. Then select OAM_POLICY_MGR1, and then click Start.
   7. Click YES to confirm that you want to start the server.

Validating OAMHOST1

Validate the implementation by connecting to the OAM server:

http://OAMHOST1.example.com:14150/access
http://OAMHOST1.example.com:14100/oam/server/logout

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

Configuring OAM on OAMHOST2

After configuration succeeds on OAMHOST1, propagate it to OAMHOST2. Pack the domain using the pack script on OAMHOST1 and unpack it with the unpack script on OAMHOST2.

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

On OAMHOST1, enter:

pack.sh -domain=$ORACLE_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=$ORACLE_HOME/user_projects/domains/IDM_Domain \
    -template=/tmp/idm_domain.jar

Starting OAMHOST2

This following sections describe the steps for starting OAMHOST2. Steps include the following:

• Create the Node Manager Properties File on OAMHOST2
  
• Start Node Manager
  
• Start Access Manager on OAMHOST2
  

Create the Node Manager Properties File on OAMHOST2

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

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

Start Node Manager

Start Node Manager by issuing the following command:

OAMHOST2>ORACLE_HOME/user_projects/domains/domainName/bin/startNodeManager.sh

Start Access Manager on OAMHOST2

To start Access Manager on OAMHOST2:

1. Log into the WebLogic Administration Console using this URL:

   http://OAMHOST1.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 server WLS_OAM2.
6. Click Start.
7. Click OK to confirm that you want to start the server.

Validating OAMHOST2

Validate the implementation by connecting to the OAM server:

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

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

Configuring Access Manager to Work with Oracle HTTP Server

Complete the subsequent procedures to configure Access Manager to work with Oracle HTTP Server.

• Update Oracle HTTP Server Configuration
  
• Restart Oracle HTTP Server
  
• Make OAM Server Aware of the Load Balancer
  

Update Oracle HTTP Server Configuration

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

OHSDomain/config/fmwconfig/components/OHS/<instancename>/moduleconf/

Create the file and add the following lines:

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName login.example.com:7777
    ServerAdmin [e-mail]
    RewriteEngine On
    RewriteOptions inherit

    <Location /oam>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAM_JSESSIONID
        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
        WLCookieName OAM_JSESSIONID
        WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100
        
    </Location>

    <Location /sts>
        SetHandler weblogic-handler
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAM_JSESSIONID
        WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100
        
    </Location>

    <Location /access>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAM_JSESSIONID
        WebLogicCluster amahost1.example.com:14150,amahost2.example.com:14150
        

    <Location /oamsso>
        SetHandler weblogic-handler
        Debug ON
        WLLogFile /tmp/weblogic.log
        WLProxySSL ON
        WLProxySSLPassThrough ON
        WLCookieName OAM_JSESSIONID
        WebLogicCluster oam_policy_mgr1.example.com:14100,oam_policy_
         mgr2.example.com:14100
        
    </Location>

</VirtualHost>

Restart Oracle HTTP Server

Restart the Oracle HTTP Server on WEBHOST1:

OHSDomain/bin/stopComponent.sh ohs1
OHSDomain/bin/startComponent.sh ohs1

Restart the Oracle HTTP Server on WEBHOST2:

OHSDomain/bin/stopComponent.sh ohs2
OHSDomain/bin/startComponent.sh ohs2

Make OAM Server Aware of the Load Balancer

By default, Access Manager sends requests to the login page 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:

1. Log into the Oracle Access Management Console at this URL as the weblogic user:

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

2. Click on the Configuration tab.
3. Click the Access Manager Settings link.
4. Enter the following information:

   • OAM Server Host: login.example.com

   • OAM Server Port: 7777

   • OAM Server Protocol: https

5. Click Apply.
6. Restart managed servers WLS_OAM1 and WLS_OAM2.

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 environment, Oracle recommends an external LDAP directory as the directory store.

Note:

Oracle recommends that you back up the environment and LDAP store before following this procedure.

• Extending Directory Schema for Access Manager
  
• Creating Users and Groups in LDAP
  
• Creating a User Identity Store
  
• Setting LDAP to System and Default Store
  
• Setting Authentication to Use External LDAP
  
• Adding LDAP Groups to WebLogic Administrators
  Access Manager requires access to MBeans stored within the administration server. In order for LDAP users to be able to log in to the WebLogic console and Fusion Middleware control, they must be assigned the WebLogic Administration rights. In order for Access Manager to invoke these Mbeans, users in the IAMAdministrators group must have WebLogic Administration rights.

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 these steps on OAMHOST1:

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

   Set IDM_HOME to IDM_ORACLE_HOME

   Set ORACLE_HOME to IAM_ORACLE_HOME

2. 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 OUD.)

   • IDSTORE_BINDDN Administrative user in the Identity Store Directory

   • IDSTORE_USERSEARCHBASE Location in your Identity Store where users are placed.

   • IDSTORE_GROUPSEARCHBASE Location in your Identity Store where groups are placed.

   • IDSTORE_SEARCHBASE Location in the directory where Users and Groups are stored.

   • IDSTORE_SYSTEMIDBASE Location in your directory where the Oracle Identity Manager reconciliation users are placed.

   • IDSTORE_SYSTEMIDBASE Location of a container in the directory where you can place users when you do not want them in the main user container. This happens rarely. For example, if Oracle Identity Manager reconciliation user which is also used for the bind DN user in Oracle Virtual Directory adapters.

3. Configure the Identity Store using the command idmConfigTool, 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

   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

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

Creating Users and Groups in LDAP

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

1. Set the Environment Variables JAVA_HOME, IDM_HOME, and ORACLE_HOME.

   • Set IDM_HOME to IDM_ORACLE_HOME.

   • Set ORACLE_HOME to IAM_ORACLE_HOME.

2. Create a properties file oam.props that contains the following parameters shown in the following example:

   IDSTORE_HOST: host.example.com
   IDSTORE_PORT: 9389
   IDSTORE_BINDDN: cn=directory manager
   IDSTORE_PASSWD: secret12
   IDSTORE_USERNAMEATTRIBUTE: cn
   IDSTORE_LOGINATTRIBUTE: uid
   IDSTORE_USERSEARCHBASE: ou=people,dc=example,dc=com
   IDSTORE_GROUPSEARCHBASE: ou=groups,dc=example,dc=com
   IDSTORE_SEARCHBASE: dc=example,dc=com
   IDSTORE_SYSTEMIDBASE: cn=systemids,dc=example,dc=com
   IDSTORE_OAMSOFTWAREUSER: oamSoftwareUser
   IDSTORE_PWD_OAMSOFTWAREUSER: example_pwd
   IDSTORE_OAMADMINUSER: oamAdminUser
   IDSTORE_PWD_OAMADMINUSER: example_pwd
   IDSTORE_PWD_OBLIXANONYMOUSUSER: example_pwd
   IDSTORE_PWD_ANONYMOUSUSER: example_pwd
   OAM11G_IDSTORE_ROLE_SECURITY_ADMIN: OAMAdministrators
   POLICYSTORE_SHARES_IDSTORE: true

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

   The command syntax is as shown in the following example:

   $ORACLE_HOME/idmtools/bin/idmConfigTool.sh -prepareIDStore mode=OAM input_file=prepareIDStore.properties log_level=ALL log_file=log_idstore1.out dump_params=true

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

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

Creating a User Identity Store

To create a user identity store:

1. Go to the Oracle Access Management Console at the URL:

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

2. Log in using the WebLogic administration user.
3. Select Configuration tab and click User Identity Stores.
4. Under OAM ID Stores, click Create. Enter the following information:

   • Store Name: LDAP_DIR

   • Store Type: OUD

   • 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 oud.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

5. Click Apply.
6. Click Test Connection to validate the connection to the LDAP server.

Setting LDAP to System and Default Store

After you define the LDAP identity store, you must set it as the primary authentication store. Follow these steps in the Oracle Access Management Console:

1. From the Configuration tab, click User Identity Stores.
2. Select LDAP_DIR as Default Store.
3. Select LDAP_DIR as System Store.
4. Click the Add [+] icon in Access System Administrators.
5. Enter OAM* in the search name field and click Search.
6. Select OAMAdministrators from the search results and click Add Selected.
7. Click Apply.
8. In the Validate System Administrator window, enter the username and password of the OAM administrator, for example, oamadmin.
9. Click Validate.
10. Test the connection by clicking Test Connection.

Setting 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:

1. Under Application Security tab, select Authentication Modules and click Search.
2. Click LDAP.
3. Select Open from the Actions menu.
4. Set User Identity Store to LDAP_DIR.
5. Click Apply.
6. Restart the Managed Servers Admin Server, WLS_OAM1 and WLS_OAM2.

Adding LDAP Groups to WebLogic Administrators

Access Manager requires access to MBeans stored within the administration server. In order for LDAP users to be able to log in to the WebLogic console and Fusion Middleware control, they must be assigned the WebLogic Administration rights. In order for Access Manager to invoke these Mbeans, users in the IAMAdministrators group must have WebLogic Administration rights.

When Single Sign-on is implemented, provide the LDAP group IDM Administrators with WebLogic administration rights, so that you can log in using one of these accounts and perform WebLogic administrative actions.

To add the LDAP Groups IAMAdministrators and WLSAdmins to the WebLogic Administrators:

1. Log in to the WebLogic Administration Server Console.
2. In the left pane of the console, click Security Realms.
3. On the Summary of Security Realms page, click myrealm under the Realms table.
4. On the Settings page for myrealm, click the Roles & Policies tab.
5. On the Realm Roles page, expand the Global Roles entry under the Roles table.
6. Click the Roles link to go to the Global Roles page.
7. On the Global Roles page, click the Admin role to go to the Edit Global Roles page.
8. On the Edit Global Roles page, under the Role Conditions table, click the Add Conditions button.
9. On the Choose a Predicate page, select Group from the drop down list for predicates and click Next.
10. On the Edit Arguments Page, Specify IAMAdministrators in the Group Argument field and click Add.
11. Repeat for the Group WLSAdmins.
12. Click Finish to return to the Edit Global Roles page.
13. The Role Conditions table now shows the groups IAMAdministrators and WLSAdmins as role conditions.
14. Click Save to finish adding the Admin role to the OAMAdministrators and IDM Administrators Groups.

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.

See Adding LDAP Groups to WebLogic Administrators

Scaling Up Access Manager Topology

You scale up to add a new Access Manager managed server to a node already running one or more server instances.

• Scaling Up Access Manager
  
• Registering the New Managed Server
  
• Configuring WebGate with the New OAM Managed Server
  

Scaling Up Access Manager

To scale up OAM:

1. Log in to the Administration Console at http://hostname.example.com:7001/console. From the Domain Structure window, expand the Environment node and then Servers.
2. In the Change Center, click Lock & Edit.
3. Select a server on the host you want to extend, for example: WLS_OAM1.
4. Click Clone.
5. 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.

6. Click OK.
7. Click on the newly created server WLS_OAM3
8. Set the SSL listen port. This should be unique on the host that the managed server will run on.

   Note:

   Enable the SSL listen port 14101.

9. Click Save.
10. Disable hostname verification for the new managed server. You must do this before you start and verify the WLS_OAM3 Managed Server. You can re-enable it after you configure server certificates for the communication between the Administration Server and Node Manager in OAMHOSTn.

    If the source server from which the new one was cloned had already disabled hostname verification, you do not need to take this step because the hostname verification settings propagated to the cloned server.

    To disable hostname verification, set Hostname Verification to None then click Save.

11. Click Activate configuration from the Change Center menu.

Registering the New Managed Server

To configure the new managed server as an OAM server, use the Oracle Access Management Console:

1. Log in to the Oracle Access Management Console as the oamadmin user at http://oamhost1.example.com:7001/oamconsole
2. Click the Configuration tab. Click Server Instances.
3. Select Create from the Actions menu.
4. 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, for example, 14100

   • Proxy Server ID: AccessServerConfigProxy

   • Port: Port you want the OAM proxy to run on. This is unique for the host, for example, 5575

   • Mode: Open

5. Click Apply when a prompt requests that you confirm the edit.
6. Ensure that the OAM_ORACLE_HOME property <ORACLE_HOME>/oam is set while starting server nodes (OAM1, OAM2 etc). In this environment, startWeblogic script is edited to pass -DOAM_ORACLE_HOME=<ORACLE_HOME>/oam while starting the Java process.

Configuring WebGate with the New OAM Managed Server

To configure the WebGate with the new OAM Managed Server, take these steps:

1. Verify that Node Manager is running on the new Access Server WLS_OAM3.
2. Start the Managed Server using the Administration Console. See the Start the Managed Server
3. Inform WebGates about the new Managed Server. See Inform WebGates of the New Managed Server

• Start the Managed Server
  
• Inform WebGates of the New Managed Server
  

Start the Managed Server

To start the Managed Server using the Administration Console:

1. Change to the directory to OAM Domain HOME. For example, DOMAIN_HOME/bin

2. Start the Managed Server. For example, enter:

   ./startManagedWebLogic.sh WLS_OAM3 http://hostname:7001
   

3. At the prompt, enter the WebLogic username and password. Click Enter.

4. Verify that the Managed Server is running. Check the startManagedWebLogic logs, or click Servers under Environment in the Administration Console to view the Summary page. Refresh the page to see updates.

Inform WebGates of the New Managed Server

To inform any WebGates about the new Managed Server:

1. Log in to the Oracle Access Management Console at http://OAMHOST1.example.com:7001/oamconsole as the oamadmin user.

2. Click Application Security tab, click Agents to open SSO Agents page.

3. On the SSO Agents page, click Search.

4. Click Search.

5. Click the WebGate you want to change.

6. Add the new server to either the primary or secondary server list by clicking the Add + icon.

7. Select the server name from the list.

8. Click Apply

Note:

Repeat this procedure to inform all the configured WebGate Agents.

Scaling Out Access Manager

You scale out to add a new Access Manager managed server to a new node. Scale out is very similar to scale up, but requires the software to be installed on the new node.

1. Install Oracle WebLogic Server on the new host. See Installing Oracle WebLogic Server.
2. Install Identity Management components on the new host. See Installing and Configuring the Access Manager Application Tier.
3. Log in to the Administration Console at http://hostname.example.com:7001/oamconsole.
4. From the Domain Structure window of the Administration Console, expand the Environment node and then Machines.
5. From the Machines table, click New.
6. At the Create a New Machine screen labeled Machine Identity, enter the following information:

   • Name: New node host name, for example, host.example.com

   • Machine OS: Select operating system, for example, UNIX

7. Click Next.
8. In the Create New Machine screen labeled Node Manager Properties, enter this information

   • Type: Keep the default SSL

   • Listen Address: Replace localhost with the hostname that WLS_OAM3 will run on.

   • Port: Verify that the Listen Port matches the Node Manager port that will run on the other node, for example, WLS_OAM3.

9. Click Finish.
10. From the Domain Structure expand Servers.
11. Select a server on the host you want to extend, for example: WLS_OAM1.
12. Click Clone.
13. From the Clone a Server screen labeled Server Identity enter the following:

    • Server Name: New name for the server, for example WLS_OAM3.

    • Server Listen Address: Name of the host the Managed Server will run on.

    • Server Listen Port: Port the new managed server will use. This port must be unique within the host.

14. Click OK.
15. From the Servers table, click the new clone you just created, for example WLS_OAM3.
16. From the Machine option, assign the server to the new machine name you just created. This is the machine that the Managed Server will run on.
17. Click Save.
18. Click on the SSL tab.
19. Click Advanced.
20. Set Hostname Verification to None.
21. Click Save.
22. Run pack.sh and unpack.sh scripts located at ORACLE_HOME/oracle_common/common/bin to pack the domain on OAMHOST1 and unpack it on the new host respectively.

    pack.sh -domain=ORACLE_HOME/user_projects/domains/domainName -template =/tmp/idm_domain.jar -template_name="OAM Domain" 
    unpack.sh -domain=ORACLE_HOME/user_projects/domains/domainName -template =/tmp/idm_domain.jar 

• Registering the Managed Server with OAM
  
• Configuring WebGate with the New OAM Access Server
  

Registering the Managed Server with OAM

To register the new managed server as an OAM server:

1. Log in to the Oracle Access Management Console at http://OAMHOST1.example.com:7001/oamconsole as the oamadmin user.
2. Click the Configuration tab. Click Server Instances.
3. Select Create from the Actions menu.
4. Enter the following information:

   • Server Name: Enter the same server name you entered while cloning the OAM server node in the WebLogic Console.

   • Host: Host that the server will run on, OAMHOST3.

   • Port: Listen port that was assigned when you created the managed server.

   • OAM Proxy Port: Port you want the OAM proxy to run on. This is unique for the host.

   • Proxy Server ID: AccessServerConfigProxy

   • Mode: Select the appropriate mode: Open, Simple, or Cert.

5. Click Apply.
6. Edit oam-config.xml available at <DOMAIN_HOME>/config/fmwconfig to set the IP range of nodes that get added dynamically.

   The Settings Map for the following example is SetWellKnownAddress>AuthorizedSubnets >Range1 >From [value of start ip range]]>To [value of end ip range].

   <Setting Name="AuthorizedSubnets" Type="htf:map">
   <Setting Name="Range1" Type="htf:map">
   <Setting Name="From" Type="htf:map">
   <Setting Name="Key"
   Type="xsd:string">oam.coherence.auth.range.from.1</Setting>
   <Setting Name="Value"
   Type="xsd:string">10.229.139.20</Setting>
   </Setting>
   <Setting Name="To" Type="htf:map">
   <Setting Name="Key"
   Type="xsd:string">oam.coherence.auth.range.to.1</Setting>
   <Setting Name="Value"
   Type="xsd:string">10.229.139.40</Setting>
   </Setting>
   </Setting>
   </Setting>

7. Ensure that the OAM_ORACLE_HOME property <ORACLE_HOME>/oam is set while starting server nodes (OAM1, OAM2 etc). In this environment, startWeblogic script is edited to pass -DOAM_ORACLE_HOME=<ORACLE_HOME>/oam while starting the Java process.

Configuring WebGate with the New OAM Access Server

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

1. Log in to the Oracle Access Management Console at http://OAMHOST1.example.com:7001/oamconsole as the oamadmin user.

2. Click Application Security tab.

3. Click Agents to open SSO Agents page

4. On the SSO Agents page, click Search.

5. Click the WebGate you want to change.

6. Under the Server Lists section, add the new OAM Access Server WLS_OAM3 to either the primary or secondary server list by clicking the Add [+] icon.

7. Select the server name from the list.

8. Click Apply.

Verifying the WebGate Configuration is Updated

To verify the WebGate configuration

1. Log into the Web server where the WebGate was updated previously.
2. Go to the directory OHSDomain/config/fmwconfig/components/OHS/<instancename>/webgate/config
3. Open ObAccessClient.xml with a text editor. Verify that primary_server_list or secondary_server_list shows that the new OAM Access Server is updated.

Note:

If the WebGate configuration does not update, recycle the web server, which pulls Webgate Agent profile updates to the ObAccessClient.xml file.

Editing Oracle HTTP Server Configuration File

Now that you created and started the new Managed Server, the web tier starts to direct requests to it. However, Oracle recommends informing the web server about the new Managed Server.

In the Web tier, there are several configuration files including admin_vh.conf, sso_vh.conf and igdinternal_vh.conf reside in the directory: ORACLE_INSTANCE/config/OHS/component name/moduleconf. Each contain a number of entries in location blocks. If a block references two server instances and you add a third one, you must update that block with the new server.

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

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100
</Location>

to:

<Location /oam>
   SetHandler weblogic-handler
   WebLogicCluster OAMHOST1.example.com:14100,OAMHOST2.example.com:14100,OAMHOST1.example.com:14101
</Location>

Deploying Oracle Identity and Access Management Cluster with Unicast Configuration

If multicast IP is disabled in deployment environment then you can deploy Oracle Identity and Access Management cluster with Unicast configuration.

In your deployment environment, if multicast IP is disabled because of security reasons or if you are using cloud Infrastructure for deployment, it is not feasible to deploy Oracle Identity and Access Management with the default configuration (multicast). It is not feasible because Oracle Identity and Access Management 12c uses EH cache, which depends on JavaGroup or JGroup library and supports multicast configuration as default for messages broadcasting.

To perform unicast configuration for EH cache, complete the following steps:

1. Get the list of host machines and available port to prepare the below JGroup configuration.
   Example:

   connect=TCP(bind_port=7800): TCPPING(initial_hosts=<Node1 IP>[7800],<Node2 IP>[7800];port_range=10;timeout=3000; num_initial_members=3): pbcast.NAKACK(use_mcast_xmit=false;retransmit_timeout=10000):pbcast.GMS(print_local_addr=true;join_timeout=3000)

2. In the EM Console, expand Identity and Access and click OIM.
3. Right-click on oim(version_number) and select System MBean Browser.

   Where, version_number is the current version number of Oracle Identity and Access Management.

4. Expand oracle.iam, click Server:oim, click Application:oim, select XMLConfig, click Config, then select XMLConfig.CacheConfig, and click Cache.
5. In the right pane, go to the Attributes tab, set the Clustered attribute value to true.
6. In the left pane, expand the Cache folder, select XMLConfig.CacheConfig.XLCacheProvider, and then click XLCacheProvider.
7. In the right pane, go to the Attributes tab, set the MulticastAddress: value to empty and the MulicastConfig attribute value to the equivalent JGroup string you identified in Step 1.
8. In oracle.iam, click Server:oim, select Application:oim, click XMLConfig, select Config, click XMLConfig.DeploymentConfig, select DeploymentConfig, click Application Defined MBeans: XMLConfig.DeploymentConfig:DeploymentConfig, and specify the Deployment Config Deployment Mode value as cluster.
9. Click Apply.
10. For using unicast IPV4, verify if the JVM property is set in the SetDomainEnv script on all the nodes. If not, set the JVM property, and then add the following parameters to the SetDomainEnv script:

    EXTRA_JAVA_PROPERTIES="-Djava.net.preferIPv4Stack=true ${EXTRA_JAVA_PROPERTIES}"

    export EXTRA_JAVA_PROPERTIES

11. Restart all the Oracle Identity and Access Management Managed Servers.