Some installations require that instead of an individual acting as an approver, a Workgroup is utilized instead. This causes a potential issue, what if the user whom the request was submitted for (the requestee) is a member of the Workgroup assigned as its approver? Potentially you have a situation where someone is approving their own access. Depending on the business requirements, this could be considered very bad.
Solution
In the provisioning approval subprocess workflow, it is possible to place a "Validation Script" in the step: "Approval". The result is a red error message (customizable) that gets show to the approver who isn't suppose to be approving. All other members of that workgroup are still able to go in and approve as normal.
Code
<ValidationScript>
<Source>
/*
This validation script will check to make sure whoever is trying to approve the
WorkItem form is not the Identity for which the access was requested. We do this by
getting the "completer" value from the WorkItem, if that is the same as the target identity
"identityName" then a red alert will be shown to that person when they attempt to approve
the item and they will not be allowed to continue. Other members of the workgroup will be
allowed to complete it.
*/
import java.util.*;
import sailpoint.api.ObjectUtil;
//returns the displayName - so need to get the actual identity
String completer = item.getCompleter();
//owner from the WI, checking to make sure it is a workgroup
Identity wiOwner = item.getOwner();
if(null != wiOwner){
if(wiOwner.isWorkgroup()){
//utility call that returns all the members of the workgroup in question
ObjectUtil obj = new ObjectUtil();
Iterator members = obj.getWorkgroupMembers(context, wiOwner, null);
if (null != members){
while(members.hasNext()){
//get the individual identity from the list of wg members
Identity identityCube= (Identity)(members.next()[0]);
String identityDisplayName = identityCube.getDisplayName();
//does the workgroup identity have the same display name as the completer?
if(identityDisplayName.equalsIgnoreCase(completer)){
//found the displayname of the approver in the wg, get the unique ID
String identityCubeName = identityCube.getName();
//if unique id of the wg member with matching displayName as "completer" matches
//the unique id of the target identity, we have a self approval - throw error
if(identityCubeName.equalsIgnoreCase(identityName)){
return "Error message that will be displayed on the approval page";
}
}
}
}
}
else{
//Check if the completer is just an id, if the id's displayName is equal to completer ... send auto-approve
//message
Identity requesteeId = context.getObjectByName(Identity.class, identityName);
if(null != requesteeId){
if(completer.equalsIgnoreCase(requesteeId.getDisplayName())){
return "Error message that will be displayed on the approval page";
}
}
}
}
</Source>
</ValidationScript>
I am trying the same thing to ensure that the requestee and approver are not the same person. I tried adding a validation script in the Provisioning Approval Subprocess and even tried the same thing in the Identity Request Approve workflow but the work item nevertheless gets created even when the requestee and approver are the same users (Basically, requestee is the forwarding user of their manager). AM I missing out somewhere?
In 7.2: whenever the approver (a member of the workgroup) is the launcher of the request, then it seems that the validation script is not evaluated (kind of bypassed).
For the validation script to be taken into account, we had to disabled the launcher auto-approval (add <Variable initializer="true" name="disableLauncherAutoApproval" /> in the provisioning approval subprocess workflow). This is annoying as the launcher auto-approval feature is quite convenient from an end user point of view.
Do you know if your script can still coexist in any way with the launcher auto-approval feature?
I haven't tried this in 7.2, but the question would be, is it possible to have a check, early in the workflow that:
Checks if the launcher is the approver
If the launcher is the approver, and is not in the workgroup - set the workflow variable disableLauncherAutoApproval == false
Otherwise, leave as initialized, true
They key would be getting this step inserted prior to whatever logic is evaluating the 'disableLauncherAuthoApproval' flag. As mentioned, I haven't actually tried this, but let me know if it works!
We have a similar requirement and are currently on version 8.3p2. I tried adding "<Variable initializer="true" name="disableLauncherAutoApproval" /> in the provisioning approval subprocess workflow and added the above validation script in the approval step but still the validation script doesn't seem to get executed. Any ideas, what I might be missing here?
@adam_creaney, does this solution work for 8.3 workflows as well?
As suggested in the post, I added this validation script in the approval step of "Provisioning Approval Subprocess" workflow but the script itself is not getting executed for me.
