25 Handling Lifecycle Management Changes

Because of integrated deployment of Oracle Identity Governance with other applications, such as Oracle Access Manager (OAM), and configuration changes in those applications, various configuration changes might be required in Oracle Identity Governance and Oracle WebLogic Server.

These configuration changes are described in the following sections:

Note:

In this section there are several command examples which includes, password in the command, this needs to be replaced with the actual password before executing the commands.

25.1 URL Changes Related to Oracle Identity Governance

Oracle Identity Governance uses various host names and ports in its configuration. Corresponding changes to host names and ports are required in Oracle Identity Governance and Oracle WebLogic configuration.

This section describes ways to make the corresponding changes in Oracle Identity Governance and Oracle WebLogic configuration. It contains the following topics:

25.1.1 Oracle Identity Governance Host and Port Changes

Oracle Identity Governance host and port changes include changing OimFrontEndURL and backOfficeURL in Oracle Identity Governance configuration, changing task details URL in human task configuration, and changing OIG server port on WebLogic Administrative Console.

This section describes about Oracle Identity Governance host and port changes in the following topics:

Note:

When additional Oracle Identity Governance nodes are added or removed, perform the procedures described in these sections to configure Oracle Identity Governance host and port changes.

25.1.1.1 Changing OimFrontEndURL in Oracle Identity Governance Configuration

The OimFrontEndURL is the URL used to access the Oracle Identity Governance UI. This can be a load balancer URL or Web server URL depending on the application server is fronted with a load balancer or web server or a single application server URL. This is used by Oracle Identity Governance in the notification e-mails as well as the callback URL for SOA calls.

The change may be necessary because of change in Web server hostname or port for Oracle Identity Governance deployment in a clustered environment, or WebLogic managed server hostname or port changes for Oracle Identity Governance deployment in a nonclustered environment.

Note:

In order to change OimFrontEndURL, perform the steps provided in this section as well as the steps in Changing OIM Server Port on WebLogic Administrative Console.

To change the OimFronEndURL in Oracle Identity Governance configuration:

  1. Login to Enterprise Manager by using the following URL when the WebLogic Administrative Server and Oracle Identity Governance managed servers, at least one of the servers in case of a clustered deployment, are running:

    http://ADMIN_SERVER/em

  2. Navigate to Identity and Access, oim.
  3. Right-click oim, and navigate to System MBean Browser.
  4. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.DiscoveryConfig, and then Discovery.

    In a clustered deployment, when you select oracle.iam under Application Defined MBeans, Oracle Identity Governance server name is displayed. Select the server and continue with the navigation.

    Note:

    In a clustered deployment, the change to the OimFrontEndURL must be made on each server in the cluster.

  5. Enter new value for the OimFrontEndURL attribute, and click Apply to save the changes. Example values can be:

    http://OIM_SERVER:OIM_PORT

    https://myoim.example.com

    https://myoimserver.example.com:14001

    Note:

    SPML clients store Oracle Identity Governance URL for invoking SPML and sending callback response. Therefore, changes are required corresponding to this. In addition, if Oracle Identity Governance is integrated with OAM, OAAM, or Oracle Identity Navigator (OIN), there may be corresponding changes necessary. For more information, refer to OAM, OAAM, and OIN documentation in the Oracle Technology Network (OTN) Web site.

25.1.1.2 Changing backOfficeURL in Oracle Identity Governance Configuration

Changing backOfficeURL is required only for Oracle Identity Governance deployed in front-office and back-office configuration. This change does not apply for simple clustered or nonclustered deployments. This URL is used internally by Oracle Identity Governance for accessing back-office components from the front-office components. You might change the value of this attribute during the implementation of back-office and front-office configuration, for adding additional servers to back office, and for removing servers from back-office.

To change the value of the backOfficeURL attribute:

  1. Login to Enterprise Manager by using the following URL when the WebLogic Administrative Server and Oracle Identity Governance managed servers, at least one of the servers in case of a clustered deployment, are running:

    http://ADMIN_SERVER/em

  2. Navigate to Identity and Access, and then oim.
  3. Right-click oim, and navigate to System MBean Browser.
  4. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.DiscoveryConfig, Discovery.
  5. Enter a new value for the BackOfficeURL attribute, and click Apply to save the changes. Example values can be:

    t3://mywls1.example.com:8001

    t3://mywls1.example.com:8001,mywls2.example.com:9001

    Note:

    The value of the BackOfficeURL attribute must be empty for Oracle Identity Governance nonclustered and clustered deployments.

25.1.1.3 Changing Task Details URL in Human Task Configuration

The task details URL is the URL of the task details page for a particular human task in the Inbox. This can be a load balancer URL or Web server URL depending on whether the application server is fronted with load balancer, or Web server, or single application server URL.

The change might be required because of change in Web server hostname or port for Oracle Identity Governance deployment in a clustered environment, or WebLogic managed server hostname or port changes for Oracle Identity Governance deployment in a nonclustered environment.

To change the task details URL in human task configuration:

  1. Login to Oracle Enterprise Manager by using the following URL:

    http://ADMIN_SERVER/em

    For a clustered deployment, ensure that at least one SOA server in the SOA cluster is running.

  2. Click the Target Navigation image shown on the left of the domain name in upper left corner of the Enterprise Manager console.
  3. Click SOA, and then select soa-infra(SOA_SERVER_NAME).
  4. Click the Deployed Composite tab.
  5. Click the DefaultOperationalApproval [6.0] composite.
  6. In the Components section, click the ApprovalTask link of type Human Workflow.
  7. Click the Administration tab.
  8. Make the required changes to Host Name, HTTP Port, and HTTPS Port.
  9. Repeat steps 6 through 8 for all other composites.
25.1.1.4 Changing OIG Server Port on WebLogic Administrative Console

You can update the OIG server port by using the WebLogic Administrative Console.

To change the OIG server port by using the WebLogic Administrative Console::
  1. Login to Weblogic Administrative Console by using the following URL when the WebLogic Administrative Server is running:
    http://ADMIN_SERVER/console
  2. Click Lock and Edit on the top left corner..
  3. Navigate to Environment, Servers. Select oim_server for which you need to modify the port. Modify the Listen Port field with the new value.
  4. Click Save. Then click Activate all changes on the top left corner.

25.1.2 Oracle Identity Governance Database Host and Port Changes

Database host name and port number changes can be in various configuration areas, such as datasource oimJMSStoreDS, oimAuthenticatorProvider, DirectDB, and incorrect database configurations.

This section describes the configuration areas where database hostname and port number are used.

After installing Oracle Identity Governance, if there are any changes in the database hostname or port number, then the following changes are required:

Note:

Before making changes to the database host and port, shutdown the managed servers hosting Oracle Identity Governance. But you can keep the Oracle WebLogic Administrative Server running.

25.1.2.1 Modifying Datasource oimJMSStoreDS Configuration

To change datasource oimJMSStoreDS configuration:

  1. Navigate to Services, JDBC, Data Sources, and then oimJMSStoreDS.
  2. Click the Connection Pool tab.
  3. Modify the values of the URL and Properties fields to reflect the changes to database host and port.
25.1.2.2 Modifying Datasource soaOIMLookupDB Configuration

To change datasource soaOIMLookupDB configuration:

  1. Navigate to Services, JDBC, Data Sources, and then soaOIMLookupDB.
  2. Click the Connection Pool tab.
  3. Modify the values of the URL and Properties fields to reflect the changes to database host and port.
25.1.2.3 Modifying Datasource oimOperationsDB Configuration

To change datasource oimOperationsDB configuration:

  1. Navigate to Services, JDBC, Data Sources, and then oimOperationsDB.
  2. Click the Connection Pool tab.
  3. Modify the values of the URL and Properties fields to reflect the changes to database host and port.
25.1.2.4 Modifying Datasource ApplicationDB Configuration

To change datasource ApplicationDB configuration:

  1. Navigate to Services, JDBC, Data Sources, and then ApplicationDB.
  2. Click the Connection Pool tab.
  3. Modify the values of the URL and Properties fields to reflect the changes to database host and port.
25.1.2.5 Modifying Datasource Related to Oracle Identity Governance Meta Data Store

To change the datasource related to Oracle Identity Governance Meta Data Store (MDS) configuration:

Note:

This step is required only if database host and port of MDS schema is changed.

  1. Navigate to Services, JDBC, Data Sources, and then mds-oim.
  2. Click the Connection Pool tab.
  3. Modify the values of the URL and Properties fields to reflect the changes in the database host and port.
25.1.2.6 Modifying OIMAuthenticationProvider Configuration

To change OIMAuthenticationProvider configuration, on Host A, which is the computer that hosts the freshly configured domain:

  1. Stop OIM Managed server and SOA Managed server of the newly installed setup of Oracle Identity Governance. To do so, from the <HOSTA_DOMAIN_HOME>/bin/ directory, run the following commands:
    sh stopManagedWebLogic.sh <OIM_MANAGED_SERVER_NAME>
    sh stopManagedWebLogic.sh <OIM_MANAGED_SERVER_NAME>
  2. From Host A, login to Oracle WebLogic Administrative Console by navigating to the following URL:

    For non-SSL setup:

    http://<ADMIN_SERVER_HOSTNAME_HOST_A>:<ADMIN_SERVER_PORT_HOST_A>/console

    For SSL-enabled setup:

    https://<ADMIN_SERVER_HOSTNAME_HOST_A>:<ADMIN_SERVER_SSL_PORT_HOST_A>/console

    Use the WebLogic admin user login credentials, which is weblogic and <WEBLOGIC_ADMIN_PASSWORD>.

  3. Navigate to Security Realms, myrealm, and then Providers.
  4. Click OIMAuthenticationProvider.
  5. Click Provider Specific.
  6. Modify the value of the DBUrl, DBUser and DBPassword fields to reflect the credentials of OIG schema of the database on Host B, as shown in Figure 25-1.

    Figure 25-1 Setting for OIMAuthenticationProvider

    Setting for OIMAuthenticationProvider
  7. Click Save.
25.1.2.7 Modifying DirectDB Configuration

To change DirectDB configuration:

  1. Login to Enterprise Manager by using the following URL:

    http://ADMIN_SERVER/em

  2. Navigate to Identity and Access, and then oim.
  3. Right-click oim, and navigate to System MBean Browser under Application Defined MBeans.
  4. Navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.DirectDBConfig, and then DirectDB.
  5. Enter the new value for the URL attribute to reflect the changes to host and port, and then apply the changes.

Note:

When Oracle Identity Governance single instance deployment is changed to Oracle Real Application Clusters (Oracle RAC) or Oracle RAC is changed to single instance deployment, change the oimJMSStoreDS, oimOperationsDB, and mds-oim datasources. In addition to the generic changes to make these datasources to multidatasource configuration, change the OIMAuthenticationProvider and domain credential store configurations to reflect the Oracle RAC URL. For information about these generic changes, see High Availability Guide for Oracle Identity and Access Management.

See Oracle Identity Governance Database Host and Port Changes for information about changing the port at the database.

25.1.2.8 Modifying the Oracle Identity Governance Database Host and Port in BI Publisher

To change the Oracle Identity Governance database host and port in BI Publisher:

  1. Login to BI Publisher.
  2. Click the Administration tab.
  3. Click JDBC Connection under Data Sources.
  4. Click OIM JDBC, and change the database host and port.
  5. Click Test Connection. The connection is established successfully after confirmation.
  6. Click Apply.
25.1.2.9 Changing Incorrect Database Configuration

Perform the following additional steps if Oracle Identity Governance is made to point to another database of another Oracle Identity Governance instance instead of current database port being changed:

  1. Copy .xldatabasekey from Oracle Identity Governance that is installed on the destination DB to the source Oracle Identity Governance deployment. Copy DOMAIN_HOME/config/fmwconfig/.xldatabasekey from destination to source Oracle Identity Governance.

  2. Copy the following keys from Oracle Identity Governance deployment on the destination DB to the source deployment:

    OIMSchemaPassword

    .xldatabasekey

    DataBaseKey

  3. To get the Oracle Identity Governance credential store from Oracle Identity Governance installed on the destination DB:

    1. Login to Oracle Enterprise Manager by using the following URL:

      http://HOST:ADMIN_SERVER_PORT>/em

    2. Navigate to Weblogic Domain, right-click DOMAIN_NAME, and select System MBean Browser.

    3. Under Application Defined MBeans, navigate to com.oracle.jps, Server:OIM_SERVER_NAME, JpsCredentialStore.

    4. Go to Operations, getPortableCredentialMap. Enter the parameter value as oim and Invoke.

      This displays the oim credential map. Note the passwords for OIMSchemaPassword, .xldatabasekey, and DataBaseKey.

  4. To change the keys in the OIM credential store on the source deployment:

    1. OIMSchemaPassword: Navigate to Weblogic Domain, right-click DOMAIN_NAME, and navigate to Security, Credentials. Expand oim, and click OIMSchemaPassword. Click Edit, and enter the new password in Password and Confirm Password fields.

    2. .xldatabasekey: Repeat the same steps for .xldatabasekey.

    3. DataBaseKey: Repeat the same steps for DataBaseKey.

