Kuali Rice and IAM SIM-SRM Workflow

Owned by David Walker (Unlicensed)
Last updated: Nov 02, 2009Version comment
4 min read

Kuali Rice and IAM SIM / SRM Workflow

The /wiki/spaces/IAM/overview(IAM) project has need of a workflow engine to process approvals of organizational role assignments to people.  The approvers will, in general, be business managers and their designates from various organizational units throughout UC Davis.

Both the Sun Role Manager (SRM) and Sun Identity Manager (SIM) come with built-in, but independent, workflow engines. Also, Kuali Enterprise Workflow (KEW) is being implemented as part of the /wiki/spaces/UCDK/overview project as a general infrastructure for workflow at the campus.

  • KEW is the stated direction for a UC Davis-wide workflow engine.
  • Aegis, one of the vendors providing consulting for the IAM project, has a GUI tool for building workflows for SIM.
  • There is no GUI tool for building workflows for KEW.
  • In general, it is Sun's strategy that workflows are built in SIM, and SIM interfaces with SRM for role manager functionality..

The following diagram illustrates this:

Organizational Role Assignment

We anticipate four types of organizational role assignment:

  • Automatic assignment, based on information gathered from the identity sources.  This does not actually require approval nor, therefore, workflow, although implementing these assignments through workflow will unify processing and audit logs.
  • Automatic request for organizational role approval, based on information gathered from the identity sources.  Workflow items requesting approval are generated automatically by the IAM system in response to status changes for a member of the UCD community.
  • Manual request for organizational role assignment, based on information gathered from the identity sources, where no human approval is needed. This does not actually require approval nor, therefore, workflow, although implementing these assignments through workflow will unify processing and audit logs. Workflow items requesting approval would generally be generated by the person to be assigned the role, although it could be others, such as that person's supervisor.
  • Manual request for organizational role approval, based on information gathered from the identity sources. Workflow items requesting approval may be generated by multiple people, including the person to be assigned the role or a role approver.

There are exceptions to these four types of role assignment, but the vast majority fit these templates.

While there are other processes, internal to the IAM, that require workflow, our main concern are those workflows that are used by people outside of the IAM administration itself.

Options

  1. Implement all workflows in SIM.  This has been the implicit assumption of the IAM project to date.
    1. Pros
      1. No disruption to the IAM project.
      2. Aegis has expertise and tools for the SIM workflow.
    2. Cons
      1. The workflows created will not be integrated with KEW-based workflows that are being implemented as part of the MyInfoVault, KFS, and KC projects.  Users will interact with a different application to process their action items.
  2. Implement all workflows in KEW.  This is not likely to be a practical option.
    1. Pros
      1. The workflows created will be integrated with KEW-based workflows that are being implemented as part of the MyInfoVault, KFS, and KC projects.  Users will interact with the same application to process all of their action items.
    2. Cons
      1. Disruption to the IAM project and, perhaps, other projects, such as Rice and MIV.
      2. Aegis has no expertise nor tools for KEW.
      3. It may not be technically feasible to integrate KEW directly into SIM or SRM.
  3. Interface KEW to SIM / SRM workflow engines for those workflows that are used by people outside of the IAM administration.
    1. Pros
      1. The workflows created will be integrated with KEW-based workflows that are being implemented as part of the MyInfoVault, KFS, and KC projects.  Users will interact with the same application to process all of their action items.
      2. UCD has expertise in KEW, and role approval specific tools can be developed.
    2. Cons
      1. Disruption to the IAM project and other projects, such as Rice and MIV, as UCD's KEW expertise is currently dedicated to MIV..

Analysis

Bob Ono, Debbie Lauriano, Gastón De Ferarri, Curtis Bray, Patrick Flannery, Monica Moldavan, Gary Jellis, and David Walker discussed these issues between 10/22/2009 and 10/30/2009. Option #2 above was eliminated quickly, as it does not seem possible to completely replace the workflow in SIM or SRM.  We then focused on options #1 and #3.

The consensus is that option #3 is what we want eventually, but that we don't have the resources do it in Phase I of the IAM project without taking resources from other projects, particularly MIV. We estimate that it would take a knowledgeable Java programmer 2-4 weeks to learn Rice workflow and another three months to implement an application to do approvals for organizational role assignments to people, as outlined above. The learning part of this would also require a Rice-knowledgeable person to do the training, and all of our Rice-knowledgeable people are dedicated to the MIV project past the targeted completion of Phase I of the IAM project.

In addition to the application work, however.  UCD's first release of Rice integrates with the legacy identity management system, so the integration does not include the new roles management.  Since the authorization of role assignments is, itself, role-based, the Rice / Role Manager integration would need to be moved to Phase I.

Other issues:

  • The original IAM plan would have had Phase I completed months ahead of Rice's first deployment. Since the IAM project was delayed getting started, consideration of the use of Rice workflow in Phase I made sense.  At this point, however, it appears that the availability of Rice for applications beyond MIV, KFS, and KC will also be delayed, making the use of Rice workflow infeasible without affecting project schedules.
  • It appears that eDocLite will not be sufficient for the IAM system's approval work flow; a Java application would need to be developed.

There are three potential paths forward:

  • Option #1
  • Option #3 in Phase I of the IAM project
  • Option #3 in a later phase of the IAM project.  (This means adopting Option #1 for Phase I.)

Option #3 in Phase I would be the best architecturally, but it also introduces risk for the IAM project, as well as other projects.  Option #3 in a later phase (hopefully, Phase II) represents the more prudent path.