2 Security Features in Oracle Directory Integration Platform

This chapter discusses the most important aspects of security in Oracle Directory Integration Platform.

Topics:

• Overview of Authentication in Oracle Directory Integration Platform

• About Access Control and Authorization and Oracle Directory Integration Platform

• About Data Integrity and Oracle Directory Integration Platform

• About Data Privacy and Oracle Directory Integration Platform

• About Tools Security and Oracle Directory Integration Platform

• Credential Store Framework for Oracle Directory Integration Platform

2.1 Overview of Authentication in Oracle Directory Integration Platform

Authentication is the process by which the Oracle directory server establishes the true identity of the user connecting to the directory. It occurs when an LDAP session is established by means of the ldapbind operation.

It is important that each component in Oracle Directory Integration Platform be properly authenticated before it is allowed access to the directory.

Topics:

• Secure Sockets Layer and Oracle Directory Integration Platform

• Oracle Directory Integration Platform Authentication in SSL Mode

• Transparent Layer Security Protocol and Cipher Suites

• Profile Authentication

2.1.1 Secure Sockets Layer and Oracle Directory Integration Platform

The Oracle back-end directory should be configured to use Secure Socket Layer (SSL).

If Oracle Unified Directory or Oracle Directory Server Enterprise Edition is your Oracle back-end directory, Oracle Directory Integration Platform will work in non-SSL mode when it is first installed. If Oracle Internet Directory is your Oracle back-end directory, however, an Secure Socket Layer (SSL) connection is required.

Oracle Directory Integration Platform supports these SSL implementation modes:

• No Authentication (SSL Mode 1)—Provides SSL data encryption, but does not use SSL for authentication.

  Note:

  If the Oracle back-end directory is Oracle Internet Directory, then Oracle Directory Integration Platform supports both No Authentication SSL mode (SSL mode 1) and SSL Server Authentication (SSL mode 2). If Oracle Unified Directory or Oracle Directory Server Enterprise Edition is your Oracle back-end directory, SSL Server Authentication (SSL mode 2) is the only SSL option.

  Oracle does not recommend using No Authentication (SSL Mode 1).

• SSL Server Authentication (SSL Mode 2)—Oracle recommends this mode for Oracle Directory Integration Platform. It Includes both SSL data encryption and SSL authentication of the server to the client. In Oracle Directory Integration Platform, the server is the directory server, and the client is the Oracle Directory Integration Platform.

Note:

Oracle Directory Integration Platform 12c supports Transport Layer Security (TLS) v1.2 protocol for communication with connected directories. See Transport Layer Security Protocol and Cipher Suites.

The server verifies its identity to the client by sending a certificate issued by a trusted certificate authority (CA). This mode requires a public key infrastructure (PKI) and certificates to be stored in the Java Keystore (JKS).

To use SSL with Oracle Directory Integration Platform, you must start both the Oracle back-end directory and Oracle Directory Integration Platform in the same SSL mode. For example, if the Oracle back-end directory is running in SSL mode 2, then Directory Integration Platform must be configured to connect to the Oracle back-end directory using the same SSL mode 2.

See Also:

If using Oracle Internet Directory as the Oracle back-end directory, refer to the Oracle Fusion Middleware Administering Oracle Internet Directory for instructions about starting the Oracle directory server in SSL mode.

2.1.2 Oracle Directory Integration Platform Authentication in SSL Mode

The identity of the directory server can be established by starting both the Oracle back-end directory and the directory integration server in SSL server authentication mode. In this case, the directory server provides its certificate to the directory integration server, which acts as the client of the Oracle back-end directory.

You can also configure the Oracle Directory Integration Platform to use SSL when connecting to a third-party directory. In this case, you store the connected directory certificates in the Java Keystore (JKS) as described in "Managing the SSL Certificates of Back-End Directories and Connected Directories".

2.1.3 Transport Layer Security Protocol and Cipher Suites

Oracle Directory Integration Platform 12c supports Transport Layer Security (TLS) v1.2 protocol for communication with connected directories and uses the cipher suites to encrypt and decrypt data.

The TLS protocol is a successor to the SSL protocol. TLS is a widely used protocol today by applications that entails data transmission over a network. The primary goal of the TLS protocol is to provide enhanced security and data integrity between two communicating applications.

The Transport Layer Security protocol now has three versions for increasing security: TLS 1.0, TLS 1.1, and TLS 1.2. The default version used in Oracle Directory Integration Platform is TLS 1.2.

Topics:

• Supported Out-of-Box Cipher Suites

• Disabled Cipher Suites in Oracle Directory Integration Platform

• Adding Cipher Suites into Oracle Directory Integration Platform

• Specify the SSL/TLS Protocol Version

