I have an Advanced Policy which isn’t being caught in the workflow. The LCM Provisioning policyScheme is set to Interactive mode.
While Entitlement SoD policies are working fine, none of the Advanced policies are working i.e. users are able to successfully submit requests.
Here’s the code. What am I doing wrong here? (We are on 8.1 p2)
This is working as designed. Advanced Policies cannot be used in “interactive” mode, as they are not necessarily related to access. However, they can still be “detected” during the Refresh Identity Cube task execution. Currently, only Entitlement SoD and Role SoD Policies will trigger the interactive mode when submitting access requests.
I was able to get it to work based on other posts in the community. Seems like I have to pull in the identity entitlements in the rule code and use that in the logic for this to work. I used IdentityService to get the identity (passed as a rule argument) to get the links and then the entitlements of the identity. Using that in my conditional logic made it work i.e. the violations now show in the UI and the user is prevented from submitting the request.
Are you able to please provide links to the other community posts that helped you to get this working? I seem to have the same issue that you had. The PolicyViolation is created during a refresh but does not prevent the Access Request from contunuing and no UI message. I have also used the IdentityService to get the entitlements so must be something else that I am doing wrong in the rule. Thanks so much!
I can’t recall the exact post but basically what it said was that when you are creating and submitting a request, a temporary version of the identity is created and used during policy violation checks.
As long as you call identity.getLinks() and then getEntitlements() on those links the policy violation will get triggered during submission.
Here’s some sample code to iterate through the identity links and entitlements:
IdentityService ids = new IdentityService(context);
List<Link> links = identity.getLinks();
//List links = ids.getLinks(identity, application);
//List<Link> links = ids.getLinks(identity, 0, 0);
List<String> requiredRoles = new ArrayList<String>();
// Get user links
if (links != null && links.size() > 0) {
for (Link link : links) {
entitlements = link.getEntitlements(Locale.getDefault(),“”);
if (entitlements != null && entitlements.size() > 0) {
for (Entitlement entitlement : entitlements) {
QueryOptions qo = new QueryOptions();
qo.addFilter(Filter.eq(“value”, entitlement.getAttributeValue()));
qo.addFilter(Filter.eq(“attribute”, entitlement.getAttributeName()));
List<ManagedAttribute> groups = context.getObjects(ManagedAttribute.class,qo);
if (groups!=null && groups.size()==1 && groups.get(0).getAttribute(“Prerequisite”)!=null) {
String preReq = groups.get(0).getAttribute(“Prerequisite”);
if (preReq.startsWith(“Role:”)) {
preReq = preReq.substring(preReq.indexOf(“:”)+1);
requiredRoles.add(preReq);
}
}
}
}
}
}
Thanks the confirming. The issue I had that was during my testing the policy I created would also cause I violation prior to the access request (if the user was refreshed). I did not realise that this is how the check was done but this link here has a good explanation to the process.