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

The following table describes Access Manager external runtime dependencies.

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

Figure 7-2 shows an 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.

Applications that other Oracle HTTP Servers access, that in turn have resources with restricted access, must have a WebGate and a custom agent. The WebGate on WEBHOST3 communicates with the Access Servers on OAMHOST1 and OAMHOST2 in the application tier using HTTP REST calls. 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 using a virtual HOSTNAME and contains Oracle Enterprise Manager 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, only one Access Manager cluster is supported per WebLogic Server domain.

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.

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.

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, jdk17.0.12 or jdk21.0.4/bin/java -jar fmw_14.1.2.0.0_infrastructure.jar and change the default installation directory path manually from /tmp/Middleware/ORACLE_HOME to /tmp/Middleware/

• Install IDM jar, jdk17.0.12 or jdk21.0.4/bin/java -jar fmw_14.1.2.1.0_idm_generic.jar and choose /tmp/Middleware/ as the installation directory.

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

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.

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

The following sections describe the steps for starting OAMHOST1.

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

/u01/oracle/config/domains/access/startNodeManager.sh

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

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

NameVirtualHost *:7777
<VirtualHost *:7777>
 
    ServerName login.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
        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>

OHSDOMAIN/bin/stopComponent.sh ohs1
OHSDOMAIN/bin/startComponent.sh ohs1

OHSDOMAIN/bin/stopComponent.sh ohs2
OHSDOMAIN/bin/startComponent.sh ohs2

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.

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

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 

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

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