2.1.3.1 Supported Out-of-Box Cipher Suites

Oracle Directory Integration Platform supports a large number of cipher suites which is available out-of-box.

During a TLS handshake, the Oracle Directory Integration Platform and connected directory initiates the connection using TLSv1.2 protocol and supported cliphers in the order listed below.

Note:

Oracle Directory Integration Platform provides you the option to add cipher suites used by the connected directories, which is not available out-of-box. See Adding Cipher Suites into Oracle Directory Integration Platform.

Table 2-1 Out-of-Box Cipher Suites

TLS Protocol	Cipher Suite
TLS version 1.2	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_RSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_RSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS version 1.2	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS version 1.2	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS version 1.2	TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS version 1.2	TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_DH_DSS_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_DH_DSS_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_RSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_DH_DSS_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_RSA_WITH_AES_256_CBC_SHA256
TLS version 1.2	TLS_DH_DSS_WITH_AES_256_CBC_SHA256
TLS version 1.2	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS version 1.2	TLS_RSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_DH_DSS_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_RSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_DH_DSS_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_DH_RSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS version 1.2	TLS_DH_RSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS version 1.2	TLS_DH_RSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
TLS version 1.2	TLS_DH_RSA_WITH_AES_256_CBC_SHA256
TLS version 1.2	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS version 1.2	TLS_DH_RSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS version 1.2	TLS_DH_RSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS version 1.2	TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS version 1.2	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS version 1.2	TLS_RSA_WITH_3DES_EDE_CBC_SHA

2.1.3.2 Disabled Cipher Suites in Oracle Directory Integration Platform

The following is a list of weak cipher suites that are disabled by default in Oracle Directory Integration Platform:

• SSL_RSA_WITH_RC4_128_MD5

• SSL_RSA_WITH_RC4_128_SHA

• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

• TLS_ECDHE_RSA_WITH_RC4_128_SHA

• TLS_ECDH_ECDSA_WITH_RC4_128_SHA

• TLS_ECDH_RSA_WITH_RC4_128_SHA

• SSL_RSA_WITH_3DES_EDE_CBC_SHA

• SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

• SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA

• TLS_EMPTY_RENEGOTIATION_INFO_SCSV

2.1.3.3 Adding Cipher Suites into Oracle Directory Integration Platform

If the cipher suites configured in the back-end or connected directory are not available or recognized in Oracle Directory Integration Platform then you must add those suites into Oracle Directory Integration Platform using the Oracle Fusion Middleware System MBean Browser.

To add cipher suites into Oracle Directory Integration Platform, complete the following steps:

Note:

• In a cluster environment, you must repeat the below steps for all of the Oracle Directory Integration Platform managed servers in the cluster.

• You can also use the WLST command to add the cipher suites. See Setting Cipher Suites Using WLST: An Example in Oracle Fusion Middleware Administering Security for Oracle WebLogic Server.

1. Open a browser, and access the Fusion Middleware Control Console using the following URL format:

   http://host1.example.com:7001/em

2. Enter the Oracle Fusion Middleware administrator user name and password and click Login.
3. From the target navigation pane, expand the domain.
4. From the domain home page, select the Managed Server (wls_ods1).

   Note:

   The default value for Oracle Directory Integration Platform Managed Server is wls_ods1.
5. From the WebLogic Server menu, choose System MBean Browser. The System MBean Browser page is displayed.

   Note:

   You can also click the Find icon to perform a search for an MBean, attribute. For example com.bea:Name=wls_ods1,Type=Server.
6. Expand Configuration MBeans in the MBean navigation tree and then select com.bea > Server.
7. Expand the Server node and then expand the Managed Server node (wls_ods1).
8. From the Managed Server node, expand SSL and then select the Managed Server MBEAN.
   The Configuration MBEAN page is displayed.
9. Select Attributes tab and then select CipherSuites.
   The Attribute: Ciphersuites page is displayed.
10. Click Add and then add the ciphers configured in the back-end or connected directory.
11. Click Apply.

    Note:

    After you add the ciphers, the out-of-box supported cipher suites in Oracle Directory Integration Platform are not recognized. You must add the required default ciphers for communication between the Oracle Directory Integration Platform and back-end or connected directories. See Supported Out-of-Box Cipher Suites.

2.1.3.4 Specify the SSL/TLS Protocol Version

You can use the Fusion Middleware Control Console to specify the SSL/TLS protocol versions enabled for the SSL handshake. While in most cases the most recent version of the SSL or TLS protocol is desirable, peers may not support it. You may want to specify the enabled SSL or TLS protocol based on circumstances (compatibility, SSL performance, and environments with maximum security requirements) .

To specify TLS protocol version in Oracle Directory Integration Platform, complete the following steps:

1. Open a browser, and access the Fusion Middleware Control Console using the following URL format:

   http://host1.example.com:7001/em

2. Enter the Oracle Fusion Middleware administrator user name and password and click Login.
3. From the target navigation pane, expand the domain.
4. From the domain home page, select the Managed Server (wls_ods1).

   Note:

   The default value for Oracle Directory Integration Platform Managed Server is wls_ods1.
5. From the WebLogic Server menu, choose System MBean Browser. The System MBean Browser page is displayed.

   Note:

   You can also click the Find icon to perform a search for an MBean, attribute. For example com.bea:Name=wls_ods1,Type=Server.
6. Expand Configuration MBeans in the MBean navigation tree and then select com.bea > Server.
7. Expand the Server node and then expand the Managed Server node (wls_ods1).
8. From the Managed Server node, expand SSL and then select the Managed Server MBEAN.
   The Configuration MBEAN page is displayed.
9. Select Attributes tab and then select MinimumTLSProtocolVersion.
   The Attribute: MinimumTLSProtocolVersion page is displayed.
10. You can specify the following versions in the Value field:

    • SSLv3: Specifies SSL V3.0 as the minimum protocol version enabled in SSL connections.

    • TLSv1: Specifies TLS V1.0 as the minimum protocol version enabled in SSL connections.

    • TLSvx.y: Specifies TLS Vx.y as the minimum protocol version enabled in SSL connections, where x is an integer between 1 and 9 (inclusive) and y is an integer between 0 and 9 (inclusive). For example, TLSv1.2.

    Note:

    The protocol that you specify here is the lowest supported version of SSL and TLS that are enabled for SSL handshake. It does not guarantee that the specified version will be picked up. The version in effect is determined by the underlying JRE which protocol that is enabled and also the SSL handshake between Oracle Directory Integration Platform and connected/back-end directories.

    For example, if SSLV3 is specified then the SSLv3,TLSv1.0 , TLSv1.1 and TLSv1.2 protocols are supported. It depends on the underlying JRE & SSL handshake and the required protocol would be picked for SSL communication.

11. Click Apply.

    Note:

    In a cluster environment, you must repeat the above steps for all of the Oracle Directory Integration Platform managed servers in the cluster.

2.1.4 Profile Authentication

Within the Oracle back-end directory, an integration profile represents a user with its own distinguished name (DN) and password.

The users who can access the profiles are:

• The administrator of Oracle Directory Integration Platform.

  In back-end directory the administrator is represented by the DN cn=dipadmin,cn=dipadmins,cn=directory integration platform,cn=products,cn=oraclecontext.

• Members of the Oracle Directory Integration Platform administrator group.

  In back-end directory the administrator group is represented by the DN cn=odisgroup,cn=dipadmins,cn=directory integration platform,cn=products,cn=oraclecontext.

When the Oracle Directory Integration Platform imports data to the Oracle back-end directory based on an integration profile, it proxy-binds to the directory as that integration profile. The Oracle Directory Integration Platform can bind in either SSL or non-SSL mode.

2.2 About Access Control and Authorization and Oracle Directory Integration Platform

Authorization is the process of ensuring that a user reads or updates only the information for which he or she has privileges.

When directory operations are attempted within a directory session, the directory server ensures that the user— identified by the authorization identifier associated with the session—has the requisite permissions to perform those operations. If the user does not have the necessary permissions, then the directory server disallows the operation. Through this mechanism, called access control, the directory server protects directory data from unauthorized operations by directory users.

• If the Oracle Unified Directory is used as the back-end directory, then some privileges are assigned to the Oracle Directory Integration Platform user. For more information, see Understanding Root Users and the Privilege Subsystem in Administering Oracle Unified Directory.

• If the Oracle Internet Directory is used as the back-end directory, then to restrict access to only the desired subset of Oracle Internet Directory data, for both the directory integration server and a connector, place appropriate access policies in the directory.

The following section discusses these policies:

• Understanding Access Controls for the Oracle Directory Integration Platform

• Understanding Access Controls for Profiles

2.2.1 Understanding Access Controls for the Oracle Directory Integration Platform

The Oracle Directory Integration Platform binds to the directory both as itself and on behalf of the profile.

• When it binds as itself, it can cache the information in various integration profiles. This enables the directory integration server to schedule synchronization actions to be carried out by various connectors.

• When contacting Oracle Unified Directory, the directory integration server operates on behalf of a profile, it acts as proxy for the profile—that is, it uses the profile credentials to bind to the directory and perform various operations. The directory integration server can perform only those operations in the directory that are permitted in the profile.

• When contacting Oracle Unified Directory or Oracle Directory Server Enterprise Edition, the directory integration server binds using the Oracle Directory Integration Platform user and then uses the proxy authorization v2 control (RFC 4370) to perform the actions against the directory server acting as the profile.

