Data Confidentiality with OpenDJ LDAP Directory Services

FR_plogo_org_FC_openDJ-300x86Directory Servers have been used and continue to be used to store and retrieve identity information, including some data that is sensitive and should be protected. OpenDJ LDAP Directory Services, like many directory servers, has an extensive set of features to protect the data, from securing network connections and communications, authenticating users, to access controls and privileges… However, in the last few years, the way LDAP directory services have been deployed and managed has changed significantly, as they are moving to the “Cloud”. Already many of ForgeRock customers are deploying OpenDJ servers on Amazon or MS Azure, and the requirements for data confidentiality are increasing, especially as the file system and disk management are no longer under their control. For that reason, we’ve recently introduced a new feature in OpenDJ, giving the ability to administrators to encrypt all or part of the directory data before writing to disk.clouddataprotection

The OpenDJ Data Confidentiality feature can be enabled on a per database backend basis to encrypt LDAP entries before being stored to disk. Optionally, indexes can also be protected, individually. An administrator may chose to protect all indexes, or only a few of them, those that contain data that should remain confidential, like cn (common name), sn (surname)… Additionally, the confidentiality of the replication logs can be enabled, and then it’s enabled for all changes of all database backends. Note that if data confidentiality is enabled on an equality index, this index can no longer be used for ordering, and thus for initial substring nor sorted requests.

Example of command to enable data confidentiality for the userRoot backend:

dsconfig set-backend-prop 
 -h -p 4444 
 -D "cn=Directory Manager" -w secret12 -n -X 
 --backend-name userRoot --set confidentiality-enabled:true

Data confidentiality is a dynamic feature, and can be enabled, disabled without stopping the server. When enabling on a backend, only the updated or created entries will be encrypted. If there is existing data that need confidentiality, it is better to export and reimport the data. With indexes data confidentiality, the behaviour is different. When changing the data confidentiality on an index, you must rebuild the index before it can be used with search requests.

Key Management - Photo adapted from

When enabling data confidentiality, you can select the cipher algorithm and the key length, and again this can be per database backend. The encryption key itself is generated on the server itself and securely distributed to all replicated servers through the replication of the Admin Backend (“cn=admin data”), and thus it’s never exposed to any administrator. Should a key get compromised, we provide a way to mark it so and generate a new key. Also, a backup of an encrypted database backend can be restored on any server with the same configuration, as long as the server still has its configuration and its Admin backend intact. Restoring such backend backup to fresh new server requires that it’s configured for replication first.

The Data Confidentiality feature can be tested with the OpenDJ nightly builds. It is also available to ForgeRock customers as part of our latest update of the ForgeRock Identity Platform.

Filed under: Directory Services Tagged: confidentiality, data-confidentiality, directory-server, encryption, ForgeRock, identity, java, ldap, opendj, opensource, security

ForgeRock OpenIG 4 – Getting Credentials from ForgeRock OpenAM 13

This blog post was first published @, included here with permission.

Interested to see how ForgeRock Identity Gateway orchestrates with the ForgeRock Access Management solution to replay a User Credential on to a Legacy Application giving him/her access to it? There’s a screen-cast right below this write up. I had already posted a couple of entries on this space, demonstrating how OpenIG fetches User Credentials from different Datastores like a CSV file and a JDBC Database. While it’s not a prerequisite to know it before viewing the Video below, it might help get a good grip on the steps performed. So if you haven’t come across those blog entries yet, here it is:

ForgeRock OpenIG 4 – Getting Credentials from File Datastore
ForgeRock OpenIG 4 – Getting Credentials from Database

What to expect in the video?

– A user tries to access ‘’ url
– A Java EE OpenAM Policy Agent sitting in front of the ‘′ url intercepts the request from the client (user’s browser) and redirects the request to ForgeRock OpenAM (
– ForgeRock OpenAM will send the OpenAM Login Page back to the user
– The user supplies the credential, which the OpenAM verifies. If authentication is successful,OpenAM adds the username of the user and his/her encrypted password to the session and sends it to Java EE Policy Agent
– Java EE Policy agent validates the user’s session, gives control to OpenIG.
– Because the URL that the client requested for (, matches a specific route (say 04-route.json) configured in OpenIG, it applies the filters in the route configuration file. The first filter will use a shared key (also known to the OpenAM) to decrypt the encrypted password sent by OpenAM. The second filter will retrieve the username and password from the exchange and replaces your browser’s original HTTP GET request with an HTTP POST login request that contains the credentials to authenticate and the third filter will remove the username and password headers before continuing to process the exchange.
– The HTTP server validates the credentials and respond back to OpenIG with user’s profile page
– OpenIG sends that response to the End user

Note: OpenAM in our setup is configured to process a ‘Password Replay’ Java Class on successful authentication. The Java EE agent in OpenAM is configured only for Single Sign On (SSO) and is configured to add the UserToken (username) and sunIdentityUserPassword (password) as session attributes in HTTP header. And the FQHN of OpenAM deployment in the Video demonstration is ‘’ and not ‘’

To satisfy your Visual Cortex, here’s an illustration of the steps above:

OpenIG Fetching Credentials from OpenAM-Modified

Now on to the step by step configuration. Enjoy!

Related Documentation / Video:
– ForgeRock OpenIG Documentation
– Screncast on ‘ForgeRock OpenIG 3.x : Getting Credentials from OpenAM

ForgeRock OpenIDM: Setting Up SSL With MySQL Internal Repository

This blog post was first published @, included here with permission.

If you’ve already seen the video demonstration on setting up ForgeRock OpenIDM to use a JDBC repository, you may now be interested to know how to secure the traffic from ForgeRock OpenIDM to its JDBC repository. So in the video that follows, you will see:

– Setting up SSL in MySQL database

– Configuring OpenIDM to use SSLto the MySQL database (its internal repository)

Like several other videos that I’ve already published on this blog space around ForgeRock products, this one also makes use of OpenIDMwithSSLtoJDBC-01

Hope you’ll find the video log useful:

MySQL Product Documentation
ForgeRock Documentation

Setting Up ForgeRock OpenAM with HTTPS on Tomcat

This blog post was first published @, included here with permission.

This post is a demo version of the ForgeRock Documentation on Setting Up OpenAM with HTTPS on Tomcat. I had earlier published a screen-cast on the ForgeRock OpenAM deployment and Configuration on a here. Below you’ll find the steps that I run in my Ubuntu Linux Container to secure our OpenAM deployment:

– Create a Certificate & store it in keystore in a Linux Container
– Modify the Tomcat Server Configuration file (server.xml) to enable SSL (on port 8443)
– Deploy ForgeRock OpenAM
– Access OpenAM from the host OS and complete the configuration

If it’s hard for your visualize how the infrastructure looks like, here’s an illustration to make life easy.


Now on to the action:

If you are not able to view the embedded video, please click here

ForgeRock OpenDJ Replication – Enabling Encryption

This blog post was first published @, included here with permission.

This is a sequel to my earlier blog update on ForgeRock OpenDJ Replication and is largely inspired by a question raised in the ForgeRock Community Website. So if you are not very familiar with the steps involved in configuring OpenDJ Replication, I suggest you read/watch it before watching the embedded video below:

One-liner about the infrastructure used: two Linux Containers, each running an instance of ForgeRock OpenDJ is already replicating the OpenDJ data, but the replication traffic is not secure. In the video demonstration that follows, we’ll tighten the security a bit by encrypting the replication traffic as well as monitor the same using wireshark running on the host OS. Well, the diagram below indicates the end state of our screen-cast:



[If you are not able to see the embedded video, please watch it on YouTube here ]