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:
Differences Between Access Manager When Deployed on WebLogic Server and IBM WebSphere
Increasing the Number of Threads Available to Access Manager
Upgrading Access Manager 11g Release 2 (11.1.2.x.x) WebSphere Environments
Moving Access Manager From a Test to Production Environment on IBM WebSphere
Installing Access Manager in a High-Availability WebSphere Environment
The following Access Manager features are only supported when Access Manager is deployed on WebLogic Server.
OSSO Agent - mod_osso is not supported in non-OHS http servers; for OAM on WebSphere, the partners are expected to be IHS. Migration of OSSO10g customers to OAM-WebSphere is also not supported. Also, OSSO10g was supported only on OC4J; from this, we certify migration only to OAM-WLS.
IAMSuite Agent - The IAMSuite Agent (DOMAIN Agent) has been marked for deprecation on WebLogic Server. As this is the first release of OAM-WAS, there is no support for the IAMSuite Agent on WAS. Customers should use an IHS WebGate to front end Identity Management components. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management for details.
OAM NAP Simple Mode - The algorithms required by NAP simple mode are not supported by the IBM JDK.
NAP Autologin for OAM - OIM Integration - Autologin is supported between OAM-OIM however this must be based out of the TAP front channel integration. NAP based autologin is NOT supported on WebSphere given this is not supported on WebLogic Server.
IDM Domain Agent - The IDM Domain Agent does not need to be removed or disabled when deploying Oracle Access Management on IBM WebSphere.
Note:
For the OAM-OAAM integration, the OAAMAdvancedScheme using TAP is preferred.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>
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.
Login to the WebSphere Application Server Administrative Console.
Choose Resources > Asynchronous Beans > Work Managers > OAMServerWorkManager.
Increase the maximum number of threads for OAMServerWorkManager from 50 to a large value (for example, 500).
This section describes configuration issues and workarounds for Access Manager on WebSphere. The following topics are included:
Section 5.4.2, "Deploying the RSA SecurID Authentication Plug-in"
Section 5.4.3, "Configuring Access Manager Running on WebSphere for Windows Native Authentication"
Section 5.4.4, "Configuring Active Directory as the Identity Store"
To configure x509 and protect a resource, complete the following steps.
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.
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.Change directories to JAVA_HOME/bin.
Create the trust store by running the following command:
keytool -import -alias trust -file scratch/simpleCA/ca.pem -keystore trust.jks
Configure the WebSphere server instance that needs to be both SSL and client certificate enabled.
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.
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.
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.
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.
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.
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
Choose SSL certificate and key management > SSL configurations.
Click New.
Complete the form to create a new configuration for OAM Server. Choose the Trust store name and Keystore name that you added previously.
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.
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.
Synchronize the node.
Restart the nodeagent.
Restart the Oracle Access Management server.
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.
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
From the command line, navigate to the following directory:
$WAS_HOME/oracle_common/common/bin/
Run the wsadmin.sh command:
wsadmin.sh -conntype SOAP -port <SSL_SOAP_PORT> -user <username>
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.In the Oracle Access Management Administration Console, choose Policy Configuration > Shared Components > Authentication Schemes > X509Scheme.
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
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.
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.
Choose the valid user certificate and click OK.
The resource is displayed.
If deploying the RSA SecurID Authentication Plug-in (authn_securid) on WebSphere, note the following requirements:
Create the following directory structure in WebSphere and place the agent configuration file (sdconf.rec) in the oam directory:
Create the following path relative to the Fusion Middleware config directory:
fmwconfig/../../../servers/oam_server1/oam
Or, create the following path relative to the profile home directory:
<PROFILE_HOME>/servers/oam_server1/oam
Note:
See "Configuring Access Manager for RSA SecurID Authentication" in the Administrator's Guide for Oracle Access Management for more information.Download the following third-party JAR files:
authapi.jar
cryptoj.jar
Add these JAR files to the following directory:
fmwconfig/oam/plugin-lib
This is a required step to run the custom RSA plug-in.
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.
If Access Manager uses Active Directory as the identity store, add the following additional property setting to the jps-config.xml properties file, otherwise you will not be able to open the OAM console. This change is required as of 11g Release 2 Patch Set 2 (11.1.2.2).
In a text editor, open the domain-level jps-config.xml file:
$DOMAIN_HOME/config/fmwconfig/jps-config.xml
Add the following property settings to the idstore.ldap.provider setting:
<extendedProperty>
<name>group.object.classes</name>
<values>
<value>group</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.member.attrs</name>
<values>
<value>member</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.filter.object.classes</name>
<values>
<value>group</value>
</values>
</extendedProperty>
For example:
<serviceInstance name="idstore.ldap.4" provider="idstore.ldap.provider">
<property name="subscriber.name" value="DC=interop,DC=local"/>
<property name="bootstrap.security.principal.key" value="bootstrap_idstore"/>
<property name="idstore.type" value="ACTIVE_DIRECTORY"/>
<property name="ldap.url" value="ldap://ldaphost.us.example.com:389"/>
<property name="bootstrap.security.principal.map" value="BOOTSTRAP_JPS"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=Users,DC=interop,DC=local</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=Builtin,DC=interop,DC=local</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.object.classes</name>
<values>
<value>group</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.member.attrs</name>
<values>
<value>member</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.filter.object.classes</name>
<values>
<value>group</value>
</values>
</extendedProperty>
Re-start the Deployment Manager, the Oracle Admin Server, and oam_server1.
This section describes how to upgrade your existing Access Manager on IBM WebSphere environment from version 11g Release 2 (11.1.2) or 11g Release 2 Patch Set 1 (11.1.2.1) to 11g Release 2 Patch Set 2 (11.1.2.2).
Note:
This chapter refers to Oracle Access Management Access Manager 11g Release 2 (11.1.2) and 11g Release 2 (11.1.2.1.0) environments as 11.1.2.x.x.Table 5-1 lists the steps to upgrade Access Manager on WebSphere 11.1.2.x.x to 11.1.2.2.0.
Table 5-1 Roadmap for Upgrading Access Manager on WebSphere 11.1.2.x.x to 11.1.2.2.0
| Task No. | Task | For More Information |
|---|---|---|
|
1 |
Review system requirements and certifications. |
See Section 5.5.2, "Review System Requirements and Certification" |
|
2 |
Stop the WebSphere Administration Server and the Access Manager Managed Servers. |
See Section 5.5.3, "Shutting Down Administration Server and Access Manager Managed Server(s)" |
|
3 |
Back up the existing Access Manager 11.1.2.x. x environment. |
See Section 5.5.4, "Backing Up Access Manager 11g Release 2 (11.1.2.x.x) Environments" |
|
4 |
Update the binaries of Access Manager 11.1.2.x.x to 11.1.2.2.0. |
See Section 5.5.5, "Upgrading Access Manager Binaries to 11.1.2.2.0" |
|
5 |
Upgrade the Access Manager (OAM) and Oracle Platform Security Services (OPSS) schemas using the Patch Set Assistant. |
|
|
6 |
If you are upgrading Access Manager 11.1.2 to 11.1.2.2.0, you must copy the modified system or domain mbean configurations. If you are upgrading Access Manager 11.1.2.1.0 to 11.1.2.2.0, skip this task. |
See Section 5.5.7, "Copying Modified System mbean Configurations" |
|
7 |
Stop the Access Manager Managed Server(s) and the WebLogic Administration Server. |
See Section 5.5.8, "Shutting Down Administration Server and Access Manager Managed Server(s)" |
|
8 |
Upgrade the system configuration of Access Manager. |
|
|
9 |
Start the WebLogic Administration Server and the Access Manager Managed Server(s). |
See Section 5.5.10, "Starting Administration Server and Access Manager Managed Server(s)" |
|
10 |
Redeploy the OAM admin server and the OAM server applications from the WAS admin console, then restart OracleAdminServer and oam_server1. |
See Section 5.5.11, "Re-deploy the OAM Admin Server and OAM Server Applications" |
|
11 |
Verify the Access Manager upgrade. |
Before you start the upgrade process, read the system requirements and certification document to ensure that your system meets the minimum requirements for the products you are installing or upgrading to. For more information see Section 2.1, "Task 1: Review the System Requirements and Certification Information,"
The upgrade process involves changes to the binaries and to the schema. Therefore, before you begin the upgrade process, you must shut down the Access Manager Managed Server(s) and the WebSphere Administration Server. For more information, see Section 3.2.1, "Starting and Stopping Servers on IBM WebSphere."
You must back up your Oracle Access Manager 11.1.2.x.x environment before you upgrade to Access Manager 11.1.2.2.0.
After stopping the servers, back up the following:
MW_HOME directory, including the Oracle Home directories inside Middleware Home
Access Manager Domain Home directory
Oracle Access Manager schemas
MDS schemas
Audit and any other dependent schemas
To update Access Manager 11.1.2.x.x binaries to Access Manager 11.1.2.2.0, you must use the Oracle Identity and Access Management 11.1.2.2.0 installer. During the procedure, point the Middleware Home to your existing 11.1.2.x.x Oracle Access Manager Middleware Home.
For information about how to update the Oracle Identity and Access Management binaries, see Section 2.4, "Updating Oracle Identity and Access Management Binaries to 11g Release 2 (11.1.2.2.0)" in the Oracle Fusion Middleware Upgrade Guide for Oracle Identity and Access Management.
After you upgrade Access Manager binaries to 11.1.2.2.0, you must upgrade the OAM and OPSS (Oracle Platform Security Services) schemas by running the Patch Set Assistant. For information about how to upgrade schemas using Patch Set Assistant, see Section 2.6, "Upgrading Schemas Using Patch Set Assistant" in the Oracle Fusion Middleware Upgrade Guide for Oracle Identity and Access Management.
If you are upgrading Oracle Access Management Access Manager 11.1.2 to Oracle Access Management Access Manager 11.1.2.2.0, you must copy the modified system or domain mbean configurations from the OAM_ORACLE_HOME to the DOMAIN_HOME, after you update the Access Manager binaries to 11.1.2.2.0.
Note:
If you are upgrading Oracle Access Management Access Manager 11.1.2.1.0 to 11.1.2.2.0, skip this section.To do this, complete the following steps:
Run the following command from the location $ORACLE_HOME/common/bin:
On UNIX: wlst.sh
On Windows: wlst.cmd
Run the following command:
copyMbeanXmlFiles('DOMAIN_HOME','OAM_ORACLE_HOME')
In this command, DOMAIN_HOME is the absolute path to the Access Manager WebSphere domain, and OAM_ORACLE_HOME is the absolute path to the OAM Oracle home. The second parameter OAM_ORACLE_HOME is optional.
For example:
On UNIX:
copyMbeanXmlFiles('/Oracle/Middleware/user_projects/domains/base_domain','/Oracle/Middleware/Oracle_IDM1')
On Windows:
copyMbeanXmlFiles('C:\\Oracle\\Middleware\\user_projects\domains\\base_domain','C:\\Oracle\\Middleware\\Oracle_IDM1')
If the modified system or domain mbean configurations are copied successfully, the following status is displayed on the command line:
STATUS: SUCCESS The mbean xml files have been upgraded to new version. The original mbean xml is saved in "<domain_directory>/output/upgrade". Please restart the admin and oam servers.
If the STATUS shows SUCCESS, restart the WebSphere Administration Server and the Access Manager Managed Server(s) by stopping and starting the servers in the following order:
Stop the Access Manager Managed Server(s) by choosing Servers > Server Types > WebSphere application servers. Select the check box(es) for the managed server(s) and click Stop.
stopManagedWebLogic.sh command work?Stop the WebSphere Administration Server.
Start the WebSphere Administration Server.
Start the Access Manager Managed Server(s) by choosing Servers > Server Types > WebSphere application servers. Select the check box(es) for the managed server(s) and click Start.
startManagedWebLogic.sh command work?Shut down the Access Manager Managed Server(s) and the WebSphere Administration Server before upgrading the system configuration.
After you upgrade to Access Manager binaries to 11.1.2.2.0, you must run the upgradeConfig() utility to upgrade the system configuration of Access Manager to 11.1.2.2.0.
Note:
If you are upgrading Access Manager 11.1.2.1.0 to 11.1.2.2.0, then you must do the following before running theupgradeConfig.sh command:
Go to the directory ORACLE_HOME/common/script_handlers.
Remove all the .class files by running the following command:
rm *.class
To upgrade the system configuration of Access Manager, do the following:
Run the following command to launch the WebLogic Scripting Tool (WLST) from the location $ORACLE_HOME/common/bin:
On UNIX: ./wlst.sh
On Windows: wlst.cmd
Run the following command in offline mode:
upgradeConfig("domain_home", "sysdbaUser", "sysdbaPwd", "oamSchemaOwner", "oamdbJdbcUrl")
In this command,
domain_home is the absolute path to the Access Manager WebSphere domain.
sysdbauser is the database user name having sysdba privileges.
sysdbapwd is the password of the database user having sysdba privileges.
oamSchemaOwner is the database user name for OAM schema.
oamdbjdbcUrl is the JDBC URL to connect to the Access Manager database. The JDBC URL must be in specified in the format "jdbc:oracle:thin:@<server_host>:<server_port>/<service_name>".
For example:
upgradeConfig("/Oracle/Middleware/user_projects/domains/base_domain", "sys", "pwd", "PREFIX_OAM", "jdbc:oracle:thin:@localhost:1521/orcl")
Start the WebSphere Administration Server and Access Manager Managed Server(s)
To re-deploy the OAM Administration Console, follow these steps:
Log in to the WebSphere Admin console.
Choose Applications > Application Types > WebSphere enterprise applications.
Select the OAM Admin Console application (oam_admin_11.1.2.0.0) check box, then click Update.
Under Application update options, choose Replace the entire application, specify the following path to the replacement .ear file, and click Next.
$ORACLE_HOME/oam/server/apps/oam-admin-was.ear
Choose use existing bindings from the Specify bindings to use menu, and click Next.
Use the default options on the Select installation options page and click Next.
On the Map modules to servers page, locate the Clusters and servers box and select the entry that ends in OracleAdminServer.
Select all of the listed modules in the table, then click Apply.
Click Next.
On the Summary page, review the installation options, and click Finish to start the deployment process.
When the installation finishes, click Save directly to the master configuration.
Restart the OracleAdminServer by choosing Servers > Server Types > WebSphere application servers. Select the OracleAdminServer check box and click Restart.
To re-deploy the OAM Server application, follow these steps:
Log in to the WebSphere Admin console.
Choose Applications > Application Types > WebSphere enterprise applications.
Select the OAM Server Console application (oam_server_11.1.2.0.0) check box, then click Update.
Under Application update options, choose Replace the entire application, specify the following path to the replacement .ear file, and click Next.
$ORACLE_HOME/oam/server/apps/oam-server.ear
Choose use existing bindings from the Specify bindings to use menu, and click Next.
Use the default options on the Select installation options page and click Next.
On the Map modules to servers page, locate the Clusters and servers box and select the entry that ends in oam_server1.
Select all of the listed modules in the table, then click Apply.
Click Next.
On the Summary page, review the installation options, and click Finish to start the deployment process.
When the installation finishes, click Save directly to the master configuration.
Restart the OracleAdminServer by choosing Servers > Server Types > WebSphere application servers. Select the oam_server1 check box and click Restart.
Use the following URL in a web browser to verify that Oracle Access Management Access Manager 11g Release 2 (11.1.2.2.0) is running:
http://<oam_admin_server_host>:<oam_admin_server_port>/oamconsole
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:
You can move Access Manager from a source environment to a target environment.
Begin by installing, configuring, customizing, and validating Access Manager in a test environment. Then, once the system is stable and performs as desired, create the target environment by moving a copy of the components and their configurations. Moving Access Manager is faster and more reliable than attempting to reapply configuration changes and customizations that were made in a source environment to a new environment.
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 "Update the Challenge URL After 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.
Moving Access Manager from a test environment to a production environment is a multi-step process:
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.
Export the OPSS Policy domain from the test database and export the OPSS Encryption Key.
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
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
Stop the OracleAdmin Server, the Managed Server, and the Node Agent and import the OPSS Encryption Key.
Import the OPSS policy data to the production (target) database.
Restart the production server.
Run the updateConfig command on the production (target) system a second time.
Stop and start the Deployment Manager. Start the Sync Node, the Node agent, and the admin and managed servers.
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.
Complete the steps in the following order.
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')
Move the archive created in the previous step to the production environment.
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
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.
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 theimportConfig 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.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 theupdateConfig command results in an error or does not produce the expected result, restart the Admin and Managed Servers and run the command again.Stop the Oracle Admin Server and the Managed Server and stop the Node Agent.
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.
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
Restart the production server.
Run the updateConfig command in the production (target) environment a second time. Use this command:
Oam.updateConfig('<ZipLocation>')
where:
ZipLocation is the path to the directory where the previously copied archive is located
Do the following:
Stop and start the Deployment Manager.
Synchronize the node.
Start the node agent.
Start the Admin and Managed Servers
This section contains information about installing Access Manager in a high-availability WebSphere environment.
The following topics are covered:
Configure the Oracle IAM Components on IBM WebSphere on Node 1
Configure the Oracle IAM Components on IBM WebSphere on Node 2
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)
Installing Access Manager in a high-availability IBM WebSphere environment includes the following high-level tasks.
Table 5-2 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:
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:
If you will also install Oracle Identity Manager, complete the following task:
|
|
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:
If you will also install Oracle Privileged Account Manager, complete the following task:
|
|
4 |
Configure the Oracle Identity and Access Management Components in IBM WebSphere on Node 1 |
Refer to Section 5.7.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.7.4, "Configure the Oracle IAM Components on IBM WebSphere on Node 2." |
|
7 |
Start the servers |
Refer to Section 5.7.5, "Start the Servers." |
|
8 |
Next steps |
Refer to Section 5.7.6, "Next Steps." |
To configure Access Manager in a new IBM WebSphere cell, complete the following steps:
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
If necessary, select Oracle Access Management - 11.1.2.1.0.
On the Select Optional Configuration screen, select the Application Servers, Clusters and End Points option, and click Next.
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.
On the Configure Clusters screen, do the following:
Click Add.
Type a name for the cluster in the Cluster Name field, for example: OAMServerCluster.
Select the appropriate OAM Server (oam_server1a) from the First cluster member list.
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.
Click Add.
In the Name field, type a name for the Oracle Access Management server to be added to OAMServerCluster—for example, oam_server1b.
Click Next and proceed through the remaining screens.
Use the following command to stop the node:
$WAS_HOME/profiles/Custom01/bin/stopNode.sh
Validate that the oam-server-info.properties file is correct:
Go to the following location and open the file in a text editor:
$WAS_HOME/profiles/Dmgr01/config/cells/Cell01/fmwconfig
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, theoracle.oam.runtimeserver property should list the names of the servers in the cluster.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
Configure the Oracle Internet Directory (OID) store for Oracle Platform Security Services (OPSS):
Run the following command to start the Deployment Manager:
$WAS_HOME/profiles/Dmgr01/bin/startManager.sh
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
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.
Stop the Deployment Manager:
$WAS_HOME/profiles/Dmgr01/bin/stopManager.sh
Provide the credentials for the WebSphere cell.
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
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.
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
Run the Oracle Fusion Middleware Configuration Wizard to federate the machine and configure its cell:
$IDM_HOME/common/bin/was_config.sh
On the Select Configuration Option screen, select the Federate Machine and Configure Cell option.
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.
On the Specify Deployment Manager Information screen, enter information about the existing Deployment Manager System.
On the Select Optional Configuration screen, select the Application Servers, Clusters and End Points option and click Next.
Proceed through the wizard and accept the default options until you reach the Configure Additional Cluster Members screen.
Complete the Configure Additional Cluster Members screen as follows:
Click Add.
In the Name box, type a name for the second server in the OAMServerCluster—for example, oam_server2.
In the Node name list, choose the node agent for oam_server2—for example, WebSphereNode2.
In the Cluster name list, choose the OAMServerCluster.
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.
Stop the node on the WebSphere Node 2 machine:
$WAS_HOME/profiles/Custom02/bin/stopNode.sh
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 --
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
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
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.
This section describes issues specific to managing OAM-Federation on IBM WebSphere. It contains this topic:
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.
You need to import the Yahoo/Google SSL certificates into the IBM JSSE Trusted keystore.
First obtain the SSL certificates.
Using the Firefox browser, go to the https URL that is being accessed.
After viewing the page, right click on the page, then view page info, then details, then view certificate, then details tab.
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.