Separation of duty : forbidden association

Hi,

I’m currently working on SoD and I have a question.
I understood how to use it to get data and approvals of some items.
But i’m left with one last case : What if, I want to achieve a complete forbidden association : Entitlement A and Entitlement B can never be granted to someone.

How would I do it, using the best practices possible.

Regards,

Loïc.

Hi @llebrault
Please find here in detail regarding SoD policies: Handling Policy Violations - SailPoint Identity Services

To answer your question, although it relates to SoD, since the use case is not to grant specific entitlements to anyone, I would suggest marking these entitlements as non-requestable. Additionally, avoid creating any access profiles or roles using these forbidden entitlements.

Hope this helps!

Thanks.

In that case, entitlement should be requestables, but never together on a same identity. The association is forbidden.
I’ve thought about using triggers and using Access Request Submitted trigger to deny the access request as soon as it triggers.
I’m just wondering if there is a better way to do it.

Regards,

I don’t think blocking access requests is possible for SoD violations out of the box.

Yes that is what I indeed understand.
So my question would be how to achieve, best practice as possible, a true preventative SoD, to deny B to be given when A is also given or already possessed.

Regards,

Where are your access requests coming from? If they’re originating from an external system like ServiceNow, you can run the start-predict-sod-violations API endpoint to see if there would be any violations and cancel the request if there are.

Sounds like if request center is used, that’s not possible

Interesting.
They’d come from both alas.

would trigger into webhook into deny access be a viable solution ?

Hi @llebrault

As you have to left both entitlements requestable, and enforce users to not have both at same time, what I can recommend is to create a workflow to remove entitlements where both are being provisioned.

Provisioning Completed trigger input has the attributeRequests array, which you should inspect with JSONPath or comparator operators, to question if both entitlements are present:

So, if both entitlements are present, you can raise an HTTP Request action to send a REVOKE_ACCESS request submit for them, followed perhaps by a notification.

I do not know your business model there, but I think that if Identity has some atrtibute that can let you deduct what of the two entitlements should not have, you can raise an HTTP Request to revoke only the incorrect entitlement.

I see, that is similar to what I had in mind but using solely wf.
I’ll think about it. Thank you!

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.