ITIM Custom Participants Explained

One of IBM Tivoli Identity Manager's strengths is in its workflow engine. Visually defining workflows by adding actions, scripts and approval "nodes" can actually be fun and the visual results can often be a thing of beauty.

That said, the visual beauty can often be regarded as ugly compared to the elegance and simplicity within our scripting!

An approval node, for example, allows a workflow designer to select an approver as a particular ITIM user; a group of users associated with an ITIM role; or users with a specific relationship to the entity being operated on (such as a supervisor or service owner). But this can be extended using "Custom Participants".

CUSTOM PARTICIPANTS

Custom participants allows us to make use of the power of scripting. Instead of defining the participant for an approval (for example), we could use scripting to find an approver based on more obscure relationships.

All we need to do within our scripting is return an array of DNs representing each user who will act as an approver for the activity.

USE CASE & SOLUTION

Why would we want to do this? Let's walk through an example scenario:

Big Corp has lots of departments filled with lots of people who are very busy indeed. Supervisors have been identified but are too busy to deal with approval requests coming from ITIM because they operate in a highly volatile world when it comes to access rights. Big Corp has therefore decided that a role called "Departmental Approver" will be created and each department can assign multiple people to the role.

Big Corp, however, has insisted that users' access requests will only be approved by those Departmental Approver who exist within the same department as the requestor.

Native ITIM wizards allow you to select the "Departmental Approver" role as the participant of an approval activity but the link to the department that the approver is in won't exist! Using this mechanism, ALL departmental approver across the entire organisation would be used as an approver. This is where our Custom Participant script can come into play and provide us with a means of selecting Departmental Approver who exist in the same department as the requestor.

The solution to the problem would look a little like this:

// Let's search for the role first - we need its DN
var roleSearch = new RoleSearch();
var roleResult = roleSearch.searchByName("Departmental Approver");

if (roleResult.length < 1) {
    // This is a disaster - the role doesn't exist
    // You should handle this by whatever means suits you
} else {
    supervisordn = roleResult[0].dn;

    // Let's search for Departmental Approvers within our department
    var myFilter = "(&(erparent=" + container.get().dn + ")(erroles=" + supervisordn + "))";
    var personSearch = new PersonSearch();
    var personResult = personSearch.searchByFilter("person", myFilter, 2);

    // For each user found, let's add them to an array
    var myParticipants = new Array();
    for (i=0; i < personResult.length; i++) {
        myParicipants[i] = new Participant(ParticipantType.USER, personResult[i].dn);
    }
    return myParticipants;
}

Of course, we should handle the situation whereby no approvers were found! Hopefully, however, there is enough information above to help you build a robust custom participant solution.