Aggregate entitlement information from different endpoint and populate on accounts - Web Services Connector

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi Everyone,

I have a Web Services based target application for which I need to configure aggregation and provisioning. First, I need to implement “Account Aggregation” configuration for the same. The problem I’m facing here is that /Users endpoint only gives the user information and not the groups information. For getting the groups info, there is different endpoint altogether called /Groups.

I cannot use parent-child operation chaining here as well because the /Groups endpoint does not support filtering based on user. For example it does not support /Groups/test_user where it should ideally give out the groups present on the user. Rather, what it only supports it /Groups/<group id> which would only return the group in their system and their respective group members.

Note: This target system is not fully SCIM compliant and the problem with groups not being part of the user response is causing issues with SCIM connectors as well. Hence implementing this via webservices.

Providing sample API responses below:

  • /Users
{
    "totalResults": 4,
    "startIndex": 1,
    "itemsPerPage": 4,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "Resources": [
        {
            "emails": [
                {
                    "type": "work",
                    "value": "iam.user2@test.com",
                    "primary": true
                }
            ],
            "displayName": "user2 iam",
            "name": {
                "familyName": "iam",
                "givenName": "user2"
            },
            "active": true,
            "id": "1410384382554223",
            "userName": "iam.user2@test.com"
        },
        {
            "emails": [
                {
                    "type": "work",
                    "value": "iam.user1@test.com",
                    "primary": true
                }
            ],
            "displayName": "iam user1",
            "name": {
                "familyName": "user1",
                "givenName": "iam"
            },
            "active": false,
            "id": "4212450687312103",
            "userName": "iam.user1@test.com"
        }
    ]
}
  • /Groups
{
    "totalResults": 2,
    "startIndex": 1,
    "itemsPerPage": 2,
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:ListResponse"
    ],
    "Resources": [
        {
            "displayName": "account users",
            "members": [
                {
                    "display": "user2 iam",
                    "value": "1410384382554223",
                    "$ref": "Users/1410384382554223"
                },
                {
                    "display": "iam user1",
                    "value": "4212450687312103",
                    "$ref": "Users/4212450687312103"
                }
            ],
            "id": "304938786029663"
        },
        {
            "displayName": "TEST Group",
            "id": "738595786832639"
        }
    ]
}

From /Users , id field on the user is the nativeIdentity and the same is present under the group members on /Groups endpoint.

Is there a way that I can configure account aggregation on this source where the groups related information is also populated on the user accounts?

Appreciate any leads on how to achieve this if anybody else has faced a similar use case?

Reverse entitlement aggregation for Web Services connector
2

Hi Arshad,

Check if this helps your use case or not.

Regards,
Mahesh

3

Have you considered calling Groups end point from AfterOperations rule and update the responseBody?

4

@iamology
I am trying to do that same approach but facing a roadblock with figuring out the JSON query to fetch user’s groups. Can you see if you can help?
Here’s the post where I’ve detailed it out : JSON Query Path to fetch user groups in Web Service After Operation Rule

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.