Web Service accounts aggregation without entitlements

[davidtrn (David Tran)]

Hello,

I am setting up a Web Service connector for an application with the following issue :

• The full accounts aggregation only return account data but not the entitlements

        {
            "id": "id1",
            "email": "email1@mail.com",
            "firstName": "FirstName1",
            "lastName": "LastName1",
            "team": "Team1",
            "enabled": true
        },
        {
            "id": "id2",
            "email": "email2@mail.com",
            "firstName": "FirstName2",
            "lastName": "LastName2",
            "team": "Team2",
            "enabled": true
        }

• The single account aggregation operation return account data and entitlements (“permissions” attribute)

       {
            "id": "id2",
            "email": "email2@mail.com",
            "firstName": "FirstName2",
            "lastName": "LastName2",
            "team": "Team2",
            "enabled": true,
            "permissions": ["entitlement1","entitlement2"]
        }

So everytime the full accounts aggregation starts, all the accounts on IdentityNow “loses” their entitlements thus removing the Access Profiles and Roles from the identities.

Is there anyway to bypass this behaviour ?

Kind regards

[uday_kilambi]

Hi David,

This is a common scenario w.r.t we service integrations. This is how you can solve this issue.

1. Define two endpoints for operation type account aggregation in you web service connector application.
2. First end point is your full aggregation end point with response mappings of all attributes that you need except the entitlements.
3. Second end point is also for type Account Aggregation, however it is the single aggregation endpoint. In this configuration, add the first end point as a parentEndpoint.
4. You can utilize the $response.id$ in your second endpoint if you need the id information inorder to make the API call. The id value here is taken from the first endpoint response.
5. Configure your entitlements in the response mapping of second endpoint

This will ensure when a full aggregation is ran, all the attributes and entitlements are updated onto the account. Hope it helps.

Regards,

Uday

[uday_kilambi]

Forgot to share the documentation related to this one for reference. Here it is:

Parent Endpoint

[davidtrn (David Tran)]

Hello Uday,

Thanks for the input.

So I’ve created a second endpoint for single aggregation that I have attached to the full aggregation operation with the “Parent Endpoint” param.

Indeed for the url I need to retrieve the id that is in the full aggregation list, so if the first endpoint response is :

{

    "data": [
        {
            "id": "id1",
            "email": "email1@mail.com",
            "firstName": "FirstName1",
            "lastName": "LastName1",
            "team": "Team1",
            "enabled": true
        },
        {
            "id": "id2",
            "email": "email2@mail.com",
            "firstName": "FirstName2",
            "lastName": "LastName2",
            "team": "Team2",
            "enabled": true
        }
     ]
}

I should just use $response.data.id$ ? And the second endpoint will be triggered on each item contained in the data list ?

[uday_kilambi]

It can still be $response.id$ if you declared id as one of the response mappings in your parent endpoint.

[Arshad (Arshad Moghul)]

Uday’s suggestion is definitely the right direction to tackle this issue. Just a heads-up though, please be mindful of API throttling/rate limits. With this setup, you’re essentially triggering a separate single aggregation call for each account returned in the parent response. So if the parent API returns 500 accounts, the child API will be called 500 times which is once per account.

This approach works well when the target API supports good pagination using offset/limit variables. However, if the target APIs enforces strict rate limits, for example, allowing only 200 API calls per minute, then it becomes a bottleneck situation. From my experience with a recent integration, SailPoint Professional Services confirmed that there’s currently no workaround for this within ISC. So it’s something to plan for if you’re working with rate-limited based endpoints.

[pradeep1602 (Pradeep gupta)]

Try this: Aggregation

[davidtrn (David Tran)]

Thanks everyone for your inputs.

I implemented Uday’s suggestion by having an additonal call to the single account aggregation API for each user in the full aggregation.

Indeed we encountered rate limiting but I added a sleep between each batch as a workaround.

Our target solution is still for the editor to update their full aggregation endpoint to add the entitlement details.

[pradeep1602 (Pradeep gupta)]

Hi David,
Sometimes applications provide a way to fetch the data by providing list of attributes you want to fetch. Check if that is possible that would avoid you making so many extra api calls.

[Arshad (Arshad Moghul)]

@davidtrn

Indeed we encountered rate limiting but I added a sleep between each batch as a workaround.

@davidtrn Appreciate if you could share the rule code or the logic of how you’ve added the sleep condition between two HTTP operation related API calls?

[davidtrn (David Tran)]

@Arshad Here is the logic I implemented.

HTTP Operations configuration :

• 1. List accounts aggregation
  • This operation is returning a list of accounts on my source, without the entitlements details
  • I used pagination to limit the number of result to batch of 200 accounts
• 2. Single account aggregation
  • This operation is returning full details on a single account
  • Set the Parent Operation to the “List accounts aggregation” so it runs for each accounts returned

I then created a rule to add the delay :

log.info("##Begin sleep ##");

java.util.concurrent.TimeUnit.SECONDS.sleep(50);

log.info("##End sleep ##");

And added this beforeRule to the List accounts aggregation.

Hope this help

[Arshad (Arshad Moghul)]

@davidtrn

And added this beforeRule to the List accounts aggregation.

Thanks for the explanation @davidtrn

Could you please share an approximate count of the total accounts available in your target application? Additionally, how long does the complete account aggregation process take, given this 50 second sleep interval applied to each account during aggregation?

[davidtrn (David Tran)]

We have approximately 3600 accounts and the full aggregation takes 30mn.

• As the list aggregation returns 170 accounts, it means there is ~22 (3600/170) call to this API
• After each call there is the 50 second sleep so 21x50 = 1100 seconds = 18mn of sleep time alone