I need to implement a Web Services connector where the account aggregation proceeds as follows:
Call endpoint #1 to get the list of all entitlements.
For each entitlement in the list from #1, call endpoint #2 with the entitlement name as a parameter in order to get all the accounts for that entitlement.
I do not have a feasible way to start out by first getting all the accounts and subsequently getting all the entitlements for each account.
I combed through documentation and posts but didn’t discern a way for account aggregation to utilize the two end points in the way I need. Am I missing something? Is it possible?
I setup Account Aggregation HTTP operations with endpoint #1 as the parent and #2 as the child, but the aggregation stops short and without error, having only aggregated two entitlements and one account for each entitlement. I have over a dozen entitlements, and the number of accounts for each entitlement range from a few to a few hundred to a few thousand.
You might be interested to know that the source system I am aggregating from is IdentityNow itself. I happen to call this source “IDN Roles as Entitlements”. On this source, the entitlements will be IdentityNow roles, and the accounts having each entitlement are the identities which are the members of each role. So what I’m trying to do for the aggregation is to first call the API to list all the roles (my source’s entitlements) and then for each one I’m calling the identity search API where my search query returns the identities (my source’s accounts) having the role. I hope you understand why I see it as unfeasible to go the other way, which would be to call the identity search API with essentially no query in order to return all the identities in IDN along with their nested attributes (a huge amount of data!) and parse out the role memberships from there. In case you’re further wondering why I would need this “IDN Roles as Entitlements” source, it’s so that when I am creating new roles I can use membership in another role as one of the criteria for the role I’m creating–I would simply use the source to make an entitlement criteria on the role which amounts to determining if the identity is a member of the other role. If you could suggest another way for me to do this, I’d love to hear about it!
I do not have answer to your problem and I am facing something similar when I am trying to make governance group self serviceable as those apis also work in similar fashion, but can you explain me what you will achieve by doing this. I have highlighted your explanation which I cannot understand.
Hi Chirag,
Maybe I could explain with an example. We have a role called ‘Basic IT Users’ where the entitlements simply allow members to log into the the IT domain and access email and the intranet. This role doesn’t provide other entitlements various workers need to do their jobs, but they need the entitlements for this role before they would be able to use any other entitlements. The ‘Basic IT Users’ role has about 16 lines of criteria configuration, which is continually evolving, and encompasses over ten thousand identities. Now let’s say we have other roles such as ‘Finance Users’ and ‘Marketing Users’, etc. where the criteria which differentiates them from all the ‘Basic IT Users’ is just their department name. To define the criteria for ‘Finance Users’, we have to restate all 16 criteria from the ‘Basic IT Users’ role plus one more criteria for the finance department, and likewise for the ‘Marketing Users’ and other roles. As the criteria for ‘Basic IT Users’ evolves, we have to change it not only in that role but the Finance and Marketing and all the other roles. That is quite cumbersome. What we would rather do instead, for example, when defining the ‘Finance Users’ role is to configure one criteria which states that the identity has the ‘Basic IT Users’ role, plus one more criteria which states that the identity is in the Finance department. However, the only kinds of criteria allowed for roles are based on identity or account attributes or entitlements. Working within those constraints, we can achieve our goal by creating a source in which the entitlements are the various roles in IDN. Then, for example, when configuring the ‘Finance Users’ role, the first criteria would be that the identity has the entitlement which represents the ‘Basic IT Users’ role, and the second criteria would be that the identity is in the finance department. Does that help you understand the challenge I’m trying to address? I’d love to hear how other folks would deal with the same kind of challenge.
All my best,
Thad
I’m not sure that I get correctly, but you can use the Role criteria based on the ‘Basic IT Users’ entitlement, if I understood correctly the ‘Basic IT Users’ always have the same entitlements, so you can filter something like this at your ‘Financial Users’ Role:
entitlements EQUALS 'Basic IT Entitlement Name' (Intranet for ex)
AND
department EQUALS 'Financial'
Hi Felipe,
The problem is that we have identities with entitlements in the ‘Basic IT Users’ role for reasons other than being a member of the ‘Basic IT Users’ role. The examples I gave don’t exactly represent my situation but were more chosen for illustrative purposes. The bottom line is that I need a role criteria which definitively determines if the identity is a member of an other role.
All my best,
Thad
Better model here would be assign all access which is basic as part of “Basic IT Role” and rest of the roles which are incremental they do not need to reuse all criteria which is being used in “Basic IT Role” because you are only assigning incremental department specific access.
The thing I do not understand here is why you want to include users again here in Finance department role again. Incremental role should have criteria which only meets specific department users and it should only assign incremental access.
e.g. company has “Basic IT Role” which assigns Access BR1, BR2, BR3(BR: Birth Right) to 10K users(nearly most of the users from organization) based on criteria (LCS : active and employeeType=Employee).
This role should ideally provision all general access which is Basic for IT role.
If you want to give anything specific to Finance department, you only need to create new role with that specific access instead of giving BR1, BR2,BR3 again and this role needs to only meet criteria for those specific users because those users would already have BR access.
Thanks for your suggestions on the the approach to the business problem.
I’m also hoping to learn how the Web Services connector can be used. It sounds like multiple endpoints with a one to many data relationship aren’t supported. Am I right?