Skip Headers
Oracle® Fusion Middleware Third-Party Application Server Guide for Oracle Identity and Access Management
11g Release 2 (11.1.2.1.0)

Part Number E28523-09
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

5 Managing Access Manager on IBM WebSphere

This chapter contains information regarding the differences when managing Access Manager on IBM WebSphere (as opposed to WebLogic Server).

This chapter contains the following sections:

5.1 Differences Between Access Manager When Deployed on WebLogic Server and IBM WebSphere

The following Access Manager features are only supported when Access Manager is deployed on WebLogic Server.

Note:

For the OAM-OAAM integration, the OAAMAdvancedScheme using TAP is preferred.

5.2 Using Oracle Access Manager WLST Commands on IBM WebSphere

You can run Oracle Access Manager commands from the IBM WebSphere wsadmin command line interface. For details, see Using the Oracle Fusion Middleware wsadmin Commands.

Access Manager commands are documented in the Web Logic Scripting Tool Command Reference. Oracle Access Management commands are functionally identical on WebLogic and WebSphere. When running Access Manager wsadmin commands, however, you must prefix the command name with the Access Manager Oam category name. For example:

Oam.displayOAMMetrics()

To connect to any WebSphere server in online mode use the following command:

./wsadmin.sh -connType SOAP -host <HOST_NAME> -port <SOAP_PORT> -user <ADMIN_USER> -password <ADMIN_PASSWORD>

where:

HOST_NAME, SOAP_PORT, ADMIN_USER, and ADMIN_PASSWORD are the correct values for your environment.

Note that there is not a WebSphere method to get domainRuntime(). For this reason you have to pass domainHome as an argument when applicable. This is true for both online and offline commands. The domainHome for WebSphere Application Server is as follows:

<WAS_HOME>/profiles/<PROFILE_NAME>/config/cells/<CELL_NAME>

5.3 Increasing the Number of Threads Available to Access Manager

If the number of concurrent requests hitting the Oracle Access Management server is high and all worker threads are currently in a processing state, a ThreadPoolQueueIsFullException error may result. The server can accept more requests if you tune the work manager configuration based on the concurrent requests expected.

To do this, follow these steps.

  1. Login to the WebSphere Application Server Administrative Console.

  2. Choose Resources > Asynchronous Beans > Work Managers > OAMServerWorkManager.

  3. Increase the maximum number of threads for OAMServerWorkManager from 50 to a large value (for example, 500).

5.4 Configuring x509 Authentication

To configure x509 and protect a resource, complete the following steps.

5.4.1 Create the Server Certificate and Trust Store

  1. Use a certificate authority to create a signed certificate for the Oracle Access Management server machine in the WebSphere cell. Include the machine name in the certificate details and save the certificate in the .p12 format.

  2. Create the server store as shown in the following sample command:

    keytool -importkeystore -deststorepass samplepassword -destkeystore server.jks –srckeystore my-server.p12 – srcstoretype PKCS12 -srcstorepass samplepassword -alias "Server"
    

    Note:

    Use the keytool utility to create and manage keys and certificates in the JKS keystore format. For command and option notes, refer to the JDK documentation provided with WebSphere Application Server.

  3. Change directories to JAVA_HOME/bin.

  4. Create the trust store by running the following command:

    keytool -import -alias trust -file scratch/simpleCA/ca.pem -keystore trust.jks
    

5.4.2 Configure the Stores

Configure the WebSphere server instance that needs to be both SSL and client certificate enabled.

Add the Keystore Server Store

  1. In the WebSphere administrative console, choose SSL certificate and key management > Key stores and certificates > New.

    Complete the form and provide the path to the server store.

  2. Click Personal Certificates (choose SSL certificate and key management > Key stores and certificates > server store name > Personal certificates) and verify that the server certificate is shown. If it is not shown, import the server certificate from the server store.

  3. Open the Signer Certificate page (choose SSL certificate and key management > Key stores and certificates > server store name > Signer certificates) and verify that the Root CA certificate is shown. If it is not shown, add the Root CA certificate.

