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.