This isn't the last post in my current provisioning series. I promised the last post would focus on a few architectural ideas for handling provisioning and de-provisioning in a distributed environment. This one simply highlights something I saw reported that helps illustrate a point I made in my last post. The Daily Press, Newport News, VA, last week reported:

A part-time computer help desk technician let go from Thomas Nelson Community College almost three weeks ago said that, as of Wednesday morning, he still had computer access to the records and Social Security numbers of every student in the Virginia Community College System.

Edwin Slater, a 24-year-old Newport News resident, said college officials told him he was being laid off from his job July 9 because of budget cuts. But Charles Nurnberger, TNCC's vice president for finance and administration, said no employees have been laid off, although some jobs have been consolidated.

The college VP's answer to the alleged data breach is quite contorted. He indicates that no employees had yet been officially terminated. The VP doesn't address the fact that the employee in question had either been notified weeks ago that he was being laid off or that, in any case, he had not showed up to work in 3 weeks. So the VP sort of implies that there was no data breach since the college hadn't officially terminated the individual's status as an employee. This is an interesting answer, but not one that has anything to do with protecting the confidential student information to which the help desk technician had access.

As I wrote in my previous post:

RBAC is like Communism: It sounds really great until you try to implement it,
David Griffeth, Vice President of Enterprise Identity Management, Citizens Bank at Catalyst Conference 2009.

In my previous post in this series, I covered the ROI for improvements in provisioning processes and I began to walk through the employment lifecycle to show how provisioning relates to specific employment lifecyle events. In this post, I finish my discussion of the employment lifecycle and talk a bit more about the limitation of role-based access controls.

RBAC and Communism

I didn't attend last week's Catalyst Conference 2009. However, when I saw David Griffeth's quote about role-based access control (RBAC) tweeted from the conference on Friday afternoon, I thought it captured quite nicely one of the points I'm trying to make in this series of posts. Managing access and entitlements by role gets complex quickly. It is not to say that roles aren't useful in managing provisioning, but starting with a table of events relevant to provisioning and de-provisioning is likely a better way to begin your planning. Increasingly, HR service delivery is distributed among multiple SaaS providers. Roles and sub-roles are likely to be tied to particular SaaS offerings. So lifecycle events - such as those covered in this post and the previous post - are a better starting point than roles. Build your table of lifecycle events, look at target systems, then perhaps look at whether and how roles fit into the provisioning and de-provisioning operations.

In my first post, I covered some basic provisioning concepts and emphasized that while provisioning processes ideally are "role-aware," they also need to be sufficiently flexible to handle a variety of intervening events. In this post, I cover some of the ROI for improvements in provisioning processes and walk through just a few events in an employment life cycle to show where provisioning fits into HR processes. I'll follow-up with two more posts. One to look at termination processes and the other to zoom-in on architecture to support provisioning.

The ROI for Improving Provisioning

There are ample business cases for investments that improve provisioning processes.

Below is the first in a few posts looking at managing access and entitlements across an employee lifecycle (from hire to termination). This post covers some basic concepts and definition of terms.

The OASIS Provisioning Services Technical Committee describes provisioning as:

...the automation of all the steps required to manage (setup, amend and revoke) user or system access entitlements or data relative to electronically published services.

In the context of HR processes, the term "provisioning" is commonly used in a few different contexts, but it broadly describes a process of communicating to a target system the information that system needs to authenticate users and to determine their access privileges. Perhaps the most critical task within the provisioning process is "de-provisioning," which refers to the removal of access rights and entitlements.

Provisioning is a horizontal enterprise process that has special relevance for HR systems management because access and entitlements for individuals usually are derived from a individual's status as an employee or contractor and from the particular position they hold or role they play.

New hire and termination processes are of special concern in managing provisioning. The new hire process is of concern, since new employees cannot become fully productive until granted system and facility access they require to do their jobs. Termination is of concern because of the security risks posed if terminating employees are not properly de-provisioned from systems. Provisioning and de-provisioning also may be triggered by many other intervening business and life events (for example, new projects, transfer, promotion, sabbatical, etc.).