2.3 Recommended Production Environment Installation Scenarios

You can install Identity Governance and the required components in many different configurations, depending on network topology and the identity management products with which it integrates. This section presents a few common installation scenarios and recommendations to inform your installation choices:

2.3.1 Identity Governance in a New Environment

You must prepare a new environment with the required components for Identity Governance. If you do not have all of the required components in your environment, you must install them before starting the Identity Governance installation. The Identity Governance installer includes an installer for Identity Reporting and Workflow Engine. In addition to the Identity Governance installer, the software download page provides the installer for OSP. You must download the other required components from the manufacturer’s website. For more information, see Section 3.0, Installing Required Components.

For best performance, do not install Identity Governance on the same server as the databases, but ensure that the databases and Identity Governance run in the same subnetwork. You must determine where you will install the required components and the Identity Governance components. For more information, see Section 2.3.5, Recommended Deployment Scenarios.

You must install the Identity Governance components in a specific order, which depends on whether you plan to integrate Identity Governance with Identity Manager. If you are integrating with Identity Manager, the order is different. For more information, see Section 2.3.3, Installing Identity Governance to Integrate with Identity Manager.

To use Identity Governance without integrating with Identity Manager Advanced Edition, install the components in the following order:

  1. (Conditional) LDAP identity service with admin and user containers

    To use an identity service for the data source, ensure that you have Active Directory or eDirectory already installed.

  2. (Optional) Audit server if enabling auditing during installation.

  3. Zulu OpenJDK on the server that runs Identity Governance.

  4. Apache Tomcat on the server that runs Identity Governance.

  5. One of the supported databases in the same subnetwork as Identity Governance.

  6. OSP or Access Manager.

  7. Identity Governance, Identity Reporting, and Workflow Engine.

  8. (Optional) Identity Reporting, if not installed at the same time as Identity Governance.

  9. (Optional) Workflow Engine, if not installed at the same time as Identity Governance, is installed on a server specific to workflow.

  10. (Optional) Audit server if enabling auditing after the installation.

2.3.2 Identity Governance and Existing Components

If you are installing Identity Governance into an environment that already has a supported version of the following components, you can use these components for the Identity Governance installation. Those components are:

  • Zulu OpenJDK must run on the server where you will install Identity Governance

  • Apache Tomcat that runs against the Zulu OpenJDK on the server where you will install Identity Governance

  • Identity service of the Identity Manager Identity Vault (eDirectory); the identity service in Identity Manager is always eDirectory

  • Authentication service of OSP or Access Manager

  • A supported database server on the same subnetwork as Identity Governance

  • ActiveMQ

NOTE:The version of Identity Reporting that comes with Identity Manager contains different reports than the version that comes with Identity Governance. If you want the Identity Governance reports, you must install the version of Identity Reporting that comes with Identity Governance. If you have a prior version of Identity Reporting that came with Identity Governance, you must upgrade that version of Identity Reporting to match what comes with the version of Identity Governance that you install.

Ensure that you review the prerequisites and requirements provided in this chapter for each existing component. You should also consider the following:

  • Availability and suitability of existing components for Identity Governance use, including capacity, throughput, and utilization.

  • Additional processing load Identity Governance can place on existing components.

  • Resources needed to host Identity Governance components you must install in the environment.

  • OWASP best practices for securing your Apache Tomcat environment at https://www.owasp.org/index.php/Securing_tomcat.

2.3.3 Installing Identity Governance to Integrate with Identity Manager

To integrate Identity Governance with Identity Manager Advanced Edition, you can use some of the components that you installed with Identity Manager: OSP and Identity Reporting. The Identity Governance installation program needs the accounts and permissions to access, configure and modify the existing Identity Manager components.

If you want to use Identity Reporting as part of your Identity Governance solution, but you already have Identity Manager installed and running, you must install the version of Identity Reporting that comes with Identity Manager. Identity Reporting that comes with Identity Manager uses the Identity Manager security module to determine who has access to the reports.

