Where is the Motivation for Deprovisioning?

A series of blog posts on self-service deprovisioning in the federation world got me thinking about a simpler, albeit very real, problem with the "traditional" deprovisioning process in a company.

Most companies that have an IdM system have 2 ways to deprovision users:

1. Emergency Termination Workflow (where a manager logs on to the deprovisioning workflow, and kicks off the termination process that disables accounts across the board)
2. Automated Terminations (where the IdM system keys off of HR or Payroll or some authoritative store that provides the user's status and termination date which in turn automatically disables accounts)

The problem I've seen most companies face is with the second workflow because data is entered in late. So why not put a workflow together for self-service deprovisioning?

The only problem with this approach is the lack of motivation for an end-user to run through the workflow. Perhaps there is an approach to tie the completion of this workflow to some interest for the end user that will motivate him/her to run through it. Some ideas...

• Severence Pay
• COBRA Enrollment
• Continued Communications (to enter in personal e-mail address?)
• An iPhone? (seems to work for other things)

I bet that this approach would solve some of the data-timeliness issues. What do you think?

More on VDS and Cache

Mark Wilcox put up a post responding to my previous queries about the virtues of persistent cache and virtual directories. The bottom line of my post was around performance, so Mark gives some figures for OVD:

The overhead is absolutely minimal - it's generally around 2-5 milliseconds. And worst I've ever seen is around 50 milliseconds (remember that's still only 5/100s of a second). This includes doing a join of data.

Are Symlabs, Radiant Logic and other vendors seeing the same results? Perhaps, a skilled SI may want to chime in? If so, then why does anyone use a persistent cache? Anyone?

Also, Blink Technologies put the following comment on my previous post:

I thought the whole point of the cache is to lighten the load against the system as a whole. It's a compromise of data freshness for performance. Plus the entire point of a cache is to "cache" frequently used data, of course depending on the algorithm used (LRU, MRU, etc.). I also assume that the cache is adjustable and can have specific timeouts for freshness. I think for a highly trafficked directory this is a great trade-off.

Funding Doc Templates From VC = Saving $$$

Brad Feld just posted a set of 5 docs entitled "Model Seed Funding Documents" that I really wished I had a few years ago. (It has a term sheet and subscription agreement!)

Anyone who is going through a seed round should/must go read Brad's blog thoroughly before speaking with attorneys. Educating yourself on your time rather than the attorney's could save you a ton of money. I wish all VCs were this helpful.

Deprovision. We're in a Recession!

Hot off the Canadian Press:

The Canada Revenue Agency has issued at least $3-million in paycheques to people who don't work there, says a new audit.
"Overpayments generally occur when employees leave the agency and through errors or omissions their pay is not stopped on time," says the internal report.

I often hear something like this from identity management workshop participants: "I wonder how much payroll gives away for free because of a broken deprovisioning process."

Me too.

Here's a quick example I saw last week. The daily inactivation report that gets sent out to all admins from HR contains an "entry date" that is weeks, sometimes months, passed the "effective date". How's that for an ROI analysis for your next identity project?