This section covers the following topics:
This section describes, where applicable, what additional steps are required when configuring the Oracle IRM J2EE application (Oracle IRM Server) to support interoperability. In most cases, the standard Fusion Middleware/WebLogic instructions are applicable. In a few cases additional steps are required to complete the configuration for Oracle IRM.
Oracle IRM requires SSL to be enabled on the front ending application; whether this is OHS (Oracle HTTP Server) or a managed server running the Oracle IRM J2EE application. Communication between Oracle IRM Desktop and Oracle IRM Server must be over SSL, because sensitive information such as passwords are communicated. Other uses of SSL, such as between OHS and the managed servers, the admin server and LDAP are optional: the recommendations are the same as those for other Fusion Middleware applications.
There are no Oracle IRM specific configuration steps when configuring SSL for these uses.
Oracle IRM uses Oracle Platform Security Services (OPSS) (in particular the Credential Store Framework) to retrieve passwords for the Oracle IRM key store. There are no Oracle IRM specific configuration steps if the credential and policy stores are reassociated with LDAP.
Oracle IRM uses OPSS (in particular the identity store APIs) to obtain user and group details from LDAP. The standard instructions can be followed for reassociating the identity store with an external LDAP.
Tuning The recommended OPSS/JPS Oracle configuration setting mentioned in section 23.3.2, Tuning the Identity Store for Performance, of the WebCenter Security Documentation, is applicable to Oracle IRM.
Unique user name If you modify a username attribute to something other than the default set for the LDAP server in the authenticator, you must also edit the jps-config.xml file to correspond to these values. Specifically, the username.attr and user.login.attr properties (highlighted below) must be added for user lookups to function correctly:
<!-- JPS WLS LDAP Identity Store Service Instance --> <serviceInstance name="idstore.ldap" provider="idstore.ldap.provider"> <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/> <property name="username.attr" value="uid"/> <property name="user.login.attr" value="uid"/> </serviceInstance>
The following instructions document how Oracle IRM stored user and group information can be migrated whilst performing this switch. The Oracle IRM system references users and groups using a globally unique identifier GUID provided by OPSS. This GUID is used to identify the user or group stored in LDAP. Storing the GUID rather than the user or group name avoids issues when user or group names change.
Any changes to the underlying LDAP can invalidate user and group details stored in the Oracle IRM database because the GUID value may no longer be valid. A number of WLST commands are provided to update user and group GUID values stored in the Oracle IRM database after an LDAP reassociation. User and group reassociation is a two-step process. The first step is to dump all the existing IRM stored user and group details into an XML file. This must be done before the LDAP reassociation. The second step is to provide this data post LDAP reassociation so the Oracle IRM database user and group GUID details can be updated.
WLST commands:
For more information about running WLST commands, see the WLST Command Guide. When running the WLST identity store reassociation commands, authenticate using the WebLogic administration account, for exampleweblogic.preIRMUserStoreUpgradeThe preIRMUserStoreUpgrade WLST command asks for the server URL, user name, and password for the WebLogic managed server hosting the Oracle IRM J2EE application. The command fetches the list of user and groups referenced by the Oracle IRM database and dumps the user name, group name, and GUID details into an XML file.
wls:/offline> preIRMUserStoreUpgrade() Enter Server URL: t3://managedserver.host:managedserver.port Enter Username: weblogic Enter Password: Connecting to server... No. of accounts retrieved so far: 1 Done!
The XML file irm-data.xml contains a list of all user and groups referenced in the Oracle IRM database, providing the user and group name and associated GUID value. The irm-data.xml file is created in the current directory, that is, where the WLST shell was started. For example, if you have invoked wlst.sh, the file will be created where wlst.sh is located, that is, in common/bin of the ECM home.
postIRMUserStoreUpgradeThis WLST command loads the user and group details from the XML file and updates the Oracle IRM database with the new GUID value for each user and group. This step looks for the user or group with the same name as the original LDAP, and updates the GUID values from the new LDAP. For example, if your Oracle IRM system was using a user called john.smith@example.com, the new user store should also have a john.smith@example.com.
This WLST command also generates a migration summary at the end of operation. The summary reports the total number of users and groups processed, the number of users and groups migrated successfully, and the number of failures. The main reason for a failure is that a user or group that existed in the original LDAP cannot be found in the new LDAP.
You can use this command as shown below:
wls:/offline> postIRMUserStoreUpgrade() Enter Server URL: t3://managedserver.host:managedserver.port Enter Username: weblogic Enter Password: Connecting to server... Migrating account name: john.smith@example.com Migration Succeeded Migration Summary ----------------- Total number of accounts: 1 No. of accounts migrated: 1 No. of failures: 0
transferIRMAccountThere may be users or groups that do not exist in the new LDAP. For those users and groups a manual transfer can be made to a different user or group that does exist in the new LDAP. This WLST command requires the XML data file created using the preIRMUserStoreUpgrade command so that the user or group GUID value can be identified. This command can also be used to transfer rights from one user or group to another.
To transfer user or groups details, run the WLST command transferIRMAccount
wls:/offline> transferIRMAccount('john.smith@example.com', 'USER', 'mary.smith@example.com', 'USER')
Enter Server URL: t3://managedserver.host:managedserver.port
Enter Username: weblogic
Enter Password:
Connecting to server...
Account "john.smith@example.com" found in data file.
Transferring "john.smith@example.com" to "mary.smith@example.com".
Transfer complete
Oracle IRM relies on the authentication set up in WebLogic and OPSS, and does not require any specific SSO setup. Oracle IRM Desktop does not currently support OSSO.
Note:
Whereas the Oracle J2EE application (the Oracle IRM Server website) supports basic, form, and certified authentication, Oracle IRM Desktop supports only OAM basic authentication.When setting up OAM for use with SSO, the following URLs need to be protected:
://<server.host:server.port>/irm_rights/faces
://<server.host:server.port>/irm_desktop/request]
Implementation of SSO with the Oracle IRM Server management console will enable access to applications as expected: input of a valid username/password combination during the same SSO session will be recognized.
Implementation of SSO with Oracle IRM Desktop will not enable access to multiple applications in the same session by entry of a single username/password combination. Oracle IRM Desktop users will be prompted for a username and password even if they have already supplied a valid username and password within the same SSO session. Support for SSO with Oracle IRM Desktop is provided so that users can be shown a recognizable sign-on dialog that will indicate the correct username/password combination to be entered.
OAM authentication requires the use of a deployment plan file to make changes to an Oracle IRM configuration file.
You can use an existing deployment plan file, or you can generate one. To generate one, use the following command:
java weblogic.PlanGenerator $ORACLE_HOME/ecm/irm/lib/irm.ear
This will result in a file plan.xml being created in the same location as irm.ear.
Note:
This assumes that the WebLogic Server classes have been added to theCLASSPATH environment variable, and that the correct JDK binaries are available in your PATH. You can use the setWLSEnv.sh or setWLSEnv.cmd script, located in the server/bin subdirectory of the WebLogic Server installation directory, to set the environment.The deployment plan file must be altered as described below, then redeployed to change the configuration.
In plan.xml, find the following element:
<application-name>irm.ear</application-name>
After this element, add the following lines:
<variable-definition>
<variable>
<name>auth-method</name>
<value>CLIENT-CERT</value>
</variable>
</variable-definition>
Now find the <module-override> element that has a child element <module-name>irm-desktop.war</module-name>. This will have a <module-descriptor> element that has a child element of <uri>WEB-INF/web.xml</uri>. Immediately after that URI element, add the following lines:
<variable-assignment>
<name>auth-method</name>
<xpath>/web-app/login-config/auth-method</xpath>
</variable-assignment>
With the changed deployment plan file saved and in place, follow these steps to make the configuration change:
In the WebLogic console application, select irm and choose Update.
Add the changed deployment plan file and complete the wizard.
Restart the server.