To install Identity Governance with Identity Manager, install the components in the following order:

  1. Identity Manager Advanced Edition

  2. (Optional) Audit server if enabling auditing during Identity Governance installation

  3. Use the Identity Manager Identity Vault as the identity service, or use a supported LDAP directory

  4. Zulu OpenJDK on the server that runs Identity Governance

  5. Apache Tomcat on the server that runs Identity Governance

  6. One of the supported databases in the same subnetwork as Identity Governance

  7. Ensure that you use an LDAP-based bootstrap administrator during the Identity Governance installation for security reasons. For more information, see Section 4.1.1, Using the Bootstrap Administrator.

  8. Identity Governance

  9. (Conditional) If you are using OSP as the authentication service and the identity service is an eDirectory server or an Active Directory server that is separate from Identity Manager, you must manually extend the schema on that server or the OSP authentications do not work. For more information, seeSection 9.2.2, Extending the Schema for OSP in the Identity Service not Part of Identity Manager.

  10. (Optional) If you want the Identity Governance reports, install the version of Identity Reporting that comes with Identity Governance. If you want the Identity Manager reports, you must install the version of Identity Reporting on a separate server that comes with Identity Manager.

  11. (Optional) Audit server if enabling auditing after the installation

For more information about these activities, see Integrating Single Sign-on Access with Identity Manager Using OSP.

You must review the prerequisites and requirements for Identity Governance and gather the server and account information necessary to complete the installation process. For more information, see the following:

2.3.4 Ensuring High Availability or Load Balancing for Identity Governance

High availability ensures efficient manageability of critical network resources including data, applications, and services. Load balancing allows you to divide the workload on a component across multiple instances of that component. Identity Governance supports high availability and load balancing through stateless clustering or Hypervisor clustering, such as VMware Vmotion. When planning a high-availability or load balancing environment, the following considerations apply:

  • To manage the availability of your network resources for Identity Governance, use the High Availability tools provided with your operating system. Always have the latest patches installed for your operating system.

  • To provide load balancing for Identity Governance, you can run Identity Governance in a stateless cluster where the load balancers shift authentication requests among the various OSP servers. During installation, you must specify a URL that drives client access through your L4 switch or load balancer rather than specifying the host name and port for the Apache Tomcat server.

  • Each node in the cluster must have a persistent unique runtime identifier. For example, node1 or ProdNode1. For more information, see Section 9.6.1, Configuring the Nodes in the Apache Tomcat Cluster.

    Each Identity Governance runtime instance uses this identifier to claim and identify tasks that it processes. Some of these tasks are long-running, so the identifier must remain unique after a restart of the environment, where an IP address or another identifier might not remain the same.

  • The configuration settings and keystore passwords for OSP and Identity Governance must be identical for all nodes in the cluster.

  • When you are running Identity Governance, Identity Reporting, and OSP in a clustered environment, ensure that you run the Identity Governance Configuration Update utility on each server in the cluster to get the information populated on each server and also use the same keystore files.

  • When installing an identity service, consider the following requirements:

    • Configure a load balancer with a DNS host name and port for the identity service.

      The identity service can use the same load balancer specified for Identity Governance, a dedicated load balancer, or a single Apache Tomcat instance.

    • Specify the values for the appropriate load balancer instead of the connection settings to the Apache Tomcat instance. For more information, see Application address in Step 6.

    • The configuration files must be on each identity service deployment in the environment. For example, if using OSP, the osp.war file must be on each deployment of OSP in the environment.

    • After the first installation, copy and use the same Identity Service keystore and Database Encryption keystore files on all nodes for all deployments. For more information, see Section 4.0, Installing an Authentication Service.

  • When installing Identity Governance, consider the following requirements:

    • Configure a load balancer with a DNS host name and port for Identity Governance use.

      Identity Governance can use a dedicated load balancer or the same load balancer for the identity service.

    • Specify the values for the load balancer instead of the host and port for the Apache Tomcat connection. For more information, see Application address in Step 8.

    • On the primary (or master) node, perform the steps for configuring the databases. For more information, see Database details in Step 8.

    • For each installation on a secondary node, do not perform any database configuration steps. Instead, specify the settings for connecting to the previously configured databases. For more information, see Database details in Step 8.

  • To silently install OSP, Identity Governance, Identity Reporting, or Workflow Engine on the secondary nodes in the cluster, create a response file the first time you install a component using the guided installer. A response file contains the correctly formatted values for your environment that you must add to the install-silent.properties file. To create a response file, you must run the installer with the -r path-to-response-file option. For example:

    • OSP: Use the following command for your platform.

      • Linux: ./osp-install-linux.bin -r path_to_silent_properties_file

      • Windows: osp-install-win.exe -r path_to_silent_properties_file

    • Identity Governance and Identity Reporting: Use the following command for your platform.

      • Linux: ./identity-governance-install-linux.bin -r path_to_silent_properties_file

      • Windows: identity-governance-install-win.exe -r path_to_silent_properties_file

    After you have the response file, you open the response file and the silent.properties file in a text editor. You copy and paste the values from the response file to the silent.properties file.

    NOTE:In the silent.properties file for Identity Governance, change the following settings:

    • install_db_configure=false

    • install_tomcat_runtime_id=node1

    For more information, see the following:

2.3.5 Recommended Deployment Scenarios

In a typical production environment, you might install Identity Governance components on three or more servers. The reason to have different components on different servers is due to the workload of the component. If one of the components has a heavy load and you have other components installed on the same server, the heavy workload impacts the performance of the other components.

The following information contains deployment recommendations for the components. Each component has different reasons why you would install it with other components or not. Use this information and the information in Table 2-2, Different Identity Governance Component Deployment Scenarios in a Production Environment to determine how you deploy the Identity Governance components in your production environment.

  • OSP: OSP does not require a lot of processing power to function unless you have hundreds of thousands of authentications occurring at the same time. In most of the production environments, you can install OSP on the Identity Governance server. In larger environments, having OSP with a clustered load on its server balances the authentications through each clustered OSP node.

  • Database: We recommend that you always install the databases for Identity Governance and Identity Reporting on a database server. Databases require a lot of processing power. If you install the database on a server with another Identity Governance component, this causes performance issues for the component.

  • ActiveMQ: ActiveMQ is an optional component that you can install to guarantee delivery of the emails that Identity Governance sends. ActiveMQ does not require a lot of processing power. You can install ActiveMQ on the Identity Governance server.

  • Identity Governance: Is a web application that the authorized users access to perform all of the tasks. We recommend that you cluster the Identity Governance component for fail-over scenarios. If one node goes down, the authorized users can still log in and use Identity Governance. You can run OSP on the same server as Identity Governance except for very large production environments. You can even run Workflow Engine on the same server with Identity Governance. You would only run Identity Reporting on the Identity Governance service if you do not generate a lot of reports. If you generate a lot of reports, we recommend that you install Identity Reporting on its own server.

  • Identity Service: The identity service is an existing, supported LDAP server in your IT environment. In most scenarios, the LDAP server already exists and contains the user accounts. Installing other components on the LDAP server can impact the performance of the users’ authentications. It is best practice to have the LDAP directory installed on its server.

  • Identity Reporting: We recommend that you install Identity Reporting on its own server if you generate a lot of reports daily. Generating reports requires a lot of processing power for Identity Reporting. If you have Identity Reporting installed on the server with other components and you see the performance of the other components being impacted, you must move Identity Reporting to its own server. You can also cluster Identity Reporting for load balancing and fail-over scenarios.

  • Workflow Engine: The Workflow Engine runs the workflow at runtime and manages approval tasks for approvers. If you have the Workflow Engine installed on the server with other components and you see the performance of the other components being impacted, you must move the Workflow Engine on a separate server. You can also cluster the Workflow Engine for load balancing and fail-over scenarios.

  • Audit Server: Identity Governance forwards the audit events to the audit server. We recommend you have the audit server installed and configured before you install Identity Governance. In a production environment, you should always install the audit server on its own server for performance reasons.

Table 2-2 Different Identity Governance Component Deployment Scenarios in a Production Environment

 

Case 1

Case 2

Case 3

Case 4

Server 1

OSP

Identity Governance

ActiveMQ

(can be clustered)

OSP

Identity Governance

Identity Reporting

Workflow Engine

ActiveMQ

(can be clustered)

OSP

Identity Governance

ActiveMQ

(can be clustered)

OSP or Access Manager

Server 2

Database server

Database server

(can be clustered)

Identity Reporting

Workflow Engine

(can be clustered)

Identity Governance

ActiveMQ

Server 3

Identity service

Identity service

Database server

(can be clustered)

Identity Governance

Server 4

 

Audit server

Identity service

Identity Reporting

Server 5

 

 

Audit server

Database server

Server 6

 

 

 

Identity service

Server 7

 

 

 

Audit server

Server 8

 

 

 

Workflow Engine (Will be supported in a future release)