Add the Trust Store

  1. In the WebSphere administrative console, choose SSL certificate and key management > Keystores and certificates > New.

    Complete the form and provide the path to the trust store.

  2. Open the Signer Certificate page (choose SSL certificate and key management > Key stores and certificates > trust store name > Signer certificates) and verify that the Root CA certificate is shown. If it is not shown, add the Root CA certificate.

  3. Choose SSL certificate and key management > Key stores and certificates > CellDefaultTrustStore > Signer certificates and add the Root CA certificate.

Create a New SSL Configuration and Adjust Settings

  1. Choose SSL certificate and key management > SSL configurations.

    Click New.

  2. Complete the form to create a new configuration for OAM Server. Choose the Trust store name and Keystore name that you added previously.

  3. Click Quality of protection (QoP) settings (choose SSL certificate and key management > SSL configuration > oam server ssl config name > Quality of protection (QoP) settings) and select Required from the Client authentication menu.

    Click Apply.

  4. Choose SSL certificate and key management > Manage endpoint security configurations.

    Expand the Inbound endpoint (Inbound > DefaultCell(CellDefaultSSLSettings) > nodes > DefaultNode(NodeDefaultSSLSettings) > servers) and click to edit the oam server instance.

    In the Specific SSL configuration for this endpoint section, select Override inherited values, and choose the OAM server SSL config name from the SSL configuration menu.

    Click Apply and repeat for the Outbound endpoint.

  5. Synchronize the node.

  6. Restart the nodeagent.

  7. Restart the Oracle Access Management server.

5.4.3 Create a User Certificate

Use a certificate authority to create a signed user certificate. Include the user name for whom the certificate is requested in the certificate details and save the certificate in the .p12 format.

Install the certificate in your browser.

5.4.4 Adding the Root CA Certificate to the Store

To enable SSL on WebSphere, add the certificate utility root certificate to the .oamkeystore and amtruststore file located here:

<WAS_HOME>/profiles/Dmgr01/config/cells/DefaultCell01/fmwconfig
 

To Retrieve the .oamkeystore / amtruststore Password

  1. From the command line, navigate to the following directory:

    $WAS_HOME/oracle_common/common/bin/
    
  2. Run the wsadmin.sh command:

    wsadmin.sh -conntype SOAP -port <SSL_SOAP_PORT> -user <username>
    
  3. From the wsadmin shell, run the following command:

    Opss.listCred(map="OAM_STORE", key="jks")
     
    

    The password is displayed.

To add the CA Certificate to the .oamkeystore / amtruststore File

Add the CA certificate to the .oamkeystore / amtrustore file as shown in the following sample keytool commands.

Note:

For keytool command and option notes, refer to the JDK documentation provided with WebSphere Application Server.

./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore <WAS_HOME>/Dmgr01/config/cells/DefaultCell01/fmwconfig/.oamkeystore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jceks
 
./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore <WAS_HOME>/Dmgr01/config/cells/DefaultCell01/fmwconfig/amtruststore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jks

Note:

The -storepass value in the sample keytool commands is retrieved using the steps in the "To Retrieve the .oamkeystore / amtruststore Password" section.

5.4.5 Protecting a Resource Using the X509 Authentication Scheme

  1. In the Oracle Access Management Administration Console, choose Policy Configuration > Shared Components > Authentication Schemes > X509Scheme.

  2. In the Challenge URL box, change the value to the SSL port of the managed server.

    For example:

    https://<managed server host name>:<managed server SSL port number>/oam/CredCollectServlet/X509

  3. To protect a resource using the X509 authentication scheme, choose Policy Configuration > Application Domains > Domain Name > Authentication Policies > Protected Resource Policy.

    Choose X509 Scheme from the Authentication Scheme menu.

5.4.6 To Access an X509 Protected Resource

  1. Open the resource using the browser that has the installed user certificate.

    The browser will prompt you to select the certificate to use to connect.

  2. Choose the valid user certificate and click OK.

    The resource is displayed.

