Hello,
Has anyone managed to build a loopback source in IDN to be able to manage Governance Group membership as entitlements?
I have seen the post about the loopback connector that can answer to my need (IdentityNow management SaaS connector). I am just trying to see if anyone was able to do it with a web service connector.
I would imagine something like
Aggregate governance groups from v2/workgroups
account aggregation is child to entitlement aggregation and uses the response of v2/workgroups/$response.workgroup_id$/members
Is there a way to link the result from the second API call with the accounts that were already aggregated to the source previously?
I think I have exactly what you need. Governance groups objects on IDN report their members but identities do not report their membership. This, to the best of my knowledge, is difficult to process for a web services accounts, since it always counts on having account to entitlement relationships, and not entitlement to account. I rescued an old internal post for you pending validation. As soon as it gets validated I’ll let you know. I believe this will help you turning this situation around, if I understood your problem correctly.
@fernando_delosrios I may be missing something, but I don’t see how this would iterate through each group to get their members. Your account aggregation endpoint has a hardcoded group ID. If a user is a member of group B and you’ve only pulled a list of accounts from group A to process the rule on, how would this work?
I’ve previously tried using GET /groups as the parent endpoint of the Account Aggregation chain and used /response.id/members in the child endpoint, but that aggregated the users as a string version of the JSON array. I was pointed to partitions and that has worked to iterate through the TMs, but even using a rule very similar to yours, I’m only getting one group per user even when a user has multiple.
The key concept here is we aggregate from two different sources: the original system and IdentiyNow. All action happens in the account aggregation process after a successful entitlement aggregation. Bear in mind your entitlements should have a multi-valued attribute representing user assignments. When aggregating accounts, we get all other information about the account from the original system and the group assignments from IdentiyNow using the wsao rule.
There’s no hardcoded group ID in the code, there are references to the SaaS tenant I used for the example.
Starting off a group endpoint for account aggregation is something I never managed to make it work.
The code works except for the paging, which is missing due to the fact this was built before we introduced API limitations.