I’m interested in exposing Group.Owner as additional data in SailPoint ISC.
It’s a useful piece of metadata that an access profile designer might choose to utilize in some cases. and it can be helpful for someone who is fluent in ISC, but not Entra to be able to know who to ask about an entitlement. (I also have some ideas about our leaver ownership check including owned entitlements in some cases)
However, I’m not sure how to do this.
I don’t believe just 'adding an attribute called “owners” will work
Owners is not a direct field in the graph call I think ISC is using.
“?expand=owners” would need to be added to the group call,
and then some additional configuration would need to be added (i.e. identity attribute technical name where Entra objectID is stored)
I think a connector rule would be able to handle this sort of entitlement enrichment… But I’m using the SaaS connector… I think a cloud rule would probably work too, but I don’t have any support hours.
Did I make the wrong choice on connector type, and I should try to move to the VA based Entra Connector, because it allows for customization like this (adding owners[] or owner/additional owner to the group entitlement? ) Should I try and lobby the business about the value here, and buying some expert service hours?
as an aside, I am struggling a little to understand why entitlement owner is not just part of the connector… it’s just metadata… it’s still opt-in to be used. it’s not automatically part of enforcement/governance.
I share your desire to be able to pull in the owner or managedBy(AD) values from Entra/AD to an entitlement attribute. However, I don’t believe that connector type (SaaS or VA) makes much difference, as I think the AD and Azure VA connectors support the “Before/After” connector rules and that’s about it. The “owners”(Entra SaaS) multi-valued attribute is automatically included in the Group schema when you create a connector, and I checked that the SaaS connector is able to pull the value into the entitlement object.(view entitlements through the connector link, or get them using the API) The issue is that ISC isn’t mapping either value to the “Entitlement Owner” attribute.(which would also require it to lookup an identity during aggregation, if one existed) Coming from an IIQ background, I do miss the ResourceObjectCustomization rule that connectors had, I’m not sure why that isn’t available in ISC.(they could restrict it to a VA connector if resource usage is a concern) Our use case for this is with entitlement certification campaigns, where we would like to be able to select an entitlement owner as the reviewer, rather than having to reassign these with a script after the campaign has been created. Our implementation resource mentioned that something like this may potentially be added later this year, but I don’t have any official confirmation of that.
My schema did NOT have a owners string MultiValue attribute in it.
Adding it produced an error that complained about NOT during entitlement aggregation.. (probably because we have "NOT groupTypes/any(c:c eq ‘DynamicMembership’) AND onPremisesSyncEnabled ne true) in our filter criteria over in criteria settings.
it looks like you cant expand and advanced query in the same rest call
You can’t Its not a Sailpoint limitation, but rather a microsoft one.
To resolve the issue - we want to bring in some extra entitlements that are not in the OOB connector - I built a WS SaaS connector and connected that to Entra.
I’m not sure I agree. I believe SailPoint could help here with some Entra connector changes.
The connector could absolutely collect Entra owner ObjectId while doing the entitlement aggregation (that’s already proven with “?$expand=owners”) and then also provide a UX field in the aggregation Entra connector settings to correlate that owner with a SailPoint identity (very likely an Identity attribute that has Entra ObjectId in it).
This then raises the Entra ownership from the source into SailPoint’s visibility. Metadata that could be used for just informational purposes (helping us better understand leaver object ownership for example, or who to follow up with for more detail), or even possibly governance (utilizing this owner data for approvals/certifications).
It’s important to note that these are all optional, the connector just raises the data, it’s up to someone/something else to action off of it.
For example, we have scenarios where we would like to have ISC be involved with managing MS Team memberships. MS Team memberships can easily be modified within the MS Teams application.
It would be extremely beneficial if we could say that the owner of a MS Team is also the approver/owner within SailPoint for processes also managing membership to that team. (IMO There are governance/operational issues if you don’t do this).
Right now, to include MS Teams in SailPoint, I have to manually maintain that data alignment, or at best build a separate custom code process that maintains this alignment.
It feels like there is a better way, just out of reach.
