3.3 Securing Communication Between Components

You need to determine the security mode you want for communication between infrastructure components and ensure that the security mode is same across all components. The security mode described here is applicable only if the components are container-based applications. To identify if the application is container-based, refer to the application's documentation.

Identity Intelligence does not support plain text communication. You must use one of the following security modes for communication between Identity Intelligence components:

For information about the security modes supported between Identity Intelligence components, see Security Modes Between Components.

3.3.1 One-Way SSL Authentication

By default, Identity Intelligence installed using scripts support one-way (server) SSL authentication between Identity Intelligence and its related components.

In one-way SSL authentication, the client authenticates the server to ensure that it is communicating with a trusted server. For the client to trust the server, the client’s trust store must have the server’s Certificate Authority (CA).

In Identity Intelligence, Transformation Hub acts as an SSL server and all the components communicating with Transformation Hub act as SSL clients. Therefore, you must retrieve the CDF root CA certificate which is used by Transformation Hub and add the certificate to the truststore of all Transformation Hub clients, such as Identity Governance, SmartConnector, Identity Manager Driver for Entity Data Model, and Vertica. To identify Transformation Hub’s clients, see Identity Intelligence Architecture diagram.

NOTE:By default, Vertica must always be configured to use mutual SSL authentication in the Identity Intelligence environment.

If you plan to use one-way SSL authentication, you must:

  • Decide the CA to be used as the CDF root CA. You can use one of the following:

    • Self-signed CA that is generated during the installation of CDF by default. For instructions to retrieve the default CA, see Retrieving CDF Root CA.

    • Replace the default CA with a well-known CA, your organization’s CA or newly generated root CA. For instructions to change the CDF CA, see Changing the CDF Certificate Authority.

  • Get the root CA certificate for configuring mutual SSL in Vertica.

    • If you are installing by using scripts, root CA generation and SSL configuration for Vertica will be automatically done by the script.

    • If you are installing manually, you can do one of the following:

      • Generate a new root CA certificate for Vertica

        For instructions to generate a root CA, see Generating a New CA section.

      • Use any well-known CA or your organization’s root CA

      • Reuse the CDF root CA for Vertica if you are planning to generate a new root CA for CDF

  • Add the CDF root CA certificate to the truststore of all Transformation Hub clients. The instructions to add certificate to truststore are available in the respective client configuration sections.

3.3.2 Mutual SSL Authentication

To enhance security, you can configure mutual (two-way or client) SSL between Identity Intelligence and some of the components.

In mutual SSL authentication, the client and the server authenticate each other to ensure that both parties involved in the communication are trusted. For the client to trust the server, the client’s trust store must have the server’s CA certificate. For the server to trust the client, the client’s certificate must be signed by the server’s CA, which is already trusted by the server.

In Identity Intelligence, Transformation Hub acts as an SSL server and all the components communicating with Transformation Hub act as SSL clients. Therefore, you must:

  • Add the CDF root CA which is used by Transformation Hub to the truststore of all its clients, such as Identity Governance, SmartConnector, Identity Manager Driver for Entity Data Model, and Vertica. This ensures that all the clients trust the Transformation Hub Server.

  • Add the client’s private key and public certificate, which is signed by the CDF root CA to the keystore of all Transformation Hub’s clients. This ensures that the Transformation Hub Server trusts all its clients.

    To identify Transformation Hub’s clients, see Identity Intelligence Architecture diagram.

If you plan to use mutual SSL authentication, you must:

  • Enable client authentication in Transformation Hub either during manual installation or after installation.

  • Decide the CA to be used as the CDF root CA.

    You cannot use the default self-signed CA that is generated during CDF installation.

    You must replace the default CDF CA with a well-known CA, your organization’s CA or newly generated root CA. For instructions to change CDF root CA, see Changing the CDF Certificate Authority.

  • Get the root CA certificate for configuring mutual SSL in Vertica. You can do one of the following:

    • Generate a new root CA certificate for Vertica

      For instructions to generate a root CA, see Generating a New CA section.

    • Use any well-known CA or organization’s root CA

    • Reuse the CDF root CA for Vertica if you are planning to generate a new root CA for CDF

  • Configure mutual SSL authentication in all the clients of Transformation Hub. For instructions, see the respective client configuration sections.

3.3.3 Security Modes Between Components

The following tables list Identity Intelligence components, supported security modes, and where to find more information on configuring the security mode.

Table 3-1 Securing Communication Between Identity Intelligence Core Components

Communication

Supported security modes

More information

Identity Intelligence to Vertica

One-way SSL

Configuring SSL for Vertica

Transformation Hub to Vertica

Mutual SSL

Creating a Kafka Scheduler with SSL

Vertica to Transformation Hub

  • One-way SSL

  • Mutual SSL

Enabled by default

Identity Intelligence to SmartConnector

NA

(Internal communication)

Install SmartConnector on the worker node with label analytics:yes, where the Identity Intelligence service is running, so that the communication is within the same node.

Identity Intelligence to Analytics

NA

(Internal communication)

Identity Intelligence and Analytics run on the worker node with label analytics:yes, so that the communication is within the same node.

ArcMC to Transformation Hub

  • One-way SSL

  • Mutual SSL

Install ArcMC before installing Transformation Hub.

ArcMC Administrator's Guide

Transformation Hub, Analytics, and Identity Intelligence to NFS Server

 

For optimal security, secure all NFS settings to allow only required hosts to connect to the NFS server.

Configuring the NFS Server

Web browser to NGINX (proxy)

One-way SSL

Enabled by default

Table 3-2 Securing Communication Between Data Sources and Identity Intelligence

Communication

Supported security modes

More information

SmartConnector to Transformation Hub

  • One-way SSL

  • Mutual SSL

Configuring One-Way SSL between the SmartConnector and Transformation Hub

Configuring Mutual SSL between the SmartConnector and Transformation Hub

Identity Manager to Identity Manager Driver for Entity Data Model

One-way SSL

Creating a Secure Connection to the Identity Manager Engine

Identity Manager Driver for Entity Data Model to Transformation Hub

  • One-way SSL

  • Mutual SSL

Configuring One-Way SSL between the driver and Transformation Hub

Configuring Mutual SSL between the driver and Transformation Hub

Identity Manager to SmartConnector over Syslog

One-way SSL

Configuring Audit Events Collection

Identity Governance to Transformation Hub

  • One-way SSL

  • Mutual SSL

Configuring One-Way SSL Between Identity Governance and Transformation Hub

Configuring Mutual SSL Between Identity Governance and Transformation Hub