Oracle Adaptive Access Manager is Oracle Identity Management's solution for web access real-time fraud detection and multi-factor online authentication security for the enterprise.
This chapter contains information about managing and integrating Oracle Adaptive Access Manager on IBM WebSphere and explains the particularities of some features on that platform. Only topics that apply specifically to IBM WebSphere are included in this chapter; those that apply to the Oracle WebLogic Server are not described here, but can be found in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager, Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager, and Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite.
This chapter contains the following sections:
Installing and Configuring Oracle Adaptive Access Manager on IBM WebSphere
Integrating OAAM and Java Message Service Queue for Asynchronous Execution
Prior to configuring Oracle Adaptive Access Manager, you must have installed all the required components, including any dependencies, and configured the environment in preparation of the configuration tasks that follow.
Table 8-1 Installing and Configuring Oracle Adaptive Access Manager
| No. | Task | Information |
|---|---|---|
|
1 |
Obtain the following software:
|
For information on obtaining the required software, refer to Task 2: Obtain the Necessary Software Media or Downloads. |
|
2 |
Create or update OAAM schema in a database using the Repository Creation Utility (RCU). |
For information on creating schemas, see Task 3: Identify a Database and Install the Required Database Schemas. |
|
3 |
Install the IBM WebSphere software. |
For information on installing IBM WebSphere software, see Task 4: Install the IBM WebSphere Software. |
|
4 |
Install Oracle Identity and Access Management Suite. |
For instructions on installing Oracle Identity and Access Management on IBM WebSphere, see Chapter 2, "Installing and Configuring Oracle Identity and Access Management on IBM WebSphere" and Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management. |
|
5 |
Configure the Oracle Fusion Middleware components in a new IBM WebSphere cell. |
A cell is a group of nodes in a single administrative domain that encompasses the entire management domain. Section 2.9.1, "General Information About Using the Configuration Wizard on IBM WebSphere" describes how to use the Configuration Wizard to configure your Oracle Fusion Middleware products in a simple IBM WebSphere cell. For complete information about using the Oracle Fusion Middleware Configuration Wizard, including information about adding servers and clusters to a cell, refer to the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server. |
|
6 |
Perform Policy Re-association Changes |
For information on performing re-association changes, see Task 10: Configure the Database Security Store. |
|
7 |
Start the servers. |
For information on starting the servers, see Starting the Servers. |
After you finished configuring the Oracle Fusion Middleware software successfully, you can start the IBM WebSphere deployment manager, node, and servers. There are two methods for starting and stopping the servers: in your IBM WebSphere cell with profile scripts or with Oracle Enterprise Manager Fusion Middleware Control. The following procedures show how to run the profile scripts and the sequence you must use to start the deployment manager, the node, and the servers in the cell. For more information about starting IBM WebSphere Servers, see Section 2.12, "Task 12: Start the IBM WebSphere Servers."
To start the deployment manager, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) WAS_HOME/profiles/deployment_mgr_profile_name/bin/startManager.sh
For example:
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/startManager.sh
WAS_HOME is the path to the AppServer directory where IBM WebSphere is installed.
A node is an administrative grouping of application servers for configuration and operational management within one operating system instance. To synchronize nodes, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) WAS_HOME/profiles/profile_name/bin/syncNode.sh DMGR_HOST DMGR_SOAP_PORT -username admin_user -password admin_password
To start the node on a UNIX operating system, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) WAS_HOME/profiles/profile_name/bin/startNode.sh
For example:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startNode.sh
To start the OracleAdminServer, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) WAS_HOME/profiles/profile_name/bin/startServer.sh OracleAdminServer
For example:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
OracleAdminServer
After you start the Oracle Admin Server, you can start the other servers using the IBM WebSphere Administrative Console or Oracle Enterprise Manager Fusion Middleware Control if you want. This server must be started to use Oracle Enterprise Manager, because the Oracle Enterprise Manager application is hosted in OracleAdminServer. For more information, see Section 3.1, "Summary of the Oracle Fusion Middleware Management Tools on IBM WebSphere".
To start the OAAM Administration Server, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) OAAM_PROFILE/bin/startServer.sh oaam_admin_server1
The default server name for the OAAM Administration Server is oaam_admin_server1. For example:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
oaam_admin_server1
OAAM_PROFILE is the IBM WebSphere profile where the OAAM Administration Server is installed. For example:
WAS_HOME/profiles/profile_name
To start the OAAM Server, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) OAAM_PROFILE/bin/startServer.sh oaam_server_server1
The default server name for the OAAM runtime server is oaam_server_server1.
For example, enter the following command to start the OAAM runtime server:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
oaam_server_server1
OAAM_Profile is the IBM WebSphere profile where OAAM Server is installed. For example:
WAS_HOME/profiles/profile_name
You can use profile scripts or Oracle Enterprise Manager Fusion Middleware Control to stop the servers in a cell you configured for Oracle Fusion Middleware.
You can also stop IBM WebSphere servers from Fusion Middleware Control. For example:
Log in to Fusion Middleware Control.
To locate the port number and URL for Fusion Middleware Control, see Section 3.1.2.2, "Locating the Port Number and URL for Fusion Middleware Control."
Navigate to the Server home page.
For more information, see Section 3.1.2.5, "Viewing an IBM WebSphere Server from Fusion Middleware Control".
From the WebSphere Application Server menu, select Control, and then select Shut down.
Fusion Middleware Control displays a confirmation dialog box.
Click Shutdown.
Note:
Fusion Middleware Control is deployed to the OracleAdminServer. As a result, if you stop the OracleAdminServer, then Fusion Middleware Control will be stopped, and you must use the profile scripts to start the servers.You can also stop IBM WebSphere servers with profile scripts. To stop the IBM WebSphere servers, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) OAAM_PROFILE/bin/stopServer.sh server_name -username username -password password
To stop the OracleAdminServer, navigate to the following directory in the IBM WebSphere home, and enter the command:
(UNIX) WAS_HOME/profiles/profile_name/bin/stopServer.sh OracleAdminServer
For example:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/stopServer.sh
OracleAdminServer
To stop the node, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) WAS_HOME/profiles/profile_name/bin/stopNode.sh -username admin_user -password admin_password
For example:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/stopNode.sh -username admin_user -password admin_password
To stop the deployment manager, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) WAS_HOME/profiles/deployment_mgr_profile_name/bin/stopManager.sh -username admin_user -password admin_password
For example:
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/stopManager.sh -username admin_user -password admin_password
By default OAAM does not provide a user that has the privileges to log in to the OAAM Administration Console. You must create a user and then grant the necessary groups to the user. Users and groups should be defined in the LDAP directory configured for the IBM WebSphere cell. For details on creating user and groups in IBM WebSphere, see the IBM WebSphere documentation. Table 8-2 lists the default roles shipped with Oracle Adaptive Access Manager.
| Role Name | Roles | Descriptions |
|---|---|---|
|
OAAMCSRGroup |
CSRGroup role |
Support Personnel |
|
OAAMCSRManagerGroup |
CSRManagerGroup role |
Support Personnel |
|
OAAMInvestigatorGroup |
Investigator role |
Investigators |
|
OAAMInvestigationManagerGroup |
InvestigationManager role |
Investigators |
|
OAAMRuleAdministratorGroup |
RuleAdministratorsGroup role |
Security Administrators |
|
OAAMEnvAdminGroup |
EnvAdminGroup role |
System Administrators |
The OAAM Command-Line Interface (CLI) scripts enable users to perform various tasks instead of using the OAAM Administration Console. Setting up the CLI environment involves the following tasks:
Set up the CLI work directory
Configure oaam_cli.properties for CLI script startup (optional).
Set environment variables.
Set up the Credential Store Framework (CSF) configuration
Set up the OAAM database credentials
Copy the CLI directory to a working directory:
cp -r ORACLE_MW_HOME/IDM_HOME/oaam/cli /home/user/IBM/oaam.cli
Note:
After you installed the Oracle Identity and Access Management suite, an Oracle Home directory for Oracle Identity and Access Management, such asOracle_IDM1, was created under your Middleware Home.The CLI scripts need the locations of the Middleware Home, IBM WebSphere installation, and IDM home on startup. You can specify these locations in oaam_cli.properties, set environment variables, or enter this information at the command line when prompted. If you want to set the locations in the oaam_cli.properties file, see Table 8-3.
Table 8-3 Setting Properties in oaam_cli.properties
| Property | Environment Variable | Definition |
|---|---|---|
|
oaam.adminserver.mw.home |
|
Location of your Middleware Home. |
|
oaam.server.was.home |
|
IBM WebSphere only. Location of your IBM WebSphere installation. |
|
oaam.server.idm.home |
|
IBM WebSphere only. Location of IDM home within |
To set the Java Home and Middleware Home environment variables, follow these steps:
Set JAVA_HOME to the JDK in IBM WebSphere (WAS_HOME/java)
set JAVA_HOME=DISK/IBM/WebSphere/Application-Server/java
Set ORACLE_MW_HOME to the Middleware directory (complete path to the Oracle_Common directory).
You do not have to set the Middleware Home if you specified it in the oaam_cli.properties file.
A credential store is a repository that can hold user name and password combinations, symmetric keys, tickets, or public key certificates. Oracle Platform Security Services includes the Credential Store Framework (CSF), a set of APIs that applications can use to create, read, update, and manage credentials securely. OAAM uses the CSF APIs to access credentials. Credentials are stored in the CSF of the IBM WebSphere Server domain and managed using Oracle Enterprise Manager Fusion Middleware Control.
To be able to access the OAAM encryption keys stored in the CSF, you must configure the OAAM database details with CSF with MBeans. Navigate to the working directory where you copied the cli directory and open the file conf/bharosa_properties/oaam_cli.properties in a text editor and then set the following properties:
| Property Name | Notes about Property Value |
|---|---|
| oaam.csf.useMBeans | true (Keep it as true) |
| oaam.adminserver.hostname | Hostname where IBM WebSphere Administration Server runs. |
| oaam.adminserver.port | Port number of the IBM WebSphere Administration Server's Deployment Manager's ORB_LISTENER_ADDRESS. Usually it is 9100.
Log in to the IBM WebSphere Administrative Console. Navigate to System Administration > Deployment Manager > Configuration > Additional Properties > Ports > ORB_LISTENER_ADDRESS. |
| oaam.was.client.sasPropFile | Absolute path to the sas.client.properties file that is required for IBM WebSphere's remote JMX client:
/home/user/IBM/oaam.cli/sample.sas.client.properties |
| oaam.db.url | Specify a valid JDBC URL of the OAAM database. |
| oaam.adminserver.type | was |
| oaam.db.additional.properties.file | Leave this field blank if there are no additional Oracle TopLink properties.
Otherwise, specify the name of the properties file that has additional Oracle TopLink properties. Make sure the file is in the same directory as the |
| oaam.db.driver | oracle.jdbc.driver.OracleDriver
Change this value only if the OAAM schema is in a non-Oracle database. |
| oaam.db.min.read-connections | 1
Do not change this value unless required. |
| oaam.db.max.read-connections | 25
Do not change this value unless required. |
| oaam.db.min.write-connections | 1
Do not change this value unless required. |
| oaam.db.max.write-connections | 25
Do not change this value unless required. |
OAAM CLI needs to retrieve two symmetric keys (generated automatically the first time the administration server is started) and database credential key (OAAM database schema and password. For example: DEV_OAAM/password) from CSF to connect to the database schema. After successful installation of OAAM, the symmetric keys should already be created, and only OAAM database schema and password credential need to be added to CSF through Fusion Middleware Control.
Steps to verify and add credentials are as follows:
Log in to Fusion Middleware Control with administrator access.
To locate the port number and URL for Fusion Middleware Control, see Section 3.1.2.2, "Locating the Port Number and URL for Fusion Middleware Control."
In the navigator, expand WebSphere Cell, right-click Cell_WebSphere and select Security > Credentials.
Expand the map named oaam. Two keys DESede_db_key_alias and DESede_config_key_alias should already exist.
Click the Create Key button, select oaam as map, provide oaam_db_key as the key name and provide a OAAM database schema user name and password.
Click OK to create the key in CSF.
For information on the credential store, see Oracle Fusion Middleware Application Security Guide.
Once the setup is complete, you can run CLI commands from your CLI working directory. The commands are the same as in the Oracle WebLogic deployment. An example of running a command is shown as follows:
Execute the CLI export command from CLI_DIR:
sh runImportExport.sh -action export -module properties
You are prompted to select Oracle WebLogic or IBM WebSphere.
Select 2 for IBM WebSphere.
You are prompted for the WAS_HOME if it is not set in the oaam_cli.properties file.
Set the WAS_HOME.
For example:
/opt/IBM/WebSphere/AppServer
You are prompted for the IDM_HOME directory if $IDM_HOME is not set. You must the same ORACLE HOME directory that you provided when installing the Oracle Identity and Access Management Suite. For example: Oracle_IDM1. By default, IDM_HOME will be set to Oracle_IDM1. If you specified the IDM_HOME in the oaam_cli.properties file, you will not be prompted for the ORACLE_HOME directory.
In Oracle Fusion Middleware, auditing refers to the process of collecting for review specific information related to administrative, authentication, and run-time events. This section provides information on setting up and enabling audit to use the database audit store for OAAM on IBM WebSphere.
To switch to a database as the permanent store for your audit records, you must first use the Repository Creation Utility (RCU) to create a database schema for audit data. The RCU seeds that database store with the schema required to store audit records in a database.
This section explains how to create the audit schema. After the schema is created, you will:
Create a datasource to point to this schema
Update the domain configuration to switch the audit data store for audit records
Note:
This discussion assumes that the Repository Creation Utility (RCU) and the database are already installed in your environment. For information on using RCU, see the Oracle Fusion Middleware Repository Creation Utility User's Guide.Before you begin, make sure to collect the details on which database to use, along with the DBA credentials to use. You should be able to log in to the database using DEV_IAU or a corresponding user.
Configuring the Schema for the Audit Data Store
To switch to a database as the permanent store for your audit records, make sure you have used the Repository Creation Utility (RCU) to create a database store for audit data.
Navigate to RCU_HOME/bin and execute the RCU utility.
Choose Create at the starting screen. Click Next.
Enter your database details and click Next.
Choose the option to create a new prefix.
Also, select Audit Services from the list of schemas.
Click Next and accept the tablespace creation.
Check for any errors while the schemas are being created.
Start the deployment manager by entering the command:
(UNIX) WAS_HOME/profiles/deployment_mgr_profile_name/bin/startManager.sh
Log in to the IBM WebSphere Administrative Console.
When configuring the data source, you must first create the J2C authentication data entry. The user ID and password required to access the database are specified in a J2C authentication data entry:
Click Security > Global Security > Java Authentication and Authorization Service and select J2C authentication data.
Click New and create the authentication data using the IAU schema user name and password.
For example: DEV_IAU/password.
You can enter any valid string for the J2C authentication alias.
Click OK.
Stop all application servers from Servers > Server types > WebSphere application servers.
Stop the node.
For example:
WAS_HOME/profiles/Custom01/bin/stopNode.sh
Synchronize the node.
For example:
WAS_HOME/profiles/Custom01/bin/syncNode.sh host soap-port
Stop the deployment manager.
For example:
WAS_HOME/profiles/Dmgr01/bin/stopManager.sh
Start the deployment manager.
For example:
WAS_HOME/profiles/Dmgr01/bin/startManager.sh
Start the node.
For example:
WAS_HOME/profiles/Custom01/bin/startNode.sh
As explained in Section 8.2.1, "Creating the Audit Schema Using the Repository Creation Utility", after you create a database schema to store audit records in a database, you must set up IBM WebSphere Server audit data sources that points to that schema. To do so:
Use the IBM WebSphere Administrative Console to create an IBM WebSphere data source for the OAAM database.
Log in to your IBM WebSphere Administrative Console:
http://host:port/ibm/console
In the left-hand panel of the IBM WebSphere Administrative Console, under the Resource section, expand JDBC and click Datasource.
Select the Cell scope and click New.
You will then be prompted to name the data source for display purposes in the IBM WebSphere Administrative Console as well as provide a JNDI name that the data source will be bound to.
Create a data source with JNDI named jdbc/AuditDB for each scope of OracleAdminServer, oaam_admin1, and oaam_server1.
For the audit data source of oaam_admin1, select OAAM_ADMIN_DB as the data provider and in Component-managed authentication alias, select the J2C authentication identity created in Section 8.2.3, "Creating J2C Authentication Data."
For the audit data source of oaam_server1, select OAAM_SERVER_DB as the data provider and in Component-managed authentication alias, select the J2C authentication identity created in Section 8.2.3, "Creating J2C Authentication Data."
For the audit data source of OracleAdminServer, select mds-oaam as the data provider and in Component-managed authentication alias, select the J2C authentication identity created in Section 8.2.3, "Creating J2C Authentication Data."
Synchronize the nodes before testing the connection of the newly created data sources. Follow the steps in Section 8.1.1.2, "Synchronizing Nodes."
Test each connection by selecting the data source and clicking the Test Connection button. Ensure the test connection of all three newly created data sources are successful.
To set up the audit repository, follow these steps:
Start the Oracle Fusion Middleware wsadmin command-line shell from the common/bin directory of the OAAM Oracle home.
Use this command syntax:
(UNIX) IDM_HOME/common/bin/wsadmin.sh -profileName profilename -connType SOAP -user admin_user -password admin_password
For example:
sh $IDM_HOME/common/bin/wsadmin.sh -profileName Dmgr01 -connType SOAP -user wasadmin -password welcome1
Run the wsadmin command to set the audit repository to the database:
wsadmin>Audit.setAuditRepository(switchToDB='true',dataSourceName='jdbc/AuditDB',interval='14')
The value of dataSourceName should be the JNDI name of the data sources that you create in Section 8.2.4, "Create Data Sources for Audit Event."
If successful, the following information is displayed:
Audit Repository Information updated Server has to be restarted
Stop and restart nodes and managers. Start all application servers from Servers > Server types > WebSphere application servers.
From Fusion Middleware Control, you can manage the Oracle Fusion Middleware products that you have installed and configured as part of the IBM WebSphere cell.
The Audit Policy Settings page manages audit events. Each component and its events are organized in a tree structure under the Name column. The tree can be expanded to reveal the details of the events available.
Log in to Fusion Middleware Control.
To locate the port number and URL for Fusion Middleware Control, see Section 3.1.2.2, "Locating the Port Number and URL for Fusion Middleware Control."
In the Fusion Middleware Control Target Navigation Pane, navigate to WebSphere Cell > Cell_WebSphere.
Right click Cell_WebSphere and navigate to Security > Audit Policy Settings. The Audit Policy Settings page appears.
Select an audit level from a drop-down list of pre-configured audit levels. Two predefined levels (Low, Medium) automatically pick up a subset of the audit events for all the components. In most cases, the predefined levels are sufficient.
None - No events are selected for audit.
Low - A small set of events is selected, typically those having the smallest impact on component performance.
Medium - This is a superset of the "Low" set of events. These events may have a higher impact on component performance.
Custom - This level enables you to fine-tune the policy. The table shows the applications running in the domain.
The table consists of these columns:
Name - shows components and applications in the domain.
Enable Audit - shows whether the corresponding event type is being audited. This column is greyed out unless the Custom audit policy is in force.
Filter - shows any filters in effect for the event type.
Enable audit events and click Apply.
To customize the audit policy, use the Custom option from the drop-down. This allows you to select all the events or hand-pick the appropriate subset as desired by checking the relevant boxes under the Enable Audit column. When you choose the Custom level, an optional filter available for success and failure outcomes of each individual event to further control how they are audited
Filters are rule-based expressions that you can define to qualify or filter events for audit. The expressions are based on attributes of the event. For example, a Login type event could specify an initiator as a user filter in which case the event would generate an audit record whenever the specified user logged in.
A pencil icon indicates that a filter is available for the corresponding event.
Click the icon to bring up the Edit Filter dialog.
Click the Select Failures Only button to select only failed events in the policy - for example, a failed authentication. The Enable Audit box is now checked for failed events.
Import/Export - These buttons enable you to save and re-use a policy configuration. At any time while editing the policy, click Export to save the current settings to a file, and Import to load the settings from a saved file.
Optionally, under Users to Always Audit, you can specify a comma-separated list of users to force the audit framework to audit events initiated by these users; auditing occurs regardless of the audit level or filters that have been specified.
If you made any policy changes, click Apply to save the changes.
Click Revert to discard any policy changes and revert to the existing policy.
Stop all relevant application servers, stop node, synchronize node, stop manager, start manager, start node, start application servers/applications.
This section describes how to move OAAM from a test environment to a production environment. You can develop and test policies and rules in a test environment, and then eventually roll out the new policies and rules and, optionally, test data to your production environment.
Moving OAAM components minimizes the amount of work that would otherwise be required to reapply all the customizations and configuration changes made in one environment to another. You can install, configure, customize, and validate OAAM in a test environment. Once the system is stable and performs as desired, you can create the production environment by moving a copy of the components and their configurations from the test environment, instead of redoing all the changes that were incorporated into the test environment. If there is an existing production environment, you can move any modifications of the test environment, such as customizations, to the production environment.
To move Oracle Adaptive Access Manager to a new production environment follow the guidelines below. Manually update the production environment for the items pertaining to your deployment.
A snapshot is a backup of the current system configuration. Use the OAAM CLI, export the OAAM snapshot from the test environment. Examples of exporting a snapshot are shown below:
runImportExport.sh -action export -module snapshot -snapshotname "name of snapshot" -description "snapshot description"
runImportExport.sh -action export -module snapshot -snapshotname "OAAM Snapshot" -description "OAAM snapshot description"
-snapshotname , -description options are optional. If snapshotname is specified then the exported zip file name is the value passed for -snapshotname.zip. If snapshotname is not specified, the CLI creates a unique filename with a name such as snapshot_unique_value.
The exported zip file would also contain one snapshot.properties file that has the following content:
| Property | Description |
|---|---|
| serverIP | IP of server from where CLI is run. |
| user | Operating system user name. |
| name | Name of snapshot, if specified by -snapshotname; if not specified, it is a system-generated unique name. |
| description | Description of snapshot, if specified by -description; if not specified, it is a system generated unique name. |
| serverName | Hostname from where CLI is run. |
If you are moving some configurations to the production environment and do not need to export the entire snapshot, use the OAAM Administration Console to export the configurations of individual components to a zip file. For information, see the specific chapters in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager for information on exporting.
Table 8-4 lists the OAAM configurations you can export individually.
Table 8-4 Individual Configurations Export
Before you import the snapshot into a production system, you should be aware that you are about to replace the entire system configuration in the production system. You should create a snapshot of the current production environment before the import since you do not want to lose the current configuration if the import fails or if there are other issues that you had not anticipated. After you have imported the snapshot, you cannot undo the import, but if there is a backup available, you can restore the original configuration into your system immediately should the import fail.
When you create a snapshot, all the configurations for the functional areas are selected, both active and disabled. For example, if there are ten policies within the policy set, and five are active and five are disabled, all policies, their configuration, and status information are included when the snapshot is created.
The status of the items are preserved on backup and restore. For example: disabled items remain disabled when you perform a backup and restore.
You cannot selectively select individual items to include in a snapshot or perform selective restoration. If you only want to include certain configurations in your snapshot, you can export them from their module, and import them back and then create the snapshot.
For snapshots, the metadata is stored with the following items:
| Artifact | Comments | Additional Notes |
|---|---|---|
| Policy sets | Policy set overrides | No additional notes. |
| Policies | All policies | Trigger combinations are included. |
| Rule instances | All rule instances | No additional notes. |
| Conditions | All rule conditions | No additional notes. |
| Groups | Group definitions for all groups whether linked or not | Only group members for alerts and actions are exported. |
| Patterns | All patterns | No additional notes. |
| Transaction definitions | All transaction definitions | No additional notes. |
| Entities | All entities whether linked or not | No additional notes. |
| Properties | Only the ones in the database | No additional notes. |
| Enums | Only the ones in the database | No additional notes. |
| Configurable actions | No additional notes. | |
| Challenge questions | Includes validations, categories, and configurations (Answer Logic and others) | No additional notes. |
Back up the configuration data in the database or file. For file, perform an export using CLI or the Universal Risk Snapshot feature.
Snapshots do not include the members of any groups with the exception of actions and alerts. However the groups themselves are included in the snapshot. To back up group members, you must perform an export of groups that is separate from export of the snapshot. These group members must be imported using the Group user interface if needed
To export the groups, see "Exporting a Group" in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Instructions to import a snapshot are provided below.
To import a snapshot for use in the system using the Universal Risk Snapshot feature, follow the instructions below:
Open System Snapshot under Environment in the Navigation tree.
The System Snapshots Search page is displayed.
Click the Load from File button.
A Load and Restore Snapshot dialog appears. You are given the opportunity to back up your current system since importing a snapshot overwrites what is in the current system.
If you want to keep a backup of your current system, select the Back up the current system now box, enter the name and notes for the backup, and click Continue.
When the Load and Restore Snapshot dialog appears with a message that the current system has been successfully stored in the database, click OK.
Then, the Load and Restore Snapshot page appears for you to choose a snapshot to load into the server so you can run the basic authentication flows.
If you are sure you do not want to back up your current configuration or you are importing the snapshot into an empty system, you can leave the dialog blank and click Continue.
Since you did not choose to back up your system, you are given a warning that you are loading a new snapshot and the details of the metadata may be overwritten. If you decide to take a backup, you can click the Back button to take you to the previous page where you can provide details for a backup. If you want to proceed with the import, click Continue.
The Load and Restore Snapshot page appears for you to choose a snapshot to load into the server so you can run the basic authentication flows.
Now that you are ready to load the snapshot, click the Browse button on the dialog in which you can enter the filename of the snapshot you want to load. A screen appears for you to navigate to the directory where the snapshot file is located. Click Open. Then, click the Load button to load the snapshot into the system.
If you are loading the snapshot out of the box for the first time, the snapshot file, oaam_base_snapshot.zip is located in the Oracle_IDM1/oaam/init directory where the OAAM base content is shipped.
Click OK.
Once the snapshot has been loaded, a summary of the snapshot is displayed.
The Preview tab is available, in which you are given the option to do the following:
View the conditions, rules, policies, and so on, in the snapshot.
View the actions that are taken on the objects. For example, if you are loading a snapshot with configurable actions and there are no configurable actions in the system, the system disables the configurable actions.
Filter the objects to see only the updates, or only the changes, or only the additions, and so on.
In general, you want to see all that changes in your system when you load the snapshot because it has the potential to invalidate all the content in your system or overwrite your existing metadata.
The Update button is available so that you can update or change to another snapshot to view what the changes would be as compared to existing system snapshot.
The items in the snapshot are not effective yet. Unless you click the Restore button, the items in the snapshot have not been applied.
To apply the snapshot, click Restore.
Once you applied the snapshot, make sure it appears in the System Snapshots page. Perform a search to view all snapshots that loaded into the database. Click any snapshot to view it and click Restore to apply changes. You can use this feature to back up the system periodically and it will be stored in the memory of the database or a file or in both.
Because snapshot imports only copies of action and alert group types, you must import the group members into the production environment. To import the groups into the production environment, see "Importing a Group" in Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
When the configurable actions are included with a snapshot, you must copy the Java classes to the specified directory after the snapshot creation so that the configurable actions are not broken when they are brought back into a system.
Shared libraries are files used by multiple applications. The deployed applications use shared library files, so you must define shared libraries for the library files and associate the libraries with specific applications.
Copy the following files and configure a custom shared library based on the instructions in this section:
Any items customized in the OAAM server, such as headers, footers, cascading style sheets (CSS), and JavaScript
Virtual Authentication Device (VAD) images, which are in a custom jar
Properties files, resource bundles, and end-user JSP screens
To make library files available to multiple applications, create a shared library by following these steps:
Log in to the IBM WebSphere Administrative Console.
In the console navigation tree, expand Environment and then select Shared libraries.
In the Shared Libraries page, select Show scope selection drop-down list with the all scopes option, and then, select a shared library scope.
Above the table, under Preferences, click the New button to create a new shared library in the scope as selected in step 3.
In the Name field in the settings page of a shared library, specify a name for the shared library.
In the Classpath text box, specify the absolute paths of all the JAR files present in the following directory:
MW_HOME/Oracle_IDM1/oaam/oaam_libs/directory_name.
These are the paths that the product searches for classes and resources of the shared library.
Note:
Each entry should be in a new line, do not use any path separator like ";" or ":".Click OK and then Save.
To add the Shared Library reference to the application:
Log in to the IBM WebSphere Administrative Console.
In the console navigation tree, expand Applications, and then Application Types and click WebSphere enterprise applications to open the list of applications.
In the Enterprise Applications page, click the application that needs to refer to the shared library.
Under Configurations, click Shared library references.
In the Shared Library Mapping for Modules section, select the checkbox next to the application, and then click the Reference Shared Libraries button above the table.
Select the shared library from the Available list and move it to the Selected list.
Click OK and then Save.
Repeat steps 2 to 7.
Stop all application servers that reference the shared library.
Stop the node.
Synchronize the node.
Stop the deployment manager.
Start the deployment manager.
Start the node.
Start the application servers/applications that reference the shared library.
Manually re-create the KBA logic, OTP logic, and policy set overrides using the OAAM Administration Console. For details on recreating these, see the Oracle Fusion Middleware Administrator's Guide for Oracle Adaptive Access Manager.
Validate that the move was successful:
Log in to OAAM Administration Console.
http://oaam_managed_server_host:oaam_admin_managed_server_port/oaam_admin
Navigate to Policies module and check that the rules and groups from the test environment exist in the production environment.
Navigate to the KBA module and check that the challenge questions in the test environment exist in the production environment.
Test the Web applications that were configured for Oracle Adaptive Access Manager. The user should be redirected to registration and challenge flow.
The integration of Juniper Networks Secure Access (SA) and Oracle Adaptive Access Manager provides enterprises with a remote access control solution with strong multi-factor authentication and advanced real time fraud prevention capabilities to enable secure access to an enterprise's applications.
To integrate Oracle Adaptive Access Manager and Juniper Networks Secure Access (SA) to use Oracle Adaptive Access Manager's Authentication and Forgot Password flows, refer to procedures in this section.
Table 8-5 lists a summary of the high-level tasks for integrating Oracle Adaptive Access Manager and Juniper SA.
Table 8-5 Juniper and OAAM Integration Flow
| No. | Task | Information |
|---|---|---|
|
1 |
Review prerequisites. |
For information, refer to Juniper Integration for OAAM on IBM WebSphere Prerequisite. |
|
2 |
Configure the authentication provider. |
For information, refer to Configuring the Authentication Provider. |
|
3 |
Configure Oracle Platform Security Services for authentication. |
For information, refer to Configuring Oracle Platform Security Services (OPSS) for Integration. |
|
4 |
Synchronize node and restart servers.
|
For information, refer to Synchronizing the Node and Restarting the Servers. |
|
5 |
Import server properties. |
For information, refer to Importing the SAML Configuration-Related Server Properties Using the OAAM Administration Console. |
|
6 |
Set up Certificate of Trust. |
For information, refer to Setting Up Certificate for Signing the Assertion. |
|
7 |
Modify integration properties. |
For information, refer to Modifying Integration Properties Using the OAAM Administration Console. |
|
8 |
Configure Juniper Networks Secure Access (SA) |
For information, refer to Configuring Juniper Networks Secure Access (SA). |
For this integration procedure, you must obtain the following software:
IBM WebSphere 7.0 and any required Fix Packs for the IBM WebSphere software
To obtain and install the IBM WebSphere software, refer to the IBM WebSphere documentation. For more information, see Section 1.4, "Documentation Resources for Using Oracle Identity and Access Management Suite Products on IBM WebSphere".
Juniper configured per the Juniper documentation
For more information on Juniper SA configuration, see the Juniper Networks Secure Access Administration Guide available at
Oracle Adaptive Access Manager configured per Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management and Chapter 2, "Installing and Configuring Oracle Identity and Access Management on IBM WebSphere."
In the IBM WebSphere Application Server, a user registry or repository authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization. The information about users and groups reside within a registry or repository. The IBM WebSphere Application Server makes access control decisions using the user registry or repository.
For information on switching from the IBM WebSphere user registry to use an LDAP user registry, see the IBM WebSphere documentation.
To configure the default identity store in the IBM WebSphere Application Server to point to LDAP, proceed as follows:
Prepare LDAP properties file with details of LDAP.
For information on setting the required properties, see Section 9.1, "IBM WebSphere Identity Stores."
Navigate to the following directory:
MW_HOME/oracle_common/common/bin
Set JAVA_HOME to the IBM JDK (bundled with IBM WebSphere):
For example (for csh):
setenv JAVA_HOME /opt/IBM/WebSphere/AppServer/java
Run the WSADMIN command to configure the identity store on IBM WebSphere.
Invoke the WSADMIN shell by running the wsadmin.sh command:
./wsadmin.sh -port SOAP_PORT -user wasadmin_user -password password -conntype SOAP
For example:
./wsadmin.sh -port port -user wasadmin -password pass -conntype SOAP
You must use the same credentials that you provided while setting up the WAS cell.
Run the following WSADMIN command from the wsadmin prompt:
Opss.configureIdentityStore(propsFileLoc="/tmp/oud.properties") - oud.properties
propsFileLoc specifies the location of the file that contains the property settings for the identity LDAP identity store. This command modifies the configuration file jps-config.xml to include the specifications in the property file.
The OPSS.configIdentityStore() command changes the default identity store in the IBM WebSphere Application Server to point to LDAP; therefore, to access the OAAM Administration Console, you must create the OAAM roles in LDAP and assign them to required users.
Once the OPSS.configIdentityStore() command is run you should see following entry in the jps.config.xml file. The entries may vary from the type of LDAP used and the content of properties file specified to the OPSS.configIdentityStore() command.
<serviceInstance name="idstore.ldap.0" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=oaam,dc=us,dc=oracle,dc=com"/>
<property name="bootstrap.security.principal.key" value="bootstrap_idstore"/>
<property name="idstore.type" value="OPEN_LDAP"/>
<property name="ldap.url" value="ldap://example.host:1389"/>
<property name="username.attr" value="uid"/>
<property name="bootstrap.security.principal.map" value="BOOTSTRAP_JPS"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>ou=users,dc=oaam,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>ou=groups,dc=oaam,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>user.object.classes</name>
<values>
<value>person</value>
</values>
</extendedProperty>
</serviceInstance>
</serviceInstances>
Oracle Platform Security Services (OPSS) provides enterprise product development teams, systems integrators (SIs), and independent software vendors (ISVs) with a standards-based, portable, integrated, enterprise-grade security framework for Java Standard Edition (Java SE) and Java Enterprise Edition (Java EE) applications. For information on OPSS, see Oracle Fusion Middleware Application Security Guide.
On the machine where OAAM is installed, navigate to the was_profile_dir/config/cells/cell_name/fmwconfig directory.
For example:
/scratch/xyz/IBM/WebSphere/AppServer/profiles/Dmgr04/config/cells/abc1234567Cell02/fmwconfig
Back up jps-config.xml.
Open the jps-config.xml.
Before closing tag </jpsContexts> add the following jps context:
<!-- This context is used for OAAM Juniper Integration --> <jpsContext name="idcontext"> <serviceInstanceRef ref="user.authentication.loginmodule"/> <serviceInstanceRef ref="idstore.ldap"/> <serviceInstanceRef ref="credstore"/> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="policystore.xml"/> <serviceInstanceRef ref="audit"/> </jpsContext>
Change idstore.ldap value to the server instance of the ID store that was created after running the OPSS script in Section 8.4.3, "Configuring the Authentication Provider."
For example, change idstore.ldap to idstore.ldap.0.
Save the file and exit.
Note:
Once you save the file, you might want to use an XML editor to check that all the tags are correct. You can also open the file in Internet Explorer to see whether there are any tags missing. If your changes are correct you will be able to open the file successfully in Internet Explorer.Stop and start the IBM WebSphere Administration Server, OAAM Admin Server and OAAM Managed Server, since these changes requires a restart.
While stopping the node and deployment manager and synchronizing the node, use the IBM WebSphere administrator credentials.
In the example, WAS_HOME is /opt/IBM/WebSphere/AppServer.
Stop the node.
For example:
WAS_HOME/profiles/Custom01/bin/stopNode.sh -user admin_user -password admin_password
Stop the deployment manager.
For example:
WAS_HOME/profiles/Dmgr01/bin/stopManager.sh -user admin_user -password admin_password
Start the deployment manager.
For example:
WAS_HOME/profiles/Dmgr01/bin/startManager.sh
Synchronize the node.
For example:
WAS_HOME/profiles/Custom01/bin/syncNode.sh localhost 8879 -user admin_user -password admin_password
Start the node.
For example:
WAS_HOME/profiles/Custom01/bin/startNode.sh
Restart the OAAM servers.
For example:
WAS_HOME/profiles/Custom01/bin/startServer.sh oaam_admin_server
WAS_HOME/profiles/Custom01/bin/startServer.sh oaam_server_server
Note:
After restarting the servers, to login to IBM WebSphere Administrative Console, use the User ID and password as provided in the properties file that was given input toopss.configIdentityStore() command.Import the SAML configuration-related properties so they are added in the OAAM database.
To import the SAML configuration-related properties, proceed as follows:
Log in to the OAAM Administration Console as a administrator with the EnvAdminGroup role. For example:
http://oaam_managed_server_host:oaam_admin_managed_server_port/oaam_admin
In the Navigation pane, click Properties under the Environment node.
Click Import Properties in the Properties page to import server properties for the integration
Browse for saml_properties.zip in the IDM_ORACLE_HOME/oaam/init directory, and click Open, and then, click Import.
Once the import is complete it will show you the properties successfully imported.
Click Done to complete the import.
This step imports the properties needed for the integration. Modify these properties according to your environment in Section 8.4.8, "Modifying Integration Properties Using the OAAM Administration Console."
A certificate authority (CA) is a trusted third-party that certifies the identity of third-parties and other entities, such as users, databases, administrators, clients, and servers. The certificate authority verifies the party identity and grants a certificate, signing it with its private key.
To set up the certificate of trust between Juniper SA and OAAM, follow the procedures contained in these sections:
The first step is to create a private key for the certificate. To create this private key, proceed as follows:
Change the working directory to the security properties directory:
WAS_HOME/java/jre/lib/security
where WAS_HOME points to the AppServer directory:
WAS_HOME=/opt/IBM/WebSphere/AppServer
Create the private key using a key and certificate management utility, called keytool. Enter the following command with cacerts as the keystore:
WAS_HOME/java/jre/bin/keytool -genkey -keyalg rsa -validity 1825 -keysize 2048 -alias OAAMCert -keystore cacerts -storepass changeit
Enter the details for the certificate.
An example of the output is shown as follows:
What is your first and last name? [Unknown]: ag-oracle-oaam What is the name of your organizational unit? [Unknown]: Juniper What is the name of your organization? [Unknown]: Juniper What is the name of your City or Locality? [Unknown]: Sunnyvale What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=ag-oracle-oaam, OU=Juniper, O=Juniper, L=Sunnyvale, ST=CA, C=US correct? [no]: yes
Note:
Typically theCN of the certificate is the name of the machine.When prompted, enter the keystore password:
Enter key password for <OAAMCert>
(RETURN if same as keystore password):
Re-enter new password:
Remember this password as it is needed later for the integration.
After you create the private key and self-signed certificate, use the keytool command to generate a Certificate Signing Request (CSR):
Change the working directory to the security properties directory:
WAS_HOME/java/jre/lib/security
where WAS_HOME points to the AppServer directory:
WAS_HOME=/opt/IBM/WebSphere/AppServer
Run this command to create the certificate request:
WAS_HOME/java/jre/bin/keytool -certreq -alias OAAMCert -file server.csr -keystore cacerts -storepass changeit
In this example you created a certificate request in a file called server.csr.
The file is located in the WAS_HOME/java/jre/lib/security directory.
Copy the server.csr file into the /etc/pki_jungle/myCA directory.
cp WAS_HOME/java/jre/lib/security/server.csr /etc/pki_jungle/myCA/
Submit the Certificate Signing Request (CSR) to a certificate authority to obtain a digital certificate. The certificate authority will issue the certificate. You must receive the issued certificate and the root CA Certificate which signed the request.
For testing, you can act as your own certificate authority to sign the certificates. For production scenarios, a certificate from a certificate authority has to be used.
For production scenarios, you can skip Section 8.4.7.4, "Acting as Your Own Certificate Authority" and go to Section 8.4.7.5, "Importing the Certificate into Your Keystore" to import the certificate from an external certificate authority.
For testing purposes, you can act as your own certificate authority to self-sign the certificates. The following sets of instructions walk through setting up to self-sign the certificates. To set this up, proceed with the subsequent example.
The package OpenSSL must be installed in the machine you will use to manage your certificates or create the certificate requests. OpenSSL is an open source implementation of the Secure Sockets Layer (SSL) protocol. OpenSSL implements basic cryptographic functions and provides utility functions.
To create the necessary directories, proceed as follows:
Create a directory where all certificate files will be kept. The default directory is /etc/pki/tls/. As root, issue the following command to create your own directories:
# mkdir -m 0755 /etc/pki_jungle
Then, create the certificate authority's directory by issuing the commands:
# mkdir -m 0755 \ /etc/pki_jungle/myCA \ /etc/pki_jungle/myCA/private \ /etc/pki_jungle/myCA/certs \ /etc/pki_jungle/myCA/newcerts \ /etc/pki_jungle/myCA/crl
where
myCA is your certificate authority's directory
myCA/private is the directory where your private keys are placed. Be sure that you set restrictive permissions to all your private keys so that they can be read only by root, or the user with whose privileges a server runs. The consequences of a certificate authority private key being stolen would be catastrophic.
myCA/certs directory is where your server certificates will be placed
myCA/newcerts directory is where OpenSSL puts the created certificates in PEM (unencrypted) format and in the form cert_serial_number.pem (e.g., 07.pem). OpenSSL needs this directory, so you must create it
myCA/crl is where your certificate revocation list is placed
To copy the default OpenSSL configuration file (openssl.cnf) from /etc/pki/tls to your certificate authority's directory and name it openssl.my.cnf, issue the following command as root:
# cp /etc/pki/tls/openssl.cnf /etc/pki_jungle/myCA/openssl.my.cnf
Since this file does not need to be world readable, you can change its attributes by issuing the command:
# chmod 0600 /etc/pki_jungle/myCA/openssl.my.cnf
Create the file that serves as a database for OpenSSL, by issuing the command:
# touch /etc/pki_jungle/myCA/index.txt
Create the file which contains the next certificate's serial number, by issuing the command:
# echo '01' > /etc/pki_jungle/myCA/serial
Since certificates have not been created yet, set it to "01":
After completing the initial configuration, you can now generate a self-signed certificate that will be used as your certificate authority's certificate to sign other certificate requests and a private key.
Change to your certificate authority's directory.
As root, issue the OpenSSL command:
# cd /etc/pki_jungle/myCA/
This is where you should issue all OpenSSL commands since it is the location of your OpenSSL's configuration file (openssl.my.cnf).
Then, create your certificate authority's certificate and private key. As root, issue the following command:
# openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825
This creates a self-signed certificate with the default CA extensions which are valid for five years.
When prompted for a passphrase for your certificate authority's private key, set a strong passphrase.
When prompted, provide information that will be incorporated into your certificate request. Information for the certificate authority is similar to the example that is shown:
Country Name (2 letter code) [GB]:GR State or Province Name (full name) [Berkshire]:Greece Locality Name (eg, city) [Newbury]:Thessaloniki Organization Name (eg, company) [My Company Ltd]:My Network Organizational Unit Name (eg, section) []:My Certificate Authority Common Name (eg, your name or your server's hostname) []:server.example.com Email Address []:whatever@server.example.com
Two files are created:
certs/myca.crt: This is your certificate authority's certificate and can be publicly available and world readable.
private/myca.key: This is your certificate authority's private key. Although it is protected with a passphrase, you should restrict access to it so that only root can read it.
Although your certificate authority's private key is protected with a passphrase, you should restrict access to it so that only root can read it. To do so, issue the following command:
# chmod 0400 /etc/pki_jungle/myCA/private/myca.key
Modifications to/etc/pki_jungle/myCA/openssl.my.cnf are necessary because you use a custom directory for your certificates' management.
Open openssl.my.cnf in a text editor as root and find the following section (around line 35):
_________________________________________________________
[ CA_default ]
dir = ../../CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several certificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
#crlnumber = $dir/crlnumber # the current crl number must be
# commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
Modify the path values to conform to your custom directory and your custom certificate authority key (private key) and certificate and save your changes:
__________________________________________________________ [ CA_default ] dir = . # <--CHANGE THIS certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt #unique_subject = no new_certs_dir = $dir/newcerts certificate = $dir/certs/myca.crt # <--CHANGE THIS serial = $dir/serial #crlnumber = $dir/crlnumber crl = $dir/crl.pem private_key = $dir/private/myca.key # <--CHANGE THIS RANDFILE = $dir/private/.rand x509_extensions = usr_cert _____________________________________________________________
Now you will sign the certificate request and generate the server's certificate. To do so, proceed as follows:
First, copy the server.csr (created in Section 8.4.7.2, "Creating a Certificate Request") to your certificate authority's directory by issuing the following command:
# cp WAS_HOME/java/jre/lib/security/server.csr /etc/pki_jungle/myCA/
Change to your certificate authority's directory by issuing the following command:
# cd /etc/pki_jungle/myCA/
Then, sign the certificate request by issuing the command:
# openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr
Supply the certificate authority's private key to sign the request. You can check the openssl.my.cnf file about what "policy_anything" means. In short, the fields about the Country, State or City are not required to match those of your certificate authority certificate.
After the steps have been completed, two new files are created:
certs/server.crt.
This is the server's certificate, which can be made available publicly.
newcerts/01.pem
This is the same certificate, but with the certificate's serial number as a file name. It is not needed.
Now, delete the certificate request (server.csr) since it is no longer needed.
The SSL VPN must import the public key of this server certificate to decrypt the message sent from OAAM.
You must import the Root CA Certificate followed by the certificate which was issued to you by the certificate authority. The name of the root certificate is myca.crt and the name of the issued certificate is server.crt.
To import a certificate into a keystore, proceed as follows:
Change the working directory to this directory:
WAS_HOME/java/jre/lib/security
where WAS_HOME points to the AppServer directory:
WAS_HOME=/opt/IBM/WebSphere/AppServer
Copy /etc/pki_jungle/myCA/certs/myca.crt and /etc/pki_jungle/myCA/certs/server.crt to the WAS_HOME/java/jre/lib/security directory.
Import the root certificate into your keystore using the following keytool command:
WAS_HOME/java/jre/bin/keytool -importcert -alias rootCA -file myca.crt -keystore cacerts -storepass changeit
In the preceding syntax:
alias represents the alias of the Root CA Certificate.
rootCA -file represents the name of the file that contains the Root CA Certificate.
keystore represents the name of your keystore.
Open server.crt in a text editor and remove everything except for content between the BEGIN CERTIFICATE and END CERTIFICATE tags.
Import the issued certificate into your keystore using the following keytool command:
WAS_HOME/java/jre/bin/keytool -importcert -alias OAAMCert -file server.crt -keystore cacerts -storepass changeit
In the preceding syntax:
alias represents the alias of the certificate, which must be the same as the private key alias assigned in Section 8.4.7.1, "Creating Private Key for Certificate."
server.crt represents the name of the file that contains the certificate.
keystore represents the name of your keystore.
Enter the key password for <OAAMCert>.
The certificate reply was installed in keystore.
Note:
Ensure that the alias is the same as the one you used when creating the request.To define the SAML configuration properties required to establish the integration, proceed as follows:
Log in to the OAAM Administration Console.
http://oaam_managed_server_host:oaam_admin_managed_server_port/oaam_admin
Double-click Properties to open the Properties page.
Now type oracle.saml* in the Name field and click Search to search the integration properties.
In the search results, click the property you must modify.
In the Properties tab, modify the value for the property and click Save.
The properties imported as part of integration that need to be modified are shown in Table 8-6, "SAML Integration Properties".
Table 8-6 SAML Integration Properties
| Property | Description |
|---|---|
|
oracle.saml.integration.version |
The SAML version used for integration Possible values are The default value is Juniper SA also supports SAML2.0. You must decide the version of SAML to use. |
|
oracle.saml.target.default.url |
The target URL (homepage) the user wants to navigate to after successful SAML assertion validation by Juniper SA For example: |
|
oracle.saml.keystore |
The full path of the keystore used for storing the certificate required to sign the assertion. In our case it will be
|
|
oracle.saml.keystore.password |
The password of the keystore |
|
oracle.saml.keystore.certalias |
The alias of the certificate used for assertion |
|
oracle.saml.keystore.privatekeypassword |
The private key password |
|
oracle.saml.redirect.post.url |
The URL where SAML assertion is posted For example: |
|
oracle.saml.set.attributes |
Indicates if additional attributes need to be sent to the Juniper SA as part of the assertion Possible values are The default value is |
|
oracle.saml.user.attributes |
List of attributes required to be appended as part of the assertion The property is only used if |
|
oracle.saml.attribute.namespace |
The name of the namespace used for assertion. The default vale is For SAML1.1 only. |
|
oracle.saml.nameidformat |
The The default value is |
|
oracle.saml.nameidattribute |
The The default value is This must be |
|
oracle.saml.issuer.url |
The URL of the issuer of SAML This is the machine where the OAAM authentication server is running. For example: |
|
oracle.oaam.juniper.intg.jps.context |
Optional Context name to be used default is ( |
To configure Juniper for this integration, you must:
For more information on Juniper SA configuration, see the Juniper Networks Secure Access Administration Guide available at
http://www.juniper.net/techpubs
You must create an Authentication Server in Juniper SA. To do so, proceed as follows:
Log in to your Juniper SSL VPN Administrator Console.
In the Juniper Administration Console in the left pane, expand the Authentication menu, and then click Auth. Servers.
From the New drop-down list, select SAML Server, and then click New Server.
Define the Authentication Server with the values in Table 8-7.
Table 8-7 Create an Authentication Server
| Parameter | Details | Value |
|---|---|---|
|
Server Name |
Name of SAMLServer |
OAAM SAML 1.1 Enter same value as shown. |
|
SAML Version |
SAML version for authentication server |
1.1 Enter same value as shown. |
|
Source Site Inter-Site Transfer Service URL |
The entry URL of OAAM server. This is where the user gets redirected to for authentication. |
Example: @ Specify the host and port according to your environment. |
|
User Name Template |
The template used for extracting the value that identifies the authenticated user |
Enter the same value as shown. You also need to keep ' |
|
Allowed Clock Skew (minutes) |
Allowed clock skew for assertion. |
Enter the same value as shown. |
|
SSO Method |
SSO method used for SAML |
|
|
Response Signing Certificate |
The certificate used for signing the response. |
This is the certificate you obtained from certificate authority. You have imported the same certificate into the Keystore in Section 8.4.7.5, "Importing the Certificate into Your Keystore." |
Import the server certificate (for example, server.crt) created (in Section 8.4.7.4.6, "Signing the Certificate Request").
Click Save Changes to save the changes.
An authentication realm specifies the conditions that users must meet to sign in. A realm consists of a grouping of authentication resources.
To create a user realm for SAML, proceed as follows:
From the Juniper Administration Console, in the left pane, expand the Users menu, point to User Realms, and then click New User Realm.
Specify the name as OAAM SAML 1.1 User Realm.
Select the Authentication Server OAAM SAML 1.1 that was created in the last step as the authentication server for this user realm.
Save the changes.
Now you should see the newly created user realm.
From the Juniper Administration Console, in the left pane, expand the Users menu, point to User Realms, and then click OAAM SAML 1.1 User Realm.
From the OAAM SAML 1.1. User Realm, click the Role Mapping tab to configure one or more role mapping rules.
Create a Sign-In policy which defines the URL on which you need to go on the Juniper SA to get redirected to OAAM for authentication.
To create a sign-in policy, in the Juniper Administration Console, expand the Authentication menu, point to Signing In, and then click Sign-in Policies.
Click New URL and in the Sign-in URL field that is displayed, enter */OAAM11/ for the URL.
For Sign-in Page, select Default Sign-in Page.
For Authentication Realm, select the OAAM SAML 1.1 User Realm that was created earlier. Ensure the User picks from a list of authentication realms radio button is selected.
Click Save Changes and make sure it is enabled.
Once all required components are configured, the next step is to test the Login and Forget Password flows. For information on the Login and Forget Password Flows, see "Authentication and Forgot Password Flows" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager. For steps to verify the integration, see "Verify the Integration" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
To debug the integration on the OAAM end, enable the debug logs. For information on using the log files, see "Debug the Integration" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager. Also see Section 3.1.2.8, "Differences When Using Fusion Middleware Control on IBM WebSphere" for the differences in managing Oracle Fusion Middleware on an IBM WebSphere cell as opposed to an Oracle WebLogic Server Domain.
For information on common problems you might encounter in an Oracle Adaptive Access Manager and Juniper Networks Secure Access (SA) integrated environment, see "Troubleshooting Common Problems" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
For the issue of concerning invalid SAML assertions, you can refer to the Juniper Knowledge Base article at:
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21687&cat=MAG_SERIES&actp=LIST
To synchronize the clock: from the Juniper Administration Console, navigate to System > Status > Overview > System Date and Time Edit.
Also see Section 3.1.2.8, "Differences When Using Fusion Middleware Control on IBM WebSphere" for the differences in managing Oracle Fusion Middleware on an IBM WebSphere cell as opposed to an Oracle WebLogic Server Domain.
Messaging is the exchanging of data between applications and clients of different types. OAAM uses JMS (Java Message Service) queues as one of the integration mechanisms. OAAM listens on one or more JMS queues for XML messages. Integration of Java Message Service Queue (JMSQ) and OAAM enables asynchronous execution to monitor and detect unauthorized access to critical and sensitive data housed in systems and databases.
This section includes the configuration and reference information you need to an asynchronous deployment on the IBM WebSphere Application Server.
This section provides instructions for installing the Asynchronous Integration Option for use with OAAM.
Before you install the Asynchronous Integration option, ensure that the following prerequisites are satisfied:
Ensure that Oracle Adaptive Access Manager 11g is installed and configured. The Asynchronous Integration Option will be installed on top of Oracle Adaptive Access Manager 11g.
Ensure that Oracle Business Intelligence Publisher is installed and configured before proceeding with installation of the report templates. The Asynchronous Integration Option includes various reports as Oracle Business Intelligence Publisher report templates.
The Asynchronous Integration Option does not require an installer. To install Asynchronous Integration Option, you will need an unzip tool to unzip the osg_integration_kit.zip file.
Create the following directories in the machine where Oracle Adaptive Access Manager 11g is installed:
osg_install
osg_install/osg_integration_kit
Extract the contents of the osg_integration_kit.zip file to the osg_install/osg_integration_kit directory
OAAM uses JMS (Java Message Service) queues as one of the integration mechanisms. OAAM listens on one or more JMS queues for XML messages. For additional information XML message formats, see "XML Schema Example for Message Formats" in Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
In an IBM WebSphere deployment, OAAM uses message-driven beans to listen for JMS messages. A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. The definition of message-driven beans is in the osg_ejb_was.jar file. By default, it is configured to look for JMS activation specifications with the JNDI name eis/oaamDefault_Act_Spec and eis/oaamHL7_Act_Spec on IBM WebSphere. OAAM listens for JMS messages sent to JMS queues on IBM WebSphere that are associated with these two JMS activation specifications. Review this configuration and update as necessary for your deployment. This section provides a basic example of configuring JMS resources on IBM WebSphere.
An example configurations for activation of the eis_oaamDefault_Act_Spec specification is as follows:
Log in to the IBM WebSphere Administrative Console, under Service Integration > Buses, create a bus named oaamBus.
In Members of oaamBus, click add and add oaam_server1 as a bus member.
In Destinations of oaamBus, add a new Queue named oaamDefaultDestination.
Navigate to Resources > JMS > Queue connection factories and create a queue connection factory named oaamQueueConnFactory. The provider could be Default Messaging Provider, and the scope should be oaam_server1.
Navigate to Resources > JMS > Queues and select the scope of oaam_server1, create a queue named oaamDefaultQueue, specify jms/oaamDefaultQueue as the JNDI name, and specify Default Messaging Provider as the provider.
Navigate to Resources > JMS > Activation specifications, and create an activation specification named oaamDefaultActSpec with following properties:
Scope: oaam_server1
Provider: Default Messaging Provider
JNDI: eis_oaamDefault_Act_Spec
Destination Type: Queue
Bus name: oaamBus
Target Inbound Transport Chain: InboundBasicMessaging
Provider Endpoints: host:port:BootStrapBasicMessaging (the port here should be the SIB_ENDPOINT_ADDRESS port of oaam_server application server)
This section demonstrates how to create a basic JMS resources required by OAAM. Similar artifacts should be created for activation of the eis/oaamHL7_Act_Spec specification. Follow the IBM documentation on creating JMS Resources for JMS for your specific requirements. IBM documentation for creating JMS resources including JMS Activation Specification, JMS Queue, and JMS Queue Connection Factory on the IBM WebSphere Administrative Console is available at:
Most of the asynchronous integration functionality is implemented as an OAAM extension. Follow these steps to deploy the extension files included in the Asynchronous Integration Option package.
Log in to the IBM WebSphere Administrative Console.
Click Applications > Application Types > WebSphere Enterprise Applications.
Select the check box next to the oaam_server application and click Update.
In Application update options, select the Replace, add, or delete multiple files option and choose osg_oaam_extension_was.zip and add it to the application. This will migrate most of the extension files to the OAAM Server application.
Make sure that JMS resources mentioned in Section 8.5.1.3, "JMS Resources" are configured properly on IBM WebSphere. OAAM is configured to work with IBM WebSphere JMS Activation Specifications with JNDI name eis/oaamDefault_Act_Spec and eis/oaamHL7_Act_Spec. JMS queues, JMS queue connection factories, Service Integration Bus also need to be configured on IBM WebSphere properly with target JMS Activation Specifications as described in Section 8.5.1.3, "JMS Resources."
Similarly, follow Steps 1-3, then in Application update options, select Replace or add a single module option and choose osg_ejb_was.jar and add it to the application. Make sure that oaam_server1 is selected and mapped to this module in the Mapmodule to servers step.
Synchronize the node and restart the OAAM Server application server.
OAAM creates database views for the entities and transactions for use in rule conditions and reports. For details on these database views, see Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
With the JMS listener implementation, Oracle Adaptive Access Manager can be configured to listen to JMS queues (or topics) for messages in XML format. JMS message contents looks similar to the OAAM Web Services API calls. Sample JMS message formats are the following:
VCryptTracker.updateLog
VCryptTracker.createTransaction
VCryptTracker.updateEntity
VCryptRulesEngine.processRules
For an overview of JMS integration in OAAM and for sample XML, see Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
Various aspects of JMS integration can be configured using OAAM properties and user-defined enums.
For a list of the JMS configuration properties used for integration, see the Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager. The following properties do not pertain to the IBM WebSphere deployments:
oracle.oaam.jms.listeners.default.initial.context.factory
oracle.oaam.jms.listeners.default.connection.factory
oracle.oaam.jms.listeners.enum.lsnr_1
oracle.oaam.jms.listeners.enum. lsnr_1.type
oracle.oaam.jms.listeners.enum. lsnr_1.url
oracle.oaam.jms.listeners.enum. lsnr_1.jndiname
oracle.oaam.jms.listeners.enum.lsnr_1.initial.context.factory
oracle.oaam.jms.listeners.enum.lsnr_1.connection.factory
oracle.oaam.jms.listeners.enum. lsnr_1.processor
oracle.oaam.jms.listeners.enum. lsnr_1.instancecount
For each queue (or topic) to be monitored, one listener must be configured by adding an enum element in user-defined enum oracle.oaam.jms.listeners.enum. Any changes to the listener list or properties require the OAAM Server, where the listeners run, to be restarted.
OAAM default JMS message processor processes only the messages of type javax.jms.TextMessage. Other types of messages would be ignored by this processor. To process other type of messages, you can implement a custom processor by extending either oracle.oaam.jms.JmsAbstractMessageProcessor or oracle.oaam.jms.JmsDefaultMessageProcessor; develop a standard Message-Driven Bean class, and associate it with a IBM WebSphere JMS Activation Specification in osg_ejb_was.jar/META-INF/ibm-ejb-jar-bnd.xmi. After adding the reference to the JMS Activation Specification in osg_ejb_was.jar, the jar file needs to be re-deployed to OAAM Server application as described in section Section 8.5.1.4, "Deploy the Asynchronous Integration Extension Files."
Further, the default JMS message processor would processes only if the contexts of the TextMessage is a XML string that conforms to the XML schema given at the end of this section.
You can define entities and transactions in Oracle Adaptive Access Manager with any number of data fields. In addition, transactions can also be defined to reference entities. Oracle Adaptive Access Manager persists the entity and transaction data in the database.
See Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager for the following topics:
Generating SQL script file
Entity view details
Transaction view details
Identifiers
Supported databases
The Asynchronous Integration Option package includes an OAAM condition to execute a given Python expression. The condition can be imported from osg_install/osg_integration_kit/osg_rule_conditions.zip.
OAAM needs the jython.jar library to run Python expressions. The location of jython.jar is at:
ORACLE_MW_HOME/ oracle_common/modules/oracle.jrf_11.1.1/jython.jar
Follow these steps to add jython.jar as a shared library for the OAAM Server application:
Log in to IBM WebSphere Administrative Console.
Click Environment > Shared libraries > New.
Provide the name for this jar and specify the path to jython.jar.
Apply the changes.
Navigate to Applications > Application Types > WebSphere Enterprise Applications > oaam_server_11.1.2.2.0.
In the details of the oaam server application, under the Configuration tab, navigate to the References section, click shared library references, check OAAM_Runtime, and click Reference Shared libraries.
Move the jython library to the selected list and apply the changes.
Synchronize the node and restart the OAAM Server application server.
For a list of the objects (variables) accessible from Python expressions, see Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
For a list of expressions that can be used in the Python Expression condition, see Oracle Fusion Middleware Developer's Guide for Oracle Adaptive Access Manager.
An OAAM sample application is available as a form of documentation to familiarize you with OAAM APIs. It is not intended to be used as production code since it only provides basic elements of API usage. Customers implementing a native integration should develop their own application using the OAAM sample application as a reference. The OAAM sample application and related files can be downloaded from My Oracle Support at https://support.oracle.com.
This section contains instructions to set up the native in-proc-based OAAM sample application.
To set up the native in-proc-based OAAM sample application:
Create an oaam_sample directory.
Extract the oaam_sample_inproc.zip file into the oaam_sample directory.
Open the web.xml file in the oaam_sample/WEB-INF directory with a text editor and add the following lines as the last section above the </web-app> tag:
<resource-ref>
<res-ref-name>jdbc/OAAM_SERVER_DB_DS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<resource-ref>
Navigate to the oaam_sample directory and run the following command to create an OAAM sample WAR file for the IBM WebSphere Administrative Console:
jar cfm ../oaam_sample_inproc_was.war META-INF/MANIFEST.MF .
Running the command generates the oaam_sample_inproc_was.war file which you will install in the IBM WebSphere Administrative Console.
Log in to the IBM WebSphere Administrative Console and in the console navigation tree, expand Applications, and then Application Types and click WebSphere enterprise applications to open the list of applications.
Select the check box next to the oaam_server_11.1.2.2.0 application and click Update.
Select Replace or add a single module and provide a unique path such as oaam_sample and specify the path to the oaam_sample_inproc_was.war file that was created in step 4; then click Next to proceed to the page, Step 2.
Make sure it is applied to oaam_server1. Also make sure jdbc/OAAM_SERVER_DB_DS is selected in the Resource Reference page for the module.
Continue through the rest of the configuration without changing the settings and save the changes.
Move oracle.security.jps.was.deployment.jar in the WAS_HOME/plugins directory and restart the node and deployment manager. Otherwise adding a WAR/JAR file as a module to an application will fail.
In the IBM WebSphere Administrative Console, navigate to Applications > Application Types > WebSphere enterprise applications > oaam_server_11.1.2.2.0 > Context Root for Web Modules and specify oaam_sample for the OAAM sample web module.
Copy the oaam_native_libs directory from the was_native_jar directory to the directory where oaam_server is installed.
In the IBM WebSphere Administrative Console, navigate to Environment > Shared Libraries and select the scope of the cell as oaam_server1.
Create a new shared library named oaam_native_libs and specify the class path as the path to the directory created in step 10.
In the IBM WebSphere Administrative Console, navigate to Applications > Application Types > WebSphere enterprise applications > oaam_server_11.1.2.2.0 > Shared library references, and check the checkbox next to the oaam_sample web module.
Click Reference Shared libraries and move the shared library that was created in step 12 from the Available list to the Selected list. Then save and synchronize the changes.
Deploy was_native_jars/was_native_web.jar from the directory that is copied to in step 10. Navigate to Applications > Application Types > WebSphere enterprise applications, and select the check box next to the oaam_server_11.1.2.2.0 application and click Update.
Under the Application update options section, select Replace or add a single module and in the Specify the path beginning with the installed application archive file to the module to be replaced or added field, provide any unique path, such as oaam_sample_web, and select the path to the was_native_web.jar files and click Next to the Step 2 page. Make sure it is applied to oaam_server1; Continue with the configuration without changing settings and save and synchronize the changes.
Move oracle.security.jps.was.deployment.jar in WAS_HOME/plugins directory and restart the node/manager.
Restart the oaam_server application servers from Servers > Server Types > WebSphere application servers.
Log in to the OAAM Administration Console.
Import the policies from the oaam_policies.zip file.
Import the challenge questions from the oaam_kba_questions_en.zip file.
Import the Transaction definitions from the Sample_Transaction_Defs.zip file.
Import the Transaction policies from the Sample_Txn_Models.zip file.
Navigate to the URL:
http://host-name:oaam-server-port/oaam_sample
You are shown the login page of the OAAM sample application.
Enter the username and then password in the next page. You be taken through the registration process and after which you are shown links to the sample transactions.
Note:
The password must betest for the initial log in. You must change the password immediately.Move the oracle.security.jps.was.deployment.jar back to the WAS_HOME/plugins directory if you moved it out in step 8 and restart the node/manager; otherwise, access control is disabled completely.
This section contains instructions to set up the native SOAP-based OAAM sample application.
To set up the SOAP-based OAAM sample application, proceed as follows:
Create an oaam_sample directory.
Extract the oaam_sample_soap.zip file into the oaam_sample directory.
Use a text editor to edit the oaam_custom.properties file under the customer application deployment/WEB-INF/classes directory:
Set the vcrypt.tracker.soap.url property.
vcrypt.tracker.soap.url=http://host-name:port/oaam_server/services
This setting specifies the location of the web services with which the application will communicate.
Set bharosa.image.dirlist to the absolute directory path where OAAM images are available.
Remove the property bharosa.cipher.encryption.algorithm.enum related to encryption keys.
Navigate to the oaam_sample directory and run the command:
jar cfm ../oaam_sample_soap_was.war META-INF/MANIFEST.MF .
This will generates the oaam_sample_soap_was.war which you will install using the IBM WebSphere Administrative Console.
In the IBM WebSphere Administrative Console, navigate to Applications > Application Types > WebSphere enterprise applications.
From the Enterprise Applications list, select the check box next to the oaam_server_11.1.2.2.0 application and click Update.
Under the Application update options section, select Replace or add a single module and provide a unique path such as oaam_sample and specify the path to the oaam_sample_soap_was.war that was created in step 4; then click Next to continue to Step 2 in the wizard. Continue through the configuration without changing settings and save the changes.
Make sure the module is applied to oaam_server1.
Move oracle.security.jps.was.deployment.jar in the WAS_HOME/plugins directory and restart the node and deployment manager.
In the IBM WebSphere Administrative Console, navigate to Applications > Application Types > WebSphere enterprise applications > oaam_server_11.1.2.2.0 > Context Root for Web Modules, and specify oaam_sample for the OAAM sample web module.
Copy oaam_native_libs directory from the was_native_jar directory to the directory where oaam_server is installed.
In the IBM WebSphere Administrative Console, navigate to Environment > Shared Libraries, and select the scope of the cell as oaam_server1.
Create a new shared library named oaam_native_libs and specify the class path as the path to the directory created in step 10.
In the IBM WebSphere Administrative Console, navigate to Applications > Application Types > WebSphere enterprise applications > oaam_server_11.1.2.2.0 > Shared library references, and select the check box next to the oaam_sample web module.
Click Reference Shared libraries and move the shared library that was created in step 12 from the Available list to the Selected list. Save and synchronize the changes.
Deploy was_native_jars/was_native_web.jar from the directory that is copied to in step 10. In the console navigation tree, expand Applications, and then Application Types and click WebSphere enterprise applications to open the list of applications.
From the Enterprise Applications list, select the check box next to the oaam_server_11.1.2.2.0 application and click Update.
Select Replace or add a single module and specify any unique path such as oaam_sample_web and select the path to the was_native_web.jar file and click Next to Step 2. Continue through the configuration without changing the settings and then save the configuration.
Move oracle.security.jps.was.deployment.jar back to the WAS_HOME/plugins directory and restart the node/manager.
Restart the oaam_server application server from Servers > Server Types > WebSphere application servers.
Log in to the OAAM Administration Console.
Import the policies into the system from oaam_policies.zip file.
Import the challenge questions into the system from the oaam_kba_questions_en.zip file.
Import the Transaction Definitions into the system from the Sample_Transaction_Defs.zip file.
Import the Transaction policies into the system from the Sample_Txn_Models.zip file.
Navigate to the URL:
http://host-name:oaam-server-port/oaam_sample
You are shown the login page of the sample application.
A clustered environment allows for high availability and scalability. A cluster typically contains Application Servers that span multiple nodes. When creating a cluster, you add the initial cluster member (which must be an existing Application Server). After creating the cluster, you add additional cluster members to it. Each additional cluster member inherits the attributes of the first cluster member.
This section documents the steps to set up OAAM 11g Release 2 (11.1.2.2) in an IBM WebSphere environment in a clustered configuration that has high availability support.
Perform the steps in this section to install this delivery of Oracle Adaptive Access Manager on IBM WebSphere in a clustered configuration. A cluster is a group of Application Servers that work together to provide scalability and high availability for applications. By creating clusters, you can group servers such that they operate as a single unit for hosting applications and resources. By performing the following steps, you will create a configuration as described in Table 8-8:
Table 8-9 lists the tasks for installing and configuring Oracle Adaptive Access Manager on IBM WebSphere in a clustered configuration.
Table 8-9 Installation and Configuration Flow for Oracle Adaptive Access Manager Cluster
| No. | Tasks | Description |
|---|---|---|
|
1. |
Install IBM WebSphere. |
For more information, see Section 8.7.3, "Task 1: Install IBM WebSphere." |
|
2. |
Install and configure the Oracle 11g database |
For more information, see Section 8.7.4, "Task 2: Install and Configure the Oracle 11g Database." |
|
3. |
Install the Oracle Fusion Middleware Repository Creation Utility |
For more information, see Section 8.7.5, "Task 3: Install the Oracle Fusion Middleware Repository Creation Utility." |
|
4. |
Create and load the OAAM schema into the database |
For more information, see Section 8.7.6, "Task 4: Create and Load the OAAM Schema into the Database." |
|
5. |
Install Oracle Adaptive Access Manager |
For more information, see Section 8.7.7, "Task 5: Install Oracle Adaptive Access Manager." |
|
6. |
Configure IBM WebSphere on the Deployment Manager Machine |
For more information, see Section 8.7.8, "Task 6: Configure IBM WebSphere on the Deployment Manager Machine." |
|
7. |
Configure Oracle Platform Security Services Security Store |
For more information, see Section 8.7.9, "Task 7: Configure Oracle Platform Security Services Security Store." |
|
8. |
Start the Deployment Manager |
For more information, see Section 8.7.10, "Task 8: Start the Deployment Manager." |
|
9. |
Configure IBM WebSphere on IBM WebSphere Node 2 machine |
For more information, see Section 8.7.11, "Task 9: Configure IBM WebSphere on IBM WebSphere Node 2 Machine." |
|
10. |
Configure an LDAP Server (Optional) |
For more information, see Section 8.7.12, "Task 10: Configure an LDAP Server (Optional)." |
|
11. |
Set Up Session Persistence in IBM WebSphere |
For more information, see Section 8.7.13, "Task 11: Set Up Session Persistence in IBM WebSphere." |
|
12. |
Restart the servers |
For more information, see Section 8.7.14, "Task 12: Restart the Servers." |
On Deployment Manager Machine and WebSphere Node 2 Machine, install IBM WebSphere Application Server Network Deployment 7.0 with the appropriate fix pack.
To obtain and install the IBM WebSphere software, refer to the IBM WebSphere documentation.
For more information about the Fix Packs available for IBM WebSphere 7.0, refer to the Fix list for IBM WebSphere Application Server V7.0 on the IBM Support Web site.
When you install the IBM WebSphere software, you are prompted for the location where you want to install the software. For the purposes of this documentation, this location is later referred to as the WAS Home, or WAS_HOME in examples.
Install and patch Oracle Database. For information on the databases supported by Oracle Fusion Middleware, see the certification information described in Section 2.1, "Task 1: Review the System Requirements and Certification Information."
Make a note of the database connection information along with the name and passwords for the schemas you create with the Repository Creation Utility. You will need these later when you configure the Oracle Fusion Middleware products.
Install the Oracle Fusion Middleware Repository Creation Utility (RCU). For more information, see "Obtaining and Running Repository Creation Utility" in the Oracle Fusion Middleware Repository Creation Utility User's Guide.
Create and load the Identity Management - Oracle Adaptive Access Manager schema into the database using the Oracle Fusion Middleware Repository Creation Utility (RCU). For more information, refer to the following documents:
Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management
Oracle Fusion Middleware Repository Creation Utility User's Guide
On Deployment Manager Machine and WebSphere Node 2 Machine, install Oracle Adaptive Access Manager. For more information about installing Oracle Adaptive Access Manager, refer to the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
Note:
Ensure you have the same path for the ORACLE_HOME on both the Deployment Manager Machine and the WebSphere Node 2 Machine.When you run the Oracle Fusion Middleware installer, you must use the parameter -DSHOW_APPSERVER_TYPE_SCREEN=true to let the Oracle Universal Installer prompt for the IBM WebSphere home location.
To start the installer:
cd iamsuite/Disk1
./runInstaller -DSHOW_APPSERVER_TYPE_SCREEN=TRUE -jreLoc LOCATION_OF_IBM_JRE
LOCATION_OF_IBM_JRE is WAS_HOME/java/jre. For example:
/opt/IBM/WebSphere/AppServer/java/jre
Before you can use Oracle Fusion Middleware products in an IBM WebSphere environment, you must create and configure the cell in which the Oracle Fusion Middleware applications will run. The Oracle Fusion Middleware Configuration Wizard for IBM WebSphere simplifies the process of creating and expanding a cell for your Oracle Fusion Middleware environment.
On the Deployment Manager Machine, use the Oracle Fusion Middleware Configuration Wizard to create the Oracle Adaptive Access Manager cell. By default, the Configuration Wizard is located at:
MW_HOME/Oracle_IDM1/common/bin/was_config.sh
For more information, refer to the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.
Table 8-10 provides information about specific Configuration Wizard screens and appropriate information to enter on those screens—the table does not cover self-explanatory, standard screens. For those screens, click Next to accept the initial values and continue.
Table 8-10 Information for Specific Configuration Wizard Screens
| Screen Name | Input Description |
|---|---|
|
Add Products to Cell |
Select Oracle Adaptive Access Manager Admin Server and Oracle Adaptive Access Manager Server Server. |
|
Select Optional Configuration |
At a minimum, you must select the Application Servers, Clusters and End Points option—this is a required option. |
|
Configure Application Servers |
Perform the following steps:
|
|
Configure Clusters Screen |
Perform the following steps:
|
|
Configure Additional Cluster Members |
Click Next, or optionally, add servers to an existing system in the cluster. When you add a new Application Server to a cluster, its attributes are cloned from the primary member of the cluster. |
Run the configureSecurityStoreWas.py script to configure the Oracle Platform Security Services (OPSS) security store as follows:
setenv WSADMIN_CLASSPATH ORACLE_HOME/common/wlst/resources/oes-common.jar
cd IDM_HOME/common/bin/wsadmin.sh
./wsadmin.sh -lang jython -profileName <dmgr-prof-name>
-f ORACLE_HOME/common/tools/configureSecurityStoreWas.py
-d <dmgr-cell-home>(WAS_HOME/profiles/<dmgr-profile-name>/
config/cells/<cell-name>)
-t DB_ORACLE
-j cn=jpsroot
-m create
--passcode <password>
--config IAM
On the Deployment Manager Machine, start the Deployment Manager as follows:
WAS_HOME/bin ./startManager.sh -profileName <dmgr_prof_name>
On the WebSphere Node 2 Machine, launch the Oracle Fusion Middleware Configuration Wizard to federate the machine and configure its cell. By default, the Configuration Wizard is located at:
MW_HOME/Oracle_IDM1/common/bin/was_config.sh
For more information, refer to the Oracle Fusion Middleware Configuration Guide for IBM WebSphere Application Server.
Table 8-11 provides information about specific Configuration Wizard screens and appropriate information to enter on those screens—the table does not cover self-explanatory, standard screens. For those screens, click Next to accept the initial values and continue.
Table 8-11 Information for Specific Configuration Wizard Screens
| Screen Name | Input Description |
|---|---|
|
Select Configuration Option |
Select the Federate Machine and Configure Cell option. |
|
Specify Profile and Node Name Information |
Enter information about the profile and node names you want to create for the WebSphere Node 2 Machine. |
|
Specify Deployment Manager Information |
Enter information about the existing Deployment Manager system. |
|
Select Optional Configuration |
Be sure to select the Application Servers, Clusters and End Points option—this is a required option. |
|
Configure Additional Cluster Members |
Perform the following steps:
|
If you are installing and configuring Oracle Identity and Access Management Suite on IBM WebSphere, you can optionally install and configure a supported LDAP server. Oracle Fusion Middleware components do not support WebSphere's built-in file-based user registry.
For information about installing a supported LDAP server, see Section 9.1, "IBM WebSphere Identity Stores."
For information on the LDAP servers that are supported by Oracle Fusion Middleware, refer to the certification information on the Oracle Technology Network:
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
When using an LDAP store, you must add a number of OAAM roles to the store. In addition to creating these roles, you must create users and assign these users to these roles to facilitate access to the OAAM Admin console.
Use the ldif files documented in this section as a reference to create users and groups in LDAP. You will have different values for the LDAP attributes. For example:
dn: cn=an_oaam_user, cn = Users, dc=us/in/etc, dc=companyname, dc =com/org/etc
dn: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com cn: oaamadmin sn: oaamadmin description: oaamadmin uid: oaamadmin objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetorgperson objectclass: orcluser objectclass: orcluserV2 userpassword: mypasswd
dn: cn=OAAMCSRGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMCSRGroup displayname: OAAMCSRGroup description: OAAMCSRGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup dn: cn=OAAMCSRManagerGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMCSRManagerGroup displayname: OAAMCSRManagerGroup description: OAAMCSRManagerGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup dn: cn=OAAMEnvAdminGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMEnvAdminGroup displayname: OAAMEnvAdminGroup description: OAAMEnvAdminGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup dn: cn=OAAMInvestigationManagerGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMInvestigationManagerGroup displayname: OAAMInvestigationManagerGroup description: OAAMInvestigationManagerGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup dn: cn=OAAMInvestigatorGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMInvestigatorGroup displayname: OAAMInvestigatorGroup description: OAAMInvestigatorGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup dn: cn=OAAMRuleAdministratorGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMRuleAdministratorGroup displayname: OAAMRuleAdministratorGroup description: OAAMRuleAdministratorGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup dn: cn=OAAMSOAPServicesGroup,cn=Groups,dc=us,dc=oracle,dc=com cn: OAAMSOAPServicesGroup displayname: OAAMSOAPServicesGroup description: OAAMSOAPServicesGroup uniquemember: cn=oaamadmin,cn=Users,dc=us,dc=oracle,dc=com objectclass: top objectclass: groupofuniquenames objectclass: orclgroup
Load the user and group into LDAP issuing the following commands from the LDAP server:
ldapadd -h myoid.myompany.com -p 389 -D cn="orcladmin" -w mypasswd -c -v \ -f oaam_user.ldif ldapadd -h myoid.mycompany.com -p 389 -D cn="orcladmin" -w mypasswd -c -v \ -f oaam_group.ldif
The configuration for session persistence in a clustered environment is different for WebSphere Application Server than for Oracle WebLogic Server, in which the element <persistent-store-type>replicated_if_clustered</persistent-store-type> can be set in the servlet to provide session persistence. In WebSphere Application Server, the web container's session management property for session persistence is sessionPersistenceMode, which is stored in the WAS_HOME/profiles/profile_name/config/cells/cell_name/nodes/node_name/servers/server_name/server.xml file.
You can display the current sessionPersistenceMode value in the IBM WebSphere Administrative Console.
You can set the session persistence mode while creating a cluster through the IBM WebSphere Administrative Console. If you use the Fusion Middleware Configuration Wizard to create a cluster, after the cluster is created, you must configure the session persistence mode manually, through the IBM WebSphere Administrative Console, and then restart the application servers.
To display the session persistence mode in the IBM WebSphere Administrative Console:
Log in to the IBM WebSphere Administrative Console as an administrator.
Expand Servers and Server Types on the left, and click WebSphere application servers.
Click an OAAM application server on the Application Servers page.
Expand Web Container Settings, and click Web container, under Container Settings on the Configuration page for the application server.
Click Session management, under Additional Properties on the Web container page.
Click Distributed environment settings, under Additional Properties on the Session management page.
The Configuration page for Distributed environment settings displays the current sessionPersistenceMode value under General Properties, as the selected value for Distributed sessions.
The value of sessionPersistenceMode can be None, Database, or Data_Replication (displayed as the Memory-to-memory replication mode on the console.
To set the session persistence mode for a cluster:
If you use the IBM WebSphere Administrative Console to create a cluster, you must select the option Configure HTTP session memory-to-memory replication.
When this option is selected, a replication domain is created automatically, and the sessionPersistenceMode property is automatically set to the Data_Replication mode for each member of the new cluster. The created Replication domain, which has the same name as the cluster name, is automatically set for the Replication Domain property.
If you use the Fusion Middleware Configuration Wizard to create a cluster, the Configuration Wizard does not present any options for cluster creation, and it creates the new cluster without creating a replication domain.
The sessionPersistenceMode property is not set to the Data_Replication mode for each cluster member. In this case, you must configure sessionPersistenceMode manually, as the following procedure describes.
To configure the session persistence mode manually:
Log in to the IBM WebSphere Administrative Console as an administrator.
Create a replication domain (if there is none, or if you want to create a new replication domain for a cluster you created through the Fusion Middleware Configuration Wizard):
Expand Environment on the left of the console, and click Replication domains.
Click the New button on the Replication domains page.
Enter the domain name, and select the option Entire Domain under Number of Replicas.
Click the Apply or OK button, and then Save.
Set the sessionPersistenceMode property value for every server member in the cluster:
Expand Servers and Server Types on the left, and click WebSphere application servers.
Click an OAAM application server on the Application Servers page.
Expand Web Container Settings, and click Web container, under Container Settings on the Configuration page for the application server.
Click Session management, under Additional Properties on the Web container page.
Click Distributed environment settings, under Additional Properties on the Session management page.
Select the Memory-to-memory replication option, under Distributed sessions on the Configuration page for Distributed environment settings to set sessionPersistenceMode to Data_Replication.
On the Configuration page for Memory-to-memory replication, select the replication domain you created for this cluster.
Select the proper Replication mode for your configuration.
Click the Apply or OK button, and then Save.
Restart the OAAM application servers.
To restart the servers, follow these steps:
Stop the node and Deployment Manager on the Deployment Manager machine. Execute the following from $WAS_HOME/bin:
./stopNode.sh -profileName <server_prof_name> -username <wasadmin username> -password <password> ./stopManager.sh -profileName <dmgr_prof_name> -username <wasadmin username> -password <password>
Stop the node on WebSphere Node 2 machine. Execute:
./stopNode.sh -profileName <server_prof_name> -username <wasadmin username> -password <password>
Start the Deployment Manager, node, and servers on Deployment Manager machine. Execute:
./startManager.sh -profileName <dmgr_prof_name> ./startNode.sh -profileName <server_prof_name> ./startServer.sh OracleAdminServer -profileName <server_prof_name> ./startServer.sh <oaam_server_name> -profileName <server_prof_name>
Start the node and OPAM server on WebSphere Node 2 machine:
./startNode.sh -profileName <server_prof_name> ./startServer.sh <oaam_server_name> -profileName <server_prof_name>
This section describes how to upgrade Oracle Adaptive Access Manager (OAAM) 11g Release 2 (11.1.2.1) to Oracle Adaptive Access Manager 11g Release 2 (11.1.2.2). The chapter contains the following sections:
Backing Up Oracle Adaptive Access Manager 11g Release 2 (11.1.2.1)
Upgrading Oracle Adaptive Access Manager 11g Release 2 (11.1.2.1) to 11g Release 2 (11.1.2.2)
Upgrading OAAM, MDS, IAU and OPSS Schemas Using Patch Set Assistant
Upgrading Oracle Platform Security Services 11g Release 2 (11.1.2.1) to 11g Release 2 (11.1.2.2)
Read the Oracle Fusion Middleware System Requirements and Specifications document to ensure that your environment meets the minimum requirements for the products you are installing or upgrading.
Note:
If you do not follow the exact sequence provided in this task table, your Oracle Adaptive Access Manager upgrade may not be successful.Table 8-12 lists the steps to upgrade Oracle Adaptive Access Manager.
| Task | For More Information | |
|---|---|---|
|
1 |
Shut down all servers. This includes both Administration Server and Managed Servers. |
|
|
2 |
Back up your environment. |
See Backing Up Oracle Adaptive Access Manager 11g Release 2 (11.1.2.1) |
|
3 |
Upgrade 11g Release 2 (11.1.2.1) Oracle Home to 11g Release 2 (11.1.2.2). |
See Upgrading Oracle Adaptive Access Manager 11g Release 2 (11.1.2.1) to 11g Release 2 (11.1.2.2) |
|
4 |
Upgrade schemas using Patch Set Assistant. |
See Upgrading OAAM, MDS, IAU and OPSS Schemas Using Patch Set Assistant |
|
5 |
Upgrade OPSS |
See Upgrading Oracle Platform Security Services 11g Release 2 (11.1.2.1) to 11g Release 2 (11.1.2.2) |
|
6 |
Add ADF libraries to class path for Admin server and the managed servers. |
|
|
7 |
Redeploy the applications on WebSphere. |
|
|
8 |
Verify the Oracle Adaptive Access Manager upgrade. |
The upgrade process involves changes to the binaries and to the schema. Therefore, before you begin the upgrade process, you must shut down the AdminServer, WebSphere servers, node, and Deployment Manager.
You can also stop IBM WebSphere servers from Fusion Middleware Control.
For example, to stop a server from Fusion Middleware Control:
Log in to Fusion Middleware Control.
To locate the port number and URL for Fusion Middleware Control, see Section 3.1.2.2, "Locating the Port Number and URL for Fusion Middleware Control."
Navigate to the Server home page.
For more information, see Section 3.1.2.5, "Viewing an IBM WebSphere Server from Fusion Middleware Control".
From the WebSphere Application Server menu, select Control, and then select Shut down.
Fusion Middleware Control displays a confirmation dialog box.
Click Shutdown.
You can also stop IBM WebSphere servers with profile scripts.
To stop the IBM WebSphere servers, navigate to the following directory in the IBM WebSphere home and enter the command:
(UNIX) OAAM_PROFILE/bin/stopServer.sh server_name -username username -password password
To stop the OracleAdminServer, navigate to the following directory in the IBM WebSphere home, and enter the command:
(UNIX) WAS_HOME/profiles/profile_name/bin/stopServer.sh OracleAdminServer
For example, on a UNIX operating system:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/stopServer.sh
OracleAdminServer
You must back up your Oracle Adaptive Access Manager 11g Release 2 (11.1.2.1) environment before you upgrade to Oracle Adaptive Access Manager 11g Release 2 (11.1.2.2).
After stopping the servers, you must back up the following:
MW_HOME directory, including the Oracle Home directories inside Middleware Home
Oracle Adaptive Access Manager schema
MDS, IAU and OPSS schemas
To upgrade Oracle Adaptive Access Manager, 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 11g Release 2 (11.1.2.1) Middleware Home. Your Oracle Home is upgraded from 11g Release 2 (11.1.2.1) to 11g Release 2 (11.1.2.2).
This section contains the following topics:
For more information on obtaining Oracle Fusion Middleware 11g Release 2 (11.1.2.2) software, see Oracle Fusion Middleware Download, Installation, and Configuration ReadMe.
Use the Oracle Identity and Access Management 11.1.2 Installer to upgrade Oracle Adaptive Access Manager 11g Release 2 (11.1.2.1) to 11g Release 2 (11.1.2.2):
After you start the installer, the Welcome screen appears.
Click Next on the Welcome screen. The Install Software Updates screen appears. Select whether or not you want to search for updates. Click Next.The Prerequisite Checks screen appears. If all prerequisite checks pass inspection, click Next. The Specify Installation Location screen appears.
On the Specify Installation Location screen, point the Middleware Home to your existing 11g Release 2 (11.1.2.1) Middleware Home installed on your system.
In the Oracle Home Directory field, specify the path of the existing Oracle Identity and Access Management Home.
Click Next. The Installation Summary screen appears.
The Installation Summary screen displays a summary of the choices that you made. Review this summary and decide whether you want to proceed with the installation. If you want to modify any of the configuration settings at this stage, select a topic in the left navigation page and modify your choices. To continue installing Oracle Identity and Access Management, click Install. The Installation Progress screen appears. Click Next.
The Installation Complete screen appears. On the Installation Complete screen, click Finish.
This installation process copies the Oracle Identity and Access Management 11g Release 2 (11.1.2.2) software binaries to your system.
For more information, see Section 2.6, "Task 6: Install Oracle Identity and Access Management Suite" and the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.
You must upgrade your OAAM, MDS, IAU and OPSS schemas using Patch Set Assistant.
This section consists of the following topics:
Before running Patch Set Assistant, you should make sure that your database is running and that the schemas are supported. To check this, run the following SQL command:
SELECT OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY;
Move from your present working directory to the <MW_HOME>/oracle_common/bin directory by running the following command on the command line:
cd <MW_HOME>/Oracle_IDM1/bin
Run the following command:
./psa
The Patch Set Assistant requires that you have sysdba access to the database. If an ORA-28009 error occurs when running Patch Set Assistant, make sure you have provided sys as sysdba for the DBA user name on the database system.
After starting the Patch set Assistant Installer, follow the instructions on the screen to update your schemas.
In the Select Component screen, select the Oracle Adaptive Access Manager top-level component and Oracle Adaptive Access Manager or Oracle Adaptive Access Manager (Partition Support)
In the Prerequisite screen, verify that you have satisfied the database prerequisites.
In the IAU Schema screen, specify the database credentials (sysdba) to connect to the database that contains the IAU schema and the IAU schema credentials.
In the OPSS Schema screen, specify the database credentials (sysdba) to connect to the database that contains the OPSS schema and the OPSS schema credentials.
In the MDS Schema screen, specify the database credentials (sysdba) to connect to the database that contains the MDS schema and the MDS schema credentials.
In the OAAM Schema screen, specify the database credentials (sysdba) to connect to the database that contains the MDS schema and the MDS schema user name.
In the Examine screen, verify that your schemas have a "successful" indicator in the Status column. The Examine screen displays the status of the Patch Set Assistant as it examines each component schema.
In the Upgrade screen, verify that the schemas are the ones you want to upgrade. The Upgrade Progress screen shows the progress of the schema upgrade.
Once the upgrade completes, exit the wizard.
You can verify the upgrade by checking out log files. When the Patch Set Assistant is launched it tells you where the logs are stored. Usually the log files are written to the following location:
<MW_HOME>/oracle_common/upgrade/logs/psatimestamp.log
The timestamp reflects the actual date and time that Patch Set Assistant was run.
If any failures occur when running Patch Set Assistant, you can use these log files to help diagnose and correct the problem. Do not delete them. You can alter the contents of the log files by specifying a different -logLevel from the command line.
Some of the operations performed by Patch Set Assistant may take longer to complete than others. If you want to see the progress of these long operations, you can see this information in the log file, or you can use the following query:
SELECT VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY WHERE OWNER='schema_name';
In the query results, the STATUS field is either UPGRADING or UPGRADED during the schema patching operation, and becomes VALID when the operation is completed.
If you are not sure if the OAAM schema was upgraded or not, log in as an OAAM schema user and verify that QUESTION_GROUP_ID column is present in V_USER_QA table and V_USER_QA_HIST table. Also, make sure that there is entry in the schema_version_registry table with the component OAAM and the version as 11.1.2.2.0.
To upgrade Oracle Platform Security Services (OPSS) schema, do the following:
Run the Oracle Fusion Middleware wsadmin command-line shell from Oracle_IDM1/bin:
ORACLE_HOME/common/bin/wsadmin.sh -profileName profilename -connType SOAP -user admin_user -password admin_password
At the wsadmin prompt, run the following command:
Opss.upgradeOpss(jpsConfig="/scratch/xyz/IBM/WebSphere/AppServer/profiles/Custom01/config/cells/adc123456Cell02/fmwconfig/jps-config.xml",jaznData="/scratch/xyz/IBM/WebSphere/oracle_common/modules/oracle.jps_11.1.1/domain_config/system-jazn-data.xml", auditStore="/scratch/xyz/IBM/WebSphere/oracle_common/modules/oracle.jps_11.1.1/domain_config/audit-store.xml", jdbcDriver="oracle.jdbc.driver.OracleDriver", url="jdbc:oracle:thin:@localhost:1521:orcl", user="DB_USER_OPSS", password="DB_USER_OPSS_PASSWORD", upgradeJseStoreType="true", transformData="false")
Add ADF libraries to class path to the Admin server and the managed servers:
Log in to IBM WebSphere Administrative Console.
Navigate to shared libraries and select OracleAdminServer, Node = HOST_NAMENode03, Server=OracleAdminServer. Select resource adf.oracle.domain.webapp_1.0_11.1.1.2.0 and augment the class path.
Library: OracleAdminServer
Additional Class Path References:
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-anim.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-awt-util.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-bridge.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-codec.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-css.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-dom.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-ext.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-extension.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-gui-util.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-gvt.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-parser.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-script.jar${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-svg-dom.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-svggen.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-swing.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-transcoder.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-util.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-xml.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/xml-apis-ext.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpclient-4.1.2.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpclient-cache-4.1.2.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpcore-4.1.2.jar
${oracle.as.jrf_11.1.1.7.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpmime-4.1.2.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-anim.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-awt-util.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-bridge.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-codec.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-css.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-dom.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-extension.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-ext.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-gui-util.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-gvt.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-parser.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-script.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-svg-dom.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-svggen.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-swing.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-transcoder.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-util.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/batik-xml.jar
${COMMON_COMPONENTS_HOME}/modules/oracle.adf.view_11.1.1/xml-apis-ext.jar
${COMMON_COMPONENTS_HOME}/modules/org.apache.http.components.httpclient-4.1.2.jar
${COMMON_COMPONENTS_HOME}/modules/org.apache.http.components.httpclient-cache-4.1.2.jar
${COMMON_COMPONENTS_HOME}/modules/org.apache.http.components.httpcore-4.1.2.jar
${COMMON_COMPONENTS_HOME}/modules/org.apache.http.components.httpmime-4.1.2.jar
Follow the above step for SOA and admin server.
Library: oimserver1 and soa_server1
Additional Class Path References:
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-anim.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-awt-util.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-bridge.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-codec.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-css.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-dom.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-ext.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-extension.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-gui-util.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-gvt.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-parser.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-script.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-svg-dom.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-svggen.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-swing.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-transcoder.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-util.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/batik-xml.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/xml-apis-ext.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpclient-4.1.2.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpclient-cache-4.1.2.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpcore-4.1.2.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/org.apache.http.components.httpmime-4.1.2.jar
On the page to define a container-wide shared library, for adf.oracle.domain.webapp_1.0_11.1.1.2.0, add as the class path:
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/adf-dt-at-rt.jar
${oracle.as.jrf_11.1.1.6.0_oracle_common_ORACLE_HOME}/modules/oracle.adf.view_11.1.1/adf-dynamic-faces.jar
Note:
For the address typed into the URL, do not includehttps.To redeploy OAAM applications, complete the following steps for each of the three applications, oaam_admin, oaam_server, and oaam_offline.
Navigate to Enterprise Applications in the IBM WebSphere Administrative Console.
Log in to the IBM WebSphere Administrative Console using administrator credentials. For example:
https:host:port/ibm/console
Expand the Application node from the left-hand panel of the IBM WebSphere Administrative Console, and then expand Application Types.
Click the Websphere enterprise applications link. A page will appear with a list of installed applications.
Update the application.
Select the check box next to the OAAM application from the Enterprise Applications page in the IBM WebSphere Administrative Console, and then click Update. A new page, Preparing for the application update, will appear.
OAAM Admin: for updating OAAM Admin, select oaam_admin_11.1.2.2.0.
OAAM Server: for updating OAAM Server, select oaam_server_11.1.2.2.0.
OAAM Offline: for updating OAAM Offline, select oaam_offline_11.1.2.2.0.
Select the Replace the entire application option. It will be selected by default. If not, select that option and specify the path to the replacement EAR file.
OAAM Admin:
MW_HOME/Oracle_IDM1/oaam/oaam_admin/ear/oaam_admin_was.ear <path_up_to_IDM_HOME>/oaam/oaam_admin/ear/oaam_admin_was.ear
OAAM Server: the path will be
<path_up_to_MW_HOME>/Oracle_IDM1/oaam/oaam_server/ear/oaam_server_was.ear
OAAM Offline: path will be:
<path_up_to_MW_HOME>/Oracle_IDM1/oaam/oaam_offline/ear/oaam_offline_was.ear
Click Next. In the next page by default the Fast Path option will be the default selected for How do you want to install the application? Click Next.
Click Next. In the page, Specify options for installing enterprise applications and modules, leave all default values.
Select the server name row under Clusters and servers.
You need to select the server where the application you are redeploying is running.
OAAM Admin: Select the row with the server name as oaam_admin_server1.
OAAM Server: Select the row with the server name as oaam_server_server1.
OAAM Offline: Select the row with the server name as oaam_offline_server1.
Note:
All the above server names are standard. If you have changed the server names, select them accordingly.In the bottom portion of the page, click the check box to select all the listed modules, and then click Apply. The Apply button is next to the list of Clusters and servers. Once you click Apply, the check box will be deselected. Click the check box again, and then click Next to go to the Summary page.
In the Summary page, review the information and click Finish.
There will be log message on the screen. Wait for the changes to take place. Once changes are done, there will be two links Save and Review. Click Review. In the next page, select the check box Synchronize changes with Nodes and click Save.
Verify the application is started.
From the IBM WebSphere Administrative Console, expand the Application node from the left pane, and then expand Application Types (if not already expanded).
Click the Websphere enterprise applications link. A page will appear with a list of installed applications.
Refresh the application by clicking the refresh icon next to the Application Status column header. Check if the status of the application is started. If the application has not been started, go to the next step to start the application.
Select the OAAM application by clicking the appropriate check box. Then click Start.
OAAM Admin: for starting OAAM Admin, select oaam_admin_11.1.2.2.0.
OAAM Server: for starting OAAM Server, select oaam_server_11.1.2.2.0.
OAAM Offline: for starting OAAM Offline, select oaam_offline_11.1.2.2.0.
After starting servers you may see the Kyros-enabled user interface.
Use the following URL in a web browser to verify that Oracle Adaptive Access Manager 11.1.2.2.0 is running:
http://oaam.example.com:<oaam_port>/oaam_admin