Stephen's Infobox
Integrating Oracle IDCS with SailPoint IdentityNow: An Identity Governance Guide

Integrating Oracle IDCS with SailPoint IdentityNow: An Identity Governance Guide

Introduction

Stephen Otieno's photo
Stephen Otieno
·

6 min read

I have recently had a project, helping a client - a huge Telecommunications company with its journey in Identity Governance. Identity Governance and Administration (IGA) refers to the process of managing digital identities of users across different systems in a organisation, so as to give the company insights of who as access to what applications, the various rights they have on those applications. This aids the company in better provisioning of access and helps the company to avert potential security risks that may arise from over-provisioned access or scenarios like ex-employees still having access to critical company system

Choice of Connector

Oracle Identity Cloud Services application is used by companies to provide a unified view of user access to SaaS applications and On-Premise AD. It provides administrative interfaces to manage these identities and also provides self service interfaces to end users so that they can manage their own profile and password and reduce administrative/help desk burden.

Oracle provides APIs to help with identity governance and other integrations that companies may want to pursue. These APIs can be found in the links below.

User Management APIs

Group Management APIs

Since we have ready APIS, it is prudent that we use the WebService connector to realise this integration. The particular EndPoints that we need are the following

  1. Fetch all IDCS Users

    Search Users - /admin/v1/Users

  2. Fetch All IDCS Groups

    Search Groups - /admin/v1/Groups

  3. Create An IDCS Account

    Create a User - /admin/v1/Users

  4. Deactivate a User Account

    Update User - /admin/v1/Users/{id}

  5. Update Group Membership

    Update a Group - /admin/v1/Groups/{id}

Base Configuration

Follow the usual steps of creating a connector. Some of the things to note when creating the connector include - we are using the OAuth2.0 as Authentication Type: Add the Client Id & Client Secret from IDCS(these you obtain when you create an application on IDCS).

Http Operations

Account Aggregation

First Add the General Information About the Endpoint

  • Operation Name - Account Aggregation

  • Operation Type - Account Aggregation

  • Context URL - /admin/v1/Users?attributes=groups,active,emails,userName,ocid,id,name,displayName&count=1000&startIndex=0

  • HTTP Method - GET

It is important that you capture the attributes you want to get back from IDCS in the attributes query param. In order to also get the groups a user belongs in you need to add the groups in that list of attributes. Many people forget to add this. And may lead to errors. Also ,since IDCS only allows fetching of 50 accounts at a time, ensure you add the count & startIndex params. Failure will lead to only aggregating 50 accounts which is the default count.

  • Headers -> Content-Type - application/json

  • Response Information - > Root Path - $.Resources Success Code - 2**

  • Response Mapping

  • Paging ->

    Initial Page Offset - 0

    Page Size - 1000

    Paging Steps

$limit$ = 1000
TERMINATE_IF $RECORDS_COUNT$ < $limit$
$offset$ = $offset$ + $limit$
$endpoint.fullUrl$ = $application.baseUrl$ + "/admin/v1/Users?attributes=groups,active,emails,userName,ocid,id,name,displayName&count=1000&startIndex=" + $offset$

Group Aggregation

Just like the Account Aggregation Endpoint, add the base configuration information needed as necessary.

Just to keep this article concise I am not going to go to the nitty gritties of the Group aggregation EndPoint, since it it almost similar to the Account Aggregation save for a few changes here and their. Let me know if you need a follow-up article on it.

Create Account

In terms of Account Creation you need to first create an Account CREATE Provisioning Policy. This can be done using the IdentityNow APIS. Use the link below to read more about this. After this don't forget to Enable attribute Sync.

https://developer.sailpoint.com/idn/api/v3/create-provisioning-policy/

On the HTTP Operation - Add all the base configuration items are below.

  • Operation Name - Create User Account

  • Operation Type - Create Account

  • Context Url - /admin/v1/Users

  • HTTP Method - POST

  • Headers - Content-Type application/json

Body - raw

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User",
        "urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User"
    ],
    "userName": "$plan.username$",
    "name": {
        "formattedName": "",
        "givenName": "$plan.givenName$",
        "familyName": "$plan.familyName$"
    },
    "idcsCreatedBy": {
        "value": "<THE ID OF THE SERVICE ACCOUNT IDN IS USING TO CONNECT TO IDCS>"
    },
    "emails": [
        {
            "value": "$plan.workEmail$",
            "type": "work",
            "primary": true
        },
        {
            "value": "$plan.workEmail$",
            "type": "recovery",
            "primary": false
        }
    ]
}
  • Response Information - Root Path - $ , Success code - 2**

Some things to note in user creation are the following.

  1. Ensure you have configured the Account ID on your account schema to be the id ttribute on IDCS, not the ocid.

  2. Ensure that when accessing the items on your provisioning plan using $plan.<attribute>$ this <attribute> is defined using the exact name as the one you used on the provisioning policy.

  3. Ensure that the service account used in this integration has the create rights. This will ensure that the creation does not fail due to insufficient rights.

  4. In order to enable automated user creation - Create a birthright Role definition, create an Access Profile and it it that role, and define an entitlement on that access profile. You will need to enable the role to create accounts automatically.

Add / Remove Users From Groups

To add or remove users to groups on the managed system, you will need to use the Update Group endPoint provided by Oracle. Use the JSON Strings below for the Add Entitlement and Remove Entitlements respectively.

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "add",
      "path": "members",
      "value": [
        {
          "value": "<The User Id>",
          "type": "User"
        }
      ]
    }
  ]
}

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "remove",
      "path": "members[value eq \"$plan.nativeIdentity$\"]"
    }
  ]
}

Note the following when it comes to Group Membership:

  1. Create the Add Entitlement EndPoint and the Remove Entitlement EndPoint, and use the JSONs above as the bodies of the requests.

  2. When it comes to the the Context Url - Ensure you capture it as /admin/v1/Groups/$plan.groups$ - groups here is the name of the attribute representing the entitlement on the Account Schema. This is very important.

  3. To test adding users on groups or removing them, you can use access requests and revoke a user's right on a particular group.

Disable Account

Disabling a user's account means setting the active attribute to false. This can be done using the update User endPoint. It is a PATCH request which takes in the following JSON string.

{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

The Configurations will look like this

  • Operation Name - Deactivate Account

  • Operation Type - Disable Account

  • Context Url - /admin/v1/Users/USER_ID

  • HTTP Method - PATCH

  • Headers - Content-Type application/json

Note that the context Url has a USER_ID placeholder on it. In order to ensure that we send the request with the real user id, you can use a WebService Before Operation Rule to reformulate the Url before sending it to the managed system. I have included a snippet of the code you may use to do this below.

if(provisioningPlan != null){
        for (AccountRequest accReq : Util.iterate(provisioningPlan.getAccountRequests())) {
            //Disable
            if (accReq.getOperation().name().equalsIgnoreCase("Disable")) {
                String accountToDelete = accReq.getNativeIdentity();
                String newDisableUrl = requestEndPoint.getFullUrl().replace("USER_ID", accountToDelete);

                log.info("IDCS: DISABLE NATIVE IDENTITY " + accReq.getNativeIdentity());
                requestEndPoint.setFullUrl(newDisableUrl);
            }
        }
    }
    return requestEndPoint;

Conclusion

Pursuing this integration using the webservices is the best way to integrate the Oracle IDCS application onto SailPoint's IdentityNow, in my experience, as Oracle provides all the APIs that you will need in the configuration.

Please let me know if I should do a follow-up article to this.

identityNowsailpointidentity-managementOracle