Chapter 13. An Architecture for Digital Identity

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 appeared thrown together. This results from a lack of planning. Imagine the difficulty and danger of living in a place where there were few building standards, multiple electrical voltages, and roads were put in place willy-nilly.

This is a situation that most enterprises find themselves in 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 becomes standard operating procedure. 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 day to day.

In the same way that city planning creates a set of standards and rules for buildings to ensure that neighborhoods are safe and pleasant, an enterprise architecture is a set of standards and rules that creates an interoperable and flexible enterprise-wide IT infrastructure.

The work of city planners provides a model that helps us understand the work required of enterprise architects. This work can be divided into three primary categories :

Standardization

Dimensioning of pipes, voltage, roadways, etc.

Certification

Regulated and standardized qualifications for workers

Management

Rules, notifications, permits, approvals, enforcement, etc.

The tasks in enterprise architecture are largely the same.

If enterprise architectures are like city plans, then system architectures are more like the plans for a single building. The plans for the building are made within the context of the scope of a city plan that not only has defined 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 building will be implemented and requires certain best practices.

Enterprise architectures, likewise, define a context for system architectures. Well-defined enterprise architectures make demands on system architectures in order to accomplish specific objectives. Like a good city plan, enterprise architectures also establish procedures that create and maintain the plan and specify the inspection and quality assurance processes that ensure it is followed.

Another aspect of planning is enforcement. There's no point in creating policies, defining standards, and establishing rules if they're not enforced. Enforcement can be a cause for contention within an organization. Furthermore, it's not free. Just as the builder (and ultimately the homeowner) pays the cost for inspections and compliance, system architectures that live within the context of an enterprise architecture will also pay a price, both implicit and explicit. Conforming to the enterprise architecture will be neither convenient nor cheap, and business units will push back if they don't understand the payoff.

Your organization may already be deeply involved in building enterprise architectures, or the concept may be new to you. Either way, the concepts of enterprise architecture can be helpful in planning and carrying out an identity management strategy within your organization. Whether or not you're developing enterprise architectures, this book will show you how you can use the ideas and methodology involved in creating one for developing comprehensive plans, processes, and infrastructure for identity management. I call this an identity management architecture (IMA).

I'm using identity management architecture in the same sense that I've described enterprise architecture. An IMA is a coherent set of standards, policies, certifications, and management activities. These are aimed at providing a context for implementing a digital identity infrastructure that meets the current goals and objectives of the business, and is capable of evolving to meet future goals and objectives.

Most of the topics we associate with digital identity have traditionally been part of an organization's security planning. By now, I hope you're convinced that proactively managing identity goes beyond the traditional security aspects of authentication and authorization. Similarly, identity management architectures differ from typical information security planning in several important respects:

  • Identity management requires a functional business model. Information security planning rarely makes mention of the business. This business model describes in some detail how the business functions. This includes identifying important entities, resources, and processes and their relationships. The functional business model may be detailed or abstract depending on the depth of the IMA planning process.

  • An identity management strategy is driven by long-term business goals surrounding employees, partners, suppliers, and customers, whereas security planning usually reacts to these relationships as perturbations or exceptions to the plan. I rarely talk to a business executive who doesn't complain about business goals being at the mercy of security planning.

  • Identity management requires that resources and entities be identified first. Typical information security plans are largely about perimeter defenses. Consequently, they are usually concerned with networks and servers rather than business documents and customers. Like the functional business model, the level of detail in the inventory of resources and entities varies depending on the nature of the IMA planning process, but these are its central focus.

  • An IMA identifies dependencies between identity data and systems. These dependencies are used to determine implementation priorities. Security planning, and most IT planning for that matter, often emphasizes projects that are deemed critical without seriously considering dependencies between data and systems. An IMA highlights those dependencies so that they can be used in the planning process.

IMAs provide business justification for security and directory infrastructures that go beyond perimeter security to enable valuable business activities. At its heart, an IMA is a set of plans, policies, and procedures whose most significant contribution to the bottom line will be through the improvements it makes to future system designs and implementations.