25.1.2.10 Updating the jps-config.xml and jps-config-jse.xml Files

You must update the jps-config.xml anf jps-config-jse.xml files when you are changing the database host or port.

To change the jps-config.xml anf jps-config-jse.xml files:

  1. Navigate to the $DOMAIN_HOME/config/fmwconfig/ directory.
  2. Open the jps-config.xml file in a text editor.
  3. Search for the jdbc.url parameter.
  4. Change the database host name or port.
  5. Save the file.
  6. Open the jps-config-jse.xml file in a text editor.
  7. Search for the jdbc.url parameter.
  8. Change the database host name or port.
  9. Search for the audit.loader.jdbc.string parameter.
  10. Change the database host name or port.
  11. Save the file.
(Optional) Enter the result of the procedure here.

25.1.3 Changing Oracle Virtual Directory Host and Port

When LDAP synchronization is enabled, Oracle Identity Governance connects with directory servers through Oracle Virtual Directory (OVD). This connection takes place by using LDAP/LDAPS protocol.

To change OVD host and port:

  1. Login to Oracle Identity System Administration.

  2. Under Provisioning Configuration, click IT Resource.

  3. From the IT Resource Type list, select Directory Server , and click Search.

  4. Edit the Directory Server IT resource. To do so:

    1. If the value of the Use SSL field is set to False, then edit the Server URL field. If the value of the Use SSL field is set to True, then edit the Server SSL URL field.

    2. Click Update.

25.1.4 Changing BI Publisher Host and Port

You can change the BI Publisher host and port in the jms_cluster_config.properties file, after which you must restart BI Publisher server.

To change BI Publisher host and port:

  1. Login to Enterprise Manager by using the following URL when the WebLogic Administrative Server and Oracle Identity Governance managed servers, at least one of the servers in case of a clustered deployment, are running:

    http://ADMIN_SERVER/em

  2. Navigate to Identity and Access, oim.

  3. Right-click oim, and navigate to System MBean Browser.

  4. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.DiscoveryConfig, Discovery.

  5. Enter a new value for the BIPublisherURL attribute, for example http://bi.example.com, and click Apply to save the changes.

  6. To change the BI Publisher host and port in jms_cluster_config.properties file:

    1. Go to the DOMAIN_NAME/config/bipublisher/repository/Admin/Scheduler/ directory.

    2. In a text editor, open the jms_cluster_config.properties file, and replace the BI Publisher host and port.

    3. Save the jms_cluster_config.properties file.

    4. Restart BI Publisher server.

25.1.5 Changing SOA Host and Port

You change SOA JNDIProvider host and port when additional SOA nodes are added or removed.

To change the SOA host and port:

Note:

When additional SOA nodes are added or removed, perform this procedure to change the SOA host and port.

  1. Login to Enterprise Manager by using the following URL when the WebLogic Administrative Server and Oracle Identity Governance managed servers, at least one of the servers in case of a clustered deployment, are running:

    http://ADMIN_SERVER/em

  2. Navigate to Identity and Access, oim.

  3. Right-click oim, and navigate to System MBean Browser.

  4. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, SOAConfig.

  5. Change the value of the Rmiurl attribute, and click Apply to save the changes.

    The Rmiurl attribute is used for accessing SOA EJBs deployed on SOA managed servers. This is the application server URL. For a clustered deployment of Oracle Identity Governance, it is a comma-separated list of all the SOA managed server URLs. Example values for this attribute can be:

    t3://mysoa1.example.com:8001

    t3s://mysoaserver1.example.com:8002,mysoa2.example.com:8002

    t3://mysoa1.example.com:8001,mysoa2.example.com:8002,mysoa3.example.com:8003

  6. Change the SOA JNDIProvider host and port. To do so:

    1. Login to WebLogic Administration Console.

    2. In the Domain Structure section, navigate to OIM_DOMAIN, Services, Foreign JNDI Providers.

    3. Click ForeignJNDIProvider-SOA.

    4. In the Configuration tab, verify that the General subtab is active.

    5. Change the value of Provider URL to the Rmiurl provided in Step 5.

25.1.6 Changing OAM Host and Port

To change OAM host and port, change the values of the AccessServerHost and AccessServerPort attributes and other attributes, as required.

To change the OAM host and port:

  1. Login to Enterprise Manager by using the following URL when the WebLogic Administrative Server and Oracle Identity Governance managed servers, at least one of the servers for a clustered deployment, are running:

    http://ADMIN_SERVER/em

  2. Navigate to Identity and Access, and then to oim.
  3. Right-click oim, and navigate to System MBean Browser.
  4. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SSOConfig, and then SSOConfig.
  5. Change the values of the AccessServerHost and AccessServerPort attributes and other attributes as required, and click Apply to save the changes.

25.2 Password Changes Related to Oracle Identity Governance

Various passwords are used for Oracle Identity Governance configuration because of the architectural and middleware requirements.

This section describes the default passwords and ways to make the changes to the password in Oracle Identity Governance and Oracle WebLogic configuration for any change in the dependent or integrated products.

This section consists of the following topics:

25.2.1 Updating Oracle WebLogic Administrator Credentials

Oracle WebLogic credentials must be updated in Foreign JNDI Provider and SOAAdminPassword in CSF.

Weblogic credentials must be updated in the following places:

  1. Foreign JNDI Provider. To do so:

    1. Login to WebLogic Administrative Console.

    2. In the Domain Structure section, navigate to OIM_DOMAIN, Services, Foreign JNDI Providers.

    3. Click ForeignJNDIProvider-SOA.

    4. In the Configuration tab, verify that the General subtab is active.

    5. Provide weblogic user's new password in the password and confirm password fields.

  2. SOAAdminPassword in CSF. See Changing Oracle Identity Governance Passwords in the Credential Store Framework for details.

25.2.2 Changing Oracle WebLogic Administrator Password

Use the WebLogic Administrative console to change the WebLogic administrator password,

To change Oracle WebLogic administrator password:

  1. Login to WebLogic Administrative console.

  2. Navigate to Security Realms, myrealm, Users and Groups, weblogic, Password.

  3. In the New Password field, enter the new password.

  4. In the Confirm New Password field, re-enter the new password.

  5. Click Apply.

25.2.3 Changing Oracle Identity Governance Administrator Password

During Oracle Identity Governance installation, the installer prompts for the Oracle Identity Governance administrator password. If required, you can change the administrator password after the installation is complete.

To do so, you must login to Oracle Identity Governance Self Service as Oracle Identity Governance administrator. For information about how to change the administrator password, see Changing Enterprise Password in Performing Self Service Tasks with Oracle Identity Governance.

When you change the Oracle Identity Governance system administrator password, you must also update the password in:

  • The OIMAdmin CSF key under the oracle.wsm.security map

  • The sysadmin CSF key under the oim map

Note:

If OAM or OAAM is integrated with Oracle Identity Governance, then you must make corresponding changes in those applications. For more information, refer to OAM and OAAM documentation in the Oracle Technology Network (OTN) Web site by using the following URL:

http://www.oracle.com/technetwork/indexes/documentation/index.html

25.2.4 Changing Oracle Identity Governance Administrator Database Password

System administrator database password can be reset in stand-alone deployment of Oracle Identity Governance and in a deployment that is integrated with OAM.

This section describes resetting Oracle Identity Governance password in the following topics:

25.2.4.1 Resetting Oracle Identity Governance Password

This section describes resetting Oracle Identity Governance password in the following types of deployments:

  • Oracle Identity Governance deployment without LDAP synchronization

  • Oracle Identity Governance deployment with LDAP synchronization enabled

  • Oracle Identity Governance deployment that is integrated with Access Manager (OAM)

Resetting System Administrator password can be performed by using the oimadminpasswd_wls.sh utility, which is available in the OIM_HOME/server/bin/ directory. The steps to run the oimadminpasswd_wls.sh utility are the same for both types of deployment: Oracle Identity Governance with LDAP synchronization enabled and without LDAP synchronization enabled.

25.2.4.2 Resetting System Administrator Database Password in Oracle Identity Governance Deployment

To reset System Administrator database password:

  1. As a prerequisite for running the oimadminpasswd_wls.sh utility, open the OIM_HOME/server/bin/oimadminpasswd_wls.properties file in a text editor, and set values for the following properties:
    • JAVA_HOME: Set this to JDK8, for example:

      JAVA_HOME=/opt/softwares/shiphome/jdk180_131
      
    • COMMON_COMPONENTS_HOME: This is Oracle Middleware common home directory, for example:

      COMMON_COMPONENTS_HOME=/opt/softwares/shiphome/oracle_common
      
    • OIM_ORACLE_HOME: This is Oracle Identity Governance Oracle home directory, for example:

      OIM_ORACLE_HOME=/opt/softwares/shiphome/Oracle_IDM1
      
    • ORACLE_SECURITY_JPS_CONFIG: Specify the jps-config-jse.xml file location present in Oracle Identity Governance Domain, for example:

      ORACLE_SECURITY_JPS_CONFIG=/opt/softwares/shiphome/user_projects/domains/base_domain/config/fmwconfig/jps-config-jse.xml
      
    • DOMAIN_HOME: Specify Oracle Identity Governance Domain Home location of the Weblogic Application Server, for example:

      DOMAIN_HOME=/opt/softwares/shiphome/user_projects/domains/base_domain
      
    • DBURL: Oracle Identity Governance database URL, for example:

      DBURL=jdbc:oracle:thin:@dbhostname:5521:orclsid
      
    • DBSCHEMAUSER: Oracle Identity Governance schema username, for example:

      DBSCHEMAUSER=DEV_OIM
      
    • OIM_OAM_INTG_ENABLED: Set this to false if Oracle Identity Governance deployment is not integrated with Access Manager, for example:

      OIM_OAM_INTG_ENABLED=false
      

    Note:

    Other properties, such as LDAPURL, LDAPADMINUSER, and OIM_ADMIN_LDAP_DN can be ignored as they are used only in an integrated setup between Oracle Identity Governance and Access Manager.

  2. Go to the OIM_HOME/server/bin/ directory, and run the following command:
    sh oimadminpasswd_wls.sh oimadminpasswd_wls.properties
    

    The following is a sample output:

    Enter OIM DB Schema Password :
    Enter OIM Adminstrator xelsysadm new Password:
    Re-enter OIM Adminstrator xelsysadm new Password:
    WARNING: Not able to fetch OIMPlatform instance for the given Platform. Hence defaulting to the OIMWebLogicPlatform
    
    OIM Admin user xelsysadm password reset successfully in OIMDB
    

    Note:

    The warning messages that are displayed while running the oimadminpasswd_wls.sh script can be ignored.

25.2.4.3 Resetting System Administrator Database Password When Oracle Identity Governance Deployment is Integrated With Access Manager

If Oracle Identity Governance is integrated with OAM, then LDAP directory, such as Oracle Internet Directory, is used for all authentication purposes. Therefore, Oracle Identity Governance Administrator xelsysadm password is reset in LDAP. Although the xelsysadm password present in Oracle Identity Governance database is not used in this topology, it is also reset along with LDAP directory to ensure that the passwords in both repositories are in sync.