5.5 Deploying the RSA SecurID Authentication Plug-in

If deploying the RSA SecurID Authentication Plug-in (authn_securid) on WebSphere, note the following requirements:

5.6 Configuring Access Manager Running on WebSphere for Windows Native Authentication

To configure Access Manager running on WebSphere for Windows Native Authentication (WNA), format the path to the keytab file in the oam-config.xml file as follows:

file://<path to keytab file>

In a UNIX environment, specify a path similar to the following:

<Setting Name="keytabfile"           Type="xsd:string">file:///refresh/home/oam.keytab
      </Setting>

For more information, see "Configuring Access Manager for Windows Native Authentication" in the Administrator's Guide for Oracle Access Manager.

5.7 Moving Access Manager From a Test to Production Environment on IBM WebSphere

This section describes how to copy Access Manager from a test environment to a production environment. These same steps can also be used to copy a production environment to a test environment.

This section covers the following topics:

5.7.1 Introduction to Moving Access Manager on IBM WebSphere

You can move Access Manager from a source environment to a target environment.

Moving Access Manager minimizes the amount of work that would otherwise be required to reapply all the customization and configuration changes made in one environment to another. You can install, configure, customize, and validate Access Manager in a source environment. Once the system is stable and performs as desired, you can create the target environment by moving a copy of the components and their configurations from the source environment, instead of redoing all the changes that were incorporated into the source environment.

5.7.2 Limitations and Restrictions

The steps to move Access Manager from one IBM WebSphere environment to another has the following limits and restrictions:

  • Use these steps if your policy store resides on a database. These steps do not describe how to move an LDAP-based policy store from test to production.

  • Migrating the User Identity Store from one system to another is not supported.

  • To move Mobile and Social from a test to a production environment, first complete the steps in this section, then complete the "Moving Mobile and Social From a Test to a Production Environment" steps, which are located in the "Managing Oracle Access Management Mobile and Social on IBM WebSphere" chapter.

  • The Test to Production (T2P) commands that Oracle provides for IBM WebSphere are not the same tools that are provided for WebLogic environments. The commands for IBM WebSphere do not support the Full Replication or Golden Template options for moving files between environments.

5.7.3 Overview of Procedures for Moving from a Source to a Target Environment

Moving Access Manager from a test environment to a production environment is a multi-step process:

  1. Run the exportConfig command on the test (source) system.

    This command does the following:

    • Exports keystores, for example, the oamkeystore and the coherence keystore.

    • Exports OAM Config

    • Exports policies, including the password policy

    • Exports partners

    • Creates an archive file named wast2p.zip for the exported data and saves it in a specified directory

    Transfer the archive to the production (target) system after the command completes.

  2. Export the OPSS Policy domain from the test database and export the OPSS Encryption Key.

  3. Run the importConfig command on the production (target) system.

    This command does the following:

    • Expands the wast2p.zip archive in the production environment.

    • Imports the keystores

    • Imports OAM Config by updating the installation of Access Manager in the production environment

  4. Run the updateConfig command on the production (target) system.

    This command does the following:

    • Imports policies, including the password policy

    • Imports partners

    • Updates the MultiDataCenter Cluster ID

  5. Stop the OracleAdmin Server, the Managed Server, and the Node Agent and import the OPSS Encryption Key.

  6. Import the OPSS policy data to the production (target) database.

  7. Stop and start the Deployment Manager. Start the Sync Node, the Node agent, and the admin and managed servers.

5.7.4 Prerequisites

Before continuing with the steps in this chapter, verify that you have completed the following requirements.

Install Oracle Access Management

Install Oracle Access Management in the production (target) environment. Ensure that the Oracle Access Management version and build numbers in the test and production environments match, as well as all configuration files.

Ensure the Admin and Managed Servers are Running

The admin server and managed server should be up and running.

5.7.5 Moving Access Manager From Test to Production

