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:
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:
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.
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.
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) .
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:
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 theconnect()
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 theJKS password
attribute is used to access the keystore. You can specify any value for theuser
.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.
-