1. Be Fast. In terms of timing, off-boarding should be executed as close as possible to employee walking out the door. What this means is that OIM needs to know about the termination event before it actually happens. One way to accomplish this is to allow incoming off-boarding events to contain a termination timestamp. The timestamp would signify a cutoff beyond which all access should be revoked. This way if someone is leaving the company or being terminated, the event could be entered in advance by, for example, someone in HR, and eventually pulled into OIM. Doing this avoids both the last minute rush to turn off access and potential data entry errors.

Let's say the event with a termination timestamp makes it into OIM on Thursday and the timestamp is set to Friday 5pm. Would OIM "wake up" at exactly 5pm on Friday and proceed with revocation or disable workflows? It may or it may not wake up at exactly 5pm. Much of the internal processing in OIM is triggered via built-in scheduled tasks (rough equivalent of UNIX cron) which run every so often. If a task runs every hour and the last run was at 4:59pm, the next run is at 5:59pm and you just missed an hour. Schedule for important built-in tasks could be modified so that they run at a higher frequency, say every 15 min, and this could cut down on the lag. (This implies mucking with internals of OIM, something Oracle discourages). It's worth noting that frequently running tasks (and their interaction with the database) may have a performance impact. Make sure to conduct a thorough performance test if you're going to be scheduling a lot of tasks to run at a high clip.

What if an upstream source of events cannot have a termination timestamp be set in the future? Some HR apps don't allow this type of logic. In this case you're at the mercy of the interface between OIM and the HR app (if the HR app is your source of events, that is). Usually the interface allows for reconciliation via HR app's API and reconciliation is triggered by a scheduled task. Rather than modify the schedule of a task (one option), a better option is to have the HR app push the events to OIM, either by calling OIM API directly or by using a service-based abstraction, the latter typically implemented as a Web service. This way the events will come to OIM as soon as they're generated by the HR app. The PeopleSoft connector for Oracle Identity Manager works exactly this way: events flow through PeopleSoft's Integration Broker to a SOAP-based web service that calls OIM APIs. (The web service ships as part of the connector).

2. Don't get stuck in traffic. Best-in-class off-boarding processes allow for exceptional circumstances where the IT portion of the process can be triggered in multiple ways via multiple channels. The classic option is to align the identity administration solution with HR so that whatever HR uses (PeopleSoft, Oracle HR, SAP, etc) becomes the authoritative source of people-related events. In Oracle Identity Manager this means reconciliation from HR or in some cases such as PeopleSoft a push of events by HR into OIM. That's a hard-coded channel which makes it impossible for anyone but a few people in HR to revoke one's access via OIM deprovisioning workflows.

At least two more channels should be available: a simple webapp that allows a bypass of HR and an administrative override. The latter option is almost always "there" since operations personnel are usually placed in OIM's System Administrators group which has permissions to do everything. (Hardened OIM deployments place admins into different groups altogether). It is probably worthwhile to note that these channels should also be aware of terminiation events, and preferrably in advance. In our experience this is typically done by a series of emails and/or reports.

Even though the administrative override is available, it does not imply operations staff will know how to use it. Oracle Identity Manager thrives on data-triggered workflows: one wrong step when filling out an OIM form and your off-boarding event may not amount to much. Thus, documentation of an admin override is very important so that guesswork is taken out of the process.

Taking up the case of the front-end webapp, it is strongly recommended for it to be bolted downwith only a few supervisor-level or higher people in each org unit (department or larger) authorized for access. This is where Oracle Adaptive Access Manager (OAAM) can add a lot of value by strengthening the authentication service without requiring cumbersome infrastructure with, for example, X.509 certificates and two-way SSL. The Adaptive Risk Manager (ARM) component of OAAM could be configured with rules that would prevent risky off-boarding transactions, e.g. an authorized person logging in at 2am from their Blackberry with a geo location of hundreds of miles away from the office (stolen device?)

In the ideal world, the webapp would mimic the HR app by submitting a reconciliation event with the same payload but differentiate itself from HR by changing the point of origin field included with reconciliation data. For HR, the point of origin might say "PeopleSoft", for front-end webapp the point of origin might be "Terminator WebApp". If webapp can mimic HR, there's no need to develop a separate interface / connector with its own resource and forms in OIM. (The policy question of whether people in org unit A should be allowed to off-board people in org unit B via the webapp should also be considered).