To reset System Administrator database password when Oracle Identity Governance Deployment is Integrated With Access Manager:

  1. As a prerequisite for running the oimadminpasswd_wls.sh utility, open the OIM_HOME/server/bin/oimadminpasswd_wls.properties file in a text editor, and set values for the following properties:
    • JAVA_HOME: Set this to JDK8, for example:

      JAVA_HOME=/opt/softwares/shiphome/jdk180_131
      
    • COMMON_COMPONENTS_HOME: This is Oracle Middleware common home directory, for example:

      COMMON_COMPONENTS_HOME=/opt/softwares/shiphome/oracle_common
      
    • OIM_ORACLE_HOME: This is Oracle Identity Governance Oracle home directory, for example:

      OIM_ORACLE_HOME=/opt/softwares/shiphome/Oracle_IDM1
      
    • ORACLE_SECURITY_JPS_CONFIG: Specify the jps-config-jse.xml file location present in Oracle Identity Governance Domain, for example:

      ORACLE_SECURITY_JPS_CONFIG=/opt/softwares/shiphome/user_projects/domains/base_domain/config/fmwconfig/jps-config-jse.xml
      
    • DOMAIN_HOME: Specify Oracle Identity Governance Domain Home location of the Weblogic Application Server, for example:

      DOMAIN_HOME=/opt/softwares/shiphome/user_projects/domains/base_domain
      
    • DBURL: Oracle Identity Governance database URL, for example:

      DBURL=jdbc:oracle:thin:@dbhostname:5521:orclsid
      
    • DBSCHEMAUSER: Oracle Identity Governance schema username, for example:

      DBSCHEMAUSER=DEV_OIM
      
    • OIM_OAM_INTG_ENABLED: Set this to true if Oracle Identity Governance deployment is integrated with Access Manager, for example:

      OIM_OAM_INTG_ENABLED=true
      
    • LDAPURL: LDAP directory URL. Non-SSL port must be specified, for example:

      LDAPURL=ldap://LDAP_HOSTNAME:3060
      
    • LDAPADMINUSER : LDAP directory admin username, for example:

      LDAPADMINUSER=cn=orcladmin
      
    • OIM_ADMIN_LDAP_DN: Oracle Identity Governance Administrator xelsysadm complete DN in the LDAP directory, for example:

      OIM_ADMIN_LDAP_DN=cn=xelsysadm,cn=Users,dc=us,dc=example,dc=com
      
  2. Go to the OIM_HOME/server/bin/ directory, and run the following command:
    sh oimadminpasswd_wls.sh oimadminpasswd_wls.properties
    

    The following is a sample output:

    Enter OIM DB Schema Password :
    Enter OIM Adminstrator xelsysadm new Password:
    Re-enter OIM Adminstrator xelsysadm new Password:
    WARNING: Not able to fetch OIMPlatform instance for the given Platform. Hence defaulting to the OIMWebLogicPlatform
    
    OIM Admin user xelsysadm password reset successfully in OIMDB
    OIM Admin user cn=xelsysadm,cn=Users,dc=...,dc=...,dc=... password reset successfully in LDAP
    

    Note:

    • The warning messages that are displayed while running the oimadminpasswd_wls.sh script can be ignored.

    • The xelsysadm password expiry setting is not set to expire until 2035. During integration between Oracle Identity Governance and Access Manager, the obpasswordexpirydate setting for the xelsysadm user is set to "2035-01-01T00:00:00Z". If this value has been changed, then revert it to "2035-01-01T00:00:00Z" for xelsysadm. This value is initially loaded from a following template LDIF file:

      $OIM_ORACLE_HOME/idmtools/templates/oid/idm_xelsysadmin_user.ldif

25.2.5 Changing Oracle Identity Governance Database Password

Oracle Identity Governance uses two database schemas for storing Oracle Identity Governance operational and configuration data. It uses Oracle Identity Governance MDS schema for storing configuration-related information and Oracle Identity Governance schema for storing other information. Any change in the schema password requires changes on Oracle Identity Governance configuration.

Changing Oracle Identity Governance database password involves the following:

After changing the Oracle Identity Governance database password, restart the WebLogic Administrative Server. Start the Oracle Identity Governance managed WebLogic Servers as well.

Note:

Before changing the database password, shutdown the managed servers that host Oracle Identity Governance. However, you can keep the Oracle WebLogic Administrative Server running.

25.2.5.1 Changing Datasource oimJMSStoreDS Configuration

To change datasource oimJMSStoreDS configuration:

  1. Navigate to Services, JDBC, Data Sources, oimJMSStoreDS.
  2. Click the Connection Pool tab.
  3. In the Password and Confirm password fields, enter the new Oracle Identity Governance database schema password.
  4. Click Save to save the changes.
25.2.5.2 Changing Datasource ApplicationDB Configuration

To change datasource ApplicationDB configuration:

  1. Navigate to Services, JDBC, Data Sources, ApplicationDB.
  2. Click the Connection Pool tab.
  3. In the Password and Confirm password fields, enter the new Oracle Identity Governance database schema password.
  4. Click Save to save the changes.
25.2.5.3 Changing Datasource soaOIMLookupDB Configuration

To change datasource soaOIMLookupDB configuration:

  1. Navigate to Services, JDBC, Data Sources, and then soaOIMLookupDB.
  2. Click the Connection Pool tab.
  3. Modify the values of the URL and Properties fields to reflect the changes to database host and port.
  4. Click Save to save the changes.
25.2.5.4 Changing Datasource oimOperationsDB Configuration

To change datasource oimOperationsDB configuration:

  1. Navigate to Services, JDBC, Data Sources, oimJMSStoreDS.
  2. Click the Connection Pool tab.
  3. In the Password and Confirm password fields, enter the new Oracle Identity Governance database schema password.
  4. Click Save to save the changes.
25.2.5.5 Changing Datasource Related to Oracle Identity Governance Meta Data Store

To change datasource related to Oracle Identity Governance MDS configuration:

  1. Navigate to Services, JDBC, Data Sources, mds-oim.
  2. Click the Connection Pool tab.
  3. In the Password and Confirm password fields, enter the new Oracle Identity Governance MDS database schema password.
  4. Click Save to save the changes.

Note:

  • For Oracle Identity Governance deployments with Oracle Real Application Clusters (Oracle RAC) configuration, you might have to make changes in all the datasources under the respective multi-datasource configurations.

  • You might have to make similar changes for datasources related to SOA or OWSM, if required.

25.2.5.6 Changing OIMAuthenticationProvider Configuration

To change OIMAuthenticationProvider configuration:

  1. In the WebLogic Administrative console, navigate to Security Realms, myrealm, and then Providers.
  2. Click OIMAuthenticationProvider.
  3. Click Provider Specific.
  4. In the DBPassword field, enter the new Oracle Identity Governance database schema password.
  5. Click Save to save the changes.
25.2.5.7 Changing Domain Credential Store Configuration

To change domain credential store configuration:

  1. Login to Enterprise Manager by using the following URL:

    http://ADMIN_SERVER/em

  2. Navigate to Weblogic Domain, and then DOMAIN_NAME.
  3. Right click oim, and navigate to Security, Credentials, and then oim.
  4. Select OIMSchemaPassword, and click Edit.
  5. In the Password field, enter the new password, and click OK.
25.2.5.8 Changing the Oracle Identity Governance Database Password in BI Publisher

To change the Oracle Identity Governance database password in BI Publisher:

  1. Login to BI Publisher.
  2. Click the Administration tab.
  3. Click JDBC Connection under Data Sources.
  4. Click OIM JDBC, and change the password in the Password field.
  5. Click Test Connection. The connection is established successfully after confirmation.
  6. Click Apply.

25.2.6 About Credential Store Framework Keys

Oracle Identity Governance installer stores several passwords during the install process. Various values are stored in Credential Store Framework (CSF) as key and value.

Table 25-1 lists the keys and the corresponding values:

Table 25-1 CSF Keys

Key Description

DataBaseKey

The password for the key used to encrypt database. The password is the user input value in the installer for the Oracle Identity Governance keystore.

.xldatabasekey

The password for keystore that stores the database encryption key. The password is the user input value in the installer for the Oracle Identity Governance keystore.

xell

The password for key 'xell', which is used for securing communication between Oracle Identity Governance components. Default password generated by Oracle Identity Governance installer is xellerate.

default_keystore.jks

The password for the default_keystore.jks JKS keystore in the DOMAIN_HOME/config/fmwconfig/ directory. The password is the user input value in the installer for the Oracle Identity Governance keystore.

SOAAdminPassword

The password is user input value in the installer for SOA Administrator Password field.

OIMSchemaPassword

The password for connecting to Oracle Identity Governance database schema. Password is user input value in the installer for OIM Database Schema Password field.

JMSKey

The password is the user input value in the installer for the Oracle Identity Governance keystore.

25.2.7 Changing Oracle Identity Governance Passwords in the Credential Store Framework

To change Oracle Identity Governance password in the CSF, edit the Directory Server IT resource.

To change the values of the CSF keys:

  1. Login to Oracle Enterprise Manager by navigating to the following URL:

    http://ADMIN_SERVER/em

  2. Navigate to Weblogic Domain, DOMAIN_NAME.
  3. Right-click oim, and select Security, Credentials.
  4. Edit the Directory Server IT resource. To do so, in the Admin Password field, enter the new OVD password, and click Update.

25.2.8 Changing OVD Password

Edit the Directory Server IT resource and specify the new OVD password in the Admin Password field.

To change the OVD password:

  1. Login to Oracle Identity Governance Administration.
  2. Click Advanced.
  3. Under Configuration, click Manage IT Resource.
  4. From the IT Resource Type list, select Directory Server.
  5. Click Search.
  6. Edit the Directory Server IT resource. To do so, in the Admin Password field, enter the new OVD password, and click Update.

25.2.9 Changing Oracle Identity Governance Administrator Password in LDAP

To change Oracle Identity Governance System Administrator password in LDAP in a Oracle Identity Governance deployment that is SSO-enabled and integrated with OAM, search for the dn for the user from LDAP, create a temporary file with the new password, and then use the file to change the password.

To change Oracle Identity Governance System Administrator password in LDAP in a Oracle Identity Governance deployment that is SSO-enabled and integrated with Access Manager (OAM):

  1. Look up the dn for the user from LDAP, as shown:
    $ORACLE_HOME/bin/ldapsearch -D cn=orcladmin -w fusionapps1 -h localhost -p 6501 -b dc=com "cn=SYS_ADMIN" orclaccountlocked dn
    

    Here, SYS_ADMIN is the System Administrator user login.

  2. Create a file similar to the following:
    $ more /tmp/resetpassword_SYS_ADMIN
    
    dn: cn=SYS_ADMIN,cn=Users,dc=us,dc=example,dc=com
    changetype: modify
    replace: userPassword
    userPassword: NEW_PASSWORD
    

    Here, NEW_PASSWORD is the password that you want in clear text.

  3. Change the password, as shown:
    $ORACLE_HOME/bin/ldapmodify -D cn=orcladmin -w fusionapps1 -h localhost -p 6501 -f /tmp/ resetpassword _SYS_ADMIN
    
  4. Verify that the user password is changed, as shown:
    $ORACLE_HOME/bin/ldapbind -D 'cn=SYS_ADMIN,cn=Users,dc=us,dc=example,dc=com' -w NEW_PASSWORD -h localhost -p 6501
    

25.2.10 Unlocking Oracle Identity Governance Administrator Password in LDAP

To unlock Oracle Identity Governance System Administrator password in LDAP in a Oracle Identity Governance deployment that is SSO-enabled and integrated with OAM, search for the dn for the user from LDAP, create a temporary file for unlocking the password, and then use the file unlock the System Administrator password.

To unlock Oracle Identity Governance System Administrator password in LDAP in a Oracle Identity Governance deployment that is SSO-enabled and integrated with OAM:

  1. Look up the dn for the user from LDAP, as shown:
    $ORACLE_HOME/bin/ldapsearch -D cn=orcladmin -w fusionapps1 -h localhost -p 6501 -b dc=com "cn=SYS_ADMIN" orclaccountlocked dn
    

    If orclaccountlocked has a value of 1, then it means that the user is locked.

  2. Create a file similar to the following:
    $ more /tmp/unlock_SYS_ADMIN
    
    dn: cn=SYS_ADMIN,cn=Users,dc=us,dc=example,dc=com
    changetype: modify
    replace: orclaccountlocked
    orclaccountlocked: 0
    
  3. Unlock the user, as shown:
    $ORACLE_HOME/bin/ldapmodify -D cn=orcladmin -w fusionapps1 -h localhost -p 6501 -f /tmp/unlock_SYS_ADMIN
    
  4. Verify that the user is unlocked, as shown:
    $ORACLE_HOME/bin/ldapsearch -D cn=orcladmin -w fusionapps1 -h localhost -p 6501 -b dc=com "cn=SYS_ADMIN" orclaccountlocked dn
    

    The value of orcladdountlocked must be 0.

25.2.11 Changing Schema Passwords

Changing schema passwords include changing the passwords for the OIG, MDS, SOAINFRA, OPSS, ORASDPM, and BI Publisher schemas.

