Orchestrating identity modernization using IBM Security Verify

Introduction

An organisation needs to manage and transform their identities and user repositories. The identities can be in an on-premises user repository or Cloud.

Here are the main two use cases:

1. Migrating identities from on-premises to IBM Security Verify's Cloud Directory starts the organisations cloud journey and refrains their efforts in hardware maintenance and skills for certain user repositories like LDAP or AD.

2. Migrate the user repository to a different vendor example – Ping Identity or Okta.

The article demonstrates the configuration steps that are needed to migrate users from LDAP or AD to IBM Security Verify and to migrate the LDAP or AD users to a 3rd party identity provider.

Migration of users from LDAP/AD to IBM Security Verify

Managing a user repository requires time and skills to provide a continuous maintenance and support.
The organizations need a solution to reduce the in-house cost incurred in repository management and rather focus on the actual business aspect of their applications.

IBM Security Verify has its own user repository known as Cloud Directory, which provides a seamless migration path to move users from an on-premises directory to Cloud Directory.

Prerequisite:

1. IBM Security Verify tenant
2. On-premise LDAP, which is current user repository

Configuration on IBM Security Verify side:

1. Login to the Admin console

2. Go to Integrations > Identity agents.

3. Select Create agent configuration.

   

4. Select Authentication as the purpose and select the LDAP tile.
   Click Next.

   

5. Under Connection settings, provide the LDAP connection details.

   

6. Under User properties, enter the user attributes that are defined user properties and returned from a successful password verification operation.

   

7. Under Attribute mapping, map the identity provider attributes from the identity provider to the Verify Cloud Directory attributes.

   

8. In the Next steps section, the following actions need to be taken.

   1. Select View API credentials and use the copy to clipboard icon to copy and store the Client ID and Client secret.

   2. . Download the bridge agent from the IBM Container Repository (ICR). Refer to Installing and configuring the Verify Bridge on Docker for further details.

9. The configuration is added to Identity agents and the identity provider is listed in Authentication > Identity providers tab.

   

10. Now, lets enable user migration for newly created Identity provider.

11. In the Identity Linking section, select Enable Identity linking for this identity provider and select a Unique user identifier from the dropdown list.

12. Enable the Just-in-time provisioning option.

13. Under Just-in-time provisioning, check the Provision password migration checkbox to enable user password migration to the Cloud Directory.

    

14. Configuration is complete now, next steps are actual login flow and validation.

Login with IBM SDS

Go to your ISV tenant and choose the option of login using IBM SDS. Provide user details that are present in SDS.

Login with Cloud Directory

Go to your ISV tenant and choose the option of login using Cloud Directory. Ensure to provide the same credentials that you used during login with SDS. Essentially, now the user is migrated to Cloud Directory and they don't need to bother about changing the username or password.

This concludes the first use case of migration of users from LDAP to IBM Security Verify's Cloud Directory.

Migration of users from LDAP/AD to third party identity provider

Now, let's consider the second use case of migrating users from LDAP or AD to any third-party identity provider. In, the described use case, Okta is the third-party provider, however, it can be Ping or Azure.

Prerequisite:

1. IBM Security Verify tenant
2. Flow designer enabled in your tenant
3. IBM Security Verify SaaS Resources contents downloaded or cloned to your machine. Refer to the parent page for details on how to achieve this. The folder is referred here-on as $GIT_REPO.
4. On-premise LDAP or AD, which is current user repository
5. Okta tenant

The following can be achieved by using the setup -

1. Use Identity orchestrator as a mechanism to migrate the users that exist on On-prem user registry.
2. Migrate the users with part of the login experience.
3. Users are navigated into the modern authentication experience after migration.
4. Eventually, sunset the on-prem user repository.

Overview of the flow :

Configuration on Okta side:

1. Generate a token so that API can be executed on your tenant. After login, in the left-side menu, go to Security-> API -> Create Token.

   

2. Configure a Web App application to establish federation between Okta and IBM Security Verify.

   

3. Login to the Admin console -> Application (On the left menu) -> Application -> Create App integration -> OIDC

4. Choose the Grant type that you want to configure - by default Authorization Code Grant type is configured.

5. Provide Sign-in redirect URIs. The values come from IBM Security Verify. For example, https://<your_verify_tenant>/auth/redirect.

6. Capture the client id and secret, they are required at the time of configuration in IBM Security Verify.

Configuration steps on IBM Security Verify side:

Enable IBM Security Verify to authenticate against On-premise LDAP or AD, here are the steps to do that -

Active Directory as an identity source

