Adding and Removing Deferred Tasks Using a Workflow

The new year often brings about many changes in an organization using any sort of identity management software.  A common task is to provision (or remove) attributes from a user, such as updating a role or removing access to a given resource on a specific date.  In many cases this is accomplished through the use of a deferred task.  In this post I’ll cover how to add, update and remove deferred tasks from a user.  (The process for managing deferred tasks for other object types is similar but since Sun IDM really focuses on users I’ll stick to that object type.  I honestly can’t say I’ve ever registered a deferred task for any other object type anyway.)

From a low-level point of view, a deferred task is an property of the user object stored in the Sun Identity Manager repository.  The property tells the IDM system two things – a date / time and the name of a workflow to run.  The purpose of the deferred task is to instruct the IDM system to run the named workflow on the given date – hence the name deferred task.  Sun IDM has a special task/workflow that must be scheduled to execute called the Deferred Task Scanner.  The Deferred Task Scanner looks at all IDM objects to see if a deferred task is registered in the object and needs to be executed.  When the date of a registered deferred task has lapsed into the past then the deferred task scanner will execute the named workflow.

So you can see how this would be useful in provisioning and de-provisioning user attributes or resource access based on time.  Adding a deferred task to a user is relatively simple.  Conveniently, Sun has provided a workflow service to do just that:

<Action application="com.waveset.session.WorkflowServices">
  <Argument name="op" value="addDeferredTask"/>
  <Argument name="type" value="User"/>
  <Argument name="name" value="$(userId)"/>
  <Argument name="instanceName">
    <s>When the task executes it is named this</s>
  </Argument>
  <Argument name="task" value="Workflow name to execute"/>
  <Argument name="date">
    <ref>your date</ref>
  </Argument>
  <Argument name="description">
    <s>A description of the task when it is executing</s>
  </Argument>
  <!-- if set to false the next option causes
       the task to be executed after each scan
       of the deferred task scanner -->
  <Argument name="executeOnce" value="true"/>
</Action>

The executeOnce option for the deferred task deserves a special explanation.  If it is not set to true then the deferred task entry is not removed from the user object after it has been executed.  Typically, this means that it is the responsibility of the workflow named in the deferred task to remove it.

Removing a deferred task is also just as simple:

<Action application="com.waveset.session.WorkflowServices">
 <Argument name="op" value="removeDeferredTask"/>
 <Argument name="type" value="User"/>
 <Argument name="name" value="$(userId)"/>
 <Argument name="task" value="Workflow name goes here"/>
</Action>

I would encourage you to use the debug page in Sun IDM to view a user object before and after a deferred task has been added to a user.  When a deferred task is present it is quite clear as it exists as a property of the user object.

My organization uses deferred tasks to sunrise and sunset employee accounts.  When a new employee or contractor is hired, a minimal settings account is created.  Typically, this happens well before the new employee even shows up for work.  A deferred task is added to the user object that is scheduled to execute the week before the employee starts.  The purpose of that deferred task is to gather approvals for account creations on many downstream resources.  An additional deferred task is used to actually create the accounts at 2 a.m. the day the new employee starts.  A similar set of tasks are used when the employee or contractor’s end of employment nears.  These tasks remove access from some of the downstream resources (but do not delete accounts) with a final deferred task used to completely remove an account if necessary.