Identity Manager Installation

  • Kenneth Ramey


In the previous two chapters, you were provided with the instructions for installing and configuring Oracle Internet Directory (OID) and Oracle Access Manager (OAM).


Identity Manager Database Schema Database Object Access Manager Secure Socket Layer 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

In the previous two chapters, you were provided with the instructions for installing and configuring Oracle Internet Directory (OID) and Oracle Access Manager (OAM). These two components set the foundation of Identity Storage and single sign–on (SSO). Identity Manager adds additional elements such as user self-service and governance to the environment, thereby completing the end-to-end identity life cycle management implementation. This chapter focuses on the installation and initial domain configuration of Oracle Identity Manager (OIM).

Preinstallation Tasks

Operating System Users

For most Oracle application installs, operating system (OS) users and groups should be created to perform the installation and configuration tasks. Creating OS groups will allow other OS users to perform certain tasks related to the management of the application environment. The most common OS users and groups related to installing Oracle applications in Linux environments are the oracle user and oinstall or dba groups.

To create the necessary oinstall and dba groups, perform the following commands as the root directory:

[root@clouddemolab home]# groupadd oinstall
[root@clouddemolab home]# groupadd dba

After the groups are created, create the oracle user:

[root@clouddemolab home]# useradd  -g oinstall -G dba oracle


-g indicates the primary group to which the user should be added. -G indicates any secondary groups.

To set the password for the user, utilize the following command as the root user.

[root@clouddemolab home]# passwd oracle

Operating System Configuration

Prior to installing the Oracle Fusion Middleware infrastructure and Oracle Identity Management software, it is important to ensure the OS meets the minimum requirements and configuration. The following presents the kernel parameters and packages and the file changes that are required.

The following kernel parameters need to be set:

kernel.sem  256  32000  100  143
kernel.shmmax 10737418240

To set these parameters, edit the sysctl.conf file located in the /etc directory.

[root@clouddemolab home]# vi /etc/sysctl.conf

Add or edit the following lines in this section of the file:

# Controls the maximum number of shared memory segments, in pages
kernel.shmall = 4294967296
kernel.sem = 256 32000 100 142
kernel.shmmax = 10737418240

After setting these values in the sysctl.conf file, you must activate and verify the new values are shown using this command:

 [root@clouddemolab home]# /sbin/sysctl –p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.sem = 256 32000 100 142
kernel.shmmax = 10737418240

The open file limits must be set to 4096 to support the instance. To do so, edit the limits.conf file.

[root@clouddemolab home]# vi /etc/security/limits.conf

If the environment is to be installed on Oracle Linux or RedHat Linux, you must perform the edit in /etc/security/limits.d/90-nproc.conf as well. If this is missed, the values in this file could override the values in the limits.conf file.

In both of these files, ensure the following lines are added or edited:

* soft nofile 4096
* hard nofile 65536
* soft nproc 2047
* hard nproc 16384

After editing this file, the server must be rebooted to ensure all the changes take effect.

Operating System Packages

Each Oracle application has its own set of required packages. Depending on the version of Linux you are using, the installation procedure might be different. In the following list, you should note that some packages require both 32-bit and 64-bit versions to be installed on a 64-bit OS. If these packages are not installed, the installation will not complete properly. The Oracle Installer will check these and display errors during the installation.

compat-libstdc++-33-3.2.3-69.el6 for x86_64
compat-libstdc++-33-3.2.3-69.el6 for i686
gcc-4.4.4-13.el6 gcc-c++-4.4.4-13.el6
glibc-2.12-1.7.el6 for x86_64
glibc-2.12-1.7.el6 for i686
glibc-devel-2.12-1.7.el6 for i686
libstdc++-4.4.4-13.el6 for x86_64
libstdc++-4.4.4-13.el6 for i686
libXext for i686
libXtst for i686
libXext for x86_64
libXtst for x86_64
openmotif-2.2.3 for x86_64
openmotif22-2.2.3 for x86_64
redhat-lsb-core-4.0-7.el6 for x86_64

