Implementing Seek and Destroy (part 1)
by Deborah Volk on May 26th, 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. Here I will go over possible implementation strategies for the first two bullets using Oracle Identity Manager (OIM) as a an automation platform. I'll cover the other two bullets in my next post.

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).

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).
Posted in Identity Management, Oracle Identity Manager, Oracle Adaptive Access Manager Tagged with off-boarding
0 Comments
Leave a Comment
Search
Topics
Access Management (19)
Ask Identigral (6)
Change Management (10)
Data Quality (4)
Identity Management (27)
Passlogix v-GO (3)
Sun OpenSSO (3)
Sun Role Manager (3)
Tags
11g 3rd bday JavaOne SAML academia accuracy active directory adapters administrative agilent ask identigral attestation audit bpel bpmn bpm business case cdi cloud computing connectors contextual search data masking data quality deployment dip entitlements federation gartner groups gtc guests insider threats insider threat java jca jms lifecycle limericks linux mashup mdm messaging migration nabaztag oaam oam oas obiee oc4j oel off-boarding ohs oid oif oim oow09 opensso operations osso ovd owsm passwords patching performance phi privileged accounts provisioning queues reconciliation risk rocks rogue accounts rsa10 semantics siem sim sjsds sod solaris suncle thermodynamics twitter virtual reality vpd waveset webinar whitepapers
Recent Posts