To establish and manage access rights granted to directory integration servers, Oracle Directory Integration Platform creates a group entry, called odisgroup, during installation. When a directory integration server is registered, it becomes a member of this group.

In back-end directory the DN of odisgroup is:

cn=odisgroup,cn=directory admins,cn=directory integration platform,cn=products,cn=oraclecontext

You control the access rights granted to directory integration servers by placing access control policies for the odisgroup entry. The default policy grants various rights to directory integration servers for accessing the profiles. For example, the default policy enables the directory integration server to compare user passwords between the Oracle back-end directory and the connected directory it binds as a proxy on behalf of a profile. It also enables directory integration servers to modify status information in the profile—such as the last successful execution time and the synchronization status.

2.2.2 Understanding Access Controls for Profiles

During installation, Oracle Directory Integration Platform creates a group entry called odipgroup that enables you to control the access rights granted to various profiles.

For additional security, the odipigroup and odipegroup groups are also created during configuration using the dipConfigurator command. All import profiles are assigned to the odipigroup group and all export profiles are assigned to the odipegroup group. Rights are controlled by placing appropriate access policies for the odipgroup entry. The default access policy, automatically installed with the product, grants to profiles certain standard access rights for the integration profiles they own. One such right is the ability to modify status information in the integration profile, such as the parameter named orclodipConDirLastAppliedChgTime. The default access policy also permits profiles to access back-end directory change logs, to which access is otherwise restricted.

See Also:

• The chapter "Controlling Access To Data" in the Oracle Fusion Middleware Administrator's Guide for Oracle Unified Directory.

• The chapter "Managing Directory Access Control" in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

• The chapter "Directory Server Access Control" in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition.

2.3 About Data Integrity and Oracle Directory Integration Platform

Oracle Directory Integration Platform ensures that data is not modified, deleted, or replayed during transmission by using SSL. This SSL feature generates a cryptographically secure message digest—through cryptographic checksums using either the Message-Digest algorithm 5 (MD5) or the Secure Hash Algorithm (SHA) —and includes the message digest with each packet sent across the network.

2.4 About Data Privacy and Oracle Directory Integration Platform

Oracle Directory Integration Platform ensures that data is not disclosed during transmission by using public-key encryption available with SSL. In public-key encryption, the sender of a message encrypts the message with the public key of the recipient. Upon delivery, the recipient decrypts the message using the recipient's private key.

To exchange data securely between the directory integration server and directory, you must run both components in the same SSL mode.

2.5 About Tools Security and Oracle Directory Integration Platform

You can run all the commonly used tools in SSL mode to transmit data to the back-end directory securely, including Oracle Enterprise Manager Fusion Middleware Control.

2.6 Credential Store Framework for Oracle Directory Integration Platform

Oracle Directory Integration Platform uses the Oracle Fusion Middleware infrastructure Credential Store Framework. Know more about the credentials Oracle Directory Integration Platform stores in this Credential Store Framework.

The following is a list and description of the credentials Oracle Directory Integration Platform stores in this Credential Store Framework:

• The Oracle Directory Integration Platform user name:

  cn=odisrv,cn=Registered Instances,cn=Directory Integration Platform,cn=products,cn=oraclecontext
  

• The Oracle Directory Integration Platform user password. The password is created during installation, stored as read-only, and read by run-time operations.

• The JKS password. The JKS password is used if the Server Only (mode 2) SSL setting is configured for connecting to the Oracle back-end directory or a third-party directory. You can use the WebLogic Scripting Tool (WLST) createCred() command to write the keystore password to the Credential Store Framework. For example: after invoking the WLST shell and connecting to the Oracle WebLogic Administration Server using the connect() command, enter:

  createCred(map="dip", key="jksKey", user="jksUser", password="password", desc="DIP SSL JKS")
  

  Table 2-2 createCred Commands

  Argument	Description
  map	Specifies the map name (folder) of the credential. The map option is fixed and the only supported value is dip.
  key	Specifies the key name of the credential. The key option is fixed and the only supported values is jksKey.
  user	Specifies the credential user name. The user attribute is not used to access the keystore and the JKS password attribute is used to access the keystore. You can specify any value for the user.
  password	Specifies the credential password. The password attribute is used to access the keystore.
  desc	Specifies a string describing the credential.

  You can change the keystore password to a new value, by running the updateCred() command:

  updateCred(map="dip", key="jksKey", user="jksUser", password="password"
  

  Note:

  • See Introduction to Oracle Fusion Middleware Audit Framework in Oracle Fusion Middleware Securing Applications with Oracle Platform Security Services.

  • The Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for more information about the WLST commands.