Complete the steps in the following order.

  1. Run the exportConfig command on the test (source) system:

    Oam.exportConfig('<TargetDir>')

    where:

    TargetDir is the path to the directory where the archive should be saved.

    For example:

    Oam.exportConfig('scratch/bkup')
    
  2. Move the archive created in the previous step to the production environment.

  3. Export the OPSS Policy domain from the test database.

    Use the export procedure that is appropriate for your database. For example:

    ./expdp system/welcome1@orcl DIRECTORY=DATA_PUMP_DIR SCHEMAS=<OPSS_schema name>DUMPFILE=export.dmp PARALLEL=2 LOGFILE=export.log
    
    
  4. Export the OPSS encryption key using the following wsadmin command from oracle_common/common/bin:

    Opss.exportEncryptionKey('<jpsConfigFilePath>','<keyFilePath>', '<keyFilePassword>')
    

    where:

    <jpsConfigFilePath> is the absolute location of the file in the test environment

    <keyFilePath> is the directory in the test environment where you want the ewallet.p12 file created. Note that the content of this file is encrypted and secured by the keyFilePassword.

    <keyFilePassword> is the password used to secure the fileewallet.p12 file. Note that this same password must be used when importing the file.

  5. Run the importConfig command in the production (target) environment. The Admin and Managed server should be running. Use this command:

    Oam.importConfig('<ZipLocation>')

    where:

    ZipLocation is the path to where the archive file copied in the previous step is located.

    For example:

    Oam.importConfig('scratch/bkup/wast2p.zip')
    

    Note:

    Due to synchronization issues you may need to restart Deployment Manager in the production environment before performing the import. If the importConfig command results in an error or does not produce the expected result, restart the Deployment Manager and run the command again. After import the keystores and OAM configuration should be updated.

  6. Run the updateConfig command in the production (target) environment. The Admin and Managed server should be running. Use this command:

    Oam.updateConfig('<ZipLocation>')

    where:

    ZipLocation is the path to the directory where the archive copied in the previous step is located

    Note:

    Due to synchronization issues you may need to restart the Admin and Managed Servers in the production environment before performing the update. If the updateConfig command results in an error or does not produce the expected result, restart the Admin and Managed Servers and run the command again.

  7. Stop the Oracle Admin Server and the Managed Server and stop the Node Agent.

  8. Import the OPSS Encryption Key using the following wsadmin command from oracle_common/common/bin :

    Opss.importEncryptionKey('<PROD_jpsConfigFilePath>','<PROD_keyFilePath>',
    '<keyFilePassword>')
    

    where:

    <PROD_jpsConfigFilePath> is the absolute location of the file in the production environment

    <PROD_keyFilePath> is the directory in the production environment where the file ewallet.p12 is created. Note that the content of this file is encrypted and secured by the keyFilePassword.

    <keyFilePassword> is the password used to secure the fileewallet.p12 file.

  9. Import the OPSS policy data to the production database.

    Use the import procedure that is appropriate for your database. For example:

    /impdp system/welcome1@orcl DIRECTORY=DATA_PUMP_DIR DUMPFILE=export.dmp PARALLEL=2 LOGFILE=import.log remap_schema=<Test schema name>_OPSS:<Prod schema name>_OPSS  remap_tablespace=<Test schema name>_IAS_OPSS:<Prod schema name>_IAS_OPSS TABLE_EXISTS_ACTION=REPLACE
    
  10. Do the following:

    1. Stop and start the Deployment Manager.

    2. Synchronize the node.

    3. Start the node agent.

    4. Start the Admin and Managed Servers

5.8 Installing Access Manager in a High-Availability WebSphere Environment

This section contains information about installing Access Manager in a high-availability WebSphere environment.

The following topics are covered:

5.8.1 Overview of the Installation Process

The following steps describe how to install Access Manager on three OAM servers across two nodes. Repeat the steps as needed to install Access Manager on more than three servers.

These steps create the following topology:

Node 1 Machine

  • Deployment Manager (Profile: Dmgr01)

  • WebSphere server – OracleAdminServer (Profile: Custom01)

  • WebSphere server - oam_server1a (Profile: Custom01)

  • WebSphere server - oam_server1b (Profile: Custom01)

Node 2 Machine

  • WebSphere server - oam_server2 (Profile: Custom02)

5.8.2 Installation Roadmap

Installing Access Manager in a high-availability IBM WebSphere environment includes the following high-level tasks.

Table 5-1 Installation Flow for Access Manager in a High-Availability IBM WebSphere Environment

No. Task Information

1

Review the System Requirements and Certification Information, then install a database that is compatible with Oracle Fusion Middleware.

Refer to Chapter 2, "Installing and Configuring Oracle Identity and Access Management on IBM WebSphere" and complete the following tasks:

  • Task 1: Review the System Requirements and Certification Information

  • Task 2: Obtain the Necessary Software Media or Downloads

  • Task 3: Identify a Database and Install the Required Database Schemas

Run the Repository Creation Utility (RCU) to create the OAM and OPSS schemas.

2

Install the IBM WebSphere Software on both the node 1 machine and the node 2 machine.

Refer to Chapter 2, "Installing and Configuring Oracle Identity and Access Management on IBM WebSphere" and complete the following task:

  • Task 4: Install the IBM WebSphere Software

If you will also install Oracle Identity Manager, complete the following task:

  • Task 5: Install Oracle SOA Suite

3

Install the Oracle Identity and Access Management Suite on both machines in Node 1

Refer to Chapter 2, "Installing and Configuring Oracle Identity and Access Management on IBM WebSphere" and complete the following task:

  • Task 6: Install Oracle Identity and Access Management Suite

If you will also install Oracle Privileged Account Manager, complete the following task:

  • Task 7: Optional: Enabling TDE in Oracle Privileged Account Manager Data Store

4

Configure the Oracle Identity and Access Management Components in IBM WebSphere on Node 1

Refer to Section 5.8.3, "Configure the Oracle IAM Components on IBM WebSphere on Node 1."

5

Configure the Oracle Identity and Access Management Components in IBM WebSphere on Node 2

Refer to Section 5.8.4, "Configure the Oracle IAM Components on IBM WebSphere on Node 2."

7

Start the servers

Refer to Section 5.8.5, "Start the Servers."

8

Next steps

Refer to Section 5.8.6, "Next Steps."


5.8.3 Configure the Oracle IAM Components on IBM WebSphere on Node 1