At this point in the procedure, the OS should be fully prepared for the installation to proceed. Performing these operations prior to installing the software will ensure a problem-free installation. In many cases, the installer will provide detailed messages if anything is missed. In the event of errors during the installation process, stop the installation and fix any problems problem before proceeding.

Database Preparation

Just like the OID, the installation of OIM requires specific database objects to be created. This includes a number of tables, views, and packages created in various database schemas. This is done using the Repository Creation Utility (RCU). Although the database objects can be created within the OID database, it is often recommended that the Oracle Identity and Access Management repository be created in a separate instance. This simplifies database administration tasks and future maintenance. To prevent issues with installation, it is important to ensure the RCU version used matches the version of the Fusion Middleware product to be installed. Mismatches found during the domain configuration will prevent the process from continuing. Unzip the download and run found in the <RCU_HOME>/rcu/bin directory. You will first see the Create Repository screen shown in Figure 7-1.
Figure 7-1.

Create or Drop schema

Because this is the first time installing OIM, select the Create option on this screen. This will start the RCU in creation mode.

After choosing to create the schemas, you must enter the database connection details for the target system on the screen shown in Figure 7-2. You can choose to create the Identity Manager schema within the same database as the OID. However, to keep database administration simpler, the Identity Manager schema is often installed within a different database. This instance can be the same as the OAM.
Figure 7-2.

Database Connection Details screen


$ORACLE_HOME/rdbms/admin/xaview.sql must be run to enable the XA transactions views and synonyms before the OIM schemas can be created.

After the RCU verifies the connection details, it will prompt you to select the components to be installed within the new repository. This screen is shown in Figure 7-3.
Figure 7-3.

Select Components screen

During this step of the RCU, you must select the components to be installed. Note that as you select the OIM component, other required items will be preselected. Do not deselect these, as they will be validated during the domain configuration step. The RCU will then validate that the database meets the prerequisites necessary for the components selected as seen in Figure 7-4.
Figure 7.4.

Checking prerequisites

Each of the Fusion Middleware components has database requirements, such as maximum connections or open processes. The RCU will check these prerequisites prior to creating the database schemas and objects.

Provided the database meets the minimum requirements, the next step is to enter passwords to be used by the new database schemas, as shown in Figure 7-5.
Figure 7-5.

Schema Passwords screen

During this step, indicate the value you wish to use for the password. You can elect to use the same password for all schemas or use a different password for each. Make the decision based on security requirements and ease of management.

Figure 7-6 displays the tablespace review screen, which shows the new database tablespaces that will be created for the selected Identity Management components. You can click Next to continue or choose to customize the new tablespaces.
Figure 7-6.

Tablespace listing

Prior to the actual creation of the tablespaces, the RCU will present you with a summary of the actions it will take. Figure 7-7 shows the Summary screen. You should make note of these for future reference when talking with your DBAs in case of runtime problems related to the database.
Figure 7-7.

Creation Summary screen

After all database objects have been created, you will be provided with the Completion Summary screen, shown in Figure 7-8. Click Close to complete the process.
Figure 7-8.

Completion Summary screen

This completes the repository creation process for OIM. The necessary database schemas and objects for Identity Manager and its required components have been installed within the target database. It is now possible to continue with the installation process.

Identity Manager Software Installation

In the previous section, you were taken through the steps to create the OIM database schemas and objects. The following sections discuss the installation of the Identity Manager software. This process creates the necessary file system structure and lays down the binaries needed by the Fusion Middleware products presented.

OIM must be installed within a WLS home. In Chapter  6, you were presented with the steps to install OAM in a separate WLS home. You can choose to install the Identity Manager software in the same home as Access Manager, or you can create a completely separate home specifically for it. It is common to separate Access Manager from Identity Manager on different tiers of the network, or on different physical hosts. If this is required for your environment, follow the WLS installation steps in Chapter  4.

