Part 2: Automated vs. Manual Identity and Access Provisioning – Permissions and Properly Restricting Assignment of Tasks
In my previous post Automated vs. Manual Identity and Access Provisioning – Breaking Down the Stigma and SOA Task Routing I talked about the capabilities of Manual Task fulfillment and provisioning in OIM and how to setup the SOA composites to properly get task assignment information. In this post, I’m going to go over the required permissions and addressing some ‘gotchas’ now that you are utilizing the manual provisioning and task fulfillment capabilities of OIM.
Once you start using the manual provisioning and task fulfillment, a couple of things are going to come up immediately as you start assigning tasks out to users. The first issue is permissions and data access for fulfillment users. By default, any user can be assigned a manual fulfillment task, but when they go to open the task they will get a series of error messages since they don’t have access to view the beneficiary information in the task (see below). To address this, fulfillment users need to be assigned administrative role permissions in OIM.
The second issue you’ll come across is task reassignment / improper reassignment. By default, any user that is assigned a task, can click Actions > Reassign and choose from any user / role in OIM and reassign the task. Inevitably, what happens is a user is assigned a task will re-assign to an OIM role (group) that contains users who have not been granted the appropriate permissions, or worse yet, will assign it a role that contains all users in OIM (ALL USERS).
Both the above issues can lead to task notifications being sent out to users who should not see tasks, Helpdesk calls, etc. and cause headaches. To fix this, 1) you need to assign fulfillment users the appropriate rights and permissions in OIM and 2) you can leverage the IRestrictedAssignmentCallback functionality of the DisconnectedProvisioning composite (developed earlier) to allow reassignment of tasks to only those users and roles who have been previously setup to be able to complete fulfillment tasks.
Out-of-the-Box Task Assignment / Reassignment and Permissions
By default, anyone that is assigned a manual fulfillment task in OIM will see the below when they open the task (if they have the proper permissions).
Once the task has been claimed by the assignee, they have the option to go to Actions > Reassign to assign the task to someone else. This can be done to move sub-sequent tasks, or to finish multiple parts of a single task.
When the assignee chooses to reassign the task, they are presented options to search by User or Group (OIM Roles). When they search, by default they can choose any user that is in OIM.
Likewise, if you change to Groups, the assignee can search any group (role) in OIM. If you notice below, the option to choose ALL USERS and many other enterprise roles is available.
If the assignee reassigns the task to someone that does not have the appropriate permissions, when that user logs in and opens the task, they will get the below error message.
To fix this issue, we are going to implement a custom java task to only allow assignment of tasks to users that have proper permissions by assignment to fulfiller roles. I generally recommend using a naming convention for fulfillment roles to ensure you can search and see the purpose of the role and its membership.
The new java task is going to have two (2) parts. Inside the DisconnectedProvisioning composite, we will have a task that populates users and groups (roles) that are allowable for reassignment. Then, we’ll have a separate class that is used on reassignment to populate the search results with the data collected in the composite.
To begin, start a new java project and create the necessary applications. In my case, I have RestrictAssignments (class to be used on reassignment search) then SOAAssignments which populates the data when a composite instance is called for a manual fulfillment task.
In the SOAAssignments project, add the necessary class and code to search OIM for the appropriate users and groups. I used a search for Administrator Role membership and my ‘Fulfiller’ naming convention for fulfillment roles.
In the RestrictAssignments application, you create a new class that implements the IRestrictedAssignmentsCallback to take data supplied from the composite and parse out the possible list of users and roles.
Once the coding is completed and validated, you can deploy the SOAAssignments jar to the DisconnectedProvisioning composite. Additionally, create some BPEL preferences to hold information to be used in the composite for searching OIM. As you can see in the below, I provide login information (from WebLogic CSF), administrator role information to use for searching users, then role name formatting to pull list of possible roles.
Once this is done, you can add a Java Embed object to the composite to gather the information from the java task and store it in the composite to be used later.
Inside the embed, add the necessary code to call OIM and set the variables to be used in the restricted reassignment later.
Once this has been completed, go to the ManualProvisioningTask, go to Access to add in the class for the restricted reassignments.
Under the Configure Restricted Assignments, add the custom java class created for the RestrictAssignments application along with the global variables from the task that stores the list of users and roles for reassignment (from the earlier java embed object).
Once the composite updates are complete, you can deploy the composite as the default revision in SOA.
Now that composite is complete, you need to make sure there is an administrative role for the fulfillers so they have the appropriate permissions to complete the tasks. In the OIM identity console, go to the Manage tab and Administration Roles.
In my environment, I am using the admin role ‘HATSecIT’ to signify the task owners / IT users that will be completing manual fulfillment tasks.
Here is the administration role information.
Below are the capabilities required for users that will be fulfilling the manual fulfillment tasks (outside of the certification capabilities, will cover those later).
I assigned these rights at the ‘top’ org so that it filters down to all users in OIM. This can be assigned at any organization level as long as it applies to the user base that will have tasks assigned.
Once you have the composite deployed and appropriate administration roles, you need to deploy the RestrictAssignments.jar file from the java application to the SOA servers. Copy over the jar file to the $SOA.HOME/soa/modules/oracle.soa.ext_11.1.1 directory shown below.
Set the MW_HOME, ANT_HOME, JAVA_HOME, and CLASSPATH environment variables to the environment.
NOTE: if you do not set the location to the ant-contrib.jar file in the classpath, when you run the ant command to build the jar, it will give you an error. This only applies to the PS3 environment.
Once completed, you can run the command ‘ant’ to build the oracle.soa.ext.jar file to be loaded in SOA. Once it completes, you should see a ‘BUILD SUCCESSFUL’ message.
Once this is done, restart all SOA servers to ensure the new class is loaded and the composite is ready to go.
With these changes in place, when opening a task now and going to Actions > Reassign, you see the same flow and options as before.
When you do a search for users, you will only see a limited set of users for possible reassignment. These represent users in the administration roles from the search / java embed that was loaded.
Similarly, when searching for groups, you will now only see ‘Fulfiller’ roles since that is the search filter that was loaded for the role search.
Logging into Fusion Middleware Control and looking at a SOA payload, now you will see the data populated from the java embed that is used in the task reassignment lookup.
Manual provisioning and task assignment is a great feature of OIM. With the additional information in this post, now you can ensure that as tasks are generated in OIM, users can only reassign them to other users and roles with appropriate permissions to complete the tasks. More importantly, you can ensure that someone doesn’t inadvertently (I speak from experience) assign the task to all users in OIM and everyone starts getting task assignment emails.