To change OIG, MDS, SOAINFRA, OPSS, ORASDPM, and BI Publisher schema passwords:

  1. Stop all the Managed Servers and application server.

  2. Create a backup of the entire domain and the database.

  3. Start the application server.

  4. Change the xxxx_OPSS user password. To do so:

    1. Run the following command:

      SQL> alter user xxxx_OPSS identified by NEW_PASSWORD;
      
    2. Go to the ORACLE_COMMON/common/bin/ directory, and run the wlst command.

    3. Run the modifyBootStrapCredential script, as shown:

      modifyBootStrapCredential(jpsConfigFile='DOMAIN_NAME/config/fmwconfig/jps-config.xml', username='xxxx_OPSS', password='NEW_PASSWORD')
      
  5. Login to Weblogic Administrative Console. Navigate to Services, Data Sources.

  6. Select opss-DBDS, Connection Pool, and enter the new password set to xxxx_opss in step 4a. Save the changes.

  7. Restart the application server, but do not start the Managed Servers.

  8. Connect to the database with sqlplus as system user, and then run the following commands:

    1. To change the password for xxx_OIM, run:

      SQL> alter user xxx_OIM identified by NEW_PASSWORD;
      
    2. To change the password for xxx_MDS, run:

      SQL> alter user xxx_MDS identified by NEW_PASSWORD;
      
    3. To change the password for xxx_SOAINFRA, run:

      SQL> alter user xxx_SOAINFRA identified by NEW_PASSWORD;
      
    4. To change the password for xxx_ORASDPM, run:

      SQL> alter user xxx_ORASDPM identified by NEW_PASSWORD;
      
    5. To change the password for xxx_BIPLATFORM, run:

      SQL> alter user xxx_BIPLATFORM identified by NEW_PASSWORD;
      
  9. Verify that the passwords have been changed. To do so, login to the database with sqlplus and the four users and the new passwords.

  10. Login to the WebLogic Administrative Console.

  11. Go to Services, Data Sources, and then perform the following:

    1. Select soaOIMLookupDB, Connection Pool, and enter the new password set to xxx_OIM in step 12a.

    2. Select oimJMSStoreDS, Connection Pool, and enter the new password set to xxx_OIM in step 12a.

    3. Select oimOperationsDB, Connection Pool, and enter the new password set to xxx_OIM in step 12a.

    4. Select ApplicationDB, Connection Pool, and enter the new password set to xxx_OIM in step 12a.

    5. Select mds-oim, Connection Pool, and enter the new password set to xxx_MDS in step 12b.

    6. Select mds-owsm, Connection Pool, and enter the new password set to xxx_MDS in step 12b.

    7. Select mds-soa, Connection Pool, and enter the new password set to xxx_MDS in step 12b.

    8. Select EDNDataSource, Connection Pool, and enter the new password set to xxx_SOAINFRA in step 12c.

    9. Select EDNLocalTxDataSource, Connection Pool, and enter the new password set to xxx_SOAINFRA in step 12c.

    10. Select SOADataSource, Connection Pool, and enter the new password set to xxx_SOAINFRA in step 12c.

    11. Select SOALocalTxDataSource, Connection Pool, and enter the new password set to xxx_SOAINFRA in step 12c.

    12. Select OraSDPMDataSource, Connection Pool, and enter the new password set to xxx_ORASDPM in step 12d.

  12. Change OIMAuthenticationProvider configuration. To do so:

    1. In the WebLogic Administrative Console, navigate to Security Realms, myrealm, and then Providers.

    2. Click OIMAuthenticationProvider.

    3. Click Provider Specific.

    4. In the DBPassword field, enter the new Oracle Identity Governance database schema password.

    5. Click Save to save the changes.

  13. Change the domain credential store configuration. To do so:

    1. Login to Oracle Enterprise Manager.

    2. Navigate to Weblogic Domain, and then DOMAIN_NAME.

    3. Right-click the domain name, and select Security, Credentials, and then oim.

    4. Select OIMSchemaPassword, and click Edit.

    5. In the Password field, enter the new password, and then click OK.

  14. Change the oim and soa schema password in BI Publisher. To do so:

    1. Login to BI Publisher.

    2. Click the Administration tab.

    3. Click JDBC Connection under Data Sources.

    4. Click OIM JDBC, and change the password in the Password field.

    5. Click Test Connection. The connection is established successfully after confirmation.

    6. Click Apply.

    7. Repeat the steps 14d through 14f for JDBC data source BPEL JDBC.

  15. If BI Publisher schema password is changed, then perform the following steps:

    1. Login to Oracle Enterprise Manager.

    2. Expand WebLogic Domain, DOMAIN_NAME.

    3. Under the DOMAIN_NAME on the right pane, from the WebLogic Domain list, select JDBC Data Sources.

    4. Select bip_datasource in the table, and then click Edit on the toolbar.

    5. Click the Connection Pool tab. In the Database Connection Information section, change the password, and then click Apply on the upper right corner.

    6. Start BI Publisher services.

  16. Restart WebLogic Admin Server.

  17. Start the SOA and Oracle Identity Governance Managed Servers.

25.3 Configuring SSL for Oracle Identity Governance

Configuring SSL for Oracle Identity Governance includes generating keys, signing and exporting certificates, setting up SSL Configuration for Oracle Identity Governance and for the components with which Oracle Identity Governance interacts, and establish secure communication between them.

A SHA-2 compliant certificate is a prerequisite for using TLS v1.2 protocol for SSL communication.

Note:

  • For information related to IBM Java 7, SR4 version support of SHA-2 cipher suites and Transport Layer Security (TLS) version 1.2 refer to IBM documentation.

  • In the following sections several examples are provided. They have parameters which are used to enable more debugging information and are optional. For example:

    -Dweblogic.StdoutDebugEnabled=true -Dssl.debug=true -Djavax.net.debug=ssl:handshake:verbose.

For Oracle JDK 8, download and apply latest Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. Relocate the local_policy.jar and US_export_policy.jar jars files into <JAVA_HOME>/jre/lib/security directory.

Note:

If Opatch version is lesser than 12.1.0.1.10, then upgrade the OPatch utility by applying p21142429_121010_Linux-x86-64.zip patch.

Apply p23176395_121020_Generic.zip patch to DB_HOME to get the support of TLS v1.2 on Oracle 12c DB (12.1.0.2).

Apply p13964737_1036_Generic.zip Weblogic patch via BSU if Demo Identity and Demo trust is used at Weblogic Level.

This section contains the following topics:

Note:

25.3.1 Generating Custom Key Stores (Optional)

This section includes the following topics:

Note:

The procedures described in this section are optional. These steps are required if you have custom identity and trust store for WebLogic servers. SSL can be enabled with default identity and trust store as well.

25.3.1.1 Creating the Custom Identity Store

You can generate private and public certificate pairs by using the keytool command.

The following command creates an identity keystore (oimsupportidentity.jks).

$JAVA_HOME/jre/bin/keytool -genkey -alias ALIAS -keyalg ALGORITHM -keysize KEY_SIZE -sigalg SIGN_ALORITHM -dname DISTINGUISHED_NAME -keypass KEY_PASSWORD -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD

For example:

$JAVA_HOME/jre/bin/keytool -genkey -alias supportpvtkey -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -dname "CN=oimhost.example.com, OU=Identity, O=ORGANIZATION_NAME,C=US" -keypass privatepassword -keystore oimsupportidentity.jks -storepass password

Note:

  • Change the parameter values passed to the keytool command according to your requirements. Ensure that there is no line break in the keytool argument.

  • The custom identity keystore, oimsupportidentity.jks must be created or copied under WL_HOME/server/lib/.

  • In this is release, JDK 8u131 is used. Therefore, the value of the keysize option must be greater than or equal to 1024. For more information about this limitation, see JDK8u131 Update Release Notes.

25.3.1.2 Self Signing the Certificates of Custom identity keystore

Use the keytool command by passing the required parameter values to self sign the certificates you created.

Run the following keytool command to sign the certificates that you created:

$JAVA_HOME/jre/bin/keytool -selfcert ALIAS -keyalg ALGORITHM -keysize KEY_SIZE -sigalg SIGN_ALORITHM -dname DISTINGUISHED_NAME -keypass KEY_PASSWORD -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD

For example:

$JAVA_HOME/jre/bin/keytool -selfcert -alias supportpvtkey
-sigalg SHA256withRSA -validity 2000 -keypass privatepassword
-keystore oimsupportidentity.jks
-storepass password

Note:

Change the parameter values passed to the keytool command according to your requirements. Ensure that there is no line break in the keytool argument.

25.3.1.3 Exporting the Certificate From Custom Identity Keystore

Use the keytool command to export the certificate from the identity keystore to a file, for example, supportcert.pem.

Run the following keytool command:

$JAVA_HOME/jre/bin/keytool -export -alias ALIAS -file FILE_TO_EXPORT -keypass KEY_PASSWORD -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD

For example, the following command exports the certificate to a file named supportpvtkeycert.pem:

$JAVA_HOME/jre/bin/keytool -export -alias supportpvtkey
-file supportpvtkeycert.pem
-keypass password
-keystore oimsupportidentity.jks
-storepass password
25.3.1.4 Importing the Certificate of Custom Identity to Trust Store

If custom trust store is used, then import the certificate in that custom trust store. If Java Standard Trust is used as trust store then import the certificate in that Java Standard Trust, such as JAVA_HOME/jre/lib/security/cacerts.

Use the keytool command to import the certificate from a file. The syntax is:

keytool -import -alias ALIAS -trustcacerts -file FILE_TO_IMPORT -keystore KEYSTORE_NAME -storepass KEYSTORE_PASSWORD 

In the following example, the certificate file supportpvtkeycert.pem is imported to the identity keystore oimsupporttrust.jks:

$JAVA_HOME/jre/bin/keytool -import -alias supportpvtkey -trustcacerts -file supportpvtkeycert.pem -keystore oimsupporttrust.jks -storepass <password>

Note:

This command loads a trusted CA certificate into a custome keystore oimsupporttrust.jks. If the keystore does not exist, it is created.

This custom trust keystore oimsupporttrust.jks must be created or copied under DOMAIN_HOME/config/fmwconfig/.

Change the parameter values passed to the keytool command according to your requirements. Ensure that there is no line break in the keytool argument.

25.3.2 Configuring Custom Key Stores (Optional)

Note:

See Generating Custom Key Stores (Optional) for information about generating custom keys.

Perform the following steps to configure custom key stores:
  1. In the WebLogic Server Administration Console, click Environment, Servers, Server_Name (OIM_Server1), Configuration, and then General.
  2. Click Lock & Edit.
  3. Select SSL listen port enabled. The default SSL port is 14002 and 14001 for non-SSL.
  4. Select the Keystores tab.
  5. From the Keystore list, select Custom Identity and Custom Trust.

    Note:

    If you have created only custom identity and using java standard trust, then select the Custom Identity, Java Standard Trust option.

  6. Copy the custom identity keystore file, say oimsupportidentity.jks, under the WL_HOME/server/lib/ directory. Enter the absolute path of this key store (WL_HOME/server/lib/oimsupportidentity.jks) in the Custom Identity Keystore field.
  7. Specify JKS as the custom identity keystore type.
  8. Type the password (password) into the Custom Identity Keystore Passphrase and the Confirm Custom Identity Keystore Passphrase fields.

    Note:

    If you are creating a custom trust keystore, then perform the steps 6 to 8 of this section for custom trust keystore field with path DOMAIN_HOME/config/fmwconfig/oimsupporttrust.jks.

  9. Click Save.
  10. Click the SSL tab.
  11. Type supportpvtkey as the private key alias.
  12. Type the password (password) into the Private Key Passphrase and the Confirm Private Key Passphrase fields.
  13. Click Save.
  14. Perform similar steps (steps 1 through 13) for Admin and SOA Servers.
  15. Click Activate changes.
  16. Import the certificate that you exported in Exporting the Certificate From Custom Identity Keystore into the SPML client truststore and Java Standard Trust Store, and WebLogic trust store:
    MW_HOME/wlserver_10.3/server/lib/cacerts

    For example:

    ./keytool -importcert -alias startssl -keystore MW_HOME/wlserver_10.3/server/lib/cacerts -storepass password
     -file supportpvtkeycert.pem JAVA_HOME/jre/lib/security/cacerts
    

    For example:

    ./keytool -importcert -alias startssl -keystore JAVA_HOME/jre/lib/security/cacerts -storepass password -file supportpvtkeycert.pem

    Note:

    Where password is the default password for Java's Standard truststore (JAVA_HOME/jre/lib/security/cacerts).

    See Importing the Certificate of Custom Identity to Trust Store for information about importing the certificate.

  17. The database trust keystore created at DOMAIN_HOME/config/fmwconfig/ by Oracle Identity Governance during installation is default-keystore.jks by default. If you are using a different name for truststore than the default name, which is dbcustomtrust-keystore.jks, then perform the following steps:
    1. Add Oracle Identity Governance Credential store map key. If you are using any other name, such as dbcustomtrust-keystore.jks, then create a key in the credential store by using Oracle Enterprise Manager as default-keystore.jks is created with Oracle Identity Governance configuration by default. To create a key in the credential store:
      1. Login to Oracle Enterprise Manager.

      2. Expand Weblogic Domain, DOMAIN_NAME. Right-click DOMAIN_NAME, and select Security, Credentials.

      3. In the Credential Store Provider table, click oim.

      4. Create a key with type as Password and with the credentials, User Name: dbcustomtrust-keystore.jks, Password: password.

    2. Change DirectDB, SSLConfig config in the oim-Config.xml file either by exporting/importing this file from MDS or by using Enterprise Manager. For the latter, navigate to oracle.iam, XMLConfig, DirectDB, SSLConfig in Application Defined MBeans section of System Mbean Browser, and then change the SSL parameters, for example:
      SSLConfig dBTrustStore="dbcustomtrust-keystore.jks"
      SSLConfig DBTrustStorePasswordKey = NAME_OF_CSF_KEY

Note:

