In both cases, the documentation indicates that there should be a project or plan variable representing the ProvisioningPlan. However, my logging indicates that the ProvisioningPlan and ApprovalItem are created after my advanced policy rule is executed. I have tried to log all of the common IIQ variables and see that plan, project, objectRequest, and accountRequest are all void. I do have identity and context.
Can someone please tell me what workflow subprocess clicking the Submit button on the Review and Submit screen goes into so that I can figure out how to access the role that has been requested? The advanced policy needs to short-circuit the access request if a specific role is being requested and another condition is met, and I cannot figure out what variable can give me that role information. Thank you for your time.
When you configure an Advanced policy it will check the Identity twice once before without the access and once again with it applied. This is all before it goes for provisioning through LCM.
You can pull the information from the Identity object and check both before and what it would look like after to trigger your violation in the UI. Unfortunately you are not able to obtain the plan at this point.
You should be able to see the role in the Advanced policy rule with method identity.getAssignedRoles()
Thank you. That is helpful and explains why my log statements show up twice after I hit the Submit button. The problem is that while it’s great to have the list of assigned roles, I really am only concerned about the role that was just requested. I can’t tell from the list whether the role I want to flag was the one that got requested with that Submit.
It seems a little strange to have the new role that was just requested show up in the assignedRoles list prior to it being approved. Is there any way to tell what role was requested with the submission in my advanced policy check? Thanks.
If you apply some logging you will see the rule is triggered twice as you mentioned. IdentityIQ will provide the identity object as an argument to the rule and you should be able to see the changes when it is triggered the second time (before it actually goes for approval and provisioning).
You are not able to see the IdentityRequest from the arguments passed to the rule.
Maybe a good approach would be to print the Identity XML to the log while you are testing. Check the difference between the two and then work out the trigger condition.
Keep in mind this was mainly for me to understand what I have available to me at the point where the policy is checked. There is more to be done once I know that the specific role was requested before I know that a policy violation should be returned. I replaced the actual role name with “Special Role”.
if (identity != void && identity != null) {
logger.info("identity is available");
boolean specialRoleRequested = false;
List<Bundle> assignedRoles = identity.getAssignedRoles();
for (Bundle assignedRole : assignedRoles) {
String roleName = assignedRole.getFullName();
logger.info("Role name = " + roleName);
if (roleName != null && "Special Role".equals(roleName)) {
specialRoleRequested = true;
}
}
if (specialRoleRequested) {
logger.info("Found Special Role request, creating policy violation");
policyViolation = new PolicyViolation();
policyViolation.setActive(true);
policyViolation.setIdentity(identity);
policyViolation.setDescription("User must complete required training before Special Role can be assigned");
policyViolation.setStatus(PolicyViolation.Status.Open);
if (identity.getManager() != null && identity.getManager() != void) {
policyViolation.setMitigator(identity.getManager().getName());
}
} else {
logger.info("Special role not found in assigned roles");
}
} else {
logger.info("No identity available, identity = " + identity);
}
It’s unfortunate that I can’t easily discern what role was requested. I will mark this as the solution though because you have given me enough to go on to resolve the problem. Thanks again.
I wanted to follow up with a better solution to get the requested role when you don’t have the provisioning plan yet that I found in a Sailpoint IIQ Show and Tell post.
In short, by getting the identity from the database and comparing the database assigned roles list to the list of assigned roles on the identity in the request, you can easily get the new role being requested from the request identity object. This made my code much simpler and cleaner. I hope this helps anyone else who comes across this problem in future.