Enterprise identity strategy: 2. Provision key systems

Connect key systems

Provision important systems, where “important” is a mix of financially and politically significant systems. Typically, this might include the ERP system (if it’s different than the HR system and especially the finance modules), help desk/trouble ticketing, call center, inventory control/supply chain, intranet or key web-based applications, custom developed database applications, and the physical security (i.e., badging). You want to come up with a list that covers 80% of what real people in the organization care about; this is surprisingly easy to do. The list, I mean; deployment is hard.

These don’t all need to be done at once and for all users, but –again — it’s important to think through the business rules that govern the identity infrastructure so that all the pieces are coordinated over time.

For example, the badging system might be a unique source of identity data with information about people (e.g., night cleaning crews) who have access to your buildings but are not otherwise represented in your IT systems. You probably don’t want to give them email accounts or access to your corporate financials, but that information might be very valuable for disaster planning so that you know who is in your offices at any given time and who, exactly, they are. In some instances, such as hospitals, there are so many employees in the ‘extended enterprise’ that aren’t directly on the payroll that the badging system becomes the source of authority for identity data.

Deploy basic provisioning and workflow

As you move beyond basic capabilities, the feature sets of identity management products start to become differentiated. But in the current state of affairs, most of the major vendors have at least some workflow and automated provisioning capabilities. With the infrastructure pieces in place, you can start to take advantage of these capabilities to do things like new hire provisioning and employee self-service.

These will have obvious end-user benefits (“obvious” in the sense of visible, if not quantifiable) but motivating factor is often de-provisioning. That is, the ability to rapidly — instantly — turn off an employee’s access to those key systems such as payroll or badging when they leave the company. It’s what’s politely described as “zero day stop.” It can be brutally effective; by the time the now ex-employee leaves the conference room after their conversation with their manager, they can no longer access their email account or the corporate intranet or, sometimes, the phone extension on their desk. And it scales! Mass layoffs made easy!

Less ghoulishly, you also get tremendous reductions in help desk calls for password resets and routine requests for changes to information. You might not want to grant all of those requests (allowing users to change job_title often leads to entertaining results and I’ve heard of instances where people change their phone number in their record to a colleague’s number, in order to avoid work), but you can add a manual approvals step to the process to minimize those impacts.

Enterprise identity strategy: 1. Establish core infrastructure

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.

Building an identity strategy in three stages

I’ve talked before about identity strategy (and here), but what does a whole lifecycle of an enterprise identity deployment look like? In other words, what is a master plan for implementing identity management? Let’s assume that there are three stages:

1. Establish core infrastructure

  • Conduct strategy / assessment / planning
  • Build out identity vault
  • Connect primary identity repositories (i.e., file & print, HR, etc.)

2. Provision key systems

  • Connect key systems (defined as financially significant and business critical)
  • Deploy basic provisioning and workflow

3. Enhance

  • Add additional systems, including disconnected systems
  • Enhance provisioning and workflow
  • Introduce role based access control
  • Other — e.g., rapid login/logoff for clinicians

OSBC

This is the first time — in what? four years?  since it started? — that I’ve missed the Open Source Business Conference in San Francisco.  OSBC is one of my favorite conferences and I always come away excited at having learned something new.  This time, I have an identity project that I’m managing and I wasn’t able to make it, but I’ve been following Gary Ardito’s regular updates on his blog, Tao Student.

As far as Novell is concerned, the big news out of OSBC is the announcement that we’re partnering with the EFF to lobby for the reform of software patents.