https://www.ibm.com/docs/en/security-verify?topic=providers-configuring-prem-ldap-provider

Okta needs to be added as an identity provider to IBM Security Verify

Configuration path - Log in to Admin console -> Authentication -> Identity Provider -> Add Identity provider -> OIDC Enterprise.

Provide the okta OIDC well know endpoint. For example, https://<yourtenant>-admin.okta.com/.well-known/openid-configuration.

Set Realm and issuer of the newly configured identity source. The tenant name itself can also be used. For example https://<yourtenant>-admin.okta.com.

Create a custom attribute and assign a rule to it

Now, a flag is needed to store the value pointing whether the user is migrated or not. The flag can be termed as Migrated to Okta.

Create a custom profile attribute – From the left-side menu, click Directory > Attributes> Custom attribute.

The following screenshot demonstrates the look after saving.

To attach a rule, in left menu go to Authentication -> Identity provider -> Global settings -> Attribute mapping.

Copy the following script and use it with custom attribute (Migrated to Okta). The custom rule is to create the user (Just in time) with the login flow and map it to a custom attribute (Migrated to Okta). In this way, it can be captured when the user logins next time and what login experience needs to be offered.

statements: 
- context: > 
    oktaTenant := "https://<your-tenant>-admin.okta.com" 
- if: 
    match: idsuser.getValue("JIT_realmName") != "<this is your On prem LDAP identity source realm name>" 
    return: "false" 
- context: > 
    oktaToken := "<token>" 
- context: > 
    r := hc.Post(context.oktaTenant + "/api/v1/users", { 
        "Accept": "application/json", 
        "Content-Type": "application/json", 
        "Authorization": "SSWS " + context.oktaToken 
    }, jsonToString({ 
        "profile": { 
            "firstName": idsuser.getValue("givenName"), 
            "lastName": idsuser.getValue("sn"), 
            "email": idsuser.getValue("mail"), 
            "login": idsuser.getValue("mail") 
        }, 
        "credentials": { 
            "password" : { "value": idsuser.getValue("password") } 
        } 
    })) 
- return: > 
  context.r.responseBody.status == "ACTIVE" ? "true" : (context.r.responseBody.status) 

This is how it looks like -

Custom branding theme

This flow presents custom pages and so, a theme needs to be created to prevent affecting the flows using the default theme. There are two customized files:

• custom_page1.html: This requests for the username.
• custom_page2.html: This shows an error in the event that the flow fails.

Login to the IBM Security Verify admin console and follow the provided steps.

1. From the left-side menu, select User experience and click on Branding

2. Create a new branding theme called "Migration LDAP to Okta". You can follow the steps mentioned here.

   

3. Click on the theme tile to view the file tree.

4. Expand "workflow" > "pages" and click on the three vertical dots next to "custom_page1.html". Click "Upload".

   

5. Choose "$GIT_REPO/flows/ldap_to_okta_migration/pages/templates/workflow/default/custom_page1.html" from the local folder. Then click "Upload".

   

6. Similar to the earlier step, under "workflow" > "pages", click on the three vertical dots next to "custom_page2.html". Click "Upload".

7. Choose "$GIT_REPO/flows/ldap_to_okta_migration/pages/templates/workflow/default/custom_page2.html" from the local folder. Then click "Upload".

Import the workflow

1. From the left-side menu, select User experience and click on Flow designer.

2. Click the Import icon adjacent the Create flow button.

   

3. Enter the details and upload the file located at "$GIT_REPO/flows/ldap_to_okta_migration/ldap_to_okta_migration.bpmn". Click Import flow.

   

4. The designer screen gets opened.

   

5. Select the "Set Vars" task and modify the "okta_tenant" and "onprem_realm" values, onprem_realm is realm name of your LDAP or AD identity source.

   

6. Select the "Ask for username" task and set the theme to the "Migration LDAP to Okta" theme.

   

7. Click on Save changes and Publish.

Running the flow

1. In the flow "Settings" tab, copy the "Execution URL".

   

2. Open an incognito tab or a completely different browser and paste the URL.

3. Enter the username and click "Continue".

4. User gets redirected to On-prem LDAP identity source login.

5. Log out and again paste the URL. This time the user gets redirected to login using okta.

The wrap

These flows are combination of using several powerful capabilites provided by IBM Security Verify

1. Use of the flow designer to orchestrate a complex migration flow
2. Functions to write complex scripted logic
3. Out-of-the-box support for OIDC Enterprise identity sources
4. Out-of-the-box user and credential migration from LDAP to Cloud Directory

💎

Vivek Jain, IBM Security