If the CN of the certificate is not the same as the hostname of the machine where WLS is installed, then you need to select the hostname verification as None. To do so, go to SSL tab, Advanced section, select None from the Hostname Verification list.

25.3.3 Enabling SSL for Oracle Identity Governance and SOA Servers

Enabling SSL for Oracle Identity Governance servers and other managed servers involves enabling SSL for Oracle Identity Governance, changing OimFrontEndURL and backOfficeURL to use SSL Port, and changing SOA server URL to use SSL port.

You need to perform the following configurations in Oracle Identity Governance and SOA servers to enable SSL:

25.3.3.1 Enabling SSL for Oracle Identity Governance
25.3.3.1.1 Enabling SSL for Oracle Identity Governance By Using Default Setting

To enable SSL for Oracle Identity Governance and SOA servers by using default setting:

  1. Log in to WebLogic Server Administrative console and go to Servers, OIM_SERVER1, General. Under the general section, you can enable ssl port to any value and activate it.
  2. The server will start listening and you can access the URL with HTTPS protocol.
  3. Perform the same steps for Admin/SOA Servers as Oracle Identity Governance might need to interact with SSL-enabled SOA Server.

    Note:

    • If JDK 7u40 or later is used, then the value of the keysize option must be greater than or equal to 1024. For more information about this limitation, see "Default x.509 Certificates Have Longer Key Length" at the following URL:

      http://www.oracle.com/technetwork/java/javase/7u40-relnotes-2004172.html

    • If SSL is configured by using the default certificates as described in this section, then apply p13964737_1036_Generic.zip. You can download this patch from the My Oracle Support web site at:

      https://support.oracle.com

  4. Restart all servers for the changes to take effect.
    Ensure that when only SSL listen port is enabled on Oracle Identity Governance server and non-SSL listen port is disabled, you must set the value of the providerURL JVM system property to point to the Oracle Identity Governance RMI t3s URL, as follows:

    For instance, on Linux, if you are using csh shell, then set the environment variable in the following way:

    setenv SSL_CONFIG_PARAMS="-Dweblogic.security.TrustKeyStore=DemoTrust -Dweblogic.security.SSL.ignoreHostnameVerification=true -DproviderURL=t3s://<hostname>:<port>"
    For bash, set the following:
    export SSL_CONFIG_PARAMS=“-Dweblogic.security.TrustKeyStore=DemoTrust -Dweblogic.security.SSL.ignoreHostnameVerification=true -DproviderURL=t3s://<hostname>:<port>”

    On Microsoft Windows, set the environment variable in the following way:

    SET SSL_CONFIG_PARAMS=-Dweblogic.security.TrustKeyStore=DemoTrust -Dweblogic.security.SSL.ignoreHostnameVerification=true -DproviderURL=t3s://<hostname>:<port>
25.3.3.1.2 Enabling SSL for Oracle Identity Governance By Using Custom Identity and Custom Trust

To enable SSL for Oracle Identity Governance by using custom identity and custom trust:

Note:

See Generating Custom Key Stores (Optional) and Configuring Custom Key Stores (Optional) for information about generating custom keys.
  1. In the DOMAIN_HOME/bin/setDomainEnv.sh file for UNIX or DOMAIN_HOME\bin\setDomainEnv.cmd for Microsoft Windows. Locate the line # SET THE CLASSPATH and add the following:
    TLS_JAVA_OPTIONS=" -Dweblogic.management.username=username -Dweblogic.management.password=password -Djavax.net.ssl.trustStore=$TRUSTSTORE_LOCATION -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.SSL.enforceConstraints=off -Dweblogic.ssl.JSSEEnabled=true -Dweblogic.security.SSL.enableJSSE=true -Dweblogic.security.SSL.protocolVersion=TLSv1.3 -Dhttps.protocols=TLSv1.3 -Djdk.tls.client.protocols=TLSv1.3 -Djdk.tls.disabledAlgorithms=SSLv2Hello,SSLv3,TLSv1,TLSv1.1,TLSv1.2 -Dssl.debug=true -Djavax.net.debug=ssl:handshake:verbose "
     
    JAVA_OPTIONS="${JAVA_OPTIONS} ${TLS_JAVA_OPTIONS}"
    export JAVA_OPTIONS

    Here, the value of TRUSTSTORE_LOCATION in case of custom trust store is:

    DOMAIN_HOME/config/fmwconfig/oimsupporttrust.jks

    The value of TRUSTSTORE_LOCATION in case of Demo trust store is:

    ${WL_HOME}/server/lib/DemoTrust.jks

    The value of TRUSTSTORE_LOCATION in case of Java Standard Trust store is:

    $JAVA_HOME/jre/lib/security/cacerts

    Note:

    • These settings work with JDK7u131, Use -Dssl.debug=true -Djavax.net.debug=ssl:handshake:verbose only for enabling SSL debugging information.

    • Stop Weblogic.sh is not supporting to pass or set the trust store in use. These scripts use Java standard trust. Import certificate in Java standard trust along with custom trust store while doing the basic SSL configurations.

  2. In a text editor, open the startManagedWebLogic.sh file and do the following:
    1. Change the value of ADMIN_URL to point to a SSL URL. For example:
      ADMIN_URL="https://myhost.example.com:7002"
    2. Comment out below line:
      #JAVA_OPTIONS="-Dweblogic.security.SSL.trustedCAKeyStore="WL_HOME/server/lib/cacerts" ${JAVA_OPTIONS}"
      #export JAVA_OPTIONS

      Save the startManagedWebLogic.sh file.

  3. Restart all servers for the changes to take effect.

    Ensure that when only SSL listen port is enabled on Oracle Identity Governance server and non-SSL listen port is disabled, you must set the value of the providerURL JVM system property to point to the Oracle Identity Governance RMI t3s URL, as follows:

    -DproviderURL=t3s://OIM_HOST:OIM_SSL_PORT

    This can be done by setting the value of the JAVA_OPTIONS environment variable before starting Oracle Identity Governance Managed Server from the command prompt.

    For instance, on Linux, if you are using csh shell, then set the environment variable in the following way:

    setenv JAVA_OPTIONS -DproviderURL=t3s://OIM_HOST:OIM_SSL_PORT

    For bash, set the following:

    export JAVA_OPTIONS=-DproviderURL=t3s://OIM_HOST:OIM_SSL_PORT

    On Microsoft Windows, set the environment variable in the following way:

    SET JAVA_OPTIONS=-DproviderURL=t3s://OIM_HOST:OIM_SSL_PORT

    If Oracle Identity Governance server is managed through Node Manager, then add the following as an argument under oim_server, Configuration, Server start, Arguments.

    -DproviderURL=t3s://OIM_HOST:OIM_SSL_PORT

    Backup the WL_HOME/common/nodemanager/nodemanager.properties file. Open the file and add the following:

    KeyStores=CustomIdentityAndCustomTrust
    CustomIdentityKeyStoreType=JKS
    CustomIdentityKeyStoreFileName=DOMAIN_HOME/config/fmwconfig/oimsupporttrust.jks
    CustomIdentityAlias=supportpvtkey
    CustomIdentityKeyStorePassPhrase=password
    CustomIdentityPrivateKeyPassPhrase=privatepassword

    Ensure that the path, alias, and password is updated as per the AdminServer configuration.

    Note:

    Oracle Identity Governance can connect to SOA via web services. If web service invocation fails, then SOA cannot connect to Oracle Identity Governance, and as a result, requests can be stuck. For example, after a create user request is approved, the request might be stuck because the corresponding SOA composite is not able to invoke the request web service deployed on Oracle Identity Governance server, which is SSL-enabled. To avoid such issues, set JAVA_OPTIONS in the in setDomainEnv.sh file, for example, with:

    -Djavax.net.ssl.trustStore==DOMAIN_HOME/config/fmwconfig/oimsupporttrust.jks
25.3.3.2 Changing OimFrontEndURL to Use Oracle Identity Governance SSL Port

To change the OimFrontEndURL to use Oracle Identity Governance SSL port:

  1. When the WebLogic admin and Oracle Identity Governance managed servers (at least one of the servers in case of cluster) are running, log in to Enterprise Manager (EM).

    For example:

    http://<AdminServer>/em

  2. Click WebLogic Doman, and select System MBean Browser.
  3. Under Application Defined MBeans, navigate to oracle.iam, Server:<oim_servername>, Application:oim, XMLConfig, Config, XMLConfig.DiscoveryConfig, Discovery.

    In a clustered deployment, when you select oracle.iam under Application Defined MBeans, Oracle Identity Governance server name is displayed. Select the server and continue with the navigation.

    Note:

    In a clustered deployment, the change to the OimFrontEndURL must be made on each server in the cluster.

  4. Enter a new value for the OimFrontEndURL attribute and click Apply to save the changes.

    For example:

    https://myoimserver.example.com:14002

    Note:

    Fusion Apps or SPML clients store Oracle Identity Governance URL for invoking SPML and also send callback response. Therefore, there will be changes needed corresponding to this. Also, if Oracle Identity Governance is integrated with OAM/OAAM/OIN, there may be corresponding changes necessary.

25.3.3.3 Changing backOfficeURL to Use SOA SSL Port

To change the backOfficeURL to use SOA SSL port:

  1. When the WebLogic admin and Oracle Identity Governance managed servers (at least one of the servers in case of cluster) are running, log in to Enterprise Manager (EM).

    For example:

    http://<AdminServer>/em

  2. Click WebLogic Domain, and then select System MBean Browser.
  3. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.DiscoveryConfig, Discovery.
  4. Enter a new value for the backOfficeURL attribute and click Apply to save the changes.

    For example:

    t3s://mywls1.example.com:14001

    t3s://mywls1.example.com:14001,mywls2.example.com:14001

    Note:

    For simple cluster and non-cluster installations the value must be empty.

25.3.3.4 Changing SOA Server URL to Use SOA SSL Port

To change SOA server URL to use SOA SSL port:

  1. When the admin server and Oracle Identity Governance managed servers are running, log in to Enterprise Manager (EM).

    For example:

    http://ADMINISTRATIVE_SERVER/em
  2. Click WebLogic Domain, and then select System MBean Browser.

  3. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.SOAConfig, SOAConfig.

  4. Change the values of the Rmiurl attribute.

    Note:

    Rmiurl is used for accessing SOA EJBs deployed on SOA managed servers.

    This is the application server URL. For clustered installation, it is a comma separated list of all the SOA managed server URLs.

    For example:

    t3s://mysoa1.example.com:8002
    t3s://mysoa1.example.com:8002,mysoa2.example.com:8003,mysoa3.example.com:8004
  5. Change the value of the Soapurl attribute. For example:

    https://mysoa.example.com:8002

    Note:

    Soapurl is used to access SOA web services deployed on SOA managed servers. This is the web server/load balancer URL, in case of a SOA cluster front ended with web server/load balancer. In case of single SOA server, it can be application server URL.

  6. Click Apply to save the changes.

The SOA server URL must be enabled in ForeignJNDIProvider-SOA as well:

  1. Login to WebLogic Administrative Console.
  2. Navigate to domain, services, ForeignJNDIProvider.
  3. Click ForeignJNDIProvider-SOA, and modify it to:
    t3s://HOST_NAME:SSL_SOA_PORT

    For example:

    t3s://mysoa.example.com:8002

25.3.4 Enabling SSL for Oracle Identity Governance DB

Enabling SSL for Oracle Identity Governance database involves setting up the database in server-authentication SSL mode, creating KeyStores and certificates, updating Oracle Identity Governance, and updating WebLogic Server.

You need to perform the following configurations to enable SSL for Oracle Identity Governance database:

25.3.4.1 Creating KeyStores and Certificates

You can create server side and client side KeyStores using the orapki utility. This utility will be shipped as a part of Oracle DB installation.

KeyStores could be of any format such as JKS and PKCS12. The format of keystore changes based on the provider implementation. For example, JKS is the implementation provided by Sun Oracle where as PKCS12 is implemented by OraclePKIProvider.

Only JKS client KeyStore is used in Oracle Identity Governance for DB server. This is because using non-JKS KeyStores format such as PKCS12 requires significant changes on the installer side at the critical release time. However, Oracle Identity Governance already has a KeyStore named default-KeyStore.jks, which is in JKS format.

The following are the KeyStores that you can create using orapki utility:

25.3.4.1.1 Creating a Root CA Wallet

To create a root certification authority (CA) wallet:
  1. Navigate to the following path:
    $DB_ORACLE_HOME/bin directory
  2. Create a wallet by using the command:
    ./orapki wallet create -wallet CA_keystore.p12 -pwd KEYSTORE_PASSWORD

    KEYSTORE_PASSWORD can be any password, it is not related to KEYSTORE_PASSWORD provided while installing Oracle Identity Governance.

  3. Add a self signed certificate to the CA wallet by using the command:
    ./orapki wallet add -wallet CA_keystore.p12 -dn 'CN=root_test,C=US' -keysize 2048 -self_signed -validity 3650 -pwd KEYSTORE_PASSWORD -sign_alg sha256
  4. View the wallet using the command:
    ./orapki wallet display -wallet CA_keystore.p12 -pwd KEYSTORE_PASSWORD
  5. Export the self signed certificate from the CA wallet using the command:
    ./orapki wallet export -wallet CA_keystore.p12 -dn 'CN=root_test,C=US' -cert self_signed_CA.cert -pwd KEYSTORE_PASSWORD