To configure Access Manager in a new IBM WebSphere cell, complete the following steps:

  1. Start the Oracle Fusion Middleware Configuration Wizard by running the following command from the Oracle Identity and Access Management home:

    ORACLE_HOME/common/bin/was_config.sh
    
  2. If necessary, select Oracle Access Management - 11.1.2.1.0.

  3. On the Select Optional Configuration screen, select the Application Servers, Clusters and End Points option, and click Next.

  4. On the Configure Application Servers screen, type the following names and click Next:

    • In the Name field, type a name for the Oracle Access Management server, for example: oam_server1a.

    • In the Node name column, select from the list the node agent name for oam_server1a, for example: WebsphereNode1.

  5. On the Configure Clusters screen, do the following:

    1. Click Add.

    2. Type a name for the cluster in the Cluster Name field, for example: OAMServerCluster.

    3. Select the appropriate OAM Server (oam_server1a) from the First cluster member list.

  6. On the Configure Additional Cluster Members screen, complete the following steps only if the second OAM server is also configured on the same node. If the second OAM Server is not on the same node, click Next and proceed.

    1. Click Add.

    2. In the Name field, type a name for the Oracle Access Management server to be added to OAMServerCluster—for example, oam_server1b.

    3. Click Next and proceed through the remaining screens.

  7. Use the following command to stop the node:

    $WAS_HOME/profiles/Custom01/bin/stopNode.sh
    
  8. Validate that the oam-server-info.properties file is correct:

    1. Go to the following location and open the file in a text editor:

      $WAS_HOME/profiles/Dmgr01/config/cells/Cell01/fmwconfig
      
    2. Verify that the file contains the correct settings for your environment. The settings should be similar to the following:

      #-- start of file contents --
      oracle.oam.adminserver=OracleAdminServer
      oracle.oam.runtimeserver=oam_server1a,oam_server1b
      OracleAdminServer= https://oamadminhost.us.example.com:9003
      oam_server1a=https://oamserver1.us.example.com:14101
      oam_server1b=https://oamserver1.us.example.com:15101
      #-- end of file --
      

      Note:

      You can add all of the OAM managed servers in the cluster to this properties file, or you can add them later using the OAM console. In the properties file, the oracle.oam.runtimeserver property should list the names of the servers in the cluster.

  9. Run the configureSecurityStoreWas.py command:

    $IDM_HOME/common/bin/wsadmin.sh -lang jython -profileName Dmgr01 -f 
    $IDM_HOME/common/tools/configureSecurityStoreWas.py -d 
    $WAS_HOME/profiles/Dmgr01/config/cells/<cell> -t DB_ORACLE -j cn=jpsroot -m create --passcode <OPSS-db-schema-password> --config IAM
    
  10. Configure the Oracle Internet Directory (OID) store for Oracle Platform Security Services (OPSS):

    1. Run the following command to start the Deployment Manager:

      $WAS_HOME/profiles/Dmgr01/bin/startManager.sh
      
    2. Run the OPSS wsadmin command to launch the wsadmin shell.

      $WAS_HOME/oracle_common/common/bin/wsadmin.sh -conntype SOAP -port <port_number> -user <username> -password <passwd>

      Note:

      Use the credentials that you used to set up the WebSphere cell (that is, the wasadmin user name and password). The port details are available in the following file:

      $WAS_HOME/profiles/Dmgr01/logs/AboutThisProfile.txt

    3. Run the configureIdentityStore wsadmin command in the wsadmin shell:

      Opss.configureIdentityStore(propsFileLoc="<location of the oid.properties properties file>")

      A sample oid.properties file is provided here:

      user.search.bases=cn=Users,dc=us,dc=example,dc=com
      group.search.bases=cn=Groups,dc=us,dc=example,dc=com
      subscriber.name=dc=us,dc=example,dc=com
      ldap.host=host06.us.example.com
      ldap.port=3333
      # admin.id must be the full DN of the user in the LDAP
      admin.id=cn=orcladmin,cn=Users,dc=us,dc=example,dc=com
      admin.pass=welcome123
      user.filter=(&(uid=%v)(objectclass=person))
      group.filter=(&(cn=%v)(objectclass=groupofuniquenames))
      user.id.map=*:uid
      group.id.map=*:cn
      group.member.id.map=groupofuniquenames:uniquemember
      ssl=false
      # primary.admin.id indicates a user who has admin permissions in the LDAP.
      # It must be the name of the user, for example, for user "cn=tom", the
      # primary.admin.id is "tom"
      primary.admin.id=orcladmin
      # optional, default to "OID"
      idstore.type=OID
      # Optional properties for JPS LDAP identity store can also be configured in
      # the file.
      username.attr=cn
      user.object.classes=person
      

      In the properties file, ensure that the primary.admin.id is set to a user who is part of the Administrators group in the specified Oracle Internet Directory instance.

    4. Stop the Deployment Manager:

      $WAS_HOME/profiles/Dmgr01/bin/stopManager.sh

      Provide the credentials for the WebSphere cell.

  11. Start the Deployment Manager, nodes and servers.

    Use the primary.admin.id user credentials provided in the previous step.

    $WAS_HOME/profiles/Dmgr01/bin/startManager.sh

    $WAS_HOME/profiles/Custom01/bin/syncNode.sh <MachineName> <SOAP port>

    $WAS_HOME/profiles/Custom01/bin/startNode.sh

    $WAS_HOME/profiles/Custom01/bin/startServer.sh OracleAdminServer

    $WAS_HOME/profiles/Custom01/bin/startServer.sh oam_server1a

    $WAS_HOME/profiles/Custom01/bin/startServer.sh oam_server1b

  12. Validate that the configuration is correct from a Web browser by opening http://oamadminhost:port/oamconsole using the primary.admin.id user credentials provided earlier.

  13. Do not stop the Deployment Manager, but stop all of the other processes on the Node1 machine.

    $WAS_HOME/profiles/Custom01/bin/stopServer.sh oam_server1b

    $WAS_HOME/profiles/Custom01/bin/stopServer.sh oam_server1a

    $WAS_HOME/profiles/Custom01/bin/stopServer.sh OracleAdminServer

    $WAS_HOME/profiles/Custom01/bin/stopServer.sh

    $WAS_HOME/profiles/Custom01/bin/stopNode.sh

