We’re looking at creating a large IT role for our database team, given they need membership across thousands of DB groups. Has anyone done something similar before? If so, did you encounter any performance issues?
Not sure if this is relevant, but these DB groups are Entra ID groups.
Thanks.
@sofia_sanjuan You can create these many roles, but make sure you have sufficient server threads available and you don’t refresh all users every time.. always go for delta.
Could you please provide more details as how these roles will be structured? Like one role with thousands of DB groups or multiple roles-entitlement combinations?
Also, if they are birthright, have you considered LCE as an option?
Before going down this path, I’d take a look at these two threads. They’re not exactly the same scenario but there are some good points around large numbers of entitlements, provisioning, refresh performance, and certifications:
With thousands of groups in one IT role, I’d definitely expect some performance impact.
The main things I’d watch are provisioning and Identity Refresh. Assigning that role could result in thousands of entitlement changes that IIQ has to process and send to Entra, so I’d also keep an eye on throttling/throughput on the Entra side.
Refresh and role detection are worth testing as well since IIQ has a much larger role profile to evaluate. Certifications could also get pretty painful, both during generation and for whoever actually has to review all that access.
I’d probably start with a smaller version of the role and gradually increase the number of groups while watching refresh and provisioning times before rolling it out.
It’s one (1) IT role containing thousands of entitlements. The motivation for creating this role is two-fold:
Thanks. I’ll try it out in our non-prod environment and see how the ID refresh will perform.
@sofia_sanjuan Having thousands entitlements in single role, will impact the performance. Provisioning or deprovisioning a role with thousands of groups generates a massive ProvisioningPlan Also, not just performance, your link and identity entitlement will become huge as well.
When an account belongs to thousands of groups, reading and writing this single link object consumes significant memory and I/O. The Hibernate L2 cache and SailPointContext hold all loaded entitlement definitions, role profiles, and link objects in memory. Without frequent context.decache(), worker threads may cause major GC pauses or java.lang.OutOfMemoryError: Java heap space
It would be better if you establish some nesting or Parent<>Child associations at the application end and configure only 2–5 high-level groups per role in IIQ rather than thousands of groups.
Hi @sofia_sanjuan ,
may I ask how many groups your are aiming to add to the bundle profile(s)?
We had a similar requirement some time ago and I remember that we hit a limit which was around 7000 entitlements within a single role.
To be honest I can’t remember the exact details (but would probably be able to find it in our project documentation) but there definitely was some unexpected behavior which made it impossible to follow that path.
In our case we ended up building a “role model” within the target system so the complexity was transferred into the database.
In other words: we created something like a “group” on database level which contained thousands of entitlements but IIQ just knows the “group” but not the content.
For sure this has some disadvantages regarding the visibility, but back in those days (around IIQ 7.x) we were not able to find another working solution.
May I suggest that you create a bundle which contains the maximum of expected entitlements and test all your use-cases before you start implementing all the details.
This would help to assess if it is working as expected or not.
Best regards,
Daniel
We’re rethinking the approach. I created 1 role with 1000 entitlements, did an access request for 4 identities. After clicking the submit button the processing request spinner went on for 2 minutes – not acceptable user experience.
@sofia_sanjuan Yes. As it has 1000+ entitlements, UI will timeout while provisioning them. Would recommend above messages and try to have the majority of the role modelling at the application end and configure handful of them in IIQ.
Hi again @sofia_sanjuan ,
you may want to consider to background the provisioning workflow right away.
This would likely help to overcome the wait time directly after “Submit”.
However, as already mentioned there are a couple of other downsides related to very large bundle profiles.
I’m just mentioning the backgrounding as it would address the performance issue you mentioned.
Best regards,
Daniel