25.3.4.1.2 Creating DB Server Side Wallet

To create a DB server side wallet:
  1. Create a server wallet using the command:
    ./orapki wallet create -wallet server_keystore_ssl.p12 -auto_login -pwd KEYSTORE_PASSWORD
  2. Add a certificate request to the server wallet using the command:
    ./orapki wallet add -wallet server_keystore_ssl.p12 -dn 'CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=US' -keysize 2048 -sign_alg sha256 -pwd KEYSTORE_PASSWORD -sign_alg sha256
  3. Export the certificate request to a file, which is used later for getting it signed using the root CA signature:
    ./orapki wallet export -wallet server_keystore_ssl.p12 -dn 'CN=Customer,OU=Customer,O=Customer,L=City,ST=NY,C=US' -request server_creq.csr -pwd KEYSTORE_PASSWORD
     -sign_alg sha256
  4. Get the server wallet's certificate request signed using the CA signature:
    ./orapki cert create -wallet CA_keystore.p12 -request server_creq.csr -cert server_creq_signed.cert -validity 3650 -pwd KEYSTORE_PASSWORD
     -sign_alg sha256
  5. View the signed certificate using the command:
    /orapki cert display -cert server_creq_signed.cert -complete
  6. Import the trusted certificate in to the server wallet using the command:
    ./orapki wallet add -wallet server_keystore_ssl.p12 -trusted_cert -cert self_signed_CA.cert -pwd KEYSTORE_PASSWORD
     -sign_alg sha256
  7. Import this newly created signed certificate (user certificate) to the server wallet using the command:
    ./orapki wallet add -wallet server_keystore_ssl.p12 -user_cert -cert server_creq_signed.cert -pwd KEYSTORE_PASSWORD
25.3.4.1.3 Creating Client Side Wallet

To create a client side (Oracle Identity Governance server) wallet:
  1. Create a client keystore or use existing keystore default-keystore.jks at following path:
    DOMAIN_HOME/config/fmwconfig

    Note:

    You can also use Oracle PKCS12 wallet as the client keystore.

  2. Import the self-signed CA trusted certificate that you have already exported using the server side commands, to the client keystore (default-keystore.jks) by running the following command:
    JAVA_HOME/jre/bin/keytool -import -trustcacerts -alias dbtrusted -noprompt -keystore default-keystore.jks -file self_signed_CA.cert -storepass KEYSTORE_PASSWORD

    Here, KEYSTORE_PASSWORD is the password given for the keystore during Oracle Identity Governance installation.

    Note:

    For custom trust keystore, import the self-signed CA trusted certificate to that, for example:

    JAVA_HOME/jre/bin/keytool -import -trustcacerts -alias dbtrusted -noprompt -keystore oimsupporttrust.jks -file self_signed_CA.cert -storepass KEYSTORE_PASSWORD
25.3.4.2 Setting Up Database in Server-Authentication SSL Mode

To set up Database in Server-Authentication SSL mode:

  1. Stop the Database server and the listener.

  2. Configuring the listener.ora file as follows:

    1. Navigate to the path:

      $DB_ORACLE_HOME/network/admin directory

      For example:

      /u01/app/user1/product/12.1.0/dbhome_1/network/admin
    2. Edit the listener.ora file to include SSL listening port and Server Wallet Location.

      The following is the sample listener.ora file:

      # listener.ora Network Configuration File: DB_ORACLE_HOME/listener.ora
      # Generated by Oracle configuration tools.
       
      SSL_VERSION = 1.2
      SSL_CLIENT_AUTHENTICATION = FALSE
       
      WALLET_LOCATION =
        (SOURCE =
          (METHOD = FILE)
          (METHOD_DATA =
            (DIRECTORY = DB_ORACLE_HOME/bin/server_keystore_ssl.p12)
          )
        )
       
      LISTENER =
        (DESCRIPTION_LIST =
          (DESCRIPTION =
            (ADDRESS = (PROTOCOL = TCPS)(HOST = server1.mycompany.com)(PORT = 2484))
          )
          (DESCRIPTION =
            (ADDRESS = (PROTOCOL = TCP)(HOST = server1.mycompany.com)(PORT = 1521))
          )
        )
       
      TRACE_LEVEL_LISTENER = SUPPORT
      
  3. Configure the sqlnet.ora file as follows:

    1. Navigate to the path:

      $DB_ORACLE_HOME/network/admin directory

      For example:

      /u01/app/user1/product/12.1.0/dbhome_1/network/admin
    2. Edit sqlnet.ora file to include:

      • TCPS Authentication Services

      • SSL_VERSION

      • Server Wallet Location

      • SSL_CLIENT_AUTHENTICATION type (either true or false)

      • SSL_CIPHER_SUITES that can be allowed in the communication (optional)

      The following is the sample sqlnet.ora file:

      # sqlnet.ora Network Configuration File: DB_ORACLE_HOME/sqlnet.ora
      # Generated by Oracle configuration tools.
       
      SQLNET.AUTHENTICATION_SERVICES= (BEQ,NTS, TCPS)
       
      SSL_VERSION = 1.2 
      SSL_CLIENT_AUTHENTICATION = FALSE
       
      WALLET_LOCATION =
        (SOURCE =
          (METHOD = FILE)
          (METHOD_DATA =
            (DIRECTORY = DB_ORACLE_HOME/bin/server_keystore_ssl.p12)
          )
        )
      
  4. Configure the tnsnames.ora file as follows:

    1. Navigate to the path:

      $DB_ORACLE_HOME/network/admin directory

      For example:

      /u01/app/user1/product/12.1.0/dbhome_1/network/admin
    2. Edit the tnsnames.ora file to include SSL listening port in the description list of the service.

      The following is the sample tnsnames.ora file:

      # tnsnames.ora Network Configuration File: DB_ORACLE_HOME/tnsnames.ora
      # Generated by Oracle configuration tools.
      
      PRODDB =
       (DESCRIPTION_LIST =
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCPS)(HOST = server1.mycompany.com)(PORT = 2484))
          (CONNECT_DATA =
            (SERVER = DEDICATED)
            (SERVICE_NAME = proddb)
          )
        )
        (DESCRIPTION =
          (ADDRESS = (PROTOCOL = TCP)(HOST = server1.mycompany.com)(PORT = 1521))
          (CONNECT_DATA =
            (SERVER = DEDICATED)
            (SERVICE_NAME = proddb)
          )
        )
       )
      
  5. Start/Stop utilities for Database server.

  6. Start the Database server.

25.3.4.3 Updating Oracle Identity Governance

You need to perform the following steps in Oracle Identity Governance to enable Oracle Identity Governance and Oracle Identity Governance DB in SSL mode for a secure communication:

  1. Import the trusted certificate into the default-keystore.jks keystore of Oracle Identity Governance.
  2. Log in to Enterprise Manager.
  3. Navigate to Identity and Access, OIM.
  4. Right click and navigate to System MBean Browser.
  5. Under Application Defined MBeans, navigate to oracle.iam, Application:oim, XMLConfig, Config, XMLConfig.DirectDBConfig, and DirectDB.
  6. Change the values for attributes "Sslenabled", "Url" and click Apply. If SSL mode is enabled for DB, then "Url" should contain TCPS enables and SSL port in it.

    For example:

    url="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=my.example.com)(PORT=2484)))(CONNECT_DATA=(SERVICE_NAME=proddb))(SECURITY=(SSL_SERVER_CERT_DN="CN=root_test,C=US")))"

  7. Restart the Oracle Identity Governance server.
25.3.4.4 Updating WebLogic Server

After enabling SSL for Oracle Identity Governance Database, you need to change the following Oracle Identity Governance datasources and authenticators to use Database SSL port:

Note:

Before performing changes to database host/port, you must shutdown the managed servers hosting Oracle Identity Governance application. However, you can keep the WebLogic Admin Server up and running.

25.3.4.4.1 Updating Datasource oimOperationsDB Configuration

To update the Change Datasource oimOperationsDB Configuration:

  1. Log in to WebLogic Server.
  2. Navigate to Services, JDBC, Data Sources, oimOperationsDB.
  3. Click the Connection Pool tab.
  4. Change the value of the URL to reflect the changes to SSl DB host/port, similar to the following example:
    jdbc:oracle:thin:@(DESCRIPTION= (ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=myhost.example.com)(PORT=2484)))(CONNECT_DATA=(SERVICE_NAME=myhost1.example.com)(SECURITY=(SSL_SERVER_CERT_DN="CN=root_test,C=US")))
    

    Where SSL_SERVER_CERT_DN="CN=root_test,C=US" is DB root certificate DN.

  5. Update Properties to add the following SSL-related properties:
    javax.net.ssl.trustStore=DOMAIN_HOME/config/fmwconfig/default-keystore.jks
    javax.net.ssl.trustStoreType=JKS
    EncryptionMethod=SSL
    oracle.net.ssl_version=1.0 for all data sources
    javax.net.ssl.trustStorePassword=PASSWORD
    

    Here, PASSWORD is the password given for the keystore during Oracle Identity Governance configuration.

    Note:

    • Use default-keystore.jks or dbcustomtrust-keystore.jks based on values provided for Wallet.

    • For custom trust keystore, provide the path of keystore in the javax.net.ssl.trustStore property file. For example:

      javax.net.ssl.trustStore=DOMAIN_HOME/config/fmwconfig/dbcustomtrust-keystore.jks
    • If required, perform similar updates to all datasources related to SOA, OWSM, or OPSS like ApplicationDB, bip_datasource, EDNDataSource, EDNLocalTxDataSource, mds-oim, mds-owsm, mds-soa, oimJMSStoreDS, opss-DBDS, OraSDPMDataSource, SOADataSource, SOALocalTxDataSource, and soaOIMLookupDB.

25.3.4.4.2 Updating Oracle Identity Governance Authenticators

The existing Oracle Identity Governance authenticators in the WebLogic server are configured against Non-SSL DB details and they do not use datasources for communicating with Oracle Identity Governance DB. In order to use SSL DB details in the authenticators, you must perform the following:

  1. Ensure that Datasources are configured to SSL.

  2. In WebLogic Administrative console, navigate to Security Realms, myrealm, Providers.

  3. Remove OIMAuthenticationProvider.

  4. Create an authentication provider of type "OIMAuthenticator" and mark the control flag as SUFFICIENT.

  5. Create an authentication provider of type "OIMSignatureAuthenticator" and mark the control flag as SUFFICIENT.

  6. Reorder the authenticators as:

    1. DefaultAuthenticator

    2. OIMAuthenticator

    3. OIMSignatureAuthenticator

    4. Other providers if any

  7. Restart all servers.

25.3.4.5 Updating the jps-config.xml and jps-config-jse.xml Files

You must update the jps-config.xml and jps-config-jse.xml files for the WebLogic Administrative server to start properly.

To update the jps-config.xml and jps-config-jse.xml files:

  1. Navigate to the $DOMAIN_HOME/config/fmwconfig/ directory.
  2. Open the jps-config.xml file in a text editor.
  3. Search for the jdbc.url parameter.
  4. Change the DB connection string to point to the SSL port.
  5. Save the file.
  6. Open the jps-config-jse.xml file in a text eidtor.
  7. Search for the jdbc.url parameter.
  8. Change the DB connection string to point to the SSL port.
  9. Search for the audit.loader.jdbc.string parameter.
  10. Change the DB connection string to point to the SSL port.
  11. Save the file.

25.3.5 Enabling SSL for SOA Approval Composites

Enabling SSL for SOA approval composites involves updating the HTTPS port for each composite with a Human Workflow component type that has a valid worklist URL entry that must use the HTTPS port.

To enable SSL for SOA approval composites:

  1. Ensure that the SOA Managed Server is running.
  2. Log in to Oracle Enterprise Manager by using your WebLogic Server administrator credentials.
  3. Click the Target Navigation image shown on the left of the domain name in upper left corner of the Enterprise Manager console.
  4. Click SOA, and then select soa-infra(SOA_SERVER_NAME).
  5. Click the Deployed Composite tab.
  6. Click the DefaultOperationalApproval [6.0] composite.
  7. In the Components section, click the ApprovalTask link of type Human Workflow.
  8. Click the Administration tab.
  9. Make the required changes to Host Name, HTTP Port, and HTTPS Port.
  10. Repeat steps 7 through 9 for each composite with a Human Workflow component type that has a valid worklist URL entry that needs to now use the HTTPS port,, such as DefaultOperationalApproval [6.0].

