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
Installing and Configuring Oracle Adaptive Access Manager Offline 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.
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.8.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 9: 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
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.11, "Task 11: 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, on a UNIX operating system:
/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, 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, to start the node on a UNIX operating system, enter:
/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, to start the OracleAdminServer on a UNIX operating system, enter:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
OracleAdminServer
After you start the OracleAdminServer, you can start the other servers using the IBM WebSphere Administrative Console or Oracle Enterprise Manager Fusion Middleware Control. 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, to start the OAAM Administration Server on a UNIX operating system, enter:
/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, on the UNIX operating system, OAAM_PROFILE
is:
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
.
OAAM_Profile
is the IBM WebSphere profile where OAAM Server is installed.
For example, to start the OAAM runtime server on a UNIX operating system, enter:
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
oaam_server_server1
For example, on a UNIX operating system, OAAM_PROFILE
is:
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, 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
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, on a UNIX operating system:
/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, on a UNIX operating system:
/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 |
OAAMSOAPServicesGroup |
SOAPServicesGroup role |
Users are granted this role in order to access the URL: |
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 as Oracle_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 |
|
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 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 /home/user/IBM/oaam.cli/sample.sas.client.properties |
oaam.db.url |
Specify a valid JDBC URL of the OAAM database. |
oaam.adminserver.type |
|
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 |
Change this value only if the OAAM schema is in a non-Oracle database. |
oaam.db.min.read-connections |
Do not change this value unless required. |
oaam.db.max.read-connections |
Do not change this value unless required. |
oaam.db.min.write-connections |
Do not change this value unless required. |
oaam.db.max.write-connections |
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.
A 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 will be prompted to select Oracle WebLogic or IBM WebSphere.
Select 2
for IBM WebSphere.
You are prompted for the WAS_HOME
.
You are not prompted for WAS_HOME
if it is already set in the oaam_cli.properties
file.
Set the WAS_HOME
.
For example: /opt/IBM/WebSphere/AppServer
You will be prompted for the IDM_HOME
directory if $IDM_HOME
is not set. Give the same ORACLE HOME directory that you gave 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.
To install and configure Oracle Adaptive Access Manager Offline, follow the steps outlined in Section 8.1, "Installing and Configuring Oracle Adaptive Access Manager on IBM WebSphere." You must also perform the following steps on the command line from the IDM_ORACLE_HOME
directory before running was_config.sh
:
cd IDM_ORACLE_HOME/oaam/oaam_offline/ear mv oaam_offline_was.ear oaam_offline_was.ear.bak mkdir temp cd temp jar xf ../oaam_offline_was.ear mkdir war_tmp cd war_tmp jar xf ../oaam_offline.war cp IDM_ORACLE_HOME/oaam/oaam_libs/was_native_jar/antlr-2.7.6.jar ./WEB-INF/lib jar -cfm ../oaam_offline.war META-INF/MANIFEST.MF * cd .. rm -rf war_tmp jar -cfm ../oaam_offline_was.ear META-INF/MANIFEST.MF * cd .. rm -rf temp
If you do not perform this step, the OAAM Offline environment will not be able to process rules. The offline logs will show the following error:
java.lang.NoClassDefFoundError: antlr.TokenStream
To set up the snapshot import and export feature, copy the org.eclipse.persistence_1.1.0.0_2-1.jar
file from the $ORACLE_MW_HOME/modules
directory of an Oracle Identity Management installation on Oracle WebLogic to the $ORACLE_MW_HOME/modules
directory on IBM WebSphere.
If the $ORACLE_MW_HOME/modules
directory does not exist on IBM WebSphere, you must create it before copying the file.
If you do not have an Oracle Identity Management deployment in an Oracle WebLogic environment, download the org.eclipse.persistence_1.1.0.0_2-1.jar
file from "Oracle TopLink Software Downloads" on Oracle Technology Network (OTN) at:
http://www.oracle.com/technetwork/middleware/toplink/downloads/index.html
Set up and enable audit using the database audit store for OAAM on IBM WebSphere. Instructions are provided in this section.
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 the audit data.
This section explains how to create the audit schema. Once the database schema is created, you can:
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 RCU and the database is 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 Database Schema
Follow these steps to configure a schema for the audit data store:
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.4.1, "Creating the Audit Schema Using RCU", 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.4.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.4.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.4.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.4.4, "Create Data Sources for Audit Event."
If successful, the following information will be 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.
A drop-down list of pre-configured audit levels can be selected. Two predefined levels (Low, Medium) will 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 will be the value passed for -snapshotname.zip
. If snapshotname
is not specified, the CLI will create 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 |
description |
Description of snapshot, if specified by |
serverName |
Hostname from where CLI was 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 |
Group members for alerts and actions only will be 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 will overwrite 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 will need to 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 will change 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.6.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 to opss.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 will import the properties needed for the integration. You will modify these properties according to your environment in Section 8.6.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 the CN
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.6.7.4, "Acting as Your Own Certificate Authority" and go to Section 8.6.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.6.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.6.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.6.7.5, "Importing the Certificate into Your Keystore." |
Import the server certificate (for example, server.crt
) created (in Section 8.6.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.7.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.7.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.7.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.0.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.0.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.0.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 classpath 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.0.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.0.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 be test
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.0.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 the Step 2 page. 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.0.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 classpath 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.0.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.0.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 11.1.2.1.0 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.9.3, "Task 1: Install IBM WebSphere." |
2. |
Install and configure the Oracle 11g database |
For more information, see Section 8.9.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.9.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.9.6, "Task 4: Create and Load the OAAM Schema into the Database." |
5. |
Install Oracle Adaptive Access Manager |
For more information, see Section 8.9.7, "Task 5: Install Oracle Adaptive Access Manager." |
6. |
Configure IBM WebSphere on the Deployment Manager Machine |
For more information, see Section 8.9.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.9.9, "Task 7: Configure Oracle Platform Security Services Security Store." |
8. |
Start the Deployment Manager |
For more information, see Section 8.9.10, "Task 8: Start the Deployment Manager." |
9. |
Configure IBM WebSphere on IBM WebSphere Node 2 machine |
For more information, see Section 8.9.11, "Task 9: Configure IBM WebSphere on IBM WebSphere Node 2 Machine." |
10. |
Configure an LDAP Server (Optional) |
For more information, see Section 8.9.12, "Task 10: Configure an LDAP Server (Optional)." |
11. |
Set Up Session Persistence in IBM WebSphere |
For more information, see Section 8.9.13, "Task 11: Set Up Session Persistence in IBM WebSphere." |
12. |
Restart the servers |
For more information, see Section 8.9.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.
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
Note:
Ensure you have the same path for the ORACLE_HOME on both the machines.
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 sessionPersitenceMode
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>