This chapter introduces 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. For more information, see Introduction to Oracle Access Management Access Manager in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
This chapter includes the following topics:
Section 6.3, "High Availability Directory Structure Prerequisites"
Section 6.4, "Access Manager High Availability Configuration Steps"
Figure 6-1 shows the Access Manager component architecture.
Figure 6-1 Access Manager Single Instance Architecture
Figure 6-1 shows the following components:
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 / 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, OSSO Proxy, and OAM Proxy components. Use Coherence Distributed Object Cache to propagate configuration file changes between Access Servers.
An Access Manager deployment consists of these system entities:
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 11g 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.
Coherence Distributed Object Cache - Access Manager components rely on this infrastructure for real time change propagation.
Access Manager Proxy - Custom version of Apache MINA server. 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 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:
Table 6-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. |
The following table describes Access Manager external runtime dependencies.
Table 6-2 Access Manager External Dependencies
Dependency | Description |
---|---|
LDAP based Identity Store |
|
OCSP Responder Service |
Real-time X.509 Certification Validation |
RDBMS Policy Store |
|
Oracle Identity Manager (when OIM-based password management is enabled) |
Oracle Identity Manager provides Password Management Services, replacing 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 (OAAM) |
Dependency when OAAM Advanced Authentication Scheme is selected |
Identity Federation |
Dependency when Identity Federation Authentication Scheme is selected |
LDAP based Identity Store |
|
OCSP Responder Service |
Real-time X.509 Certification Validation |
This section provides conceptual information about using Access Manager in a high availability two-node cluster.
Section 6.2.1, "Access Manager High Availability Architecture"
Section 6.2.2, "Protection from Failures and Expected Behaviors"
Figure 6-2 shows an Access Manager high availability architecture:
Figure 6-2 Access Manager High Availability Architecture
In Figure 6-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
. 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 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 ovd.example.com
routes 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. 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 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
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.
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.
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.
Session state is maintained in 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.
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.
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."
A high availability deployment requires product installations and files to reside in specific directories. A standard directory structure makes facilitates configuration across nodes and product integration.
The following table describes high availability directory structure prerequisites.
Table 6-3 Directory Structure Prerequisites
Directory | Requirements |
---|---|
MW_HOME |
Each product must have its own MW_HOME. For example, OAM and OIM must go in separate MW_HOME locations. MW_HOME contents must be identical across all nodes. Across all nodes, MW_HOME must:
|
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 MW_HOME; do not put these directories in the MW_HOME/ |
|
Each OAM and OIM installation requires its own, separate WebLogic Server installation. |
For a description of installation directories, see "Identifying Installation Directories" in Oracle Fusion Middleware Installation Guide for Oracle Identity Management.
You have three options to set up the high availability directory structure:
Use shared storage to store MW_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.
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.
This section includes the following topics:
Section 6.4.2, "Running the Repository Creation Utility to Create the Database Schemas"
Section 6.4.4, "Installing and Configuring the Access Manager Application Tier"
Section 6.4.6, "Creating boot.properties for the Administration Server on OAMHOST1"
Section 6.4.12, "Configure Access Manager to Work with Oracle HTTP Server"
Section 6.4.13, "Configuring Access Manager to use an External LDAP Store"
Section 6.4.14, "Validating the Access Manager Configuration"
Section 6.4.15, "Configuring Oracle Coherence to Keep Configuration Files in Sync"
Before you configure Access Manager for high availability, you must:
Run the Repository Creation Utility to create the Access Manager schemas in a database. See Section 6.4.2, "Running the Repository Creation Utility to Create the Database Schemas".
Install Oracle WebLogic Server on OAMHOST1 and OAMHOST2. See Section 6.4.3, "Installing Oracle WebLogic Server".
Install the Oracle Identity Management executables on OAMHOST1 and OAMHOST2. See the Section 6.4.4, "Installing and Configuring the Access Manager Application Tier".
Ensure that a highly available LDAP implementation is available.
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.
To install Oracle WebLogic Server, see Oracle Fusion Middleware Installation Guide for Oracle WebLogic Server.
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.See "Installing and Configuring Identity and Access Management" in Installation Guide for Oracle Identity and Access Management.
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 Installation Guide for Oracle Identity and Access Management for more information.
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 to:
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 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.Stop the Administration Server if it is running.
See "Starting and Stopping Oracle Fusion Middleware" in Administrator's Guide to start and stop WebLogic Servers.
Start the Administration Server on OAMHOST1 with the startWebLogic.sh
script in the MW_HOME
/user_projects/domains/
domainName
/bin
directory.
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
This section describes the steps for starting OAMHOST1.
Before you start managed servers from the console, you must create a Node Manager property file. To do this, run the script setNMProps.sh
located in the MW_HOME/oracle_common/common/bin
directory. For example:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
Start Node Manager by issuing the following command:
OAMHOST1> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
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.
To validate the implementation, connect to Oracle Access Management Console at:
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.
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 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
This section describes the steps for starting OAMHOST2. Steps include the following:
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 MW_HOME/oracle_common/common/bin
directory. For example:
OAMHOST1> $MW_HOME/oracle_common/common/bin/setNMProps.sh
Start Node Manager by issuing the following command:
OAMHOST2> $MW_HOME/wlserver_10.3/server/bin/startNodeManager.sh
To start Access Manager on OAMHOST2:
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_OAM2.
Click Start.
Click OK to confirm that you want to start the server.
Validate the implementation by connecting to the OAM server:
http://OAMHOST2.example.com:14100/oam/server/logout
The implementation is valid if an OAM logout successful page opens.
Follow these steps to configure Access Manager to work with Oracle HTTP Server:
On WEBHOST1 and WEBHOST2, create a file named oam.conf
in this directory:
ORACLE_INSTANCE/config/OHS/ohs1/moduleconf
Create the file and add 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 WLCookieName OAMSESSIONID 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 OAMSESSIONID 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 OAMSESSIONID 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 OAMSESSIONID WebLogicCluster oam_policy_mgr1.example.com:14100,oam_policy_ mgr2.example.com:14100 </Location> </VirtualHost>
Restart the Oracle HTTP Server on WEBHOST1 and WEBHOST2:
WEBHOST1>opmnctl stopall WEBHOST1>opmnctl startall WEBHOST2>opmnctl stopall WEBHOST2>opmnctl startall
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:
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.
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.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:
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
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.
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
Check the log file for errors and warnings and correct them.
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.
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 Configuration then Data Sources. Under the Configuration Tab, click Identity Stores.
Select User Identity Stores then click Add. Under OAM ID Stores, click Create. 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.
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:
Under the Configuration tab, click the System Configuration tab.
Select Data Sources from the navigation pane then click User Identity Stores.
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.
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:
Under Application Security Tab, click the System Configuration tab.
Select Access Manager Settings. Click Authentication Modules and click Search.
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 useoamadmin
to manage OIF, you must add the OAM Administrator Role. For more information, see Section 6.4.13.3, "Create a User Identity Store."Validate the configuration by logging into the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole
as oamadmin
.
In a highly available environment, Oracle Coherence keeps configuration files in sync. Oracle Coherence uses port 9095 by default but you can change this in Oracle Access Management Console.
Log in to the console at http://admin.example.com/oamconsole then follow these steps:
Click on the Configuration tab.
Click Servers then Search.
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.
You scale up to add a new Access Manager managed server ed to a node already running one or more server instances.
This section includes the following topics:
To scale up OAM:
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.
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 run on.
Note:
Enable the SSL listen port 14101.Click Save.
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 OAMHOST
n
.
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.
Click Activate configuration from the Change Center menu.
To configure the new managed server as an OAM server, use 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 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, 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
Click Coherence tab.
Set Local Port to a unique value on the host.
Click Apply.
Click Apply when a prompt requests that you confirm the edit.
To configure the WebGate with the new OAM Managed Server, take these steps:
Verify that Node Manager is running on the new Access Server WLS_OAM3.
Start the Managed Server using the Administration Console. See the "Start the Managed Server."
Inform WebGates about the new Managed Server. See "Inform WebGates of the New Managed Server."
To start the Managed Server using the Administration Console:
Log in to the new node WLS_OAM3.
Change to the directory ORACLE_BASE/OAM_DOMAIN/bin
. For example:
/u01/app/oracle/admin/oam/user_projects/domains/oam_domain/bin
Start the Managed Server. For example, enter:
./startManagedWebLogic.sh WLS_OAM3 http://hostname:7001
At the prompt, enter the WebLogic username and password. Click Enter.
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:
Log in to the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole
as the oamadmin
user.
Click the Configuration tab.
From Launch Pad, under Application Management, click and open Agents under the Application Security tab. Click Search.
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
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.
Install Oracle WebLogic Server on the new host. See Section 6.4.3, "Installing Oracle WebLogic Server."
Install Identity Management components on the new host. See Section 6.4.4, "Installing and Configuring the Access Manager Application Tier."
Log in to the Administration Console at http://
hostname.example.com:7001/oamconsole
.
From the Domain Structure window of the Administration Console, expand the Environment node and then Machines.
From the Machines table, click New.
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
Click Next.
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
.
Click Finish.
From the Domain Structure expand Servers.
Select a server on the host you want to extend, for example: WLS_OAM1.
Click Clone.
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.
Click OK.
From the Servers table, click the new clone you just created, for example WLS_OAM3
.
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.
Click Save.
Click on the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
To register the new managed server as an OAM server:
Log in to the Oracle Access Management Console at http://oamhost1.example.com:7001/oamconsole
as the oamadmin
user.
Click the Configuration tab. Click Server Instances.
Select Create from the Actions menu.
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
.
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.
From Launch Pad, select the Application Security tab.
Click Agents and click Search.
Click the WebGate you want to change.
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.
Select the server name from the list.
Click Apply.
Verifying the WebGate Configuration is Updated
To verify the WebGate configuration
Log into the Web server where the WebGate was updated previously.
Go to the directory WEB_HOME/config/OHS/ohs1/webgate/config
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 theObAccessClient.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.
To do this, update 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,OAMhost3.example.com:14300 </Location>