Service-Oriented Architecture Installation

OIM requires Oracle Service-Oriented Architecture (SOA ) to run properly. This installation is separate from the OIM process, but can be installed within the same WebLogic home. After the SOA installation, you can install OIM and configure the domain for both products at the same time. This is the recommended process for the two products.

Just like many other Fusion Middleware products, the SOA installation tool is started using the runInstaller command to start the Oracle Universal Installer. This is found on Disk 1 of the installation media. When running the tool, you must indicate the location of the Java Runtime Environment. This is done as shown in Figure 7-9.
Figure 7-9.

Starting the Universal Installer

runInstaller -jreLoc /home/oracle/jdk1.6.0_45/jre

OIM requires SOA This version will be installed using this tool. The starting screen displays information pertinent to the planned installation and a reminder to run the RCU. Much like other iterations of the Universal Installer, Oracle checks the OS to ensure it meets the minimum requirements. A completed prerequisite check is shown in Figure 7-10.
Figure 7-10.

Prerequisite Checks screen

As with OAM, SOA has its own set of required OS packages, kernel parameters, memory, and storage allowances. These must be met prior to continuing with the installation. Although many of these are the same as the Access Manager installation, it is important to visit the beginning of this chapter to view them.


Prerequisite failures will be shown with a red X on the Universal Installer screen. You can open a terminal window logged in as root to correct any problems and retry the prerequisite checks until all issues have been resolved.

In the next step, you must select the Middleware Home location for this installation. Because this environment consists of separate WLS for each Access Manager and Identity Manager, it is important to install SOA in the correct Middleware Home. In this case, Identity Manager will be installed in the IDMMiddleware directory. See Figure 7-11 for more details.
Figure 7-11.

Specify Installation Location screen

Oracle SOA can be installed on either WLS or WebSphere server. This book focuses on the WLS installation types. Select WebLogic Server, as shown in Figure 7-12, and continue to the next step.
Figure 7-12.

Selecting the application server type

The Installatio Summary screen, shown in Figure 7-13, displays a summary of the selections made during the installer screens. Confirm the selections and click Install to start the installation.
Figure 7-13.

Installation Summary screen

The actual installation can take about 10 minutes. The progress screen, shown in Figure 7-14, will keep you apprised of the current status. Do not panic if the progress seems to stall for a while.
Figure 7-14.

Installation Progress screen

After the installer has completed copying the necessary files and creating the file system, the Installation Complete screen shown in Figure 7-15, will be displayed. This screen contains details directly related to your new environment. It might be useful to take note of the contents for future reference. At this point, you can click Finish and exit the installer.
Figure 7-15.

Installation Complete screen

Now the required Oracle SOA suite instance has been installed. When configuring the OIM domain, the Configuration Wizard will set up the necessary components of SOA. As you will recall, this SOA instance is installed in the same Middleware Home as the Identity Manager. The next section covers IOM installation.

Identity Manager Installation

The WLS and SOA software has been installed. It is now time to install the Identity Manager software. Again, this process is started using the runInstaller script found on Disk 1 of the installation media. Just like the SOA installation, you must indicate the Java Runtime Environment location for the installer to run properly. Figure 7-16 shows the Universal Installer.
Figure 7-16.

Installation Welcome screen

./ -jreLoc /home/oracle/jdk1.6.0_45/jre

The first screen displays important information about the software to be installed. Ensure the version displayed matches your requirements and the version of the RCU previously run.

As with OAM, OIM has its own set of required OS packages, kernel parameters, memory, and storage allowances. These must be met prior to continuing with the installation. As seen in Figure 7-17, the Installer will check these before allowing the process to continue. Although many of these are the same as for the OAM installation, it is important to visit the beginning of this chapter to view them.
Figure 7-17.

Prerequisite Checks screen