5.8.4 Configure the Oracle IAM Components on IBM WebSphere on Node 2

  1. Run the Oracle Fusion Middleware Configuration Wizard to federate the machine and configure its cell:

    $IDM_HOME/common/bin/was_config.sh

  2. On the Select Configuration Option screen, select the Federate Machine and Configure Cell option.

  3. Specify the profile and fnode name information. Enter information about the profile and node names that you want to create for the WebSphere Node 2 Machine.

  4. On the Specify Deployment Manager Information screen, enter information about the existing Deployment Manager System.

  5. On the Select Optional Configuration screen, select the Application Servers, Clusters and End Points option and click Next.

  6. Proceed through the wizard and accept the default options until you reach the Configure Additional Cluster Members screen.

  7. Complete the Configure Additional Cluster Members screen as follows:

    1. Click Add.

    2. In the Name box, type a name for the second server in the OAMServerCluster—for example, oam_server2.

    3. In the Node name list, choose the node agent for oam_server2—for example, WebSphereNode2.

    4. In the Cluster name list, choose the OAMServerCluster.

  8. Optional. On the Port Configuration screen, edit the port settings for oam_server2 on the Node2 machine so that they match the HTTP and HTTPS (SSL) port settings for oam_server1a on the Node1 machine. (This is an optional step for consistency.) The port specified should match the port setting specified in the oam-server-info.properties file.

  9. Stop the node on the WebSphere Node 2 machine:

    $WAS_HOME/profiles/Custom02/bin/stopNode.sh

  10. Add the node 2 OAM server instance to OAM Configuration using one of the following methods.

    • From the OAM console, choose System Configuration, create a new OAM Server instance, and enter the oam_server2 details.

    • From the wsadmin command line, use the createOAMServer command and enter the oam_server2 details.

    • Open the following properties file in a text editor:

      $WAS_HOME/profiles/Dmgr01/config/cells/Cell02/fmwconfig
      

      Add the OAM managed server(s) in the cluster to this properties file. The oracle.oam.runtimeserver property should list the names of the server(s) in the cluster. The settings should be similar to the following:

      #-- start of file contents --
      oracle.oam.adminserver=OracleAdminServer
      oracle.oam.runtimeserver=oam_server2
      OracleAdminServer= https://oamadminhost.us.example.com:9003
      oam_server2=https://oamserver2.us.example.com:14101
      #-- end of file --
      

5.8.5 Start the Servers

  1. Start the servers on the node 1 machine.

    $WAS_HOME/profiles/Dmgr01/bin/startManager.sh

    $WAS_HOME/profiles/Custom01/bin/syncNode.sh <MachineName> <SOAP port>

    $WAS_HOME/profiles/Custom01/bin/startNode.sh

    $WAS_HOME/profiles/Custom01/bin/startServer.sh OracleAdminServer

    $WAS_HOME/profiles/Custom01/bin/startServer.sh oam_server1a

    $WAS_HOME/profiles/Custom01/bin/startServer.sh oam_server1b

  2. Start the servers on the node 2 machine.

    $WAS_HOME/profiles/Custom02/bin/syncNode.sh <MachineName> <SOAP port>

    $WAS_HOME/profiles/Custom02/bin/startNode.sh

    $WAS_HOME/profiles/Custom02/bin/startServer.sh oam_server2

