Implementing Seek and Destroy (part 2)

by Deborah Volk on June 1st, 2009

In the previous blog post, I have described some of the best practices that are worthy of consideration when designing robust off-boarding processes. In part 1, I talked about how to implement some of these best practices using Oracle Identity Manager. This post is a continuation of the implementation discussion.
Trust but Verify. You need a system of checks and balances, at worst a single control where an alarm will go off somewhere if the terminated employee hasn't been off-boarded. In Oracle Identity Manager (OIM) this is best accomplished via attestation. Attestation tasks could be automatically generated for both the direct supervisor of the off-boarded employee as well as someone in HR. The attesters could be notified via email and they would also have open tasks show up on their OIM dashboard/self-service console in the web UI. (They'd have to login there first, thus email as a primary alert mechanism). Since it's possible to have the task escalate to the person's manager or a designated delegate if the task SLA has been breached (e.g. no action on the task in 24 hours), attestation is a potent weapon for ensuring that off-boarding indeed occurs...but there's a catch.

In order for OIM to generate tasks as part of the attestation workflow where the tasks are scoped (targeting) only the terminated person, it must know about the termination event. If the termination event makes it into OIM, whether via reconciliation or push from an authoritative HR source upstream or via another channel such as a web front-end or operator override, why do we need a redundant control in the form of attestation? We can Be Fast and revoke access right then and there when the termination event comes in or when its timestamp-based threshold is exceeded.

The catch is that OIM needs the termination event to act but in order for the termination event to come in from the upstream source, someone upstream needs to act first and this often doesn't happen as promptly as one would like. Sometimes it never happens. Without the termination event, OIM can't automatically revoke access BUT it can still schedule an attestation. This attestation will not be narrowly scoped since we assume that we don't know who was terminated and when. That's how many Oracle Identity Manager implementations deal with zombies - they have people in the supervisor capacity in the entire company attest every quarter that Joe Smith onis still there and breathing. The problem with this wide-ranging attestation is that it's an expensive process; you have to reduce its scope to make it cheaper...which runs into a Catch-22 described above.

This is why the Don't Get Stuck in Traffic is a best practice from a process perspective. If you've got a single source of termination events, that source may become a bottleneck and the best you could do is run a company-wide drill every quarter to clear out dead people. On the other hand, if you have multiple channels that can produce a termination event, you have a way out. This becomes particularly important if a person leaving the company, voluntary or involuntarily, had privileged access, be it to systems or data such as a worldwide sales forecast. The extra channels then become very handy since you can revoke this person's IT access without waiting for HR to complete the termination paperwork and enter the event into their system.

Last but not least, let's not forget that having OIM accept events from upstream source, usually an HR app, is far from a given. I've seen a number of deployments that attacked provisioning first (gotta have an Active Directory account to get onto the network!) with terminations and alignment with HR being further down on the list. In this case, we recommend having a web front-end that lets OIM know that a person should be off-boarded. Once the switch to HR occurs and all events start flowing from there, you still have your web front-end as a working backup channel.
Seek and Destroy. Physical access (entering gates, buildings, floors, offices) is just as important as logical access (entering network and various systems). Best-in-class off-boarding processes do not differentiate between physical and logical access. In Oracle Identity Manager, physical access can be revoked along with logical access. This starts with bringing physical access into OIM as a resource with a lifecycle to be managed.

There are two scenarios. One scenario is that physical access is managed by an application such as Manhattan Software's Centerstone with some factor such as a key card or a badge used to gain entry. The other scenario is that physical access is not managed by software. At best, there might be a spreadsheet with a list of Active and Terminated users and a person who owns the spreadsheet. These two scenarios might seem like extremes but surprisingly enough they represent the two most frequently encountered cases.

In the first scenario, a resource in OIM can be automatically disabled or revoked during off-boarding. This would then trigger a sequence of events that percolates down to the connector which in turn calls the physical access software. This is a worst case scenario - custom connector that talks to the app directly via the app's API or via a friendlier abstraction such as a web service sitting on top of an unfriendly app API. (Many physical access systems are indeed somewhat archaic in their internal architecture so the web service scenario is not uncommon). Some physical access management packages use LDAP-compliant directories as identity stores which makes this downright easy. Technically, there's nothing special about this use case. The details of the integration between OIM and the target application that manages physical access can be worked out.

In the second scenario, we can use a feature of OIM that few people know about - human-powered workflow tasks. The OIM workflow engine and application layers that use it were conceived to handle both programmatic (automated) tasks that many people think of simply as "tasks" and human tasks. The physical access resource still exists in OIM, its lifecycle is no different from the resource in the first scenario. When a human task is generated during the workflow, it's assigned to a human (with an OIM login, of course) and put on his or her queue. The workflow pauses and waits for the task to be completed. The human assigned the task gets notified via email, logs into OIM, sees the task on his task list (aka Open Tasks) and acts on it. The action occurs outside of OIM, e.g. moving the user from Active Users spreadsheet tab to Terminated Users tab, taking the office keys from the user and escorting him out of the building, but it's recorded inside OIM. When the task is done, the human task owner marks it as completed in OIM and the workflow proceeds.

In both scenarios, the user's physical access is revoked.


Posted in Identity Management    Tagged with off-boarding


0 Comments


Leave a Comment
Search

Subscribe

follow on

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)