On the Specify Installation Location screen, you must select a Middleware Home to house the installation. Figure 7-18 provides details on this entry point. This location must be a directory that has WLS installed. Because this physical host houses two instances of WLS, make sure to select the location that is not currently used for OAM. The selected home should be the same as you chose in the previous step for SOA.
Figure 7-18.

Specify Installation Location screen

At this point the Universal Installer will begin copying files to their new locations. A progress screen such as the one shown in Figure 7-19 will show the current operation and progress.
Figure 7-19.

Installation Progress screen

The actual installation of the software files usually finishes in about 10 minutes. During this time you can see the actual operations on the progress screen, which also shows the location of the installation log file. You can monitor this log for any errors. Once completed, you can close the installer, as all installation operations are complete. In the next sections, you will be configuring the OIM domain.

Configure Identity Manager Domain

After the necessary software components have been installed, you can continue to configure the WebLogic domain to support OIM. This process is started by running the config script located in the IDM_HOME/common/bin directory. It is important to note that you are only configuring the WebLogic domain at this time. OIM will not be ready to run.

To avoid confusion for the rest of this chapter, the following conventions are used. MIDDLEWARE_HOME is the base directory where WLS was installed. IDM_HOME is the directory within the WLS installation where OIM is installed. This is usually a directory called Oracle_IDM1. Figure 7-20 shows the Configuration Wizard.
Figure 7-20.

Create a new WebLogic domain


There are multiple instances of the script that can be found within the Middleware Home subdirectories. It is very important to run the correct version found within <MIDDLEWARE_HOME/Oracle_IDM1/common/bin.

Because this is the first time a domain is being created within the WLS environment, choose Create a New WebLogic Domain.

During the next step of the process, select the OIM component. As seen in Figure 7-21, this list is based on the software found within the WebLogic Home directory. You will notice that Oracle SOA Suite is automatically selected. If SOA Suite is not found within the WLS Home, you will be shown an error indicating this. Before continuing, ensure that any missing software is installed.
Figure 7-21.

Select domain components

During the configuration, you are prompted for the name of the domain you wish to create. You can keep the default name of “base_domain” or you can name it something that makes sense in your environment. See Figure 7-22 for an example. In some cases, it might be desirable to locate the associated files separate from the Middleware Home directory. This is often done for clustered environments that require shared storage across the physical hosts.
Figure 7-22.

Enter domain name and location

The user password for weblogic should be set to something standard for your environment. This password will be used for starting and stopping managed servers as well as logging into the WebLogic Admin Console and Fusion Middleware Control. Figure 7-23 shows what the password configuration screen looks like.
Figure 7-23.

Administrator password

The Startup Mode determines how the managed servers are started. In Development Mode, the managed servers can be started and stopped from the command line without a password. Also configuration changes can be made and activated within the WebLogic Console without locking the environment. Configuring the Startup Mode to Production Mode locks the environment down to ensure no changes are made without locking the console for edits. Command-line tools will also require a password. These choices are shown in Figure 7-24.
Figure 7-24.

Server Start Mode


Locking the Administration Console prevents multiple administrators from making changes and overwriting each other.

After the Java database connectivity (JDBC ) connection details are entered, the information is validated by the configuration tool. Any errors will be shown. If a schema was not able to be validated, revisit the previous step to ensure the schema name and details are correct. If the database schema does not exist, rerun the RCU to create it. Figure 7-25 shows a completed database check.
Figure 7-25.

Database schema check

As discussed in the AOM installation chapter, the example used in this book utilizes a split domain. As such, each component (OID, OAM, and OIM) will have its own Administration server. As shown in Figure 7-26, select Administration Server, Managed Servers, Clusters and Machines.
Figure 7-26.

Select Optional Configuration screen

The default port for the Administration server is 7001, which was used in the previous chapter for the Access Manager Administration listen port. Using a standard port convention will help eliminate confusion or forgotten ports. For this exercise, use Port 7101 as seen in Figure 7-27. Subsequently, if more WLS instances are installed, use Ports 7201, 7301, and so on.
Figure 7-27.

Configure the Administration Server screen

