WebService Connector - link user accounts to groups

Hello,
Can someone help out or explain how to link aggregated accounts to aggregated groups?

I am using the Webservices connector, I can aggregate accounts. example get users REST response from source

[
   { "userID": "001", "username": "alice" },
   { "userID": "002", "username": "bob" }
]

And for groups I can aggregate. Example get groups REST from source

[
   { "groupID": "998", "groupname":"group 1" },
   { "groupID": "999", "groupname":"group 2" }
]

Then I need to call a third API endpoint for each group to get members - this i can do with $response.groupID$ but I dont know how to match everything up, so the users show with all their groups.

Exampte REST for get “group 1” members

[
   { "userID": "001" },
   { "userID": "003" }
]

So how do I link everything so that Alice (user 001) has group “group 1”?
Any assistance would greatly be appreciated.

Thank you!

Inside account schema you need to add attributes that are entitlements and mark their “attribute type” same as the name of entitlement type (most likely group unless you have named them something else) and run account aggregation. In some web services you will need to have a second account aggregation to fetch the entitlements in which case you can use parent-children relation between aggregation operations

I have the same question. I am currently working with Advisory services to get this done and will update when they come back to me, but in the mean time here is my situation.

I have Account Aggregation being done through a graphql query, I get all the attributes I need to fill out the account, except for the groups the user is apart of. I also have an entitlement aggregation that pulls in all the groups. I have a 3rd call that will bring in group members, but instead of searching user by user, I search group by group and find the members of the group. This is because the application I’m using does not allow me to search for the groups by searching the user or this could all be done in 1 API call.

What we are trying to find out is, how do we go from getting the user through account aggregation, then run the entitlement aggregation, to then run the group membership aggregation and the link the group members to the user account.

Hopefully this is what the OP is asking for and we have the same issue.

Hi @mwander that sounds exactly like what I am after.
If you work out a solution, please share.
I too will share a solution if I can work it out.

Thanks!

1 Like

Hi @jrossicare, This works well and good if the child endpoint you are using, gets you the group(s) for each user. But if it gets you the users from each group, maybe I should try figuring out other solution. Since my case is the former, I have tried linking user accounts to groups and got it done.

I’m assuming that the following two goes fine:

  1. Group aggregation where you fetched all entitlements (having the schema - groupID, groupname)
  2. Account aggregation - First endpoint or the Parent endpoint where you got all the attributes (userID, username) to be filled out for the account other than groups

In the second or child account aggregation endpoint, having configured something like /users/$response.userId$/groups, (The “$response.userId$” is something that the parent endpoint provides as input.) which is used to GET a particular user’s (eg - userID 001) linked groups, I have a response let’s say:

[
   { "groupID": "998"},
   { "groupID": "999"}
]

Map the response accordingly (groupID) in the second account aggregation operation and set your parent endpoint name in the Parent endpoint tab. (Make sure that you have added the groupID in account schema with type marked as entitlement and multi-valued)

Perform entitlement aggregation first and then account aggregation so that Sailpoint recognizes the groups before associating them with the user accounts. The entitlements would now be displayed for an account on this source.

Hi @varshini303

I ended up going with Fernando’s Reverse entitlement aggregation for Web Services connector

That did the trick, and was way simpler solution. :slight_smile:

3 Likes

That’s great! will refer to it. Thank you :blush:

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