Advanced Policy Violation Rule

IdentityIQ (IIQ) IIQ Community Knowledge Base
1

Hello Sailors,

If you would like to prevent user from submitting a Request for any business use cases

  1. User should not have both approver and requestor Roles
  2. User should not have more than 1 Role at a time
  3. User who has account in application already can only request for the additional groups
  4. Only some department users can request for the Role or Entitlement
  5. Or any custom condition(s)

It is better to prevent the false request instead of depending on approvals, assuming that approver anyway will reject the request.

We have two types of policy violations

  1. Preventive: Preventing user from having a specific access through LCM
  2. Detective: Detecting violations for the access user already have

We will look into Preventive one here, we have couple of OOTB SoD Policy violation concepts.

  1. Role SoD: You can use it if user should not have more than 1 Role at a time
  2. Entitlement SoD: You can restrict entitlement requests based on some conditions

But the challenge with these are a lot of combinations you need to configure and not all the requirements can be implemented, that is where Advanced Policy Violation is useful.

As the name indicates, you can use it for complex customizations which are not feasible with OOTB.

You need a Rule for Advanced Policy implementation which is a bit tricky, let us go through the coding.

  1. Import the libraries, import only you need and do not use *
import sailpoint.object.Identity;
import sailpoint.object.Bundle;
import sailpoint.object.PolicyViolation;
import java.util.List;
  1. Declare the Policy variables
PolicyViolation violation = null;
boolean vflag = false;
String desc = null;
  1. You don’t get Plan as input, only identity you get in the Rule. This is optimistic Identity. What is that mean ?
    SailPoint considers that the requested access will be approved, so requested access is included in Identity.
    We should get Identity from DB which doesn’t have the requested access.
Identity reqIdentity = identity;
Identity dbIdentity = context.getObjectByName(Identity.class, identity.getName());
  1. Now you have 2 identities, one with requested access and other one without the requested access. If you get access from both identities and compare/subtract then you get the requested access.
List dbIdRoles = dbIdentity.getAssignedRoles();
List reqIdRoles = reqIdentity.getAssignedRoles();
  1. Optimistic (Requested) Identity will have both existing and requested Roles, so let’s subtract them to get just the requested ones
 if(reqIdRoles != null && !reqIdRoles.isEmpty() && dbIdRoles != null && !dbIdRoles.isEmpty()) {
      reqIdRoles.removeAll(dbIdRoles);
    }
  1. Add the conditions, if reqIdRoles size is more than 1 then set the violation flag as true and set the violation description which is presented to the requestor.
if (reqIdRoles.size() > 1 ) {
       vflag = true;
        desc = "You should not have more than 1 Role";
}
  1. Set the violation object
if (vflag) {
    violation = new PolicyViolation();
    violation.setActive(true);
    violation.setIdentity(identity);
    violation.setPolicy(policy);
    violation.setConstraint(constraint);
    violation.setDescription(desc);
    violation.setStatus(sailpoint.object.PolicyViolation.Status.Open);
  }
  return violation;

Policy gets executed 2 times

  1. Without considering the requested access, just to check if user is already in violation before placing the current request. If user is already in violation then no need to throw one more
  2. By considering the requested access
  3. So, you need write the condition #6 in such a way that violation is true in 2nd execution only. That is why I am subtracting the Roles. In 1st execution Roles list will be empty as both Identities will have same (existing) access.

You can implemented any kind of complex and customized Policy Violations using this feature. You do not need to purchase SAP GRC module, you can implement all of them inside SailPoint itself.

There will be a debate, why should we develop again when we can use already existing one. Well, I agree on that as well, if you are reqdy to pay for that cool, if not then make use of Advanced Policy Violation.

Hope this helps you :slight_smile:

Thanks
Krish

6 Likes
2

Awesome instruction. Just a quick question, what if my policy after successfully executing, allows for “Submit with violation” ? Which arguments/attributes/options are responsible for allowing this action?

3

undefined
undefined1976Ă—1334 208 KB

4

But i want to forbid submitting the request on violation. And it can’t be that setting, since I have two policies (identical when it comes to type, and almost identical when it comes to returned value). But one is forbidding from submitting, and other is allowing for “submit with violation”. Any ideas why?

[Edit] Nevermind, i found it in custom piece of code regarding subprocess to LCM, by doing workflow.put(“allowRequestsWithViolations”, false).
But thanks for trying :wink:

5

Hi @MVKR7T
Is there a way this rule can work both in Access Request (preventive) and Policy Scan (detective) ?

6

Hi Christine,

when you implement an advanced policy using a Rule, it will work for both preventive and detective policy Evaluation.
Evaluation during LCM access request is called a preventive way of finding violations as they finding violations in this stage may prevent assigning conflicting access rights.
Evaluation during aggregation or identity cube refresh is a so called detective way of finding violations. There is an option to enable during the aggregation or identity refresh task for detective policy evaluation.

image
image1515Ă—175 25.5 KB

Regards,
Arun

7

Hi Arun, thanks for the reply. What I meant was from the sample shared by Krishna, it checks for both reqIdentity vs dbIdentity and subtracting the roles. For detective / identity refresh, is it the same case? Do we need to compare and subtract as well? As far as I know the identity being checked in detective is already the persistent identity from db.