One of our application teams raised a need and expected SailPoint to be able to directly fill it. At the simplest, they need a way to correlate entitlements across two discrete sources for RBAC change reporting (not provisioning).
A sailpoint role exists with group entitlments from Active directory.
A source exists which has entitlements which share a property with the included AD groups, but entitlements and accounts in that source are NOT Active Directory.
The application team wants to see change reporting on any role that has AD groups which are mapped by property match to their internal entitlements.
I believe I could do this via API reporting, but is there any means of establishing an entitlement relationship in SailPoint which can be updated via a correlation process so that mapping isn’t based on something which may not be trustworthy (object name).
Question: Why is this requirement coming from applications teams instead of RBAC governance team / committee?
Additionally, given this:
“The application team wants to see change reporting on any role that has AD groups which are mapped by property match to their internal entitlements.”
That is a relationship reporting between two systems’ entitlements. With or without IGA / automation.
You’ve assessed the situation correctly.
The heart of my question is: Can entitlements in one system by systematically associated with entitlements in another system?
System 1: Entra AD Groups.
System 2: Snowflake Database Roles which have been granted internal permissions through an Entra Enterprise Application connection where some of the Entra groups have been affiliated.
The system owner (Snowflake) needs to be able to determine which SailPoint roles map directly to internal permissions, not Entra groups. (We could make names match, but names can be changed).
So what we need is a method of affiliating relationships between entitlements across sources, ideally established systematically inside of SailPoint.
Systematically, manually, yes.
Systematically, automatically, yes.
Devil is in the detail though:
“The system owner (Snowflake) needs to be able to determine”
Did the application team(s) also specify how then envision to ‘view’ such relationships? Like, they’ve, somehow, determined ISC is part of the solution. What “GUI” do they think is available for them to view this?
And what UX is expected with this determination process? (e.g. manual PDF / Excel lookup, graphical search, query simplicity / complexity, keywords…etc)
Not trying to make this difficult…but I’ve personally seen this type of lazy single point / dump-it-on kind of requirements time and time again. They need to be end-to-end thoughtful about this. And just because something is required, doesn’t mean it’s a good requirement to begin with. i.e. With every problem, always ask & understand how you got this problem in the first place before trying to solve it.