Strategy

Okay, so you’ve conducted some kind of identity strategy project to figure out what you want to do with an identity management system for your company. You have an overall idea of the sequencing of work, of the technical architecture, the business case, the goals and requirements, and the people who are going to be responsible to do the work.

Congratulations! Sit back, relax, have a homebrew.

Connect primary identity repositories

Next, assuming that it’s a company with thousands of employees, you’re going to be dealing with a lot of existing infrastructure so one of the first decisions you’re going to have to make is the sources of authority for the initial deployment. There probably are already multiple identity stores in your organization; the HR department, the file & print directory, the badging system, the PBX, and so forth. Technically, you need to figure out how to connect them (may I suggest Novell Identity Manager?), but you’re also going to have to make some business decisions about the ownership of the data and decide on authoritative sources.

For instance, I might have a phone number listed in the corporate PeopleSoft HR system and another one in the PBX. If we connect both of those to the identity infrastructure, which has precedence? If the number changes in the PBX, should that change propagate to the HR system? What is the business rule in that situation? You might say, “PBX,” which seems like the right answer, except that the Personnel department might not like the idea of giving up control of their records like that. So it bears saying and repeating and repeating: HR must be involved from the beginning of any successful enterprise identity project.

Of course, it would be especially nice if I followed my own damned advice; I’m working on a project right now for a mid-sized government agency that is struggling with HR issues precisely because they have not included HR representation from the beginning. So we now have to integrate not only the HR system, but a separate database that the department maintains of pending changes, contractors, and temporary employees. All of which can be handled, and gracefully, by PeopleSoft, if only we had the HR department involved.

So maybe I should amend the rule to say: It makes things much easier to involve HR from the beginning of any successful enterprise identity project. We even have a white paper on this very topic.

Tip: A nice quick way to demonstrate success, always a problem with IT infrastructure projects, is to deploy a white pages applications. This is actually useful to end users and is relatively easy to do (YMMV) once you’ve got the core pieces in place.

Establish an Identity Vault

When we do these first phase deployments, we almost always set up an “identity vault” (IDV) as the centerpiece directory. The IDV is itself not authoritative, which is initially counter-intuitive. In fact, it ought not to hold any unique information at all but simply replicate information held elsewhere (such as, in the example earlier, a person’s telephone number from the PBX.) The connectors, in Novell’s architecture, hold the business rules about the flow of information in and out of the IDV. The IDV needs to be highly available but you don’t necessarily want to be hitting the IDV with a lot of requests, at least not directly. Instead, we usually build out “service directories” that are tailored for particular situations; they may vary by geography or application type and so forth. The service directories can be placed physically close to the users, to improve performance, and the service directories communicate back to the IDV.