In this environment, Access Manager and Identity Manager are installed in separate Oracle Middleware Homes. This means that each one consists of WLS, Administration server, and managed servers. As discussed previously, this was done for ease of future maintenance such as patches and upgrades. It also allows the separation of these tiers to different physical hosts at a later time if required. Because these will be running on the same physical host but within separate WLS, each Administration server will require its own listen port.

The managed servers will be prepopulated with the standard ports used by the installation. If desired, you can change the ports or populate a Secure Sockets Layer (SSL) listen port. In many cases, it is sufficient to allow the HTTP server or load balancer to perform the SSL endpoint duties, thus providing some performance gain by offloading the encryption duties to the external device. For ease of troubleshooting and future maintenance, leave the ports as defaults, seen in Figure 7-28.
Figure 7-28.

Configure Managed Servers screen

During the course of this book, clustering is not a concern. However, to facilitate the creation of clusters later, the cluster configuration information is entered here, as shown in Figure 7-29. As such, the WebLogic domain will be preconfigured with the clusters in place. In effect, this step creates a single node cluster that can be later expanded to include multiple machines and instances.
Figure 7-29.

Configure Clusters screen

Assign the managed servers to the desired cluster, as shown in Figure 7-30. Note that it is possible to create a single cluster and assign all of the managed servers to it. However, for simplification of administrative tasks, each will be assigned to its own cluster within WebLogic.
Figure 7-30.

Assign Servers to Clusters screen

It should be noted at this point that if you only have a single node in your cluster, you might see errors in the managed server logs related to waiting for communication with other members of the cluster. These can be ignored and will go away after adding additional members to the cluster.

As discussed in the previous chapter, machines provide the information necessary for the WebLogic Administration server to communicate with the server processes for status and life cycle events. It is important that any UNIX-based OS use the Unix Machine type. This ensures that any necessary environment settings are properly configured when the Administration server executes its operations. Clusters can contain one or more machines, and machines can include one or more managed servers. Figure 7-31 shows a new Unix Machine.
Figure 7-31.

Configure Machines screen

Assign the managed servers to the machine created in the previous step. In Figure 7-32, you will see that all the new managed servers are assigned to the single Unix_Machine created in the previous step. You can choose to create multiple machines and assign different components to different machines. If you have multiple cluster members, each machine can reside on a separate cluster.
Figure 7-32.

Assign Servers to Machines screen

After assigning the managed servers to machines, you will be presented with a summary of all of the inputs you have entered. This Configuration Summary screen, shown in Figure 7-33, provides a last look at the configuration you are about to launch. Review this to ensure that the file locations, names, and configuration parameters look correct. Click Create to start the new WebLogic domain creation.
Figure 7-33.

Configuration Summary screen

During domain creation, a number of files are created and various processes are started. The progress of this can be seen on the Creating Domain screen of the Configuration Wizard, as seen in Figure 7-34. A configuration log will be displayed. Let this run uninterrupted until complete. If there are any errors, check the indicated log.
Figure 7-34.

Configuration progress

Once the domain configuration is complete, click Done to exit the tool. If you have followed the process up to this point, you will have installed OID, OAM, and OIM. Each component resides within its own WebLogic domain and is controlled by its own WebLogic server. This serves to simplify the management processes and facilitate future upgrades and patches. It should also be noted that in some cases, your network infrastructure might require the components to be separated in different network zones. Visit the architecture sections of this book for more information.


This chapter served to cover the steps required to install OIM in a new WebLogic domain. If followed from the beginning, you were presented with the steps for creating the necessary database objects required for the metadata repository. The chapter also covered the actual software installation and creation of a new WebLogic domain for both OIM and the required Oracle SOA installation. Future chapters cover the configuration of OIM components and the integration with each other.

Copyright information

© Kenneth Ramey 2016

Authors and Affiliations

  • Kenneth Ramey
    • 1
  1. 1.Colorado SpringsUSA

Personalised recommendations