5.8.6 Next Steps

Both nodes are now configured and the OAM manager servers are ready to accept requests.

A load balancing router (LBR) now needs to be configured to route traffic to the managed server configured in both nodes. When the LBR configuration is complete, update the OAM load balancing configuration in oamconsole with the LBR information.

5.9 Managing OAM-Federation on IBM WebSphere

This section describes issues specific to managing OAM-Federation on IBM WebSphere. It contains this topic:

5.9.1 SSLHandshakeException Error for Google and Yahoo IdP Partners

When you integrate Access Manager with Identity Federation, and configure a Google or Yahoo IdP partner for federated SSO on IBM WebSphere application server through the OpenID protocol, you may see an SSLHandshakeException error when you attempt to access the resource.

For a Google partner, the error is as follows:

oracle.security.fed.controller.library.LibraryException:
oracle.security.fed.controller.frontend.action.exceptions.ResponseHandlerExcep
tion: oracle.security.fed.util.http.HttpException:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building
failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl
could not build a valid CertPath.; internal cause is:
        java.security.cert.CertPathValidatorException: The certificate issued
by OU=XXX Secure Certificate Authority, O=XXX, C=US is not trusted;
...

For a Yahoo partner, the error is as follows:

[2013-02-15T15:18:58.747-08:00] [oam_server1] [WARNING] [OAM-12001]
[oracle.oam.audit] [tid: WebContainer : 5] [ecid: disabled,0] [APP:
oam_server_11.1.2.0.0] Cannot load audit configuration.
[2013-02-15T15:18:58.749-08:00] [oam_server1] [WARNING] [OAM-12001]
[oracle.oam.audit] [tid: WebContainer : 5] [ecid: disabled,0] [APP:
oam_server_11.1.2.0.0] Cannot load audit configuration.
[2013-02-15T15:18:58.750-08:00] [oam_server1] [WARNING] [OAM-12001]
[oracle.oam.audit] [tid: WebContainer : 5] [ecid: disabled,0] [APP:
oam_server_11.1.2.0.0] Cannot load audit configuration.
[2013-02-15T15:18:59.136-08:00] [oam_server1] [ERROR] [FEDSTS-12078]
[oracle.security.fed.controller.library.api.FedEngineInstance] [tid:
WebContainer : 5] [ecid: disabled,0] [APP: oam_server_11.1.2.0.0] Library
Exception: {0}[[
oracle.security.fed.controller.library.LibraryException:
oracle.security.fed.controller.frontend.action.exceptions.ResponseHandlerExcep
tion: oracle.security.fed.util.http.HttpException:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building
failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl
could not build a valid CertPath.; internal cause is:
        java.security.cert.CertPathValidatorException: The certificate issued
by CN=XXX Root, OU="XXX, Inc.", O=XXX Corporation, C=US is not trusted; 
...

This error is due to missing Yahoo/Google SSL certificates.

Solution

You need to import the Yahoo/Google SSL certificates into the IBM JSSE Trusted keystore.

First obtain the SSL certificates.

  1. Using the Firefox browser, go to the https URL that is being accessed.

  2. After viewing the page, right click on the page, then view page info, then details, then view certificate, then details tab.

  3. Click export, then save.

Next, import the certificates into the keystore using the instructions provided in the following IBM Technote:

http://www-01.ibm.com/support/docview.wss?uid=swg21588087

Note: When executing the keytool command in Step 6 of the Technote:

  • The alias is whatever string you want to use to reference that certificate afterwards.

  • If you are not sure which cacerts to use, import the certificates to all the cacerts keystores.

Note: You may need to download Equifax certification from this URL:

http://www.geotrust.com/resources/root-certificates/index.html

Under Root Certificates, download Root1 - Equifax Secure Certificate Authority (.pem file).

Import this certificate using the steps described above.