SoD Policy violation not shown to approver

Feedback Bugs
,
1

What problem are you observing?

I have simple SoD Policy in my ISC tenant. When a user request the conflicting entitlements in same access request, the violation warning is not shown to the approver.

What is the correct behavior?

The approver (source owner in this case) should be shown the SoD policy violation so that they can make informed decision. The same request contain both conflicting entitlements.

What are the steps to reproduce the issue?

  1. SoD policy for two conflicting entitlements

image
image975×345 48.4 KB

  1. User request both of them in same access request

image
image975×460 66 KB

  1. User is able to successfully submit the request, which is understood as SoD is not evaluated yet (but it would be better to inform the user at this level itself)

image
image864×551 63 KB

  1. User gets confirmation email.

image
image592×379 45.2 KB

  1. From the access request details, it can be seen that SoD evaluation is complete and now the request is waiting on source owner to approve.

image
image876×776 70.5 KB

image
image879×766 69.8 KB

  1. Source owner gets notification to approve/deny

image
image975×513 85 KB

  1. Source owner doesnt get any warning while taking action that this would be violating a SoD policy.

image
image975×469 108 KB

  1. Source owner approves both

image
image975×454 76 KB

  1. Request is completed and next aggregation brings back the access/account for user.

image
image975×233 31.4 KB

  1. The violation is now detected when the policy runs next time.

image
image975×772 66.2 KB

This should have been avoided at first stage (request or approval) and shouldnt been allowed for the user to get the conflicting access.

Do you have any other information about your environment that may help?

2

Hello Sanjay. This appears to be expected behavior rather than a bug. It comes down to how preventive SoD evaluates the request.

Preventive SoD considers access the identity already has provisioned. It does not consider access that is still in flight. In your repro, PO Approver and PO Creator are requested together, so when the SoD check runs, neither entitlement is provisioned on the identity yet.

The same scenario was discussed here, where it was confirmed that ISC considers already provisioned access and not access still in flight. One entitlement already assigned + requesting the conflicting entitlement was detected, while requesting both together was not.

The same limitation was also discussed here: when the identity has neither conflicting access and requests both together, the preventive violation is not detected.

Your step 10 is the detective side working correctly. SailPoint defines an SoD violation as an identity having access found in both conflicting lists. Once both entitlements are provisioned, that condition exists, so running the SoD policy detects the violation.

The issue you are reporting, the approver not seeing the violation during the request, is the preventive path. To isolate that path, I would test it this way:

  1. Provision PO Approver and aggregate it into ISC.
  2. Confirm the identity shows PO Approver.
  3. Request only PO Creator.
  4. Check the source owner’s approval.

In that scenario, the preventive check should detect the conflict because one side is already provisioned. If the violation is still missing from the approval, that would be a valid case to investigate further as a possible bug.

Also, a detected SoD violation does not automatically prevent approval. For entitlement requests, ISC allows a reviewer to approve a request that has policy violations and can be configured to require a comment when they do (documentation).

So the current reproduction matches the known limitation around two simultaneously requested, in-flight accesses rather than demonstrating a defect.

3

Thanks Harish for response.

I understand that when user is requesting both conflicting access at same time, the SoD is still not violated as the approve may not approve both access.

But arent we relying too much on the approver to make right decision here :slight_smile:

The tool (ISC) already has information (through SoD configuration) that this is toxic combination and if approved will result in SoD violation. Why wouldnt it just warn the approver about it. Thats what I am expecting.

1 Like
4

Yes, that is a fair expectation. Since ISC already knows that the two accesses form a toxic combination, it would be useful to warn the approver when both are requested together.

The current preventive check looks at already provisioned access and does not evaluate multiple in-flight items in the same request against each other. So I see this more as a valid enhancement request than a bug.