How NOT to provision

I’m often teaching customers how to migrate from their old, clunky, non-integrated non-systems to integrated, fully operational, and completely audit-friendly systems. A common non-system is back-door provisioning. As I’ve said here, and in many meetings, and especially in the book, a help desk ticketing system is not a sound basis for provisioning. You want a proper request process, showing only those things that should be on the menu for the given user, an/or you want automation based on roles and attributes. Then you want full blown approval workflow, documentation for approvals and disapprovals, you want target system connectors. And then you want automated DE-provisioning. None of this is available through the help desk.

Well, here’s another one I run into, not as often, but it’s just as bad, if not WORSE. It’s the use of synchronized directories for provisioning. In other words, I set up a schema in a virtual directory that synchronizes the necessary attributes to mimic rights in target system directories. So besides the usual attributes:

• First name
• Last name
• Phone extension
• Hair color
• Boxers or briefs

 you also have:

• SAP roles
• Peoplesoft roles
• AD group memberships
• Blah blah

The supposed goal here is to fill in the attributes, then allow the directory sync to populate those target directories. Sounds awfully easy. And there’s only a few things missing. A few big, fat, hairy things, such as:

Referential / transactional integrity

Rollback

Two-phase commit

Approvals / denials

Do you gather all the approvals in advance, then send everything off? What if one of the approvers says nay? Do you go back in and wipe out the attributes you DON’T want to sync? What happens when one or more of the updates doesn’t work? Can you undo the ones that did? If not, will your target systems themselves be out of sync?

How about dependencies? Are you going to write a whole bunch of LDAP or database triggers?

There certainly won’t be any parallel processing.

Many to one is easy. One to many is hard. And this architecture makes it even harder.

Oracle Virtual Directory is a wonderful tool for aggregating information from multiple sources, including other directories, databases, even web services, and presenting this data in a single LDAP interface. And bi-directional is also good. But using it for provisioning is NOT good.

A true meta-directory, like Oracle Internet Directory, at least allows for rollbacks and other intelligence. It is actual persistent storage, and allows for more robust updates in the other direction. But there are still pieces missing which makes it less than desirable for full blown provisioning, as with Oracle Identity Manager and its brethren.

Do you want to reduce complexity? Of course. But do you simplify to the point of not having what you need? Of course NOT.