25.3.6 Configuring SSL for the Design Console

To change the Design console to establish secure connection between Oracle Identity Governance and Design console:
  1. Copy wlthint3client.jar file from WEBLOGIC_HOME/server/lib folder to DESIGN_CONSOLE_HOME/ext folder.
  2. Ensure that ./ext/wlthint3client.jar is set in the relevant file:

    For Linux: DESIGN_CONSOLE_HOME/classpath.sh

    For Windows: DESIGN_CONSOLE_HOME/classpath.bat

  3. Copy /oracle_common/modules/oracle.rsa/cryptoj.jar to the OIM_HOME/designconsole/ext/ directory.
  4. Edit the $DESIGN_CONSOLE_HOME/config/xlconfig.xml file. Make the following changes:

    Change:

    <Discovery>
                <CoreServer>
    <java.naming.provider.url>t3://HOST_NAME:OIM_PORT/oim</java.naming.provider.url>
    <java.naming.factory.initial>weblogic.jndi.WLInitialContextFactory</java.naming.factory.initial>
                </CoreServer>
    </Discovery>

    To:

    <Discovery>
                <CoreServer>
    <java.naming.provider.url>t3s://HOST_NAME:OIM_SSL_PORT/oim</java.naming.provider.url>
    <java.naming.factory.initial>weblogic.jndi.WLInitialContextFactory</java.naming.factory.initial>
                </CoreServer>
    </Discovery>
  5. If $DESIGN_CONSOLE_HOME/config/xl.policy does not contain the default grant policy for all, then add the following permission for cryptoj.jar at the end of the file, as shown:
    grant codeBase "file:DESIGN_CONSOLE_HOME/ext/cryptoj.jar"{  permission java.security.AllPermission;};

    Copy $MW_HOME/modules/cryptoj.jar to the $OIM_HOME/designconsole/ext/ directory.

    Note:

    Here, copying $MW_HOME/modules/cryptoj.jar to the $OIM_HOME/designconsole/ext/ directory is a mandatory step. Setting the permission is necessary if xl.policy does not contain the default grant policy for all.

  6. In the relevant file, add the following properties:

    For Linux: DESIGN_CONSOLE_HOME/xlclient.sh

    For Windows: DESIGN_CONSOLE_HOME/xlclient.cmd

    /u01/jdks/jdk1.8.0_131/bin/java -DXL.ExtendedErrorOptions=TRUE \
       -DXL.HomeDir=. -Djava.security.policy=config/xl.policy \
       -Djava.security.manager -Djava.security.auth.login.config=config/authwl.conf \
       -Dlog4j.configuration=config/log.properties \
       -DAPPSERVER_TYPE=wls \
       -Djavax.net.ssl.trustStore=$TRUSTSTORE_LOCATION \
       -Dweblogic.security.SSL.protocolVersion=TLSv1.2 \
       -Dhttps.protocols=TLSv1.2 \
       -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2 \
       -DproviderURL=t3s://oimhost.us.example.com:14002 \
       -Dweblogic.ssl.JSSEEnabled=true \
       -Dweblogic.security.SSL.enableJSSE=true \
       -Dweblogic.security.allowCryptoJDefaultJCEVerification=true \
       -Dweblogic.security.SSL.enforceConstraints=off \
       -Dweblogic.security.SSL.ignoreHostnameVerification=true \
       -Dweblogic.StdoutDebugEnabled=true \
       -Dssl.debug=true \
       -Djavax.net.debug=ssl:handshake:verbose \
       -cp $CLASSPATH com.thortech.xl.client.base.tcAppWindow -server server
  7. Set environment variable TRUSTSTORE_LOCATION to the location of custom/demo/Java Standard trust keystore used at server side.

    For example:

    setenv TRUSTSTORE_LOCATION DOMAIN_HOME/config/fmwconfig/oimsupporttrust.jks 

Note:

  • To get trust store location, in the WebLogic Server Administration Console, click Environment, Servers. Click OIM_SERVER_NAME to view details of the Oracle Identity Governance server.

    Click KeyStores tab and note down the Trust keystore location in the Trust section.

  • If the Design Console and Oracle Identity Governance are deployed on a different host, then copy the Trust keystore to the host on which Design Console is deployed, and set the TRUSTSTORE_LOCATION environment variable to the location where Trust keystore is copied on the local host.

    For example:

    setenv TRUSTSTORE_LOCATION OIM_HOME/designconsole/copied_oimsupporttrust.jks

25.3.7 Configuring SSL for Oracle Identity Governance Utilities

Oracle Identity Governance client utilities include PurgeCache, GenerateSnapshot, UploadJars, and UploadResources.

When Oracle Identity Governance is configured with TLS, perform the following steps to configure Oracle Identity Governance utilities:
  1. Export the Oracle Identity Governance server certificate and import it into custom keystore oimsupporttrust.jks.
  2. Edit the OIM_HOME/server/bin/oimClientWrapper.sh file to add the following parameters after $JAVA_HOME/bin/java -cp $CLASSPATH:
    -Dweblogic.security.SSL.trustedCAKeyStore=$TRUSTSTORE_LOCATION 
    -Dweblogic.security.SSL.protocolVersion=TLSv1.3 
    -Dhttps.protocols=TLSv1.3
    -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.3 
    -DproviderURL=t3s://oimhost.us.example.com:14002 
    -Dweblogic.ssl.JSSEEnabled=true 
    -Dweblogic.security.SSL.enableJSSE=true
    -Dweblogic.security.allowCryptoJDefaultJCEVerification=true
    -Dweblogic.security.SSL.enforceConstraints=off
    -Dweblogic.security.SSL.ignoreHostnameVerification=true
    -Dweblogic.StdoutDebugEnabled=true
    -Dssl.debug=true
    -Djavax.net.debug=ssl:handshake:verbose 
  3. Before running the utilities, in the command prompt, set the TRUSTSTORE_LOCATION environment variable to pointing towards the location of custom/demo/Java Standard trust keystore used at server side. For example:
    setenv TRUSTSTORE_LOCATION DOMAIN_HOME/config/fmwconfig/oimsupporttrust.jks

    Note:

    Ensure that Oracle Identity Governance server certificate is already imported into above trust store.

  4. For clients, such as Remote Manager, and other utilities to connect to Oracle Identity Governance in SSL/TLS way, the public key (certificate) must be made available in the keystore for clients to use it. To do so, export and import public key (certificate) as below:
    1. Export the public certificate from DemoIdentity.jks or oimsupportidentity.jks, which has private keys, by using the following command. Alternatively, you can export from the browser.
      $JAVA_HOME/jre/bin/keytool -export -file key.cer -alias demoidentity -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase

      In case of custom identity store:

      $JAVA_HOME/jre/bin/keytool -export -alias supportpvtkey -file supportpvtkeycert.pem -keypass password -keystore oimsupportidentity.jks -storepass password
    2. Import that certificate to the client keystore, as shown:
      $JAVA_HOME/jre/bin/keytool -import -trustcacerts -file key.cer -alias qa_certgenca -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

      Here, it is DemoTrust.jks for demo keystore or oimsupporttrust.jks for custom key store.

    3. In clients, such as Design Console, Remote Manager, and utilities, point TRUSTSTORE_LOCATION or -Dweblogic.security.SSL.trustedCAKeyStore to this key store, as shown:
      setenv TRUSTSTORE_LOCATION WL_HOME/server/lib/DemoTrust.jks
      -Dweblogic.security.SSL.trustedCAKeyStore= WL_HOME/server/lib/DemoTrust.jks \
    4. To configure SSL using Transport Layer Security (TLS) with additional parameters for the Remote Manager scripts, in a text editor, open the following scripts:

      OIM_HOME/remotemanager/remotemanager.sh

      Add the following parameters:

       -Dweblogic.security.SSL.trustedCAKeyStore=$TRUSTSTORE_LOCATION
       -Dweblogic.security.SSL.protocolVersion=TLSv1.2 -Dhttps.protocols=TLSv1.2
       -Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2
       -DproviderURL=t3s://oimhost.us.example.com:14002
       -Dweblogic.ssl.JSSEEnabled=true -Dweblogic.security.SSL.enableJSSE=true
       -Dweblogic.security.allowCryptoJDefaultJCEVerification=true
       -Dweblogic.security.SSL.enforceConstraints=off
       -Dweblogic.security.SSL.ignoreHostnameVerification=true
       -Dweblogic.StdoutDebugEnabled=true -Dssl.debug=true
       -Djavax.net.debug=ssl:handshake:verbose

25.3.8 Updating the System Properties for SSL Enabled Servers

For SSL enabled servers, you must set the required properties in the setDomainEnv file in the domain home.

Set the following properties in the DOMAIN_HOME/bin/setDomainEnv.sh (for UNIX) or DOMAIN_HOME\bin\setDomainEnv.cmd (for Windows) file before you start the servers:
  • -Dweblogic.security.SSL.ignoreHostnameVerification=true

  • -Dweblogic.security.TrustKeyStore=DemoTrust

25.3.9 Enabling FIPS Mode on Oracle Identity Governance

To enable FIPS mode on Oracle Identity Governance server:

Note:

  • As a prerequisite, OIG server is installed and configured. JDK used is Oracle JDK 1.8.0_271-b09.

  • See Enabling FIPS 140-2 Mode From Java Options in Administering Security for Oracle WebLogic Server for detailed steps.

  1. Update java security file of the JDK instance referred by your IDM WebLogic domain, as follows:

    Note:

    You can obtain JAVA_HOME reference from the SetDomainEnv script.

    1. Add RSA Security Provider to the top of the security file JAVA_HOME/jre/lib/security/java.security.
    2. update the sequence number for the remaining providers, as shown:
      security.provider.1=com.rsa.jsafe.provider.JsafeJCE
      security.provider.2=com.rsa.jsse.JsseProvider
  2. Update WLS Pre-ClassPath Setting with FIPS specific jars. To do so:
    1. Set WLS PRE_CLASSPATH variable to point to jcmFips.jar and sslj.jar, which is in the WL_HOME/server/lib/ directory.
    2. Export PRE_CLASSPATH by adding an entry in the setDomainEnv.sh script, which is in the DOMAIN_HOME/bin/ directory. The following is a sample entry:
      PRE_CLASSPATH="WLS_HOME/server/lib/jcmFIPS.jar:WLS_HOME/server/lib/sslj.jar"
      export PRE_CLASSPATH

      Here, replace WLS_HOME with the absolute path of WLS_HOME in your environment after confirming that jcmFIPS.jar and sslj.jar exists in the location specified. This will set the PRE_CLASSPATH variable for the entire WLS Domain.

  3. Restart the WebLogic Administrative Server and all Managed Servers.

25.3.10 Changing Client Policies to Create Custom Policy for FIPS

Federal Information Processing Standards (FIPS) are a series of standards established by the US National Institute of Standards for Technology (NIST) for use in evaluating the security of computer systems and networks. See FIPS 140 Support in Oracle Fusion Middleware in Administering Oracle Fusion Middleware for information about FIPS support.

To change client policies for creating custom policy for FIPS:

  1. Login to Oracle Enterprise Manager Fusion Middleware Control.
  2. Go to the OWSM policy page by navigating to Weblogic Domain, Web Services, WSM Policies.
  3. Search for "http_saml20_token_bearer_over_ssl_client_policy" and create a copy of it. Name the copy as http_saml20_token_bearer_over_ssl_client_policy_FIPS.
  4. Export the policy to a zip file, such as policyexport_clint.zip, and then unzip it.
  5. Open the policy file in a text editor.
  6. Inside the following XML tag:
    <orasp:require-tls
    orasp:algorithm-suite=suite="Basic128" orasp:include-timestamp="false"
    orasp:mutual-auth="false"/>
    

    Replace the string "orasp:algorithm-suite="Basic128" with "orasp:algorithm-suite="Basic256Exn256Rsa15".

  7. Save the file.
  8. Delete the existing custom policy http_saml20_token_bearer_over_ssl_client_policy_FIPS from the Enterprise Manager.
  9. Navigate to the meta-inf folder, zip the policy file, and import it back.
    The updated policy http_saml20_token_bearer_over_ssl_client_policy_FIPS is listed back.
  10. For service policy, select "http_saml20_token_bearer_over_ssl_service_policy" and create a copy of it as "http_saml20_token_bearer_over_ssl_service_policy_FIPS".
  11. Repeat steps 4 through 10.
  12. For policy set changes:
    1. Select policy set "policySetFacade". Detach the existing policy and attach "http_saml20_token_bearer_over_ssl_client_policy_FIPS".
    2. Select policy set "policySetAPPONBRD". Detach the existing policy and attach "http_saml20_token_bearer_over_ssl_service_policy_FIPS".

25.3.11 TLS 1.3 Support in Oracle Identity Governance

Transport Layer Security (TLS) 1.3 is supported with Oracle Identity Governance 12c to provide communications security over the Internet. This protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

