Migrating from a Legacy IAM Solution to Identity Security Cloud

anneragh · July 30, 2024, 2:48pm

Overview

When migrating from one Identity and Access Management (IAM) solution to another, it’s important to provide a seamless experience for end users requesting access. Requiring users to utilize two separate applications for access requests during the transition period can lead to confusion and inefficiency.

One approach is to leverage SailPoint Identity Security Cloud (ISC) as the unified user interface for all access requests. By configuring Identity Security Cloud to fulfill the provisioning actions in the legacy IAM system behind the scenes, you can ensure that users have a single, consistent access request experience.

This setup allows ISC to serve as the central portal for users to request access, review access, and certify access, while the legacy system remains responsible for fulfilling those requests on the backend. Users are shielded from the complexity of the migration, submitting all their access requests through the ISC until all connectors are migrated from the legacy IAM solution to ISC.

Integration Strategies

Here is a summary of the key ways to integrate a legacy IAM solution with ISC.

Direct Connector

A direct connector can be created if the legacy IAM solution provisions access and acknowledges success/failure in the same request

However, a direct connector will not work well if:

The legacy IAM creates a request like ISC does
Access fulfillment happens after some validations and process
The provisioning response is not immediate

Ideally, most IAM solutions have multiple steps and validations, so this approach does not fit.
For Implementation, Please refer: Connectivity | SailPoint Developer Community

Service Desk Integration

A Service Desk integration is best when the legacy IAM solution:

Provides an API to create an access request
Returns a request ID in the API response

With a request ID, ISC can:

Store the ID
Keep checking the status of the access request
Mark the request as completed in IdentityNow once fulfilled on the legacy side

For Implementation, Please refer: Service Desk Integration | SailPoint Developer Community

Manual Task

Manual tasks may be appropriate when the legacy IAM solution:

Does not have a usable API
Requires calling multiple APIs to fulfill provisioning
Needs complex data translation between systems

With manual tasks:

Instead of a human completing the provisioning steps in the legacy system, implement a process that:
- Submits an access request in the legacy IAM
- Polls the status of the request from the legacy system
- Marks the request as complete in ISC once fulfilled

This allows automation of the manual provisioning steps through a custom process, rather than relying on a human to complete the provisioning in the legacy system and update the status in ISC.

Manual Task Process for Legacy IAM Integration

When a legacy IAM solution lacks a suitable API for direct integration or requires complex multi-step provisioning, a custom manual task process can be implemented to automate the integration. This process replaces the need for a human to manually complete the provisioning steps in the legacy system and update the status in IdentityNow.

The manual task process typically involves the following steps:

graph TD
    A[Request Submitted] --> B{ISC Validations Success}
    B -->|Yes| C{Access Request Approved in ISC}
    C --> D[Trigger Manual Task Process]
    D --> E[Collect Request Data from ISC]
    E --> F[Construct Request Payload for Legacy IAM]
    F --> G[Submit Request to Legacy IAM]
    G --> H[Poll Legacy IAM for Request Status]
    H --> I{Error}
    I -->|No| J[Update Request Status in ISC]
    I -->|Yes| K[Handle Error]
    K --> L[Log Error Details]
    L --> M{Retry or Escalate?}
    M -->|Retry| G
    M -->|Escalate| N[Escalate]
    J --> O[Access Request Fulfilled]

Triggering the Process

When an access request is approved in ISC, it triggers the custom manual task process.

Submitting the Request to Legacy IAM

The process collects the necessary data from ISC for the access request.
It then constructs the appropriate request payload for the legacy IAM system.
The request is submitted to the legacy IAM system using the available APIs or by directly inserting it into the system’s database.

Polling for Request Status

After submitting the request, the process periodically polls the legacy IAM system to check the status of the provisioning request.
The polling interval can be configured based on the expected processing time of the legacy system.
The process continues to poll until the request reaches a terminal state (e.g., completed, provisioned, fulfilled) in the legacy system.

Updating Request Status in ISC

Once the process determines that the request has been completed in the legacy IAM system, it updates the corresponding request status in IdentityNow.
The status update in IdentityNow can be done using the IdentityNow API.
This keeps the request status in sync between the two systems.

Error Handling

If the process encounters any errors during the submission or polling steps, it should handle them gracefully.
Error details can be logged for troubleshooting purposes.
In case of failures, the process can retry the operation or escalate the issue based on predefined rules.

While a manual task process requires upfront development effort, it provides a flexible and automated way to integrate with legacy IAM systems when direct integration is not feasible.

Pre-step assumptions

Before implementing the automated manual task process, ensure that the following prerequisites are in place:

Source Configuration:
- You have already connected ISC and the legacy IAM solution.
- This connection can be achieved through various methods such as JDBC, or any other supported integration mechanism to retrieve all entitlements.
- The source configuration in ISC is set up to retrieve all the access from the legacy IAM system.
- The source configuration is read only - It will read the entitlements and access through aggregation
Approval Workflows:
- The approval workflows for the entitlements have been properly configured in ISC.
- These workflows define each entitlement request’s approval steps.
Entitlement Naming and Description:
- The entitlements imported from the legacy IAM system have been mapped to user-friendly names and descriptions in ISC.
- This mapping ensures that the entitlements are easily understandable and identifiable by the users and approvers.

By fulfilling these pre-step assumptions, you lay the foundation for a smooth integration between ISC and the legacy IAM system. The source configuration ensures that ISC has access to all the necessary entitlement data from the legacy system. The approval workflows define the process for reviewing and approving entitlement requests. The user-friendly entitlement naming and description make it easier for users to request and manage entitlements within ISC.

With these prerequisites in place, you can proceed with implementing the automated manual task process to handle the provisioning of approved entitlements from ISC to the legacy IAM system.

Implementation

Reading pending work items and waiting for the manual action from the owner

curl --location 'https://<tenant name>.api.identitynow.com/beta/work-items?ownerId=<ownerID to filter>' \
--header 'Authorization: ••••••'
// ownerId - Identity allocated to take manual action after all approval done (Source Owner)

Extract data from the work items, Above API returns the list of work items
Each approval items will have a list of entitlements requested, For each work item loop through the approvalItems and create a request in legacy system. approvalItems.account Is a unique identifier from the legacy system configured in source provisioning policy.

 {
        "id": "<work item ID>",
        "requesterId": "<ID of the person who requested the access>",
        "requesterDisplayName": "<Requester name>",
        "ownerId": "<waiting for manual action>",
        "ownerName": "<Name of the person to take manual action>",
        "created": "2024-05-28T16:02Z",
        "modified": "2024-05-29T12:55Z",
        "description": "Manual Changes requested for User: <requested for user name>",
        "state": "Pending",
        "type": "ManualAction",
        "remediationItems": [],
        "approvalItems": [
            {
                "id": "<approval item>",
                "application": "<source name>[source]",
                "account": "<Attribute configured in provisioning policy>",
                "operation": "Create(new user)/Add (grant entitlement)/Remove(Revoke entitlement)",
                "name": "GROUPS",
                "value": "<Entitlement ID of a legacy system - configure in source entitlement schema>",
                "state": null
            }
        ],
        "name": null,
        "completed": null,
        "numItems": null,
        "form": null
    }

Once a request is created in the IAM legacy system, Forward the request in ISC to another owner so that in step 1. We always get the requests which were not processed by the job. Easy way to know how many requests are already submitted in legacy IAM system vs new requests.
```
curl --location --request POST 'https://<tenant>.api.identitynow.com/beta/wotk-items/:id/forward' \
--header 'Authorization: Bearer <Token>' \
--data ''
```
Push the newly created request number into the messaging queue for polling the status or maintain an intermediate data store to store the ISC work item ID and respective request ID from the IAM legacy system for polling or audit.

Once the request is completed in IAM Legacy system MARK request as completed in ISC.
Mark approval item is completed

curl --location --request POST 'https://<tenant>.api.identitynow.com/beta/work-items/:workitemid/approve/:approvalitemid' \
--header 'Authorization: Bearer <Token>'
curl --location --request POST 'https://<tenant>.api.identitynow.com/beta/work-items/:workitemid' \
--header 'Authorization: Bearer <token'

In case of any error in legacy IAM solution, Escalate to the team or manage as per the business requirement.

Conclusion

By implementing the automated manual task process described above, you can effectively integrate and manage your legacy IAM system within SailPoint Identity Security Cloud (ISC). This process enables you to leverage the powerful features and benefits of ISC while seamlessly handling the provisioning and management of entitlements in your legacy IAM system. Additionally, This provides the IAM engineering team with additional quality time to thoroughly implement and migrate connectors from legacy IAM solution to ISC.

Topic		Replies	Views
In Discovery: IIQ AWS Connector - Support for AWS IAM Identity Center In Discovery identityiq , connectors , in-discovery	4	1155	November 29, 2023
New Capability - Identity Security Cloud Governance Connector is now LIVE! Product News saas-connector , identity-security-cloud , new-capability	35	702	August 22, 2024
Integrating SailPoint with Identity Security Cloud Governance Connectivity Documentation Feedback saas-con-docs	2	42	July 31, 2024
In Discovery: Integration with Physical Access Management solutions In Discovery identity-security-cloud , connectors , in-discovery	3	877	August 10, 2023
Identity Security Cloud Extensibility: The Art of the Possible Community Blog saas-connector , workflows , transforms , apis , rules , identity-security-cloud , connectors	8	1365	April 9, 2024