Better Living Through Chemistry
by Deborah Volk on May 21st, 2009

I have always loved the subject of physics, but I am definitely a macro-gal instead of a quantum one. A Newton over Hamilton kind of thing. As a result, chemistry was one of my least favorite subjects in school. Having said this, I recently found that chemistry might actually be helpful in explaining the complexities surrounding the movement of an employee throughout an organization
We start by modeling the organization as a closed system with many molecules, like the Finance molecule, the HR molecule, the IT molecule and so on. Since molecules are made up of atoms, within each departmental molecule we have our business atoms (HR Operations, HR Benefits, ...), and within each of these atoms, we have electrons, the worker bees. Life is pretty good for our molecules, they form and dissolve bonds freely, until some worthy event occurs. For example, addition of new, foreign molecules (new departments spring up) or heat (economic meltdown) are possibilities. Once the event happens, we've got electrons moving around (electron A saying to electron B - "I am transferring, good-bye!"). Too many electrons going one way or too many of them going a different way and you've got a disaster on your hand.

Similarly to the discombobulation that occurs at the (very) low physical level, organizational or self-inflicted changes in a corporation that trigger a transfer of an employee from X to Y are hard to handle in software, whether X/Y is location, org unit such as department, or a job title. Managing the employee's transfer process while making sure his or her access required to do the (old or new) job remains correct at appropriate checkpoints along the way is no small feat. It's not unlike trying to control a chemical process so explosions don't occur. The goal of the supporting cast in the transfer process should be protection of corporate assets while maintaining a high level of productivity. And in my experience, fortunately or unfortunately, productivity trumps protection. (Quantiatively, this gets into probabilities. Potential loss from a breach vs employee idling).
There are many strategies in representing job change/transfer events in the identity and access management world. A simple approach is to treat the transfer as a role change. Role-based automation on both the identity side and the access side is simple to understand and (relatively) simple to implement with the right tools such as Oracle Identity Manager and Oracle Role Manager. As the person changes jobs or transfers to another department, we automagically notice the event (thanks to our ever-vigilant HRIS), change the role and from there automation does the rest. Accounts are enabled or disabled, entitlements added, removed or changed, appropriate access is granted and the old, inappropriate access is revoked.

This is all fine and dandy for the transfer process that fits into role-based access control model (read: straightjacket) but what about exceptions to that? Exceptions are the way of life in people-focused processes. For example, in his previous (outgoing) job, the employee might have been granted entitlements by his manager on an exceptional basis, they are not part of employee's job responsibilities. Another great example and something that happens quite often is that the employee is going to be temporarily performing both the new job AND the old job while the organization is searching for a replacement. This seemingly innocent scenario turns into pure wickedness if you're working under the role-based model, although in all fairness I have to say that this is a function of implementation and tools used, some are more flexible than others. One more fun challenge is a so-called toxic combination of privileges that follow from a combination of roles. Coming from Segregation of Duties (that fountain of audit youth), a toxic combination of privileges is a situation where the same employee can write checks and approve checks.

An alternative way of handling role-based model and corresponding access conundrum is via attestation. Nothing is revoked on a transfer; no accounts are disabled, no privileges are removed, only additional items may or may not be granted to the employee. Someone then has to say (attest) that a person should keep their "old" access post-transfer. Unfortunately, this puts an undue burden on people, as they may end up having to attest to hundreds of entitlements. This is especially true if the notion of a "transfer" is defined as any job-related change.

There are many other strategies of dealing with transfers, but ultimately, it comes down to being able to harness the capabilities of identity and access management platform.

Posted in Oracle Role Manager, Oracle Identity Manager, Identity Management, Access Management    Tagged with attestation


Leave a Comment

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)