Oracle Identity Governance supports TLS 1.3 across the following channels.

Channel TLS 1.3 Status

Front

TLS 1.3 is fully supported as incoming traffic is terminated on the Load Balancer, Web Server, or WebLogic Server.

LDAP Back

TLS 1.3 transport is supported with Oracle Identity Governance Bundle Patch 12.2.1.4.2104XX. However, TLS 1.3 is not supported when using an IDS Profile-based User Identity Store.

Outbound HTTPS

All outbound calls are done using JSSE and rely on the JDK-specific defaults.

25.3.12 Troubleshooting SSL Enablement with TLSv1.3

This topic provides the following troubleshooting tip for configuring SSL with TLSv1.3 protocol:

Issue

After enabling SSL with TLSv1.3 protocol, accessing Identity Self Service and Identity System Administration displays error 404 on the browser. This is because identity.ear and self-services.ear are in failed status in the deployed application status.

Resolution

To troubleshoot this issue:

  1. Export the following trust certificate from the custom trust store, which is oimsupporttrust.jks, used at the WebLogic level:

    keytool -export -keystore oimsupporttrust.jks -alias supportpvtkey -file
    supportpvtkeycert.pem
  2. List the content of the exported certificate in RFC format and copy the output. This output must be pasted during the import step. The command to list the certificate and the output is:

    [USERNAME@HOST newcert]$ keytool -printcert -file supportpvtkeycert.pem -rfc
    -----BEGIN CERTIFICATE-----
    MIIDPTCCAiWgAwIBAgIEPXSBCjANBgkqhkiG9w0BAQsFADBPMQswCQYDVQQGEwJV
    UzEaMBgGA1UECgwRT1JHQU5JWkFUSU9OX05BTUUxETAPBgNVBAsTCElkZW50aXR5
    MREwDwYDVQQDEwhkZW4wMmNqdDAeFw0yMTAzMTcxMzA2NTRaFw0yNjA5MDcxMzA2
    NTRaME8xCzAJBgNVBAYTAlVTMRowGAYDVQQKDBFPUkdBTklaQVRJT05fTkFNRTER
    MA8GA1UECxMISWRlbnRpdHkxETAPBgNVBAMTCGRlbjAyY2p0MIIBIjANBgkqhkiG
    9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlLwqdu7oi/M8mku0mbS5awRH71OGmM2F+iHm
    k00JSczsA5x1p3OMo2Mq7Hnt6IlXrPIdmbIfv6QOYYrmWKI5meh/duYNYhPGZQs6
    ov8jvuzKjjaRjzsSy4s38hCQ12UE2DZ31H0mzjHxHKWpJ021bqK5VnFsL6taPuaU
    wM/dA/JizYCa90QdcQcJh4paFBDhPAmWGUhVLbNZmFVFNKzYvgWYIWHtTXunyocK
    Dy8/0bC6vvv9MIfaCQJuu0NJVvi8yHoH2QpCgbe0e6HweUF79DQx9m7LPqFVxgqx
    fJTLu0ZGkySYU5M6R+In3cSuYPXt/JTBT/XHEa5aGyrgR12j2QIDAQABoyEwHzAd
    BgNVHQ4EFgQU0jDsOPbsaTvLXWKRLPuJwX07W1UwDQYJKoZIhvcNAQELBQADggEB
    AG3mRFFzLSmT2IecuxxotoHBz3ptZHtYTjiBVSce8fatgzFfiStfwME9/XbRlQbQ
    iWPUn4p92Q3GlVXZbwx7JOCiy/Gg0Vtkt2SglWARVuQCLszoPmjJC9nDnmxw2fl5
    JQ81NUrwkfHMLf4ZOzl/0t0Fp19/sGT7IjOfzLQzeZosxN+MjzTaux+n10Usf4lN
    lzxMdUz1jxObmXR6vZc8uwD3224QZJgGWhK16kYfkdoXUX+2gFb7VqoolGEOe208
    ioLpYSBkarhZysUUqpAJ0PLbN3zJvA5uU5q5CGUOHLnTHZeyvKKWr9zUQseFYMqQ
    kW2o9gPuPUdhQa6F9D+k29o=
    -----END CERTIFICATE-----
  3. Log in to Oracle Enterprise Manager Fusion MIddleware Control.

  4. Expand Weblogic Domain on the top, and navigate to Security, Keystore.

  5. Expand the OPSS stripe with name as system, and select the publiccacerts keystore. Then, click Manage.

  6. Click Import.

  7. In the Import Certificate section, select the Paste Certificate or Certificate Chain option if it not already selected.

  8. Under Paste Certificate String here, paste the exported supportpvtkeycert.pem certificate in RFC format that you copied in step 2.

  9. Click OK.

  10. After successful import, restart all the servers including the WebLogic Admin Server.

You can now access the Identity Self Service and Identity System Administration user interfaces.

25.4 Using Ready App

Understand, register, and use Ready App to allow applications that are not fully initialized at the time when WebLogic Server completes the application’s deployment to register their desire to participate in the readiness state of the server and tell the server when it is fully initialized.

25.4.1 About Ready App

Ready App is a mechanism within WebLogic that allows an application to influence the ready state of the server and/or partition in which it runs. This is done by registering and using the ready() and notReady() methods of the ReadyLifecycle java interface.

For a lot of applications, everything in the server is ready to receive requests if WebLogic Server (WLS) is in a RUNNING state. But for some applications, asynchronous processing may be occurring that may take longer than WebLogic Server's startup cycle. If there is a possibility that your application is not going to be ready to handle requests when WebLogic reaches the RUNNING state, then that application should register with ReadyApp. LoadBalancers and lifecycle tooling should always utilize the ReadyApp URL to determine if a WebLogic Server instance is ready to receive requests just in case one of the deployed applications may not be ready prior to reaching the RUNNING state.

During the startup process of the Fusion Middleware applications, WebLogic Server does not have the visibility of the startup processes for upper stack applications, such as SOA Suite or BPM. This creates the situation where a load balancer or other WLS instance prematurely starts routing traffic to the server that is not fully functional. In addition, it is difficult for patch tools and other lifecycle operations to determine when a server is ready during automated steps involving server restarts. This document defines a mechanism for the upper stack applications to register with WLS and to notify the WLS startup process when the application startup is complete.

The purpose of this framework is to allow applications that are not fully initialized at the time WebLogic Server completes the application’s deployment to register their intent to participate in the readiness state of the server and tell the server when it is fully initialized. This is important for the following purposes:

  • For any automation mechanisms, tools need a reliable way to determine when the server, with all of its applications, is ready to process requests. This check enables the automation tooling to know when it is safe to proceed to the next step of the process. For example, when a tool needs to perform a rolling restart of a set of servers, it is vital that the stopped server be completely available before initiating the shutdown of the next server in the domain or cluster so that the domain or cluster does not end up in the state where more than one server is unavailable (or still starting/initializing).

  • For load balancing purposes, this framework provides a reliable health-check URL for the server (and the partition in the case of multi-tenancy) so that the load balancer can reliably determine when the server is ready to accept requests.

If your application is fully initialized and ready to accept requests as soon as WebLogic Server completes the deployment of the application during startup (that is, by the time that the server listen port is opened), then there is no need for an application to participate or use this framework.

25.4.2 Registering Your Applications with Ready App

To use the Ready App feature, you have to register your application with Ready App.

The recommended method of registering your applications with Ready App is to put the following line in the META-INF\weblogic-application.xml file:

<wls:ready-registration>true</wls:ready-registration>

Note:

Depending on the contents of your weblogic-application.xml file, the 'wls:' may or may not be required. If other tags do not have the prefix, then remove it from the Ready App registration tag.
This automatically registers your application and sets the ready state to Not Ready on application startup. It also automatically unregisters your application if the application is undeployed from WebLogic.

25.4.3 Using Ready App with an EAR

To use Ready App with an EAR, register your application with Ready App and make calls to the ready() and notready() methods.

To use the Ready App feature with your application EAR:
  1. Register your application with Ready App. See Registering Your Applications with Ready App for information about registering your application with Ready App.
  2. Find a location in your code immediately after it has completed its initialization. At that point, you can put the following line of code to indicate that your application is ready:
    weblogic.application.ready.ReadyLIfecycleManager.getInstance().ready();

    This indicates to Ready App that your application is ready to process requests. This does not mean that the server or partition will be ready as all other registered applications must signal they are ready prior to the server or partition being ready.

  3. If your application needs to stop processing requests, for example, to reinitialize, then you can call the following method to indicate that your application is no longer ready:
    weblogic.application.ready.ReadyLifecycleManager.getInstance().notReady();
    This should be followed by your initialization code and then another call to the ready() method. Otherwise, the server or partition will remain in a not ready state and will not be able to receive requests.
The calls to ready() and notReady() have the possibility of causing two different run time exceptions. They are:
Exception Description
IllegalArgumentException This exception occurs with the applicationId reported by the Component Invocation Context is null.
IllegalStateException This exception occurs when the application has not be properly registered. Check the deployment descriptor for proper setup.

25.4.4 Using Ready App with a WAR

To use Ready App with an EAR, register your application with Ready App and make calls to the ready() and notready() methods.

To use the Ready App feature with your application WAR:

Note:

These instructions only apply to independently deployed WAR files. If you deploy your application as a WAR inside of an EAR, then see the instructions in Using Ready App with an EAR for using Ready App with an EAR.
  1. Register your application with Ready App. See Registering Your Applications with Ready App for information about registering your application with Ready App.
  2. Find a location in your code immediately after it has completed its initialization. At that point, you can put the following line of code to indicate that your application is ready:
    weblogic.application.ready.ReadyLIfecycleManager.getInstance().ready();
    This indicates to Ready App that your application is ready to process requests. This does not mean that the server or partition will be ready as all other registered applications must signal they are ready prior to the server or partition being ready.
  3. If your application needs to stop processing requests, for example to re-initialize, then you can call the following method to indicate that your application is no longer ready:
    weblogic.application.ready.ReadyLifecycleManager.getInstance().notReady();
    This should be followed by your initialization code and then another call to the ready() method. Otherwise, the server or partition will remain in a not ready state and will not be able to receive requests.
The calls to ready() and notReady() have the possibility of causing two different run time exceptions. They are:
Exception Description
IllegalArgumentException This exception occurs with the applicationId reported by the Component Invocation Context is null.
IllegalStateException This exception occurs when the application has not be properly registered. Check the deployment descriptor for proper setup.

25.4.5 Testing Ready App

To test whether or not Ready App is working, login to the WebLogic Administrative Console, and enable the debug settings for DebugReadyApp.

Perform the following steps to test whether or not Ready App is working:
  1. Login to WebLogic Administrative Console by navigating to the following URL:

    http://localhost:PORT/weblogic/ready

    Change hostname and port to the appropriate SERVER:PORT that you are using. This returns a page with any one of the following status:
    • 200: This means that the server is ready.

    • 503: This means that the server is not ready.

    This is a blank page with only the HTTP status set, and therefore, you need to use a tool inside the browser to see the status. Google Chrome web browser has a Developer Tools setting that shows the status of the page and the latency. Other browsers might have similar functionality.
  2. If you are unable to see the HTTP status from the browser, then you can also turn on debug logging in WebLogic. To do so:
    1. In the WebLogic Administrative Console, navigate to the server debug page.

    2. Expand weblogic, application. Select the checkbox adjacent to DebugReadyApp, and then click Enable. This will write information out to your log file (or console if you have STDOUT logging on).

  3. Set the log levels to Debug. To do so, select the following options, and then click Save.
    1. From the Minimum severity to log list, select Debug.

    2. Under Log file, from the Severity level list, select Debug.

    3. Under Standard out, from the Severity level list, select Debug.

    4. Under Domain log broadcaster, from the Severity level list, select Debug.

    When you hit the /weblogic/ready URL, something similar to the following will be displayed:
    <Aug 19, 2016 6:43:53 AM PDT> <Debug> <ReadyApp> <BEA-000000> <getReadyStatus for partition GLOBAL>
    
    <Aug 19, 2016 6:43:53 AM PDT> <Debug> <ReadyApp> <BEA-000000> < 
    
    **********************
    
    Ready App Map - Operation: Get Ready Status
    
    Partition Id GLOBAL
    
    Item 0 key: TestEar value: 1
    
    Partition Id ratestp2
    
    Item 0 key: ReadyApp2Test$ratestp2 value: 1
    
    Partition Id ratestp1
    
    Item 0 key: ReadyApp2Test$ratestp1 value: 1
    
    **********************
    >

In this example, there are three applications that are being deployed to the server; one in the global partition, and one each in the latest partitions. You can see from this the value of 1, which means not ready. If the ready() method is called on these applications, then the value will be 0, indicating that the application is ready.

If all applications are ready, then the server is considered ready. It is possible for one partition to have all applications ready but other applications could not be ready.