Firstly, I created two policies within OIA (Policy1 and Policy2). Once created, I can then populate OIA by highlighting that these policies will be a SOD violation if coupled together to a business role. The image highlights on the left the 2 policies that were created and the exclusion between the policies (on the right). In this example I am highlighting that Policy1 should not be assigned to Policy 2. If I clicked on Policy2, I would be able to see the reversed relationship.

To cause a violation, I must first couple these two policies with a business role (Called Role3). At this stage I am only preparing for approval so the preventative enforcement is yet to take place.

I navigate into Role3 and assign both policies to the role then send this for approval request to the role owner. Being able to send an approval with a SOD violation suggests that a request can override the 'preventative' enforcement (Which I'm not sure is correct). Ideally, there should be an explicit enforcement to enforce the inability to submit a request containing a violation.

Until now,there has been no explicit flagging or indication that I have just committed an approval containing an SOD violation. The argument would suggest that It's essentially the role owners responsibility to ensure that no SOD enforcement should take place. So lets see what the approver would see when they receive a pending request.

So the role owner has logged in and accepted the request. No changes to the policy were made meaning no policy approval has taken place. This now means that the SOD violation has now been accepted.

If we review the completed request, we are able to see an implicit indication of the violation. In this example, there are only 2 policies so the violation is obvious if the individual reviewed the 'exclusion policy'. though we must remember that this should be a preventative enforcement rather than an indication.

This indication could be potentially missed if multiple policies were involved. The associated violation may not be within the same request, meaning the navigator would require further analysis to determine if there's a possible violation.

We are able to see this violation by clicking the policy and acknowledging that there's a violation. The issue here is that based on human error, the approval can be easily missed.

There is now a new active version of the role with the policies assigned. The best indication for the policy enforcement is that the policies are flagged as red within the OIA GUI highlighting a violation.

You are able to see this clear indication when I include another policy to the role which is not subjected to any other violation.

Even though there's a clear indication that there's a violation, we are still able to push this to the provisioning server and implemented into the real world Within OIM, if we click on Role3 we'd be able to see the access policies (policies assigned)

Even though there's a clear indication that there's a policy indication, I do not believe this enforcement is preventative as we are able to submit the request should be still have a simple workaround, this does not prevent the preventative enforcement to take place.

About the author