After some analysis, you've decided that your company needs to beef up its digital identity infrastructure. You've read some white papers from vendors and even considered buying an enterprise package that you've been promised will solve your single-sign-on problems. Still, you're uncomfortable. You should be.
The problem is that a digital identity infrastructure isn't something you buy from a vendor, any more than you bought your file, print, and desktop infrastructure. Likely, you built that--from various components you bought--in accordance with goals and requirements specific to your company. Your digital identity infrastructure is no different.
The problem is that such an infrastructure is quite a bit more complicated than your desktops and corporate LAN, and there's not as much collective wisdom in the IT community on how to go about it. A bigger problem is that identity management is as much about politics and economics as it is about technology--maybe more.
To succeed, you need a strategy, one that takes into account not only the technology, but the politics and economics surrounding digital identity. I call such a strategy an identity management architecture, or IMA.
An IMA is like a city plan. We've all seen cities that don't quite seem to have a sense of place, where the zoning didn't yield a coherent set of uses or designs, and things just seem thrown together. This results from a lack of planning. Imagine the difficulty and danger of living in a place where there were few standards for building, multiple electrical voltages and phone systems, and roads were placed willy-nilly.
This is the situation in which most enterprises find themselves with their digital identity infrastructure. The systems are thrown into place with little thought to standards or interoperability. Solving the problem of the day, week, or month takes precedence over long-term goals. The end result is a tangled mess of systems that are brittle and unreliable. Heroic efforts are required to make small changes or even keep the systems running from day to day.
In the same way that city planning creates a set of standards and rules for buildings to ensure that the overall area is consistent and workable, an IMA is a collection of policies, rules, and standards that provides the context for creating a flexible digital identity infrastructure.
If identity management architectures are like city plans, then system architectures are more like the plans for single buildings. The plans for a building are made within the context and scope of a city plan that not only defines roads and lots, but also sets standards for sidewalks, setbacks, and so forth. Furthermore, the city plan has adopted building codes that define how the buildings will be implemented and sets out best practices.
Identity management architectures likewise define a context for system architecture. A well-defined identity management architecture will make demands on system architectures in order to meet certain ends. Like a good city plan, a large part of the effort is in establishing governance procedures that create and maintain the plan, as well as the inspection and quality assurance processes that ensure that it's followed correctly. Also, like a good city plan, conforming to the identity management architecture will be neither convenient nor cheap, and there will be considerable pushback if your organization is not committed to the process.
Building an IMA involves creating a series of interrelated components. This figure shows a schematic diagram of these components.
The following paragraphs describe these components briefly. For detailed information on how each of them are created and how they work together, see my book, Digital Identity. An IMA is created within a governance framework that lays the ground rules and a business context that lays out long-term business goals, principles, and objectives. Governance is one of the most political parts of the entire process, and hence, it can be the messiest. The number one rule for establishing governance for your IMA effort is to be inclusive. Everyone who will be affected, from the business managers who will pay for and use it to the technologists who build it, needs to have a way to participate and understand the process.
Closely aligned with the governance process is the process of gathering information about the business so that the IMA reflects the needs and structure of the organization. This isn't as complicated as it sounds and can be useful for more than just the IMA, including other IT project planning.
The process architecture describes how your business accomplishes identity tasks now and how they should be accomplished in the future. Identity processes are evaluated and improved using a maturity model for identity management that gives clear direction on how processes should be changed to improve your identity infrastructure.
The data architecture is a model of the identity data in your organization. Building an identity data architecture involves determining what data you have and then standardizing data practices in three important areas: categorizing, exchanging, and structuring data. Data usually gets the short end of the stick in any IT project. By linking the identity data to the business processes that use it (from the process architecture), you'll be able to create and justify projects to normalize and document data.
Identity policies are a crucial way for your organization to set direction, communicate standards, and create an environment in which interoperable systems can be designed and built. An identity interoperability framework is a set of standards that your organization has committed to using. These two pieces form the backbone of the IMA and are informed and used by the other components.
Identity-related policies have traditionally been all mixed up in security policy. I'm a firm believer that identity policies are more fundamental, and thus form a foundation for traditional security policies. You'll find a set of policy templates for identity policies at www.windley.com/identity-policy.
The technical reference architecture provides implementation guidance to system architects. Reference architectures tell system architects how to create systems that work with the enterprise identity infrastructure and each other. The technical reference architecture contains not only an overall blueprint for the digital identity infrastructure you're creating, but also recommended architectures for the various system types that will use it.
An IMA probably sounds like a lot of work. In fact, the very idea of policies and rules may be somewhat distasteful to you. First, recognize that an IMA isn't something that you build in one fell swoop, but is really a name for an ongoing process that helps system designers, programmers, and others in your organization build and use the digital identity infrastructure.
As you contemplate the effort involved in creating an IMA for your organization, you may have some concern that it can really work. If so, you may still believe some of the myths about digital identity and enterprise planning.
The first myth goes something like, "This is great for a smaller organization, but we're too complex for this level of planning." The truth is, the more complex you are, the more you have to rely on interoperability to get strategic value out of identity. Without interoperable systems, you'll find that even the smallest of tasks become huge projects, since they have to be fitted into the ad hoc infrastructure that has grown up over time. Fight this myth by creating a vision and piloting the IMA in a self-contained business unit.
The second myth is just the opposite: "This is great for a larger organization, but we don't have the staff or time to manage this effort." The IMA process can be adapted to even the smallest of organizations. The process can be scaled to fit most situations. In small organizations, the IMA effort is made easy by the fact that there are usually a few recognized decision makers and the group arrives at consensus fairly easily because of shared goals. You may already have a good handle on process and identity data, so start with an interoperability framework and some baseline policies. Build a reference architecture and follow it. This will provide a good foundation as your business grows.
The third myth is a variation on the second: "An IMA is great for an organization that has a tradition of planning, but we've always prided ourselves on being nimble." In fact, most organizations that can say this with a straight face do plan; they just don't recognize it as such. The prescription is largely the same as the last myth. Don't build a straightjacket. Make the governance process fit your traditions, but set standards and policies to guide system development.
The fourth myth says, "We'll spend all our time planning and none of it executing." This myth misses the point that the IMA should be built to fit the organization and its needs. Pick the places in your organization where having good identity infrastructure would make the most difference. Engage in an IMA process for that piece and then repeat on the next priority. Whatever you do, do something.
The last myth is common in many IT shops: "Interoperability is about buying (or building) the right technology." Many technologists wish this were true, and act as if it were. The result is a litany of failed projects that never meet their goals because they missed the important governance and modeling steps necessary for success. Smart CIOs and IT managers know that good IT is much more than buying the right product.
How your organization manages digital identities will have a great impact on whether you are constantly fighting problems brought on by a lack of attention to identity management or whether you are exploiting opportunity enabled by a flexible and rational digital identity infrastructure. Building that infrastructure depends on having the right strategy. I'm confident that identity management architecture can help you develop your strategy and the right infrastructure.
Phil Windley is an Associate Professor of Computer Science at Brigham Young University.
Return to the O'Reilly Network
Copyright © 2009 O'Reilly Media, Inc.