Co-Authored By Sameer Kapadia
Integrating hybrid identities with IBM Security Verify and onboarding onPrem LDAP into IBM Security Verify SaaS with the power of OpenShift
Challenges
In today’s dynamic landscape, where organizations leverage a multi-cloud hybrid deployment model, the management of digital identities and their security becomes paramount. The hybrid nature, with identities dispersed across various sources such as private clouds, legacy systems, or anywhere in the multi-cloud environment, accentuates the need for a comprehensive approach.
In the ongoing journey of cloud modernisation, the movement of identities is inevitable. Throughout this process, critical considerations must be given to user experience, the security of digital identities, and ensuring minimal disruption or threats to businesses.
IBM Security Verify empowers organisations to embark on Identity Fabric Journey, offering solutions to the challenges outlined above.
This article delves into how IBM Security Verify facilitates the seamless integration of on-prem LDAP eg:OPENDJ and, gradually, the migration of identities into a modern Identity and Access Management solution IBM Security Verify SaaS which offers
• Modern security methods
• Threat intelligence
• Auditing and tracking capabilities
Use Case
Consider the fictional company JKE, which currently maintains a user store in an on-premises OPENDJ LDAP. OpenDJ operates on the SSL port, storing user attributes, groups, and password information. The organization recognizes the necessity to transition to a modern Identity and Access Management (IAM) solution, represented by IBM Security Verify. The objective is to enable users to authenticate into Verify SaaS while seamlessly utilizing identities stored in on-premises OPENDJ.
Throughout this transition, the customer anticipates a Just-In-Time provisioning of identities from OPENDJ into IBM Security Verify, along with a gradual password migration from OpenDJ into Verify SaaS. This phased approach ensures a smooth and secure evolution over time.
Components and Flow
IBM Security Verify SaaS is a modern IAM solution with components;
-
In this approach, the Verify Bridge agent is deployed in an OpenShift environment with which it brings all the features of OpenShift.
-
Verify Bridge agent is deployed in a container environment (There are also different deployment pattern around different containers orchestration platform and other operation systems.) Here OpenShift is used.
-
In this article, We are considering OpenDJ as ldap source. It can als also be used in similar manner against a web service or Database.
A component Diagram which highlights, LDAP, Verify Bridge, Verify SaaS.
Pre-Requisites
-
OpenDJ already running in an environment
-
A Verify SaaS tenant is available
-
An OpenShift environment
Work Flow of the Deployment
Deployment Steps
Here we will go through the steps in Details which are described in the Deployment workflow in detail.
Pre-Requisites
-
OpenDJ is deployed in intranet
-
OpenShift environment is available (either Intranet or in public cloud)
-
IBM Security Verify SaaS is available
Create Identity Agent Configuration in Verify SaaS
The Verify Bridge when started connects with Verify SaaS and fetches the configuration.
Verify Bridge needs ClientID and Secret in process to connect with Verify SaaS.
Verify Bridge gets following information and the following steps will demonstrate how to configure those
-
Login to Verify SaaS tenant admin.
-
https://<tenant FQDN>/ui/admin
-
Goto Integrations -> Identity Agents
-
Click on Create Agent Configuration
-
Make sure Authentication is selected and Type is LDAP 
-
Fill in Connection Details related to OnPrem LDAP OPENDJ which has Orginationzation Users Identity Details
-
Bind dn for OpenDJ is cn=Directory Manager
-
Certificate is the signer certificate of OpenDJ which is listening on ssl port 636
-
Here openssl is used to fetch the certificate information
-
Example: openssl s_client -showcerts -host "opendj" -port "636" < /dev/null | sed -ne '/-----BEGIN CERTIFICATE-----/,/-----END CERTIFICATE-----/p' >> openDJSigner.pem
-
Adjust Additional Settings
-
These Settings are the connection level setting between Verify Bridge -> LDAP
-
Examples: Simultaneous LDAP connection Limit from Verify Agent to LDAP
-
Considerations need to be put to adjust connection time limit which should be less than firewall timeout limit(if any) between Verify Bridge -> LDAP 
-
User Properties settings are the values that Agent uses to look attributes /users in LDAP
-
For example: Usesrname attribute is the attribute it uses to search LDAP
-
Comma Separated attributes(during writing of this article space is required , later releases a space will not be required) for example: businessCategory, uid 
-
This page shows Attribute Mapping, which is what attribute of onPrem LDAP is mapped to Verify SaaS Cloud Directory, do note the example, on how businessCategory is mapped to customattribute in Cloud Directory. 
-
Fill in the details about the configurations
-
Notice Identity Provider displayName is what we will see when we configure Identity Agent Later
-
Realm is help to distinguish that these are the identities from these set of onPrem LDAP
-
Expand View Advanced Settings
-
Here you can add option Agent related configuration which agents reads and perform some action
-
Two of the example configurations(https://www.ibm.com/docs/en/security-verify?topic=installation-optional-configuration)
-
InsecureSkipVerify -> related to TLS connection verification
-
noGroups -> related to onPrem LDAP group population when set to true then ldap groups will not form credentials
-
Certificate for encryption controls cert between Bridge Agent -> Verify SaaS
-
Click on same and continue
-
Click on Finish step and note down the Api Credentials which is Client ID and Client Secret
-
Identity Agent Configuration in Verify SaaS is complete at this point
-
Create Identity Provider in Verify Saas
This configuration is what controls how users Authenticate into Verify SaaS using OnPrem Identities present in OpenDJ. This also controls password policy, Just In Time Provisioning and Password Migration.
-
Go again to Verify SaaS tenant and then Authentication -> Identity Providers
-
You will notice there is an entry already created by the name AuthenticateOnPrem as a result of Identity Agent configuration in previous set of steps 
-
Review other settings which got created
-
When its enabled , it will be shown as an option to users during login,refer SignIn Options
-
There is also an example towards the end of the section on how to incoming only this Identity Source.
-
Below is an example of Identity Provider Screenshot
-
A custom password policy can be created and attached to this(optional)
-
Whether admin can do password reset 
-
Username recovery attribute is specified here 
-
Below picture shows, Identity Linking As part of the configuration you have access to
-
Identity Linking on how the external identity mapped to users in cloud directory , attribute of givenName in openDJ is uniquely identified.
-
Just In Time Provisioning which helps users to be created into Cloud Director y upon authentication and is the basis how user identities are migrated from onPrem Identity Source(openDJ) to Verify SaaS Cloud Directory which is a central User repository of Verify SaaS
-
Password Migration is what provides a seamless experience to the User wherein they can continue to use same password they were using on onPrem Identities without a need to change it and over a period of time passwords are in cloud directory
-
Attribute mapping is populated from Identity Agent configuration 
-
This completes the Identity Provider Configuration
Deploy Verify Bridge on OpenShift
OpenShift is an orchestration Platform. There are other options like windows Host , Linux host, docker etc. Here, the example taken is Openshift and with it, it brings all benefits of OpenShift Orchestration Platform.
The approach of Verify Agent Deploment is via OpenShift Template.
Create Verify Bridge Openshift Template -> Instantiate Verify Bridge Openshift Template Instance
Openshift template is template which when instantiated can help to create the following in one click
-
Persistent Volume claim (IF Any)
-
Pass in all parameters required by verify Bridge container
Create OpenShift Template
-
Make sure openshift environment access is provided
-
In an OpenShift Project, create a template
-
Template yaml file is provided at the following github
-
Create template from the yaml file copied
-
Sudo oc create -f Verify-Bridge-Tempalte.yaml
-
Sudo oc get template (this will show that template is created). Picture shows name verify-bridge-stateful
-
Test the template by passing in parameters
sudo oc process verify-bridge-stateful \
-p APP_NAME="verifybridgeuat" -p CLIENT_ID="7c9a36ca-f4ce-47d9-9748-1e5516fbb2f7" \
-p CLIENT_SECRET="YJL4hV9Ar1" -p TENANT_URI="https://xx-us.verify.ibm.com"
-
Instantiate the template (create a template which creates secret, containers etc)
sudo oc process verify-bridge-stateful \
-p APP_NAME="verifybridgeuat" -p CLIENT_ID="7c9a36ca-f4ce-47d9-9748-1e5516fbb2f7" \
-p CLIENT_SECRET="YJL4hV9Ar1" -p TENANT_URI="https://xx-us.verify.ibm.com" \
-
It will create a secret and a statefulset(example is show in below picture)
-
The template Instantiation creates two things
-
A secrete which holds client-id,client secret , tenant id
-
There is a need to update secret with obfuscated client secret instead of
-
This is an option step which can be achieved once you have the pod running
-
Rsh into POD to obfuscate the secret
sudo oc rsh verifybridgeuat-config-0 /go/src/onprem -obf "YJL4hV9Ar1"
-
fSOzeJVhoBQ06j4jx1ywTtyAACn1xxxVbbw4kyOFiT4=
-
the output will be obfuscated password
-
this password can be passed into the existing running deployment by change parameter CLIENT_SECRET to OBF_CLIENT_SECRET
-
This will be a two step process
-
Update secrete created with obf password
-
Convert obfuscated client secret into base64
-
echo "fSOzeJVhoBQ06j4jx1ywTtyAACn1xxxVbbw4kyOFiT4="|base64
-
ZlNPemVKVmhvQlEwNmo0angxeXdUdHlBQUNuMXh4eFZiYnc0a3lPRmlUND0K
-
Sudo oc edit secret verifybridgeuat
-
At this point the verify Bridge is able to successfully run and connect
-
Cd go/src will have onPrem.log
Completion of All Configurations steps
At this point following configuration has been completed
Verification by logging into Verify SaaS using OnPrem OpenDJ
start the request by putt the above URL way that
This also does a Just In Time Provisioning into Verify Cloud Directory
OnPrem ldap is successfully Integrated with Verify SaaS. Which achives the purpose of migrating onPrem Identity into a modern IAM.Over a period of time all Identities will moved into Verify SaaS along with password. The integration will be seamless without affecting Customers, Employees, Business.
The same integration is effective for OpenDS based on prem repository as well.