Digital Identity

Phillip J. Windley

Copyright © 2008 O'Reilly Media, Inc.

O'Reilly Media

Dedication

To my parents, Rolla and Ranae Windley, for giving me the freedom to explore.

Foreword

The migration of sociability, business, entertainment, and other activities from the physical world to the virtual world of the Internet has dramatic implications on many fronts. The societal mores, legal structures, and commonly accepted business practices that govern everyday life in the physical world have evolved over thousands of years, and that evolution continues every day. But now we're in the process of translating those structures to the Internet, creating a new place where people can interact. That "place" is radically different from the physical world, one where networked applications combine with ubiquitous connectivity to free transactions, communications, and other activities from physical constraints, thus, creating an entirely new set of requirements.

When it comes to enabling a truly virtual world that can accommodate the breadth and depth of human endeavor, nothing is more important than identity. On the Internet, movement is instantaneous. People, applications, transactions, and data can cross many types of borders via many different paths. At the same time, the security issues associated with a very public and virtual space have become painfully clear as spam, phishing attacks, fraud, and identity theft have become all too common.

Digital identity is the keystone that will ensure that the Internet infrastructure is strong enough to meet basic expectations for not just service and functionality, but security, privacy, and reliability. That fact is becoming more and more obvious to more and more people every day. But as the Zen master once said, knowing the path and walking the path are two very different things.

How we create, use, store, and verify identity in the Internet context is a complex question, one that transcends both the public and private sectors, and every conceivable business. It raises a large number of thorny issues for society and individuals (not the least of which is privacy), corporations (including the regulation of core operations), and governments (laws, regulations, international treaties). The manner in which these issues are resolved will have a long-term impact on all segments of society and will determine what forms of digital identity will first augment, and then (at least potentially) replace the "official" and "trusted" manifestations of identity on which the physical world relies today. That change will take years, extending past the end of the current decade, involving societal, cultural, business, and political efforts.

How much control individuals will be able to take—or will want to take—over their digital identity is the subject of intense debate, for example. Pessimists predict that the intersection of government and commerce will create a surveillance state, one that will make privacy an artifact of the past. Optimists predict the liberation of the individual from both corporate and government control through the use of identity technologies that will put the individual in charge, inverting the traditional relationship between "consumers" and "service providers." That debate will continue for the foreseeable future as unfolding events pull us in both directions.

Today, much of the activity around digital identity is business-focused. The pressure to compete in a networked world while simultaneously reducing costs is driving companies to integrate business processes and information technology on an increasing scale. Many enterprises are creating inward- and outward-facing systems that tie employees, customers, partners, suppliers, contractors, and other constituents into their business processes, for example. Instead of thinking about individual applications, enterprise IT architects must consider end-to-end business processes that span many boundaries, and how they can integrate the components of IT to support them. These trends are causing wholesale change in IT architectures, moving them to what we at Burton Group call "the virtual enterprise."

The move to the virtual enterprise brings with it new security risks. These risks, along with the rapidly increasing number of regulations, both in North America and the European Union, are driving the need for new security models. Simply put, the traditional exclusionary security model—perimeter-based systems focused on keeping bad people out of the network—are not sufficient to protect the virtual enterprise. Today, businesses must augment exclusionary security with an inclusionary security model, one capable of explicitly determining, through policy, who can access the applications and data that support core business processes.

Such inclusionary models are unattainable without identity management. Identity must become persistent through the continuum of any given business process, spanning not just multiple applications, but also multiple organizations. Only then can identity provide the predicates for corporate governance, security, regulatory compliance, risk and liability management, and other core business functions.

For most enterprises, identity management is not easy. In fact, most enterprises' identity management processes are poor, a fact that internal and external audits make painfully clear. Historically, enterprises have treated the symptoms of the identity management problem with point solutions. But Internet-scale identity management requires an integrated set of infrastructure services that enable a holistic approach to defining and managing identity. This sophisticated array of tools includes directory services, rules-based user provisioning, delegated administration, and self-service administration for passwords or other attributes. General-purpose, strong authentication systems, along with good credential management, are also core components of better identity management. Beyond authentication, enterprises must link applications to access management systems across a variety of operating systems, applications, and web-based single sign-on (SSO) products, making policy management yet another important part of the system.

Effective identity management also requires a new approach to systems integration and interoperability. Previous efforts to solve the identity problem (such as X.509-based, public-key infrastructure) attempted to achieve interoperability through symmetry and homogeneity. But federation has recently emerged as a new and more effective approach to enabling interoperability between security domains. Emerging federation standards rely heavily on the loosely coupled web services architecture, which in turn relies heavily on the eXtensible Markup Language (XML). Both the web services framework and interoperable identity are evolving along similar architectural lines for obvious reasons. While the web services framework enables the virtual enterprise, identity management secures it. So it's quite necessary for them to share architectural underpinnings.

The web services framework has, in essence, begun to create a standard software "communications bus" in support of service-oriented architecture. Applications and services can "plug in" to the bus and begin communicating using standard tools. The emergence of this "bus" has profound implications for identity exchange. Just as application and transactional data will flow across that bus, identity data will flow over that bus. And within service-oriented architectures, identity will become a core service.

The combination of web services and federated identity management has enormous potential; however, we have only just begun a long but inevitable transition to such a full-scale identity management infrastructure. And technology alone will not enable it. Regulations, laws, policies, and other mechanisms must evolve—both nationally and internationally—to create the context and boundaries for the acceptable use and management of identity. Likewise, business models for federating identity—including liability, risk management, and workable governance models—must evolve.

The evolution will be painful at times, occurring in fits and starts. Today, we're several years and many breakthroughs away from the combination of standards, technologies, legal frameworks, and business models necessary to create a fully interoperable identity framework. While we're in the early days, however, it's clear that the era of digital identity management has arrived, and tools and techniques are emerging that will help companies address the issue. There are clear and strong links between identity management and enterprise business objectives in many industries. The market forces that will drive us inexorably forward to resolve these complex problems are active, causing real and significant movement.

Given these realities, today's IT managers must start creating an identity management infrastructure that meets their business objectives. And that makes books such as this one all the more important. Through his work in both the public and private sectors, Phil Windley has a perspective on the issues of IT architecture and identity management that can come only through experience. Phil has lived the problem and is dedicated to finding a solution: one that works not just for one company, but for all companies. Phil has poured much of his experience into this book, which provides a great starting point for anyone needing to understand both the issues and technologies behind effective identity management.

It's that starting point that is often the most important in any attempt to drive significant change, either in an organization or a technical architecture. The people and companies who take what Phil has to offer in this book, learn from it, and use it to start the process of change will be better prepared for the future. This book can be the first step toward a general-purpose identity management infrastructure that will enable new applications, services, or business models while reducing costs.

As an increasing number of enterprises take that path, digital identity management will emerge as a pervasive infrastructure, within, between, and across organizational structures. The technologies and standards, as well as the law and policy that evolve to regulate corporate use of identity information will both influence and be influenced by the larger personal identity infrastructure to come. Enterprise identity management and the larger societal move toward digital identity for customer, governmental, and other activities will inevitably intersect, changing the way we live and work in the process. I look forward to working with Phil and a host of other participants in the creation of that infrastructure.

Jamie Lewis CEO and Research Chair Burton Group February 2005

Preface

In late 2000, Governor Michael Leavitt of Utah asked me to serve as his CIO and a member of his cabinet. Governor Leavitt had a strong belief in the power of e-government to transform government operations and thought that my private-sector experience as CTO for an early e-commerce start-up, http://iMall.com, and then as vice president of product development at Excite@Home was just what was needed to help build e-government in Utah.

I spent almost two years working on that vision and building an infrastructure to support it. While I was CIO, I struggled to learn how to build flexible, interoperable infrastructure in a large, loosely coupled organization. Many of the issues we faced, such as privacy, naming, directories, authentication, and digital signatures, were identity issues. Many more of them were about how to execute an enterprise strategy in a decentralized organization. State governments are not alone in those challenges.

I have a deep respect for the power of digital identity, and I am convinced by my experiences in e-commerce and as CIO that digital identity was a foundational element in modern IT systems. I can't imagine an agile, business-responsive IT infrastructure that doesn't have at its core a flexible, interoperable identity infrastructure.

Not long ago, Doug Kaye sent an email to a group of folks that said, essentially: "The world needs a book on digital identity. Would any of you like to write it?" I thought that sounded fun, and this book is a direct result of Doug's question.

Throughout this book, you'll find stories from my experiences as a CTO and CIO that illustrate identity concepts. Interestingly, when I had those experiences, I wasn't usually thinking about digital identity. Consequently, I was surprised to find that many of my past experiences were directly related to the subject of this book. In relating these experiences, I don't want to take undue credit for what happened. Literally hundreds of people participated in the experiences I relate, and I'm grateful that they did. I learned a lot.

Who Should Read This Book

This book is designed to familiarize CIOs, IT managers, and other IT professionals with the language, concepts, and technology of digital identity. As I said, I believe that managing digital identity is one of the most fundamental activities in IT and that a good identity management strategy is the key to not only protecting the enterprise from attack, but, more important, providing flexible access for partners, customers, and employees to needed information and systems.

The concepts in this book apply equally well to a wide variety of organizations. While this book primarily talks about digital identity in the context of business, the concepts are as applicable, and opportunities as great, for non-profit groups and government agencies. As I mentioned, my experiences cover the public and private sectors as well as large and small organizations. When I use the word "enterprise" in this book, I mean any business or organization—for-profit or not. The term can even apply to business units, provided their decisions about identity are relatively independent from other business units in the larger organization.

This book is not a book with code examples and recipes for building digital identity management systems. Even so, it is a technical book that explains the technology of digital identity in some detail. More importantly, the book puts the technology in context and shows how it can all be put to the task of managing digital identities inside your organization.

The book is divided into three sections. The first section is about the core concepts in digital identity, including privacy and trust. The second section discusses the technology of digital identity. The third section portrays in some detail a process, called an identity management architecture (IMA), that you can use to build a digital identity infrastructure in your organization, regardless of its size or organization. The information in the last section is prescriptive in nature. Because of my experiences, I have a clear philosophy on how to build an IMA. I present a rather a detailed series of steps that show how to create an IMA and how to use it.

Conventions Used in This Book

The following typographic conventions are used in this book:

Italic

Used for file and directory names, email addresses, Unix commands, and URLs, as well as for new terms where they are defined.

Constant Width

Used for code listings and for keywords, variables, tags, functions, command options, and strings where they appear in the text.

Constant Width Bold

Used to mark lines of output in examples.

Constant Width Italic

Used as a general placeholder to indicate items that should be replaced by actual values.

Comments and Questions

Please address comments and questions concerning this book to the publisher:

O'Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

(800) 998-9938 (in the United States or Canada)

(707) 829-0515 (international or local)

(707) 829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:

http://www.oreilly.com/catalog/digidentity

To comment or ask technical questions about this book, send email to:

bookquestions@oreilly.com

For more information about our books, conferences, Resource Centers, and the O'Reilly Network, see our web site at:

http://www.oreilly.com

Safari Enabled

When you see a Safari® enabled icon on the cover of your favorite technology book, that means the book is available online through the O'Reilly Network Safari Bookshelf.

Safari offers a solution that's better than e-books. It's a virtual library that lets you easily search thousands of top tech books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.

Acknowledgments

This book would have never happened without the encouragement, help, and advice of Doug Kaye. I've mentioned his original question that motivated the book. He also provided valuable coaching and mentoring, as well as served as the book's first editor. I'm grateful for his guidance and friendship.

Bradford Windley drew the picture of the trebuchet in Chapter 1.

Some portions of Chapter 12, on federating identity, are adapted with permission from Scenarios for Identity Federation & Drivers of the Identity Network by Linda Elliott and Eric Nolin of Ping Identity Corporation, Tom McKenna of SRI Consulting Business Intelligence, and Kevin Werbach of the Supernova Group LLC.

I'm grateful for the help of Gary Daemer of Booz Allen Hamilton who provided valuable information and advice about the maturity model for identity discussed in Chapter 15.

Burton Group and Jamie Lewis, in particular, were very generous in letting me use their ideas in writing Chapter 19 on reference architectures. I'm also grateful to Jamie for agreeing to write the Foreword to this book and for his insights into the state of the art in digital identity systems and technology.

The technical reviewers offered many thoughtful suggestions that greatly improved the final result. I'm thankful for their efforts.

Lastly, I'm grateful to my wife, Lynne, and my children, Bradford, Alexandra, Jacob, Joseph, and Samantha, for their support, help, love, and mostly for their understanding at the many times I had to say "Sorry, I can't—I've got to work on the book."

Chapter 1. Introduction

In medieval times, strong walls and moats surrounded great cities. Guards were posted at the gates of the city, and everyone coming or going was inspected and questioned about their purpose for entering or leaving the city. At the same time, cities were where the markets were held. You can imagine the crush at the gates on market day with peasants bringing their goods into the city from outside and visitors clamoring to get to market. After market was over, the process was reversed. With our modern eyes, we can see what an impediment to commerce the walls were, yet at the time, city residents were thankful for their security.

The walls were not broken down by enlightened thinking about of how markets should work, but rather a weapon for which the walls were no match: the trebuchet (see Figure 1-1). A trebuchet is a gravity-powered catapult that is vastly superior to its torsion-powered cousins. The trebuchet revolutionized medieval siege warfare and eventually spelled the end for city walls. The result not only forced an alternative strategy for security, but also had the pleasant side effect of increasing commerce.

I recently had the opportunity to sit with a group of CIOs and discuss digital identity. What struck me was how much of the conversation was about security and liability rather than identity and opportunity. They had a siege mentality and their security planning showed it.

Modern corporations are the walled cities of our time—sitting behind firewalls and defending themselves from attack. What these CIOs and others can't see is that their security implementations are restricting their company's opportunities in the same way that ancient walls restricted commerce in their day. Fortunately, commercial enlightenment, rather than a weapon that cannot be withstood, is awakening a desire in corporations to rethink how we provide security so that our interactions with customers, employees, partners, and suppliers are richer and more flexible.

Figure 1-1. Trebuchet

Business Opportunity

The economic shifts that have occurred over the last decade have changed how businesses operate and the expectations of customers. One of the most dramatic shifts has been the rise of network-based, automated services. In many cases, we're "spending more and owning less," in the words of Jeremy Rifkin. When I fly, I almost always purchase tickets online, but more than that, almost all of my needs as a customer of the airline are self-serviced, using online web applications. I can check flight schedules, be notified by SMS if my plane is running late, check my frequent flyer account balance, and even redeem upgrade points and change my seat online. The changes underlying these trends have profound implications for businesses and customers alike.

For businesses, a service-oriented economy means that they must adjust to entirely new ways of relating to their customers. The World Wide Web changed the way companies market their products. But more importantly, the products themselves have changed. Perhaps the most significant change is that there is no longer a human in the loop to create a trust relationship with the customer, make up for process deficiencies, and represent the company. When two businesses merge, they often find that they have very different approaches to knowing their customer and that this makes leveraging the combined operation almost impossible.

For customers, the changes are equally dramatic. Where they used to purchase things from people at physical locations, they now purchase or use services delivered to them electronically on their computer, PDA, and even their phone. The usual trust marks that customers have relied on in the past are either missing or easily forged. As the number and breadth of services that people use grows, they find that they are inundated with requests to identify themselves and to divulge information they consider private.

In addition to their customers, businesses have relationships with partners, suppliers, and employees. Networks have changed those relationships as well. Just as with the business-customer relationship, these relationships are increasingly moving to the electronic world and being mediated by automated processes rather than people.

Digital Identity Matters

At the heart of this service-oriented economy are network-based, automated transactions. Automated transactions are fundamentally different than the transactions that occur in the physical world. When I stop by the convenience store to buy a snack, I can exchange cash for peanuts. Unless the clerk happens to know me, the transaction is anonymous. In contrast, in the service-oriented economy, anonymous transactions are rare, because delivering service automatically almost always implies that you have to know something about who's receiving the service—if not their names, then at least their preferences or other attributes. This identifying information is usually transferred digitally, across the network. In a service-oriented economy, digital identity matters.

Of course when we talk about the service-oriented economy, we're not just talking about e-commerce. Note that my example with the convenience store involved a small cash purchase. But imagine the same scenario, except this time I use a debit card, credit card, or check. In any of those cases, I've invoked a network-based financial service as part of the overall transaction. Network-based services are as pervasive in transactions that occur in the physical world as they are in online interactions.

In an automated, network-based service, I have to know who you are in order to sell you access to my service. Since these services are increasingly delivered over digital networks, businesses need reliable, secure, and private means for creating, storing, transferring, and using digital identities. Network-based, automated services are not just delivered to customers—employees, partners, and suppliers also interact with the enterprise via services. In many cases, anonymous service is impossible or undesirable, and as a consequence, digital identities must be assigned and managed.

In addition to identifying customers to sell them services, business have an increasing need to identify employees, systems, resources, and services in a systematic way to create business agility and ensure the security of business assets.

Using Digital Identity

Digital identity is the lynch pin in each of the activities we have just discussed, along with a wide variety of other activities important to business. Consequently, 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 managing identity, or whether you are exploiting opportunity enabled by a flexible and rational digital identity infrastructure.

The common ATM machine is a great example of how digital identity enables new business opportunities. Before ATMs were invented, a bank's customers took care of their banking needs by presenting pieces of paper to a human teller. The papers included instructions to the bank (e.g., deposit slips), cash, checks, and other financial instruments. Unless the teller personally knew the customer, the customer usually also presented some kind of identity credential, such as a driver's license. The teller was able to verify the identity of the customer and the validity of the various pieces of paper.

The ATM was possible only because banks created a means of identifying their customers digitally. We're all familiar by now with the debit card and PIN that ATMs require from us before service. The card carries identity information and the PIN tells the bank that the person presenting the identity is entitled to use it. With the advent of a digital identity infrastructure, banks no longer needed a human in the loop to verify the customer's identity.

From the bank's perspective, the most obvious benefit from an ATM is to reduce the cost of employing the teller, but there are other benefits as well. I lived in Japan for two years during the 1970s and experienced ATM machines there for the first time. I'd never even heard of ATM machines before that. I had a chance to visit Japan again in 1996 and found something strange. There were still plenty of ATM machines, but they operated only when the bank was open. You you could only receive during banking hours.

Japanese banks, at least in 1996, still viewed ATMs as simply "teller replacements." But in the U.S., something more interesting had happened: ATMs were used to extend service in ways that went beyond merely replacing the teller in the branch. ATM machines extended service in three fundamental ways:

ATM machines were open 24 hours per day, seven days a week. In fact, the first time I ever saw the phrase "24/7" was as part of a branding campaign for a small credit union in California. 24/7 was a catch phrase in the banking industry before the Internet made it popular.

ATM machines increased the number of customers a bank could service simultaneously, with multiple ATM machines being installed in many bank branches.

Because they are relatively inexpensive, ATM machines were installed outside of bank branches in convenience stores, shopping malls, theaters, and so on. These businesses usually shared in the profit from the ATM transactions.

This example shows clearly the three primary ways that information technology can extend a business. Tom Parenty[*] describes them as extensions of time, scale, and locale.

Each of these extensions is built on a foundation of digital identity. Without a digital identity infrastructure to give bank executives the ability to trust that people using the ATMs are allowed to take authorized actions, ATMs would have never been deployed.

The other side of this relationship is equally instructive. Customers feel good about participating in transactions with the bank because of trust marks that they encounter before and during the experience: the big building, the brand of the bank, the FDIC sticker, and last but not least, the teller are all part of this. The first ATMs were installed in bank lobbies to keep much of that intact. Humans frequently helped customers through their initial fear of dealing with a machine, effectively transferring the trust that customers placed in the human teller to the digital identity infrastructure and computer systems that made up the ATM system. Nowadays, of course, ATMs appear in all kinds of settings, and most people trust the debit card and PIN to adequately protect their assets.

Just as ATMs changed the way banks do business, information technology, and especially the growth of the Internet, has fueled a multitude of opportunity for business to throw off the old restrictions of time, scale, and locale. Doing so, however, requires a better understanding of digital identity than ever before.

[*] Parenty, Thomas J. Digital Defense: What You Should Know About Protecting Your Company's Assets. Cambridge. Harvard Business School Press, 2003.

The Business Context of Identity

Like medieval city planners, IT professionals and others have traditionally thought of security as an edge game. Given a firewall and access control to the network, we can do a reasonable job securing a business. However, the economic shifts spoken of previously have driven the need to integrate systems not only internally, but with trading partners and customers as well. This trend is fueled by XML and the creation of standards for exchanging data and the increasing trend to decentralized computing that is embodied in service-oriented architectures (SOAs) and web services. But this trend has ramifications for business security: we can no longer treat the edges of the network as a secure perimeter.

When integration is driven by business, rather than IT needs, security policies need to talk about documents, data, actions, people, and corporations instead of machines and networks. This new security model is infinitely more complex than the old "secure perimeter" model. But even if you can define your identity strategy, how do you ensure that it is properly implemented across dozens or even hundreds of systems, and, at the same time, control access to fields of a database or paragraphs of a document?

Foundational Technologies for Digital Identity

Understanding how your organization can make use of digital identity requires understanding concepts such as trust and privacy. Moreover, digital identity is built on a set of technologies that includes cryptography, authentication, authorization, identity provisioning, directories, digital rights management, identity federation, and interoperability standards. Later chapters in this book will discuss these concepts and technologies in detail, and show how they fit into an overall identity management strategy.

Identity Management Architectures

The most difficult part of getting identity management right isn't technical. Management, policy, and even political issues are more likely to be the things that stand in the way of success. To that end, the final section of this book will describe a methodology for creating what I call an identity management architecture (IMA) that can help you overcome these challenges.

An IMA is unique to each organization. Creating an IMA for your organization requires a firm framework for governance and understanding the business context within which it will operate. To that end, the methodology in this book includes detailed ideas about how you can document, analyze and understand the business context that your identity infrastructure will have to support.

An IMA has three primary components:

Process Architecture

The process architecture is a methodology for determining how your business accomplishes identity related tasks now and how they should be accomplished in the future. The architecture is based on an identity infrastructure maturity model that lays out how processes can be changed to make them more effective in supporting the identity needs of the business.

Data Architecture

The data architecture is a model of the identity data in your organization. Recently, a number of news stories have highlighted organizations that lost control of identity data and were publicly embarrassed over the resulting privacy concerns. Getting a handle on where your identity data is and what processes affect it will help you avoid these problems and help you build an infrastructure that is responsive to business needs.

Technical Reference Architecture

The technical reference architecture is how the IMA communicates implementation guidance to system architects, the people who design the systems that use identity processes and data.

Later chapters in the book will discuss each of these components in detail and help you build processes in your organization to create them. Each of these components makes use of two other important parts of an IMA:

Policies

Policies are crucial in creating identity infrastructures that work for the simple reason that it's impossible to create technical solutions to every problem. Ultimately, the behavior of people in your organization will determine whether or not your identity infrastructure meets its operational goals.

Interoperability Framework

An interoperability framework is a list of standards that your organization has chosen to support and use. Making these decisions explicit is critical to building an identity infrastructure.

Some organizations believe that they can't be bothered to create policies and make standards decisions, but I hope that the chapters on these two important subjects will change your mind and show you how policies and standards can be liberating, rather than confining, for your business.

Digital identity is at the core of almost every modern business process. I'm confident that an IMA will help your organization, regardless of its size, use digital identity technologies to build an infrastructure that will pay dividends in every other area of your business.

Chapter 2. Defining Digital Identity

In 1974, the family therapist Salvador Minuchin declared that "The human experience of identity has two elements: a sense of belonging and a sense of being separate." This is as good a description of digital identity as it is our psychological identity. A digital identity contains data that uniquely describes a person or thing (called the subject or entity in the language of digital identity) but also contains information about the subject's relationships to other entities .

To see an example of this, consider the data record, stored somewhere in your state or country's computers, that represents your car. This record, commonly called a "title," contains a VIN (vehicle identification number) that uniquely identifies the car to which it belongs. In addition, it contains other attributes of the car such as year, make, model, and color. The title also contains relationships; most notably, the title relates the vehicle to a person who owns it. In many states, the title is also a historical document, because it identifies every owner of the car from the time it was made.

Digital identity management is about creating, managing, using, and eventually destroying records like the one that contains the title for your car. These records might identify a person, a car, a computer, a piece of land, or almost anything else. Sometimes these records are created simply for inventory purposes, but the more interesting ones are created with other purposes in mind: allowing or denying access to a building, authorizing the creation of a file, allowing the transfer of funds, and so on. The relationships between identities and the authorized actions associated with them make digital identities useful, though, at the same time, difficult to manage.

The Language of Digital Identity

The world of digital identity has its own nomenclature. Most of the terms are familiar but are used in specific ways. This section introduces some of that terminology.

A subject or entity is a person, organization, software program, machine, or other thing making a request to access a resource. A resource might be a web page, a piece of data in a database, or even a transaction on a credit card. To gain access to the resource, the subject lays claim to an identity. Throughout this book, we'll frequently use the word "subject" instead of "person" to remind us that non-human subjects such as machines or programs often use resources.

In this context, identities are collections of data about a subject that represent attributes, preferences , and traits . Attributes are acquired, describing information about a subject such as medical history, past purchasing behavior, bank balance, credit rating, dress size, age, and so on. Preferences represent desires such as preferred seating on an airline, favorite brand of hot dog, use of one encryption standard over another, preferred currency, and so on. Traits are like attributes, features of the subject, but they are inherent rather than acquired. Another way of thinking about the difference between attributes and traits is that the former may change, but traits change slowly, if at all. Examples of traits include blue eyes for a person, or how and where a company was incorporated. Since the distinction between attributes, preferences, and traits rarely makes a difference in the design of an identity infrastructure, we'll typically use attributes to mean all three unless there's a specific need to distinguish among them.

One of the primary purposes of an identity system is to authorize particular actions. This process is shown in Figure 2-1 and is broken down as follows:

To use an identity to justify accessing a resource, a subject must present credentials along with the request. Credentials are proof that a subject has the right to assert that a particular identity belongs to them. Credentials are a way of transferring trust between subjects.

When credentials are presented to a security authority or policy enforcement point (PEP), the authority authenticates the credentials, perhaps using a separate authentication server.

Credentials can be authenticated using many different methods, including a simple username and password, an X.509 certificate, or biometrics . The level of authentication required is usually proportional to the risk that attends accessing the resource.

Once the credentials are authenticated, the authority retrieves the security policy for the resource or passes them to a separate policy decision point (PDP) .

The PDP uses the policy and asserted identity to determine the entitlements and permissions associated with that resource for the asserted identity. Entitlements are the services and resources to which an identity is allowed access. Examples include a credit limit, disk space or bandwidth allocations, and so on. Permissions are the actions that the subject is allowed to perform with respect to the resource, such as withdrawing funds, completing a purchase, or updating a record.

When the PDP transfers this information back to the PEP, it does so in an authorization decision assertion (ADA).

Finally, the PEP either allows or denies the action.

Figure 2-1. The interaction between policy enforcement points and policy decision points

Identity Scenarios in the Physical World

The concepts and words used in the last section can seem intimidating, but in reality, most of these concepts are perfectly understandable given our everyday experience in commercial transactions in the physical world. To see how some of these ideas map to our everyday understanding, let's consider a common transaction at a convenience store: buying beer.

When a person (i.e., the subject or entity) wants to buy beer (i.e., perform an action on a resource), he is required to submit proof that he is of legal drinking age. The common way to do that is by presenting a driver's license. A driver's license is a credential that asserts that a person has certain attributes and traits. The license contains authorization to perform certain tasks, specifically to drive a car. The clerk (i.e., security authority) examines the license to see if it looks real (i.e., determines the validity of the credential) and uses the picture (i.e., embedded biometric device) to see if the person presenting the license is the same person who owns it (i.e., authenticates the credential). Once certain that the license is authentic, the clerk reads the birth date (i.e., an attribute) from the license and determines whether the person is over 21 (i.e., consults a security policy determined by the state and makes a policy decision about permissions associated with the identity for a particular resource).

Now, suppose the person pays with a credit card. The credit card (a separate identity credential) is presented to the clerk. The clerk just saw the driver's license and so can establish the validity of this credential based on the first. The clerk, acting as the policy enforcement point, runs the card through the point-of-sale terminal, which transmits identity attributes from the card (the cardholder's name, credit card number, and expiration date) along with the resource to be accessed (credit in the amount necessary to buy the beer) to the bank, which acts as the policy decision point and determines whether or not the subject is entitled to credit in the necessary amount. The clerk receives the credit authorization (authorization decision assertion) and completes the transaction.

In later chapters, we'll discuss these terms in detail and see how they apply in less-familiar scenarios.

Identity, Security, and Privacy

Digital identity is often thought of as a subtopic of computer or information security. Certainly, digital identity is an important part of security, but digital identity has greater utility than just protecting information. We've already discussed how digital identity enables important business relationships. At the same time, information security is about more than simply performing authorization and authentication. Firewalls, for example, provide security but is not necessarily about identity.

Still, the goal of information security is to protect information from unauthorized access, destruction, or alteration. Privacy is the protection of the attributes, preferences, and traits associated with an identity from being disseminated beyond the subject's needs in any particular transaction. In a circular manner, privacy is built upon a foundation of good information security, which is, in turn, dependent on a good digital identity infrastructure. This relationship is shown in Figure 2-2.

Figure 2-2. The identity, security, privacy triangle

We will discuss privacy in some detail in Chapter 4. Computer security, beyond the concepts that it has in common with identity, is beyond the scope of this book.

Digital Identity Perspectives

We usually speak of identity in the singular, but in fact, subjects have multiple identities. From our point of view, they tend to seem like different facets of our identity, but other entities have a specific view that corresponds to only a subset of those attributes. For example, my bank sees a set of attributes for me that correspond to my credit card numbers, account numbers, credit score, and so on. My employer sees a different subset that overlaps only in a few points such as name, social security number, and the one bank account I give my employer for depositing my paycheck.

My multiple identities are linked by me and little else. They represent different perspectives on who Phil Windley is and what attributes I possess. Most of these attributes are stored in various formats in myriad databases. In the State of Utah alone, there are over 250 different databases in which portions of my digital identity might be stored, depending on my interactions with the State. These multiple identities, or personas, as they are sometimes called, are tied together by a few common data elements that are used, imperfectly, as keys for accessing them: my name, my address, my social security number, and my birthday.

To make sense of all of this, Andre Durand, the founder and CEO of Ping Identity Corp. introduced the concept of "tiers of identity."[*] Figure 2-3 shows a schematic of these tiers. At the bottom is the first tier, labeled "My Identity." Tier 1 consists of attributes and traits that are associated with the subject and are both timeless and unconditional. For example, my name is Phillip John Windley, I have blue eyes, and so on.

Figure 2-3. Identity tiers and their relationship

Tier 2, labeled "Shared Identity," consists of the attributes that are assigned to us by others. These attributes are shared , because they are used to identify the individual but are temporarily issued based on some kind of relationship. Your wallet is filled with Tier 2 identities; your driver's license, your employee badge, your credit card, your health insurance card, and your library card are all examples of identity information that is assigned to you. Once the relationship that defines the identity is terminated, the attributes associated with it are no longer useful.

The topmost layer, labeled "Abstracted Identity" establishes the identity of groups. For example, I may be identified as a "Utahn," a "white male over 40," or as a member of any number of other demographic groups. Companies may classify me as a "frequent flier" or a "first time customer." All of these groupings identify me in some way, but only abstractly. Tier 3 is largely about marketing.

Tier 2 identity relationships usually happen with our consent and are mostly welcome because of the benefit we perceive. Tier 3 relationships are usually forced on us and most people resent them. For example, unsolicited commercial email (usually called "spam") is a Tier 3 identity issue. Telephone solicitations and even TV advertisements are Tier 3 identity issues as well. The problem with Tier 3 identity is that it is inaccurate and nonspecific. Consequently, Tier 3 identities rarely meet a real need. The benefit is so small as to be inconsequential, so most people perceive Tier 3-based relationships as bothersome.

[*] Durand, Andre. "Three Tiers of Identity." Digital ID World located at http://www.digitalidworld.com/modules.php?op=modload&name=News&file=article&sid=26.

Identity Powershifts

How your employees and customers perceive your efforts to build a digital identity infrastructure depends in part on being cognizant of people's inherent dislike of what we can now classify as Tier 3 relationships and sensitive to their desire that you give them real value in any Tier 2 relationships. The identity problems and potential faced by organizations—the very subject of this book—happen in Tier 2.

For the most part, Tier 2 relationships are dictated on the terms of the business or organization and consented to by the individual. This one-way relationship is likely to change over time as service-oriented businesses become more sophisticated. This powershift is brought on by increased service standards and improved systems that make it easier for customers to switch their allegiances. Also, businesses are beginning to offer more customized services, making it more likely that customers will begin to dictate some of the terms in their relationships. It will no longer be a "take-it-or-leave-it" world, but a world based on what some have called "mass customization."

One of the fallouts from this powershift is identity aggregation . As we've noted, individuals mentally aggregate their Tier 2 relationships much more than is possible in the real world. I don't tend to think of myself as a Key Bank customer; I think of myself in holistic terms, with Key Bank being just one of many relationships that I am party to. Federation and other means of aggregating identity, which we'll discuss in Chapter 12, are one answer to the identity silos created by the multiple Tier 2 relationships. I have completely separate relationships with my airline and my rental car company, and that creates extra work for me each time I travel. Getting back to value, I'm willing to have those identities aggregated if it makes booking travel more convenient.

Another fallout from this powershift is the convergence of Tier 3 and Tier 2 identities. As sophisticated identity systems allow companies to better identify individual customers and businesses adapt by providing more fine-grained service customization, the need to market to broad demographic groups is lessened. I'm not about to predict the disappearance of spam anytime soon, but it and other mass-market approaches are becoming less and less effective. Good businesses will recognize this shift and move their operations away from broadcast and mass marketing and towards more individual-specific marketing efforts.

Conclusion

I believe that over the next decade we will see brand new mechanisms spring up by which customers can telegraph their desires to businesses, and businesses will find new ways to meet those demands. As an example, not too long ago, I was at a conference and got an email from Doc Searls asking if anyone had a spare power adapter for a Powerbook. He'd forgotten his at home. This simple act was Doc signaling a need to the group he knew was at the conference and used Macs. Later that day, we discussed how it would be nice for Doc to be able to let local businesses know of his need as well, so that they could offer to solve his problem—for a fee, of course. At present, the only way to do this would be for Doc to actually look up local businesses and contact them one at a time. That needn't be the case in a world with good networks and better identity infrastructures. Doc calls this "demand informing supply." I like to think of it as the spontaneous fulfillment of desire.

Regardless of what you call it, business is more than just transactions. Business is about relationships—relationships with customers, employees, suppliers, and partners. These relationships—especially those with customers—have tended to be one-way and very impersonal. Digital identity changes that, and just in time, because customers are demanding better and more customized service wherever they happen to be and exactly when they want it.

Chapter 3. Trust

In the influential book Trust: The Social Virtues and the Creation of Prosperity, Francis Fukuyama argued that public values, especially trust, shape the direction of national economies. Among other things, Fukuyama shows how trust reduces transactions costs, and ultimately, economic friction. In a smaller way, being able to use a digital identity infrastructure to establish and capitalize on circles of trust within your organization, and between your organization and its partners and customers, may very well shape the direction of its success.

Trust is an important and yet tricky topic. Ultimately, every authorization made using a digital identity infrastructure is dependent on trusting that an identity and its attributes are correct. At the same time, trust is a concept that humans understand implicitly but have difficulty capturing algorithmically. Various mechanisms for establishing trust in identity credentials are available. This chapter introduces the notion of trust and the methods used to achieve it, but details of how those technologies are used to build trust are saved until later chapters.

In a digital identity infrastructure, trust occurs in a variety of places. Here are some examples of trust:

Trust that the identity credentials are held by the correct entity

Trust that the system I'm talking to is the one I want to talk to

Trust that my communication will be unaltered and private

Trust that the access control policy is implemented consistently throughout the enterprise

When we create a policy about digital identity and the actions available to holders of particular identity credentials, we're setting out a collection of objectives based on the circumstances of the transactions involved, the business requirements, the degree of risk that the business is willing to bear in those circumstances, and the cost the business is willing to pay to reduce the risk to an acceptable level. These objectives drive the level of trust and the amount of evidence we need to collect to attain it.

Circumstances of the transaction may vary greatly. On one end of the spectrum might be electronic transactions over secure lines wholly owned and operated by the company and on machines that are carefully maintained in secure facilities. At the other end are circumstances where such transactions occur over the Internet using machines that are owned by people who may be actively trying to take advantage of the organization.

Business requirements spell out what has to happen. Sometimes they may also spell out how it happens, as any supplier to Wal-Mart can attest. Business requirements spell out who we are dealing with and why. They also should make the end goal of the transaction clear and set forth the penalties for not achieving that goal.

Risk is something that is managed by the business either actively or passively. Some businesses and people are very risk averse. Others are more tolerant of risk, especially in light of the cost of reducing risk. Even so, our assumption is that most businesses want to reduce the risk attendant to electronic transactions, and understanding the appetite your organization has for risk is critical to building an effective digital identity infrastructure.

What Is Trust?

Trust is a firm belief in the veracity, good faith, and honesty of another party, with respect to a transaction that involves some risk. For example, when you give your credit card to the waiter at a restaurant, you are expressing trust that the waiter will use the credit card to process a transaction that will pay for your meal. You expect that that transaction will be the only one processed and that the waiter won't steal the credit card number for some other purpose. The only time I've ever had my credit card number stolen was in a restaurant, and yet I still blithely hand my credit card over to any waiter who comes along. There is clearly risk, but I take it because I'm convinced that the risk is small. Most of us don't consciously think about the risk of using a credit card to pay for a meal; we evaluate the risk intuitively based on a variety of factors including our previous experience, the way the restaurant looks, and, perhaps most importantly, beliefs about the credit card company indemnifying us beyond a certain point.

There's no doubt that trust is linked to risk when we consider who we're willing to trust with what. I may trust a particular person to fix my car, but not to baby-sit my children. Trust is based not just on the entities involved in the transaction, but also on their roles and the particulars of the transaction.

Trust is something I grant to or withhold from others—they cannot hold it for me. I can adjust it or revoke it completely, at any time. This leads to some important trust properties.

Trust is transitive only in very specific circumstances. For example, if Alice trusts Bob's taste in music and Bob trusted Carol to select songs for the last party, Alice may be willing to trust Carol to pick the songs for her party.

Trust cannot be shared. If Alice trusts Bob and Alice trusts Carol, it doesn't necessarily follow that Bob trusts Carol.

Trust is not symmetric. Just because you trust me, doesn't mean that I trust you.

Trustworthiness cannot be self-declared. This is so self-evident that the phrase "trust me" has become a cliché sure to get a laugh.

In the world of digital identity, trust is generally linked to a particular set of identity credentials and the attributes associated with them. I may have several email addresses, for example, and even though they all belong to me, people may see them in different contexts and trust a request contained in an email from my work address, for example, more than they do from my Gmail account.

Trust and Evidence

One day I went to the store to buy a disposable camera for my son to take to an activity. As I stood before the display rack, I pondered which of several choices I should buy. One bore the brand of a reputable company with a strong reputation in the world of photography. The other camera bore the house brand of the store I was at. The house-branded camera was $1 cheaper than the camera with the national brand. I bought the more expensive camera, even though they may have actually been manufactured in the same facility on the same day. Why? Because the brand was evidence that I could trust that the camera would work and the film would be good quality. The $1 extra that this evidence cost me seemed a reasonable trade-off to avoid the risk of missing the shots.

Just as in the physical world, trust in a digital identity is ultimately based on some set of evidence. For example, when you log into your computer, you present an identity in the form of a user ID and evidence that you are the person to whom that ID refers by typing in a password. The password is evidence that the computer should trust that you are who you say you are.

Sometimes the evidence for trust in a computer-based transaction is explicit and automatically collected as in our password example. At other times, the evidence is present but less visible than in physical situations. For example, when I conduct an electronic transaction at http://Amazon.com, their digital certificate presents evidence to my browser that I'm really dealing with http://Amazon.com and not an imposter just trying to steal my credit card number. While this happens automatically, few people pay much attention to the trust marks that the browser presents (such as the little padlock indicating a secure transaction) and fewer still ever ask to see the details that their browser hides from view. The recent increase in phishing scams, where criminals pose as a legitimate online business in order to steal identity information, is evidence of this.

Passwords, digital certificates, biometrics, and the like are all examples of evidence that can be presented to show authenticity for a particular set of digital identity credentials. Chapter 7 discusses the collection, use, and relative merits of the various types of credential evidence used with digital identities. Other systems for recording and measuring trust will be discussed at other locations.

One of the chief impediments to flexible digital identity infrastructures is that current methods of managing policy and trust are inflexible, slow, and costly. New requirements, such as federation of identities across corporate boundaries, exacerbate the problem. There is considerable work taking place on languages for expressing policy. We'll see an example of such a policy in Chapter 11. The ultimate goal of such policy languages is to create machine-readable policies that are consistent, adaptable, and function in heterogeneous environments. Current state of the art in policy management is still quite a ways from this ideal condition, so we will see in Chapter 18 how to use enterprise governance to create a process that makes up for some of the deficiencies of the technology in the area of policy management.

Trust and Risk

Trust can be difficult to quantify. Do I trust Alice more than Bob? Why? Unfortunately, when evaluating the effectiveness of identity policies, we need to be able to quantify the trustworthiness of a system, method, or technique. Fortunately, we don't ultimately have to measure our trust in a system or approach; rather, we can try to quantify the risk of a particular business process and balance that risk with the expected rewards or returns. Businesses have been analyzing risk for years.

Analyzed in this way, for each business process, we have to be able to give a measure of the risk that the digital identity infrastructure will fail to perform as required for that particular business process. To answer these questions, we need to have a detailed understanding of the systems and processes that make up the digital identity infrastructure, including detailed assessments of the required interactions with partners and their ability to perform as required. Further, we have to quantify the potential losses and their probabilities.

Often, for processes that have been in place for some time, we can use historical measurements to determine the expected level of risk. This assumes that the processes used to manage the digital identity infrastructure include system and outcome monitoring and tracking.

The level of detail available for these analyses will depend on the maturity of our identity infrastructure, a topic we will return to in Chapter 15.

One way to manage risk is with service level agreements, or SLAs. SLAs are nothing more than contracts that set expectations around what you are promising and what the consequences will be of failing to deliver. A complete discussion of SLAs and risk management is beyond the scope of this book, but should play a part in your digital identity strategy.

Reputation and Trust Communities

I just bought a cell phone cover on eBay from someone in Hong Kong. Normally, I'd consider an international purchase pretty risky. But eBay provides a means for me to gain trust in someone living in Hong Kong. The trust is based on feedback from other eBay users. Each time an eBay seller completes a transaction, the buyer can rate the seller on a number of different points. When I bought my cell phone cover, I was able to review the seller's history on eBay and determine that other buyers were happy with their interactions with this seller. In the same way, sellers can see a buyer's reputation to determine if the buyer is trustworthy and therefore likely to complete the transaction. eBay's feedback system creates a social network wherein reputation can flourish. This social network aggregates the reputations of eBay buyers and sellers into a community of trust.

In that way, eBay is like a village where trustworthiness is based on one's reputation. First-time sellers, like strangers in the village, have no reputation and are thus viewed with suspicion. Over time, this changes for better or worse depending on the actions of the person. On eBay, identities, rather than people, gain a reputation over time, and that reputation can be used to judge a particular buyer or seller.

eBay, of course, is not the only example of a system where this kind of trust community has developed. MSN Messenger, for example, serves as the infrastructure that supports a community for securities traders. Over the course of time, individual traders, identified by the MSN Messenger ID, build a reputation based on what they say and do.

Similarly, over time, people build up trust in the email addresses of people with whom they've interacted. Unfortunately, as we've seen, the lack of credible authentication for those identities makes them subject to exploitation by email worms and viruses.

Given that communities of trust are so important to trustworthy interactions, we might ask how they are constructed. As illustrated in Figure 3-1, a community of trust has five components:

Governance, which describes the operating rules, roles and responsibilities, and legal validity of the policy

People or other entities involved in the trust relationships

Processes for performing operations and transactions

Technology tools, including software and hardware

A viable economic model

Let's look at how each component plays a part on eBay. First of all, eBay has established a set of rules and policies about how sellers and buyers should act and what they can and can't find out about each other. Buyers and sellers are represented by digital identities that are protected by an authentication system. There is a process

Figure 3-1. Communities of trust are supported by five components

for establishing feedback, and this process is embodied in the feedback tools that are part of the eBay site. Finally, the economics of this trust community are simple: the sellers pay for any costs needed to maintain the system out of their commissions. Moreover, the buyers and sellers carry the risk of the transaction, not eBay, which cuts the cost dramatically.

In contrast, Public Key Infrastructures, which will be discussed in detail in Chapter 6, is an example of a technology that has failed to develop a widespread community of trust, at least among individual users. Its true that many have struggled with the technology and tools—current tools are too complex—but more importantly, the economics of widely issuing digital certificates has been a hurdle. A large part of the cost comes from that fact that certificate authorities are legally certifying that the holders of the certificates are who they say they are. This means that they are liable and carry at least a portion of the risk. Certificate authorities have to charge money to cover this potential liability.

Conclusion

We can create digital identities all day long, but they are worthless without authority. As we've seen, authority is established on the basis of trust, but trust is hard to measure. In building digital identity infrastructures, remember that you're attempting to establish a community of trust, even if trust is never mentioned.

Chapter 4. Privacy and Identity

Several years ago, General Motors set out to create a company-wide telephone directory. Of course, in the 21st century you don't create a printed phone directory for a company as large as GM; you create an online directory. Two years and numerous legal hurdles later, GM had an online phone directory. This tale is amazing, given that GM wasn't trying to do anything particularly difficult, like aggregate identity pools or implement single sign-on company wide. They were simply creating a phone directory; something companies have been doing for a hundred years.

GM's hang-up was not the technology, but rather the legal challenges presented by differing privacy laws and regulations in each of the many countries where GM has employees. European privacy laws are much stricter than those in the United States. Privacy turned a seemingly simple project into a two-year ordeal.

More and more corporations and government agencies are appointing Chief Privacy Officers, high-level officials whose job is to ensure that identity data is protected. The reason is simple: privacy is a big deal. People believe that their identity data should be private. They don't necessarily believe that everyone else's data should be private, but they want to protect their own identities.

Who's Afraid of RFID?

RFID stands for "radio frequency identification device." RFID tags are small integrated circuits that broadcast an identifying code whenever they're hit with radio frequency radiation. The circuit uses the radiation to charge a small capacitor that gives the tag just enough energy to broadcast the identifying code. RFID tags have been used to automate the collection of tolls or access to parking garages.

One of the really interesting uses of RFID tags is to identify things. This has generated significant interest in the retail industry. Imagine if the barcodes on the groceries you buy could talk. Rather than having to scan the items one at a time, the RFID reader could ask all the items in the grocery cart to identify themselves and total up the purchase all at once. An RFID reader in a refrigerator could keep track of what's in the fridge and build your grocery list for you. Smart shirts could tell your dryer how high to set the temperature.

Against this backdrop of a consumer Utopia is an Orwellian nightmare of massive intrusions into individual privacy. Who else gets the data from your grocery purchase? When you wear your Gap shirt into Eddie Bauer, do they scan it to know what kinds of clothing to offer you? In general, who else can scan the tags in the things you own?

This debate has created lots of heat over the last few years. Gillette planned a pilot with RFID-enabled shelf displays that would automatically send restocking alerts to the company when a display ran low. They were forced to abandon the pilot because of concerns by privacy advocates. Wal-Mart has led a push for RFID in retail, but so far has limited the roll-out to pallet-level packaging in the supply chain. Part of this is pragmatic: RFID tags are not yet cheap enough to put on everything.

The debate over RFID and privacy highlights a crucial aspect of privacy. People are scared of the theoretical threats to their privacy—especially in technologies they don't understand. At the theoretical stage, privacy advocates are very effective at using this ignorance as a backdrop for painting draconian pictures.

Privacy Pragmatism

The debate over RFID illustrates the great irony of privacy. As someone who's been involved in online commerce and services for over a decade, I've found that while everyone cares about privacy in the abstract, they're usually willing to trade their personal data for the most trivial of benefits. A cynic would say that this is because people don't really understand digital identity and how their privacy can be eroded, but I think that most people make rational choices. People willingly choose to share personal data if there is a payoff that they understand.

Here's an example: if you've been to a grocery store, you're familiar with their "preferred customer" cards. The premise is simple: scan the card, get a discount. Groceries stores do this, of course, so that they can tie customer identities to purchasing habits—very valuable data for a company looking to drive sales and establish loyalty. Even the most hardened privacy warriors are likely to succumb to a large rebate offer on a TV or a computer and send in the rebate form in order to capture the savings.

While the U.S. has its share of privacy advocates, it has been slow to adopt many of the privacy safeguards that have found a home in Europe and elsewhere (the next section will explore the exceptions). The hesitancy has been partly based on free speech concerns, but often, it is because U.S. legislatures are loath to take action that will have negative impact on business development. Again, the cynic would say that business has bought off the legislative process, but from my experience, both in the private and public sectors, the reason has more to do with legislative concern about regulatory burdens making U.S. industry less competitive.

Even with the pragmatic attitudes of consumers and the business-friendly climate promoted by many legislatures, your organization should be very careful in handling the personal data of employees and customers and the private information of partners and suppliers. While it's true that customers are usually willing to trade identity information for some benefit, they react with anger when they feel like they've had their identity data "stolen." Likewise, legislatures sometimes react with ill-conceived legislation when pressed by anecdotes regarding identity theft, fraud, and misbehaving companies.

Privacy Drivers

Even with the relatively pragmatic attitude of most U.S. consumers regarding privacy, there are still many significant laws and regulations affecting organizations. Table 4-1 shows some of the more prominent laws and regulation concerning privacy. In the U.S. and Canada, those laws tend to be limited to specific kinds of organizations (e.g., health care and financial services), but the European Union directive (the one that tripped up GM in its efforts to build an employee phone directory) is extremely far reaching.

Table 4-1. Some privacy laws and regulations

Law/regulation

Description

Canadian Personal Information Protections and Electronic Documents Act

Applies to employees of firms regulated by the federal government. Recognizes an employee's right to privacy and imposes principles that employers must follow with respect to the personal data of their employees.

Customer Identification Program (Patriot Act)

Applies to financial services organizations in the U.S. Requires the collection and storage of customer data and its verification against government-owned lists of known or suspected terrorists.

European Data Protection Directive

Applies to organizations operating in the European Union. Imposes wide-ranging obligations regarding the collection, storage, and use of personal information relating to employees and customers.

Health Information Portability and Accountability Act (HIPAA)

Applies to any organization that manages health care data in the U.S. Establishes a patient's right to control access and use of personal health information (PHI). Requires that organizations control and safeguard PHI. Imposes technical standards for access control, audit, data integrity, and security.

Gramm-Leach-Bliley Act

Applies to financial services organizations in the U.S. Requires physical, administrative, and technical measures to protect customer data. Data can be reused or disclosed only with the specific opt-in of the customer.

The laws listed in Table 4-1 can have a direct impact on your identity management plans. There are other laws and regulations that can indirectly affect the identity management efforts of your organization. For example, NASD Rules 3010 and 3110 and SEC Rule 17a-4 require securities brokers and dealers to retain records for certain periods of time. This clearly affects the design and implementation of a digital identity infrastructure in affected industries.

Another law with indirect effects is Sarbanes-Oxley . Sarbanes-Oxley applies to public companies and, among other things, requires annual reports on the effectiveness of internal controls and procedures. Identity management issues like directories and access control have a direct impact on internal controls and procedures. Consequently, public companies need to design and implement their digital identity infrastructure to not only comply with Sarbanes-Oxley requirements, but to minimize that cost where possible.

In addition to national laws, in the U.S. at least, many state and local governments have adopted various laws and regulations that you may be obligated to obey. These can be especially troublesome, because your organization may operate in multiple jurisdictions, each with widely different expectations.

Determining what laws and regulations affect your identity management strategy and what to do about them is impossible if you attempt to manage identity like most IT departments have traditionally managed security. The issues are business issues and require business input. As an example, consider Sarbanes-Oxley. The Audit Committee of your board of directors will determine the ground rules for how your company is going to comply with Sarbanes-Oxley. Not understanding their directives and ensuring that they're met would be a career-limiting act.

We'll spend the final part of this book discussing how you can develop an identity management architecture that ensures business drivers are used to shape your digital identity infrastructure.

Privacy Audits

Chief Privacy Officers and others concerned with privacy in an organization worry about what they don't know. It's not the data you know about that will get you in trouble. In Chapter 16, we'll discuss resource mapping and specifically talk about how to create inventories of the data in your organization. Having these data maps is the first step to being able to perform privacy audits . Here are some of the privacy-related questions you might ask about the identity data in your organization:

What kinds of identity data are you collecting?

How is this identity data collected?

Why was the identity data collected?

Were special conditions on its use established at any time?

Who is the data owner?

Who is the custodian?

Who uses the data, why, and how do they usually access it (i.e., remotely, via the Web, from home)?

Where is it stored?

Is any of the data stored on devices that are routinely transported off-site such as a laptop or PDA?

Are there backups? If so, you need to answer these same questions about the backups.

Are there access logs for the data?

Where are the logs stored?

Are the logs protected?

What other security measures (firewalls, intrusion detection systems, and so on) are used to protect the data?

Conducting privacy audits and collecting all of this information may seem like a lot of work, but ask yourself what it means if you don't know the answers to these questions. There's good news and bad news. The good news is that data maps are useful for more than just privacy, so you can balance the cost and effort with other benefits. The bad news is that it's hard to get anyone very excited about data. Applications are the stars of the IT world. In Chapter 16, we'll cover a strategy for moving your organization toward having a better understanding of what data it owns and getting answers to the preceding list of questions.

Privacy Policy Capitalism

When we view the exchange of identity information through the lens of a transaction where the customer perceives some benefit and thus parts with bits of identifying information in consideration for that benefit, privacy policies take on a new feel. Many companies view their privacy policy as something they have to do to keep their customers from being angry with them, because their industry demands it, or because someone convinced the CEO or CIO that she'd be liable if the company didn't have one. All of these may be true statements, but they're only ancillary to the real reason for a privacy policy: your privacy policy represents the terms of service you're offering for whatever benefit the customer perceives.

For example, say you're an online merchant. You collect identity information from your customers at various stages of the transactions, and the customer receives some benefit. At the most basic level, whenever a customer visits, you install a cookie on his browser so that your shopping cart works. Cookies are a way of maintaining program state across HTTP, an otherwise stateless protocol. In addition to making the shopping cart work, you realize that you can use the cookie to recognize the customer the next time he returns and even to track his shopping habits. When the customer buys something, you collect personal information, such as his name, address, and credit card number, and can link that to the cookie as you create a customer profile.

What should this online merchant's privacy policy say? First, tell the truth. Tell customers what data you collect, why you collect it, and what you do with it. Be specific. In this example, the merchant might say, in part:

We use cookies. Our shopping cart will not work without them.

When you make a purchase, your personal information is stored in our system only if you give us permission by clicking the "Save my information" box on the checkout form. When you do this, we can serve you better by automatically filling out some forms for you when you shop.

We use cookies to track the shopping habits of our customers. This data is used to make our search tool better and to help us offer a better product selection. The shopping habits of our customers may be released to partners and suppliers in aggregate, but your individual shopping habits will be released to a third party only with your specific permission, obtained in advance.

Advertisements appearing on our system may make use of third-party ad response tracking systems that use cookies to track ad click-through and to target those ads to specific customers.

A real privacy policy would be longer, and your lawyers will probably want to fill it with lots of other information. While it's a good idea to involve lawyers in the process, since it's ultimately a term sheet between you and your customers, make sure that the privacy policy is readable and understandable by your customers, or it won't do what you need it to do: inform them in clear language the terms of the bargain that you're proposing.

If you approach your privacy policy as a term sheet, with a clear understanding of what each side is giving and getting in the relationship, you and your customers will be happier with the result.

Anonymity and Pseudonymity

One of the questions that your business should understand clearly is what level of identity is needed for which relationships. For many purposes, you need specific, authenticated, and detailed identity information from your partners, suppliers, and employees. You may be able to provide service to customers, however, as they remain anonymous or at least pseudonymous.

True anonymity is not realistic for most online services, since they probably have to at least maintain some kind of user state and that requires telling which individual HTTP requests are related. Consequently, the user is not anonymous, because you can distinguish between different users. This leads to the concept of pseudonymity .

In a pseudonymous system, users are uniquely identified, but other identifying information is not shared. Pseudonymous systems give subjects a unique ID with which attributes, rights, and privileges can be associated. Pseudonymity is a term usually reserved for people, since the unique ID and its associated attributes, rights, and privileges constitute an identity as we've defined it. Pseudonymity implies that this identity cannot be tied to other identities that the subject might have without the subject divulging the connection.

Businesses should ask, "What identifying information is required?" early in the design process for an online service. I say "businesses" because this is almost always a business decision, not a technology decision. In keeping with our concept of the privacy policy being a term sheet for an identity transaction, each piece of the customer's identity that is being requested should also be associated with the need for the data as well as the benefit that the customer will receive by giving the data.

This rule is not followed as often as it should be. You've probably been to web forms that ask you for more data than you think the company needs to provide the service. You probably resented it. Adding insult to injury, it's likely that the company collecting the data never made any use of it whatsoever, whether for your benefit or not. Collecting unnecessary data alienates customers and clutters forms, so don't do it.

Privacy Principles

You might be asking, what principles can I use to make sure I'm acting in good faith with respect to the personally identifying data of my employees, customers, and partners? The Canadian Personal Information Protections and Electronic Documents Act described in Table 4-1 contains 10 principles that, if modified slightly, can serve as a guide:

Accountability

Your organization is responsible for the personal information under its control and must designate someone who is accountable for complying with these principles.

Identifying purposes

Any project must specify why it is collecting personal information at or before the time it does so.

Consent

The subject's consent is required for the collection, use, or disclosure of personal information. Exceptions should be documented.

Limiting collection

Projects may collect only the personal information that's necessary for the purpose they've identified, and must collect it by fair and lawful means.

Limiting use, disclosure, and retention

Unless a project has the consent of the subject, or is legally required to do otherwise, projects may use or disclose personal information only for the purposes for which they collected it, and they may retain it only as long as necessary for those purposes.

Accuracy

The subject's personal information must be accurate, complete, and up to date.

Safeguards

Security safeguards must be employed to protect personal information.

Openness

The project must make its personal information policies and practices known to people from whom they collect information.

Individual access

Subjects must be able to access personal information about them, and be able to challenge the accuracy and completeness of it. Exceptions should be documented.

Challenging compliance

Subjects must be able to present a challenge about the project's compliance with the privacy policy to the person that the organization has designated as accountable.

Even though these principles are not the law in the U.S., or even for most industries in Canada, they provide good guidance for how an organization can protect personally identifying information and be fair about the information they collect. If your organization ignores any of these principles, you should ensure that it does so by choice rather than accident and that the risks are thoroughly explored.

Prerequisites

As we've seen, understanding the privacy concerns of employees, customers, and so on is an important part of creating a working digital identity infrastructure. In commercial transactions, people must also believe that your organization is capable of keeping its promise. The perceived credibility and technical competence of your organization will determine whether the promises in your privacy policy are believed.

Even big companies run afoul of this. Microsoft, for example, largely abandoned its plans for Microsoft Passport, because users didn't believe that Microsoft would do what it said it was going to do. eBay and Yahoo! have drawn fire over the years for changing their privacy policies. When your customers don't believe your privacy policy, they become cynical and see everything in it as an attempt to create a loophole that will allow their personal data to be sold or given away.

Conclusion

Customers have unrealistic expectations about privacy; get over it. In many cases, the data they claim belongs to them is actually data regarding a transaction that you were both party to and in fact is mutually owned. Nevertheless, it pays to pay attention to privacy. Mitigating customer expectations about privacy requires being clear about what data is being collected and why. Providing unmistakable value for the data collected will usually resolve customer privacy concerns.

Chapter 5. The Digital Identity Lifecycle

When I was in grade school, our class captured a caterpillar and placed it in a jar with some leaves to see what would happen. Of course, in time, the caterpillar spun a cocoon and the little jar became pretty boring. But our teacher encouraged us to keep watching, and one morning, we were thrilled to see a large moth in the bottle. This simple experiment clearly illustrated to me that the moth and the caterpillar were the same creature at different stages of its life.

Scientists use lifecycles to connect the seemingly unconnected. I'm a big fan of lifecycles in analyzing information technology problems for the same reason. Lifecycles help define all of the phases of a problem or project so that they can be dealt with holistically rather than piecemeal. In addition, lifecycles are useful for categorizing activities associated with the process.

Digital identities have lifecycles, as shown in Figure 5-1. The digital identity lifecycle is applicable regardless of whether we're discussing a complex identity system for a large business or the accounts on a home computer. Understanding how the digital identity lifecycle plays out on every system in the enterprise, and in the enterprise as a whole, is crucial when creating a digital identity management strategy.

Figure 5-1. Digital identity management lifecycle

Briefly, a digital identity starts out by being provisioned, or created. Once created, the digital identity is propagated to any systems that will use it. Once propagated, the identity is used. Occasionally, some kind of maintenance will be performed on the identity, such as a password change or an attribute addition, and it is repropagated. At some point, the digital identity has served its purpose and is no longer needed and it is deprovisioned, or destroyed. We discuss each phase in more detail below.

Provisioning

Provisioning is the process of preparing an IT system to provide service to a client, customer, or other user. From the perspective of digital identity, provisioning is the creation of the identity record and its population with the correct attributes. These attributes might be standard items, such as name, location, email, and phone, as well as items more specific to the system. For example, the identity system that feeds the custom page presentation system for My Yahoo! contains attributes such as page color, positioning, and so on.

Provisioning can be done through the action of an administrator, or it can be self-service, occurring as a result of user actions. When a new employee joins a company, administrators, usually on multiple systems, provision identities for that employee so that she can be assigned an office, get on the payroll, get a computer, get a badge, become part of the health plan, and so on. One of the trends in enterprise computing has been termed "zero-day start," meaning that the enterprise links all of these systems so that when a new employee starts, all of the systems, permissions, and infrastructure are set up and ready, allowing the employee to start work the first day and have access to all of the resources, physical and virtual, that she needs to be productive.

We're all familiar with self-service provisioning—we see it every day on the Web as we visit web sites and sign up for services, both paid and free. For example, I've had a virtual server account with Verio for six years, and I've never talked to a human. I signed up online, and I manage the account entirely online. Self-service provisioning is a hallmark of the Internet age and perfect for services that are delivered over the network. Self-service provisioning works well where there is little need to verify credentials other than perhaps a credit card.

Propagating

Depending on the nature of the system on which the identity is created, the identity record may need to be propagated to other systems as part of its lifecycle. For simple systems, the propagation is as simple as writing the identity information to the filesystem or storing it in a local database. More complex systems may provide some sort of shared identity directory where the identity created in one place is used by multiple systems. In Chapter 9, we'll discuss metadirectories and virtual directories, which allow multiple directory systems to be linked together.

When I was CTO of iMall, we built a large e-commerce system that allowed small merchants to sign up for an account and then create a full-service online store. The system had a self-service account management system that allowed merchants to provision an account. Once the account was created, the identity information was propagated so that the system could create directories and files on numerous systems, add records to databases on other systems, and even establish a merchant banking account through an outside partner. This propagation of identity information was critical to the overall functioning of the system.

Propagation must occur after each change to the identity records, and the propagation must happen reliably. Because not all of the systems interfacing with the identity infrastructure support the notion of transactions (atomicity across multiple independent actions), this can be a challenge. To see why, consider the example I gave in the last paragraph. Suppose you create an account and the system creates files and database records, only to discover that the customer's payment has been declined. The system is in a state of partial completion, and backing out to a clean state is often nontrivial. The more actions involved in a single propagation, the more difficult this problem becomes. For such systems, the only alternative is to carefully think through compensating actions and when they should be applied.

Using

The use phase is probably the most obvious of all the phases in the lifecycle. Once the identity has been provisioned and propagated, the identity is used by various systems and agents. This might be as simple as consulting the identity to authenticate and authorize user actions against resources, or it could include more complicated actions, such as billing or payroll.

Maintaining

Regardless of the nature of the identity, the attributes will change from time to time, either because the base attributes of the entity change (e.g., a new home address) or because roles and assignments change. Often, to support new business opportunities, the schema of the identity record may need to be changed to add new fields to or include entirely new systems.

We've seen that identities are often about things other than people. In these cases, it's possible that the entire entity referred to by the identity is changed. As an example, consider upgrading the departmental laser printer. The name and IP number for the printer may be the only attributes that remain the same. This same phenomenon occurs when people occupy positions with strong role-based identity (e.g., the on-call duty officer).

All of these actions result in changes to the identity that, after completion, must be repropagated to the affected systems.

Maintenance of identities is one of the most costly activities that an IT help desk deals with day to day. Users frequently lose or forget passwords to systems. They change roles or move. The more things users can do on their own, the more money the company can save in maintenance calls to the help desk. Password reset has become of one of the driving forces behind enterprise identity management systems for this very reason. Often, an identity management project can be justified on the basis of savings from building a self-service password system alone.

Deprovisioning

Just as important as the notion of provisioning is the idea of deprovisioning : removing identities from the system once they are at the end of their lifecycle. One employee of a company whose identity systems have won some acclaim told me that the company's sophisticated identity management system had ensured he was ready to start work the same day he started. Ironically, two years after he quit, his voicemail still functioned. This company was doing a good job of provisioning, but had fallen down on the deprovisioning task. Leaving a voicemail account active may not be such a big deal, but leaving an employee with access to a sensitive system could be catastrophic.

Failure to properly deprovision an identity can lead to confusion, access to critical data by outsiders, and even fraud or theft. Old accounts, left active long after an employee is gone, are to blame for one of the largest security holes faced by many companies. These are dangerous for two reasons. First, the employee may continue to use company resources after she's quit. More often, however, these accounts represent prime places for hackers to crack into corporate systems, because they are unmonitored and strange activity won't raise any eyebrows.

Conclusion

Planning for each phase of the identity management lifecycle is critical to designing your identity management architecture and building a digital identity infrastructure. This planning can't simply be done at the abstract level, but must extend to each subsystem that the enterprise operates. For example, the customer relationship management (CRM) system and the enterprise resource planning (ERP) systems have different sets of identities and have their own unique needs in each stage of the lifecycle. Later, we'll discuss identity management architectures in some detail and see how an identity management architecture helps define the business context so that these different identity requirements can work together.

Chapter 6. Integrity, Non-Repudiation, and Confidentiality

Among the foundational concepts in digital identity are message integrity, non-repudiation, and confidentiality. Integrity ensures a message or transaction has not been tampered with. Non-repudiation provides evidence for the existence of a message or transaction and ensures its contents cannot be disputed once sent. Confidentiality ensures that only the people or processes authorized to view and use the contents of a message or transaction have access to those contents. In some situations, these properties are unneeded luxuries, but in others, the lack of one of these properties can lead to disaster. Understanding them, and when to use them, is crucial to a digital identity management strategy.

Integrity

Integrity is a fundamental requirement of a trustworthy identity infrastructure. Identity systems exchange credentials as well as messages and transactions regarding attributes, provisioning information, and other data. Trusting that the contents have not been tampered with is important. As an example, consider a document representing identity credentials. To trust those credentials, we must be able to verify they are authentic and have not been changed.

Non-Repudiation

Non-repudiation is the presentation of unforgeable evidence that a message was sent or received. If messages or transactions can be disputed, then important identity actions can be challenged and jeopardized. These disputes can take two forms. Consider two people, Alice and Bob, who are exchanging messages. In one case, Alice denies sending a message to Bob that he claims to have received. Being able to counter Alice's denial is called Non-Repudiation of Origin (NRO). In the second case, Alice claims to have sent Bob a message that he denies having received. Offering evidence to counter Bob's claim is called Non-Repudiation of Receipt (NRR).

Confidentiality

Confidentiality can be achieved in several ways. The two most common are steganography and encryption . Steganography is the process of putting a message inside another message in such a way that observers do not know that its there. For example, modifying the low-order bits in an image to transmit a message does not interfere with viewing the image, and the presence of the message is difficult to detect. While steganography has some interesting uses, it cannot serve as the basis for confidentiality in an enterprise identity system.

Encryption is the process of transforming a message using a key so that anyone viewing the message without the key cannot determine its contents. Cryptography is the basis for the technologies, such as digital certificates, that provide properties like integrity non-repudiation and confidentiality. While digital certifications and cryptographic issues are by no means the answer to the problems of identity in and of themselves, they are an important tool for solving some critical identity problems. Understanding digital identity requires at least a passing understanding of the technology, processes, and politics surrounding cryptography and digital certificates.

Cryptography

Cryptography is the science of making the cost of discovery of hidden information greater than the value of the information itself. An important corollary to this statement is that there is no single cryptographic solution to every problem. With increasing needs for confidentiality, the methods become more involved and the costs increase.

This single idea is perhaps the most important thing you can know about cryptography. Many people mistakenly think that cryptography is about absolute protection of data and are consequently upset to learn that someone has cracked a trusted cryptographic algorithm. While such news is certainly worth paying attention to, even easily compromised algorithms have uses in certain circumstances. The goal is to understand the needs and match those to the method that solves them for the least cost.

Secret keys

Secret key encryption uses keys to transform a message in such a way so as to render it unreadable to anyone without the proper key. Secret key cryptography is also known as symmetric cryptography (since the same key is used to encrypt and decrypt the message) or conventional cryptography .

Figure 6-1 shows a simple secret key transaction. Alice and Bob wish to share a message without divulging its contents to outside parties. Alice uses her secret key to put the plaintext message through a process that transforms it into an encrypted message. Alice can send the message to Bob without fear that an outsider will be able to read it, as long as the eavesdropper does not possess the secret key. Later Bob puts the encrypted message through another process, using the same key, to recreate the plaintext message.

Figure 6-1. Encryption and decryption using a secret key

One of the most important factors affecting the strength of a secret key encryption process is the length of the key. There are a significant number of secret key algorithms that differ in their key length, their efficiency for encryption and decryption, and their vulnerability to attack. Table 6-1 shows some common secret key algorithms and their key lengths. For most identity problems, the selection of a secret key algorithm is independent of other concerns, and consequently, they can be selected based on the requirements of the specific task at hand.

Table 6-1. Secret key algorithms

Algorithm name

Key length (bits)

Blowfish

Variable, up to 448

DES

56

IDEA

128

RC2

Variable from 1 to 2048

RC4

Variable from 1 to 2048

RC5

Variable from 1 to 2048

Triple DES

56

This process depicted in Figure 6-1 relies on Alice and Bob having agreed ahead of time on the secret key. One of them could choose the key and then transmit it to the other party using some other form of communication, or they could meet together to choose or exchange the key. The problem with both of these methods is that in both cases, an attacker has the opportunity to steal the key. Once the key is compromised, an attacker can decrypt and read any message encrypted with it.

To make matters worse, common attacks against cipher systems involve collecting large amounts of ciphertext that has been encrypted using the same key. To combat this attack, keys must be changed often, making key exchanges a frequent affair. The next section will discuss a concept that solves this problem.

Public key cryptography

The dilemma facing Alice and Bob is how to exchange keys. This is a big enough problem when just Alice and Bob are exchanging keys. Imagine the problems you'd have if you wanted to exchange encrypted messages with all the people in your organization and each subgroup. For example, if the development group wants to exchange messages in private, they need a key known to all of them that is different than any of the keys they use to exchange mail with each other. The management complexity of such a scheme is staggering. Fortunately, there's a cryptographic technology that does away with the need to exchange, store, and use secret keys, called public-key cryptography .

Public-key cryptography makes use of two distinct keys, called the public key and the private key. The private key is kept secret by its owner and is never divulged. The public key can be freely shared with other parties. The public and private keys are mathematically related to each other and are called a key pair. The mathematical relationship that the keys share enables a message encrypted with one to be decrypted by the other. Yet, neither key can be used to decrypt what it has encrypted. Thus, a message that is encrypted with the public key can be decrypted only by using its corresponding private key, and a message that is encrypted with the private key can be decrypted only by using its corresponding public key. Because of this property, public-key cryptosystems are sometimes called asymmetric.

Figure 6-2 shows how Alice and Bob might use public-key cryptography to exchange a message. Because Bob's public key can be freely shared, he has posted it on his web site. Alice downloads Bob's public key and uses it to encrypt her message. She then sends the encrypted message to Bob. Bob uses his private key to decrypt Alice's message. Only Bob's private key, which he has kept secret, can decrypt messages encrypted with his public key, thus ensuring that Alice's message has been kept confidential.

Figure 6-2. Public-key cryptography

Now, suppose that instead of encrypting her message with Bob's public key, Alice uses her private key to encrypt the message. Alice sends the encrypted message to Bob and Bob uses Alice's public key, which he can get from her web site or in some other way, to decrypt her message and read it. Of course everyone else also has Alice's public key. So Alice cannot use her private key to send confidential messages to Bob. To send a confidential message to Bob, Alice uses Bob's public key to encrypt the message.

Encrypting something with a private key is, however, useful for two other important properties we need: integrity and non-repudiation. As long as Alice has kept her private key secret, anyone using Alice's public key to decrypt her message knows two things:

The message has not been tampered with in transit.

The message is truly from Alice.

If the message has been changed, then Alice's public key will no longer decrypt it. If the message is encrypted with any key other than Alice's private key, her public key will not decrypt it. To impersonate Alice, Charlie must have access to her private key.

Using a private key to encrypt a message creates a digital signature. Using a public key to decrypt a message that has been encrypted with a private key is called signature verification .

A key system is called reversible if a private key can decrypt messages encrypted with its associated public key and a public key can decrypt message encrypted with its associated private key. Key systems where the private key can encrypt but cannot decrypt and the public key can decrypt but cannot encrypt are called irreversible. Reversible key systems can be used for confidentiality, integrity, and non-repudiation. Irreversible key systems can be used only for integrity and non-repudiation.

Hybrid key systems

Public-key cryptosystems are significantly more expensive from a computational standpoint than secret key algorithms. Public-key cryptosystems can take 100 to 1,000 times longer than secret key systems to encrypt or decrypt the same message. Consequently, public-key cryptosystems are rarely used to encrypt large amounts of data. Rather, they are used to negotiate a secret key between the parties in the initial phase of communication. This kind of cryptosystem is called a hybrid cryptosystem.

Key exchange algorithms allow two parties that know each other's public keys to calculate a secret key using one party's private key and the other's public key. In our example, Alice and Bob have exchanged public keys. They also exchange a large prime number and another number smaller than the prime called the generator. Alice uses her private key, Bob's public key, the prime number, and the generator to create a secret key. This process is commutative, and so when Bob uses his private key, Alice's public key, the prime, and the generator, he calculates the same secret key that Alice did. Charlie can know both public keys, the prime, and the generator, and still not be able to calculate the shared secret, because he doesn't have access to either private key.

Of course, if Charlie can somehow insert himself into the middle of the key exchange so that both Bob and Alice end up with his public key while thinking they've got the correct one, he can impersonate Bob to Alice and set up a shared secret with her and impersonate Alice to Bob and set up a shared secret with him. Afterward, he can sit in the middle of the conversation, reading the communication and forwarding the packets onto the other party. When Alice sends a message, it goes to Charlie who decrypts it, reads it, reencrypts it with the shared secret he negotiated with Bob, and sends it on. This kind of attack points out the need for trustworthy key exchanges, a topic we'll visit later in this chapter when we talk about digital certificates.

The most commonly used hybrid key system is transport layer security (TLS ), most widely known as SSL (Secure Sockets Layer). SSL is the technology used to create secure web communications.

SSL creates an encrypted channel between two applications. An encrypted channel automatically encrypts all of the data being sent on the wire without any action by the user. SSL uses the public-key cryptosystem to negotiate a shared secret that is used to encrypt the communications. A different shared secret is negotiated for each session. Because SSL requires only one of the parties to have a key pair, the algorithm for negotiating the shared secret is different than that outlined above. SSL sits below the application protocol and thus can be used to secure HTTP communications, email transport, or any other application protocol on the Internet.

Public key cryptosystem algorithms

There are a number public-key cryptosystems . Table 6-2 lists four of the common public-key cryptosystem algorithms, their types, and how they can be used. The choice of which algorithm to use depends on the particular task, the level of security needed for the task, relative efficiencies, and so on. Public-key cryptography schemes can be subject to non-obvious attacks that render them transparent, so it is best to employ a cryptographic expert when choosing which algorithm or scheme to use for any particular task.

Table 6-2. Public key algorithms

Algorithm

Type

Usage

DSA

Irreversible

Digital signatures

El Gamal

Irreversible

Digital signatures

RSA

Reversible

Confidentiality, digital signatures, key exchange

Diffie-Helmen

Reversible

Key exchange

Message Digests and Hashes

Sometimes it is enough to be able to determine when a document or message has been changed, either maliciously or not, without suffering the computational overhead of encryption. A mathematical technique called a message digest (also called a hash) can be used to show integrity in such cases.

A message digest is a fixed-length string of bits that is produced from a variable-length message through a special mathematical transformation that has three important properties:

Irreversible

Feeding the message digest into another transformation should not be able to produce the original document. This is a reasonable assumption of any algorithm that turns long strings into relatively short fixed-length strings, since there simply isn't enough information capacity in the short bit-string to contain the longer one.

Nonselectable

Finding a message that will produce a particular digest should be mathematically infeasible.

Unique

Finding two documents that produce the same message digest should be mathematically infeasible.

Irreversibility ensures that we can communicate the message digest without worrying that the contents of the message will be divulged. As an example, a common usage for digest algorithms is storing passwords in computer systems. In this usage, the user's password is passed through a message digest algorithm and then stored on the machine. When the user logs in and enters a password, it is passed through the same message digest algorithm, and then the two digests are compared. If they match, the entered password is correct. In this way, passwords are never stored in the clear but can be used to authenticate users. Obviously, this method wouldn't be secure if the digest algorithm could be reversed.

Nonselectability and uniqueness ensure that a different message can't be substituted for the one for which the message digest was created. This is important, because we're relying on the digest to provide evidence of message integrity. If I can find a message that has a particular digest, I can substitute it for a message you have sent with that same digest and no one will be the wiser. As an example of how this could create a problem, consider a common usage of message digests: ensuring the integrity of code distributions. If I can insert malicious code into a code distribution (for example, a program that emails any user's passwords to me) and then create the same message digest for the new distribution, you would download and install my version of the code and never know about the switch.

Table 6-3 shows some message digest algorithms, their digest size in bits, and the developer or owner of the algorithm. Ronald Rivest (the "R" in RSA) is the inventor of MD2, MD4, and MD5. MD2 was developed in 1989 and optimized for 8-bit machines. MD4 and MD5 are built for 32-bit machines. MD5 is computationally more expensive than MD4, but provides better security. MD5 is used in a number of applications from building hashes of passwords to integrity check-sums of code distribution.

Table 6-3. Message digest algorithms

Message digest algorithm

Digest size (bits)

Owner

MD2

128

RSA Data Security, Inc.

MD4

128

RSA Data Security, Inc

MD5

128

RSA Data Security, Inc

SHA

160

U.S. government

SHA-1

160

U.S. government

SHA and SHA-1 were developed by the National Institute of Standards and Technology and specified in Federal Information Processing Standards (FIPS) 180 and 180-1. MD5 has some discovered theoretical weaknesses, and as a consequence, SHA-1 has been preferred over MD5 for some time. However, in October 2004, researchers also published preliminary reports of weaknesses in SHA-1.

These developments point out why it's important to design identity systems so that the cryptographic functions can be easily changed out and why systems that use encryption as well as the policies that govern them should be reviewed periodically.

Digital Signatures

We've discussed how using a public-key cryptosystem in reverse can provide a sort of digital signature: if I encrypt a document with my private signature, anyone can decrypt it, but only with the matching public key. Provided I've kept my private key secure, this is strong evidence that I encrypted the document in question and can thus serve as a signature.

This methodology suffers from several disadvantages:

The signed document is rendered unintelligible unless it is decrypted with the public key. This is intrusive in an environment where one might only occasionally want to check signatures.

The signature and the document are inseparable. There's no way to send a signature under separate cover.

We can overcome these disadvantages if we combine public-key cryptography and message digests . Figure 6-3 shows the methodology schematically. Since a message digest is unique to a particular document (within certain cryptographic constraints), we can create a message digest of the document or message to be signed and then sign the digest rather than the message. The message remains in plaintext, and the signature and message are separable.

To verify the signature, we use the public key of the sender to decrypt the message digest and then apply the same message digest algorithm to the signed message. If the two message digests match, the message is the same as the one that was signed by the sender.

Figure 6-3. Digitally signing and verifying a message

Digital signatures, produced in this way, provide us with evidence of a document's integrity, since changing the document, intentionally or not, would result in the receiver calculating a different message digest. The digital signature also provides us with non-repudiation, since it is clear that the person who created the original digest had access to the identical document, and as long as that person has maintained control of his private key, he's the only one who could have produced the signature.

When used for digital signature purposes, the private key is sometimes called the signing key and the public key is called the verification key. Technically, these keys operate in the same way as standard public-key pairs; the terminology simply indicates clearly which key is used for what purpose.

Digital Certificates

Public-key cryptosystems provide technology for creating identity systems with confidentiality, integrity, and non-repudiation. As we've seen, however, they are subject to several serious limitations:

If you lose control of your private key, you can be impersonated and your confidential documents can be read.

If an enemy can convince me that her public key belongs to you, I'll accept whatever she tells me as coming from you.

The first problem is an authentication and authorization problem. We'll talk more about those in Chapter 7 and 8.

The second problem is mitigated by the use of digital certificates and what's called the Public-Key Infrastructure.

A digital signature is a data structure that associates identifying information with a public key. As we've seen, a public key is just a very long, seemingly random number. There's no way to look at a public key and tell who it belongs to. By combining a public key with other identifying information, such as a name and address, we can more easily identify the owner of the key and be sure that it's the right key. Of course, we will want to ensure the integrity of this document by digitally signing it so that no one tampers with it and substitutes an alternate key.

A digital certificate need not be issued to a person. In fact, many are not. Digital certificates can be issued to a variety of entities including individuals, companies, groups, and even web servers. The entity whose identifying information is associated with the public key in the certificate is called the certificate subject.

When a certificate is created, the data structure is populated and then the issuer signs the certificate by creating a message digest of the information and then encrypting the digest with the issuer's private key. By signing the certificate, the issuer is making a statement that the public key contained in the certificate and the identifying information in the certificate belong together. The digital signature ensures the integrity of the certificate.

Digital certificates are not human-readable documents, but rather data structures meant to be used by computer programs. However, with the aid of programs, like OpenSSL, we can view the contents of a certificate. Here are the contents of a sample digital certificate:

    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 163 (0xa3)
            Signature Algorithm: md5WithRSAEncryption
            Issuer: C=US, ST=California, L=San Francisco,
                    O=Pacific Distribution, Inc.,OU=Certification,
                    CN=PDI Certificate Authority/Email=certs@pdi.com
            Validity
                Not Before: Aug 19 17:31:59 2003 GMT
                Not After : Aug 18 17:31:59 2004 GMT
            Subject: C=US, ST=California, L=San Francisco,
                     O=www.California_distribution.com, OU=1885658,
                     CN=www.California_distribution.com
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                RSA Public Key: (512 bit)
                    Modulus (512 bit):
                        00:a4:45:15:66:ca:4b:e9:4f:b2:85:32:df:73:63:
                        01:b6:a0:45:31:c4:db:67:7b:ed:29:7e:66:d9:30:
                        8f:0e:33:3c:cb:bc:2d:2b:a8:51:48:a2:e5:68:84:
                        82:aa:d1:07:f9:64:f2:fd:67:5d:cd:58:c6:c7:71:
                        3d:7e:d7:ec:63
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                X509v3 Basic Constraints:
                    CA:FALSE
                X509v3 Key Usage:
                    Digital Signature, Non Repudiation,
                    Key Encipherment
                X509v3 Extended Key Usage:
                    TLS Web Server Authentication
                Netscape Comment:
                    OpenSSL Generated Certificate.
                X509v3 Subject Key Identifier:
                    48:7E:92:A1:6E:B0:06:42:05:6C:FA:F3:47:81:85:4E:
                   3A:2D:05:BB
                X509v3 Authority Key Identifier:
                    keyid:F8:F1:41:1C:D6:A2:C3:77:B1:A6:3D:CA:49:59:
                        E8:86:C0:0A:2B:4A
                    DirName:/C=US/ST=California/L=San Francisco
                            /O=Pacific Distribution, Inc.
                            /OU=Certification/CN=PDI Cert Authority
                            /Email=certs@pdi.com
                    serial:00
        Signature Algorithm: md5WithRSAEncryption
            75:a5:ca:a3:90:e3:03:a6:40:5c:95:a5:f8:a0:a1:b3:b3:e9:
            e9:fb:e8:ce:d1:b4:f5:e1:ee:04:c1:e2:c7:ad:f4:a6:b2:5d:
            59:d6:d9:81:34:ec:b7:30:0a:b3:49:0c:58:d2:70:a0:e7:c2:
            71:bd:c8:de:33:e3:f1:5f:78:67:db:4c:84:70:ba:7b:d7:52:
            cf:43:19:ab:4d:d4:7e:1a:2e:30:35:47:57:0d:6d:25:e7:a7:
            13:a9:a8:57:63:9d:0e:54:ec:16:2d:a1:f6:e4:12:97:94:a5:
            38:84:54:2f:7c:05:fc:9b:6b:3f:c8:86:56:df:89:c3:4f:8b:
            4d:7c

There are several items in the certificate of interest to us. There are two main parts: the data block and the signature block. The data block tells us the certificate's serial number, who the subject of the certificate is, what signature algorithm was used, and who issued the certificate. The data block also contains the actual public key (512 bits, in this case) and a list of extensions. The signature block contains the actual signed hash.

You probably noticed the string "X509" in several places in the data block. X.509 is part of the X.500 standard for directories, which we will discuss in Chapter 9. X.509 specifies the format of the data structure that holds the certificate information. Despite its origins as part of X.500, X.509 has taken on an independent life as a standard.

The X.509 specification defines ways to extend certificates to contain any data that the issuer deems important. Extensions take the form of key-value pairs. Each extension has an associated criticality flag that indicates to applications using the certificate whether they can safely ignore an extension that they don't understand.

The certificate, being a data structure, is binary data. Many of the uses for certificates, however, require that they be transmitted over networks. To make this possible, the data structure is serialized using an encoding algorithm called the Distinguished Encoding Rules (DER) . In its serialized form, the certificate takes the form of a string of octets and is suitable for transmitting over network connections. When the certificate is to be included in email and other text documents, the octet string is base 64-encoded to create a stream of ASCII characters. Since it appears as a long, random-looking string of ASCII characters, many people confuse the encoded certificate with the public key itself. You can recognize base 64-encoded certificates because they are, by convention, set apart with a beginning string "--BEGIN CERTIFICATE--" that serves as the header and an ending string "--END CERTIFICATE--" that serves as the footer.

Certificate Authorities

As we've discovered, a digital certificate associates identity information with a public key in a trusted package. Since the certificate issuer signs the certificate, we can easily verify that the information in the certificate has not been tampered with or otherwise modified. But how can we be certain that the identity and public key are correctly associated?

While anyone can issue certificates using OpenSSL or some other certificate programming API, there are trusted issuers of certificates called certificate authorities (CAs). The certificate authority accepts and processes applications for certificates from entities, authenticates the information that the entities provide, issues certificates, and maintains a repository of information about certificate and their subjects.

Certificate authorities provide the following services:

Certificate enrollment process

This is the process whereby entities apply for a digital certificate.

Subject authentication

The certificate authority authenticates that enrollees are really who they say they are. The level to which authentication is done depends on the level of assurance the certificate authority is promising.

Certificate generation

As we've seen, certificate generation is not a complicated process computationally. What makes this task difficult is the need to do it in a completely secure manner.

Certificate distribution

Certificates and the private keys associated with them must be distributed to the enrollee.

Certificate revocation

When there is a question about the integrity of a certificate that has been issued (e.g., the private key has been compromised), the certificate is added to a revocation list.

Data repository

All of the information related to the enrollment and authentication, along with any other important information, must be kept, securely, for an agreed upon length of time (e.g., 10 years, 100 years, etc.) in case information about the certificate and its use is questioned.

The CA typically publishes policies and practices related to the above activities in a certification practice statement (CPS). These documents are typically understandable and not overly filled with legal jargon. Even so, they are lengthy; VeriSign's CPS is nearly 90 pages long. Most users of digital certificates have never bothered to read the CPS.

A set of standard extensions was added to Version 3 of the X.509 specification to provide CAs more control over certificates. These include a basic constraints field that indicates whether the subject is a CA, a certificate policy field that contains a reference to the policy under which the CA issued the certificate, and a key usage field that restricts the purpose of the key contained in the certificate. Since the key usage field is typically marked "critical," CAs can use it to limit the use of the general purpose keys they issue to specific tasks such as digital signing or non-repudiation. The key usage field keeps keys from being used for purposes for which their subjects did not intend. A cynic would also recognize that it also helps CAs sell more certificates.

Certificate Revocations Lists

The State of Utah uses digital certificates to control access to some of the systems used by the State police and other public safety officials around the state. Because a compromise to that system could result in the loss of sensitive data or worse, the designers used digital certificates for authentication. A natural question is, "What happens if a user loses a certificate or it is compromised in some other way?"

As we've seen, X.509 certificates have a period during which the certificate is valid. When the validity period passes, the certificate expires. Events can transpire, however, that make a certificate invalid before it expires. Examples include the disclosure of the private key associated with the certificate, a change in the identifying information contained in the certificate, or the compromise of the CA's private key. The compromise of a CA's private key would invalidate all of the certificates that have been signed using that private key—quite a catastrophe for the CA and its customers.

When a certificate is prematurely terminated, the certificate is said to have been revoked . Using a revoked certificate is usually in conflict with the CA's policy and could be risky since you can no longer rely on its integrity.

When a certificate has been revoked, the CA places the certificate on a certificate revocation list (CRL). The CRL is a data structure that contains identifying information about the CA, a timestamp, and a list of serial numbers of all the certificates that have been revoked. The CA signs the CRL to assert its authenticity and protect it from tampering. Whenever a certificate is used, the user should obtain the most recent CRL from the CA who issued the certificate and check to see that the certificate's serial number is not on the CRL. Of course, no one's going to do this unless the process is automated, a practice that is spotty at best.

Certificate authorities provide CRLs on a predefined schedule. The frequency of issuance depends on the level of assurance guaranteed by the types of certificates that are included. CRLs for certificates issued for causal use are not updated as frequently as those certificates used for high-value transactions. The level of protection afforded by a particular class of certificate depends, in part, on the frequency of CRL issuance and how CRL status is to be obtained. There are three general ways that CRLs can be checked:

The application using the certificate can ask the CA for the latest CRL. This is known as polling. The advantage is that the CRL is transferred only when it is needed. The disadvantage is that frequent polling can cause significant overhead to systems.

The application can subscribe to a service from the CA that sends the CRL out on a predefined schedule. This ensures that the application always has the latest CRL, but an attacker may be able to block the CRL from reaching its destination and the application may be none the wiser.

The application could query an online service provided by the CA. The advantage of this approach is that the application always has the latest information, and only information relevant to the application is passed back (the status of a particular certificate). The disadvantage is that the CA must operate a secure, real-time infrastructure for this purpose.

Of course, all this is moot if the application does not check the CRL. Internet Explorer (IE Version 6.02), for example, has CRL-checking code built-in, but it is turned off by default. This means that the browser will indicate that it is securely connected to a site using SSL even if the certificate at that site has been compromised and revoked. If you turn it on, however, you'll discover why it is turned off by default: IE can't get CRL information at many sites and complains every time that happens.

Certificate revocation is one of the big holes in the use of digital certificates, because many applications do not support it and CAs often make it difficult, or at least expensive, to access CRLs. This is probably of minor concern for web browsers. It's a greater concern when certificates are used in authentication schemes that control access to highly sensitive applications or protect sensitive data.

In the case of the Utah public-safety system I described at the beginning of this section, the system designers recognized that CRLs needed to be part of the system. Unfortunately, the online process offered by the CA was deemed too expensive. We found other, less-expensive means to check certificate revocations, but they were less than ideal. Ultimately, cost plays an important part in any identity system and the cost-risk trade-off can be difficult to quantify.

Public-Key Infrastructures

If digital certificates are to be widely used, there must be a supporting infrastructure that provides policies, rules, agreed upon standards, interoperability, and so on. This is called the public-key infrastructure (PKI). The PKI must have two characteristics: it must be secure and it must be scalable.

We've already discussed many of the standards and procedures that make up the public-key infrastructure, including algorithms, X.509 certificates, certification practice statements, and certificate revocation lists. If there were only one CA, then this would be enough and that CA would constitute the PKI. There are, however, dozens of CAs around the world, and we need methods of using and establishing the veracity of certificates from each of them.

Figure 6-4 shows the hierarchical relationship that exists among CAs. In this schematic, there are two independent hierarchies of digital certificates and certificate authorities. The root of one tree is CA1, and CA2 is the root of the other. Each of these root CAs has certified several subordinate CAs: CA3 and CA4, in the case of CA1. Consequently, the private key that CA3 uses to issue digital certificate DC2, for example, is associated with a digital certificate signed by CA1. The heavy bidirectional arrow in the figure is meant to indicate that CA1 and CA2 have cross-certified each other, signing each other's digital certificates.

Figure 6-4. Hierarchical structures of CAs make up a PKI

When we want to check the integrity and veracity of digital certificate DC3, we can use the digital certificate of CA3 to verify the signature on the certificate. We can further verify CA3 by checking to see that its digital certificate was signed by CA1, and we can check on CA1 by verifying its certificate was signed by CA2. The dotted line arrows in the diagram represent this check.

The series of checks represented by the dotted line is called a certification path . Whenever we are presented with a digital certificate, we can, in theory, discover its certification path as a way of checking its validity. In practice, discovering the certification path may be a complex problem. Solving it once might not be overly expensive, but checking each time the application uses the certificate probably is. As a result, most applications simply check that the certificate is signed by one of a large list of known CAs.

Browsers are a good example. Internet Explorer and Netscape both contain a list of certificate authorities that the browser knows. If the server you visit uses a digital certificate from one of these CAs, you'll be securely connected. If the CA that issued the server certificate is not in the list of trusted CAs, you will be warned that the browser could not determine if the site is using a valid certificate and asked if you want to proceed. For performance reasons, browsers typically limit their certificate path discovery to one level. That is, if the certificate presented is not signed by one of the CAs trusted by the browser, the certificate is reported as untrusted.

Going Further

If you'd like to experiment with some of the concepts in this chapter, I recommend that you visit Thawte (http://www.thawte.com) and request an email certificate. Thawte will give you one for free, and you can use it with Firefox, Netscape, Mozilla, or Internet Explorer. You'll go through an enrollment process and, once you've installed your newly minted certificate in your browser, be able to view the details of the data stored inside the certificate. Free certificates from Thawte are not very useful in establishing your identity, because Thawte doesn't do anything to verify the identity of the requester. The certificate does, however, associate your email address with the public key contained in the certificate, and Thawte provides a process that you can use to verify your identity and have your name put into the certificate as well.

You can also use programs from the OpenSSL open source project to create, sign, and manipulate certificates. Using OpenSSL, you can create a certificate authority and use it to sign your own certificates. These certificates won't be verifiable in many circumstances, because the certificate authority is not part of the trusted PKI, but they are useful in some circumstances. For example, I use a self-signed certificate to provide SSL connectivity to portions of my web site that I use. Since I issued the certificate, and only I and handful of other people who know me personally use the trusted features of the site, it provides sufficient security.

Conclusion

Integrity, non-repudiation, and confidentiality are important foundational properties in an identity management system. Almost every activity in identity management relies on one of more of these three concepts.

Public-key cryptography and the public-key infrastructure have suffered from over-hype—seen by some as the answer to every security problem that has surfaced over the years. For example, some have proposed the widespread adoption of digital certificates for authentication and authorization tasks. While the technology is theoretically up to the task, these schemes have usually collapsed under the weight of complexity, institutional policy, politics, and the sense that widespread adoption is too expensive or difficult to manage.

As an example, consider the task of using digital certificates to secure access to an online banking service. For a large bank, this means issuing millions of digital certificates and renewing them on a periodic basis. These certificates would need to be installed on client machines and then used and managed by the bank's customers. Automating the process of installing and managing the certificate on the client's machine opens significant holes in the security system, because this automated process could be exploited by attackers to install bogus certificates on unsuspecting customers' machines.

For digital certificates to be effective in an identity infrastructure, users of digital certificate technology need be aware of the certificates at some level and actively participating in their installation and management. People have historically shown little tolerance for the subtle nuances and finicky installation procedures that accompany digital certificates today.

That's not to say that public-key cryptography and digital certificates have no role. Indeed, SSL secures millions of web sessions every day in an effective manner with little thought by the many users. Digital certificates and the public-key infrastructure that supports them are a well-understood technology that can be used to provide support for identity management. To be effectively used, however, they must be used in conjunction with other technologies and protocols that we'll discuss in coming chapters.

Chapter 7. Authentication

Authentication is how an identity is established. This is a prerequisite to controlling a subject's access to critical resources, the topic of Chapter 8. Authentication answers the questions "Who are you?" and "How do I know I can trust you?"

In the physical world, we answer these questions in a variety of ways. If we leave aside personal recognition of friends and acquaintances, identity is typically established in the physical world by means of a token of some sort. Identity badges and spoken passwords are examples of tokens that are used to identify someone to a stranger. When a person presents an identity badge, we trust the badge only if we trust the entity that issued the badge and believe that the badge is not a forgery.

Identity badges and other trust tokens are more properly called credentials . Credentials in the physical world establish our right to claim a certain set of attributes. In the digital world, they are no different. To lay claim to a set of attributes (e.g., an identity), the subject presents credentials that can be authenticated.

Authentication and Trust

In Chapter 3, we discussed the concept of trust in digital identity. Authentication is dependent on trust. As an example, consider how a person uses the picture on a driver's license to authenticate the credential; specifically, the authenticator uses the picture to ensure that the person presenting the license and the person who owns the license are one and the same. There is a second step we perform, however, when we look at a driver's license that we hardly ever think about: we decide whether or not we believe the license was really issued by an authority we trust. In the case of U.S. driver's licenses, that authority is one of the 50 states.

I could create a credential that has all the same information on it as the state-issued driver's license and even include a picture. The clerk at the convenience store could still authenticate that the person pictured is the same as the person presenting the credential, but there's no reason for the clerk to trust that I am telling the truth about the person's name, address, age, or any other attribute.

The same is true of digital credentials. In many cases, we don't have to worry about trust, because the entity authenticating the credentials is the same entity that created them. ID/password systems usually have this property. With other types of credentials, such as digital certificates, the certificate is issued by a different organization. As we've seen, PKIs make up the infrastructure that establishes trust in the world of digital certificates.

Thought of this way, trust may seem like a binary thing: you trust an entity or you do not. In fact, we know from our real-world experience that trust is typically established by way of introduction and built over time as the relationship deepens. This concept of trust is not used often in authentication systems, but it is important in digital identity. For example, over time, I come to gain trust in the identity represented by the email addresses of people I correspond with frequently.

Authentication Systems

As we've seen, authentication systems require some sort of credential. Although we usually associate credentials with some sort of document, that need not be the case. More broadly, credentials can be created using:

Something you know

Something you have

Something you are

Some combination of the three

These are known as authentication factors . In general, the more authentication factors that are present in an authentication system, the more secure it is. You'll hear the term "two-factor authentication," for example, meaning that the system incorporates two of these authentication factors. The remainder of this section will discuss some common authentication schemes and their authentication factors.

Cookies

You may not have thought of cookies as an identity credential; but, the fact is, they represent the most prevalent form of identity credential on the Internet. The Hacker's Dictionary defines a cookie as a handle, transaction ID, or other token of agreement between cooperating programs. The claim check you get from a dry-cleaning shop is a perfect example of a cookie; the only thing it's useful for is making sure that you get your clothes back by relating two transactions that happen at different times.

On the Internet, cookies are exchanged between the browsers people use to access the Web and the servers the people visit. These cookies serve the same purpose as the claim check in the dry cleaning example: they tie transactions together that are otherwise difficult to connect.

To see how this works, suppose I use my browser to visit a web site I've never been to before, let's call it http://www.foo.com. The people who maintain http://www.foo.com configured the server to give a cookie to everyone who visits. So, on my first visit to the site, the server passes a cookie back to my browser. My browser dutifully stores the cookie in a file on my computer used especially for this purpose. The magic of cookies happens the next time I request a page from http://www.foo.com (which could happen in the same browsing session or days or even weeks later). When I tell my browser to retrieve a page from http://www.foo.com, my browser sends back the cookie it received on the last visit.

So, let's review what has happened:

The server asked my browser to store some information for it, knowing that it would be sent back verbatim when the browser made its next request.

The server chose the information it gave to my browser.

My browser didn't add any information to the cookie, just passed it back.

My browser stored the cookie in a special file that it chose, not one the server chose.

The cookie does not contain any information about me.

The cookie is not a program: it can't be executed and has no ability to access other information on my computer.

The next time I retrieve a page from that web site, the information is sent back.

That's really the long and short of cookies. There are some more details, but all cookies obey these rules.

Cookies were added to servers and browsers to identify the same user over multiple sessions. Because HTTP is a stateless protocol, every request looks like a different session. This ability to link together time-separated transactions is what allows a web site to run a shopping cart, remember who you are, fill in forms for you, or remember your password between visits. Just as you wouldn't return to a dry cleaner who couldn't match up their customers with their clothes, web sites without the ability to link transactions across time are pretty boring.

Cookies aren't typically thought of as an authentication device, but they are a credential that is used to lay claim to a particular identity. Cookies have a single authentication factor: "something I have." Cookies are a weak form of authentication, because there's no way to ensure that the same entity is using the cookie from visit to visit. The browser might be on a shared computer. I can even move cookies from one browser to another, if I'm clever, and let multiple people use the same cookie. Even with these problems, cookie-based identities are useful in a variety of circumstances. Chances are, you've got hundreds of cookie-based identities that you're largely unaware of.

ID and Password

If you're like me, you have dozens of ID/password pairs on various computer systems around the Internet. By typing in an ID, we lay claim to an identity, and the password is used to authenticate that we are allowed to do so. The system uses the identity represented by the ID to associate attributes with the holder of the ID.

Strictly speaking, ID and password systems are a two-factor authentication system with the ID representing something I have and the password being something I know. The problem, of course, is that an ID is usually public and is easily duplicated. As a result, most ID and password systems are nearly as weak as a one-factor system.

Password management

The biggest advantage of ID and password systems is their simplicity and familiarity. The largest drawback is their reliance on passwords . In theory, because passwords are secret (something you know), they are secure, and only the entity with the secret can reveal it to the authentication system. In practice, passwords suffer from several serious limitations:

People can remember only a limited number (around eight) of items with perfect accuracy. Furthermore, they usually have multiple passwords that they are trying to remember. As a result, people create passwords that are short and easy to remember. They also tend to use the same password for multiple credentials.

Easy to remember passwords can be easily guessed by an attacker. Even passwords that have no relation to the entity that holds them can be effectively guessed if they are what are known as "dictionary words." The best passwords would be long, random strings of characters, but people can't remember long, random strings.

People (and even machines) can be tricked into revealing the secret password to an attacker. This could be done, for example, by creating fake login screens. Another common technique is known as "social engineering" where the attacker contacts the person and tricks him into revealing his password by posing as an administrator or someone else the person trusts.

People write passwords down. Passwords get stored in files on computers. This makes them vulnerable to theft and misuse.

These problems don't have easy solutions. For example, many IT departments institute a password aging policy that forces users to change their passwords on a periodic basis to mitigate loss or sharing. They also frequently enforce rules about password structure in an effort to make passwords less guessable. For example, the rules may disallow dictionary words, require passwords longer than six characters, or require passwords to contain a mixture of letters, numbers, and punctuation. Often, the result of these kinds of policies is that users give up trying to remember their passwords and simply write them down and paste them to their monitors or stick them in the pencil drawer.

When it's poorly implemented, password aging can be a detriment in other ways. Some password aging implementations, for example, allow a user to immediately change her password back to the previous password, defeating the purpose. Also, many password aging systems surprise the user with a requirement to select a new password when she logs in. Faced with the goal of getting something done and having to select a new password quickly, many users select easily guessable passwords.

Password management systems can be implemented so as to conduct extensive checking on user-selected passwords to weed out poor choices. These systems can be customized on a per-project or per-group basis to eliminate passwords that might be acceptable in a general population, but bear additional significance to the group members or project team.

Password reset

Managing passwords is a significant challenge in a large organization. Issues surrounding passwords can make up 25% of all calls to an IT help desk. With help desk calls costing as much as $35 per call, this can be an expensive proposition. To mitigate password management costs, many organizations have implemented self-service password reset systems. These systems allow a user to reset his password to something new whenever he wants, without knowing the old password.

Password reset services can work in various ways. One of the most common methods is to ask the user a question that she has previously answered and, if she gives the right answer, allow the password reset to proceed. The questions can be canned (e.g., "What is your mother's maiden name?") or free form, allowing the users to enter their own questions and answers when their accounts are originally established. Another common technique is to allow a user to create a new password and have it emailed to a previously specified account. This presumes that the user has access to her email without the password. Hybrid solutions that use both of these methods are also possible.

Challenge-Response Systems

Challenge-response systems are related to password systems. In a challenge-response system, the server generates a random string of characters, and the user is required to manipulate the string according to some predefined, and secret, algorithm and send it back to the server. The algorithm may include the use of a secret key. Usually, a computing device of some sort performs the manipulation so that the algorithm can be made more complicated and thus more difficult to guess.

To see how this works, consider a simple problem. Suppose Alice and Bob agree to meet at the zoo to exchange a package. Alice and Bob do not know each other by sight and agree to verify their identities by way of a spoken password. We've seen this played out in spy movies. The two parties approach each other and one says something and the other responds with a predetermined response. This is essentially no different than how cookies work.

In a challenge-response system, Alice could give Bob a number, say, 5634. Bob has been told that he's to add 3133 to the number Alice gives him and repeat it back. He responds with 8767. Alice performs the same calculation and gets the same answer and knows that Bob is the party she's to meet. She could distinguish between multiple parties by the algorithm they use. Another party might have been told to reverse the number and add 3, for example.

Challenge-response systems have an advantage over ID/password systems, because the algorithm can be made sufficiently complex so that it is nearly impossible to guess. The disadvantages are that the algorithm must be coded on a special-purpose device or on the user's computer and is subject to loss or theft.

A variation on the challenge-response system gives the user a special-purpose computing device called a token, which calculates a series of pseudorandom numbers. The token and the server that is doing the authentication both run carefully synchronized clocks. The token shows a new pseudorandom number periodically (say, every 60 seconds).

This number can be used in several ways. As a challenge-response system, the server could issue a challenge and the user could use the pseudorandom number to manipulate the challenge phrase in some way. This is more secure than having a predetermined algorithm.

In a second scenario, the user enters an ID, the number from the token, and a password in response to the challenge. The server uses the ID to retrieve the correct number and password and verify that they are correct. In this system, the server doesn't issue a challenge, but both the server and the token use a carefully synchronized, complex algorithm to calculate a shared secret.

The pseudorandom number token creates a two-factor authentication system where the user uses something that he has (the token) and something he knows (the algorithm or the password) to log in. An attacker would have to have both pieces to break into the system.

Challenge-response systems can be combined with ID and password systems to avoid transmitting passwords across the network. In this scheme, both the client and the server know the password. The server generates a challenge phrase and sends it to the user. The user creates a message digest for the challenge phrase using the password and sends the result back to the server. The server compares the response with the message digest it calculates for the phrase with the user's password. If they match, the server knows that the client possesses the password without ever having to send it across the network. Care must be taken to ensure that the message digest algorithm and the way it's combined with the password are cryptographically sound or an attacker may be able to deduce the password from the network traffic.

Digital Certificates

We discussed digital certificates in detail in Chapter 6. Because certificates aggregate identity information and a public key that has been signed by a third party, digital certificates can easily be turned to the task of authentication.

The simplest way of using a digital certificate for authentication is in a challenge-response system. In this use, the digital-signing algorithm is substituted for the secret algorithm. The server generates a random string and sends it to the user. The subject digitally signs the random string and sends it back to the server. The server can verify that the random string is the same one that it generated and was in fact signed by the owner of the certificate. Once verified, the identifying information in the certificate can be assumed to belong to the subject.

Besides their cryptographic security advantages, digital certificates have other advantages over other authentication mechanisms. Multiple digital certificates can be associated with a single account so that a user does not need to hold multiple accounts to store different sets of attributes. Because the attributes can be stored in the certificate, the correct attributes are selected based on the certificate that the user presents. Furthermore, as we've seen, the certificate data structure can be extended so that it carries information specific to its use.

Even with their inherent security and other advantages, however, digital certificates have not had much success in authentication systems. Microsoft and others have invested millions of dollars building systems for creating, administering, and using client-side certificates for authentication. The primary problem is that digital certificates are quite a bit more complicated for users to manage. The concepts surrounding digital certificates are considerably more difficult to understand than those of simpler systems like ID and password systems.

A secondary problem is that commercially issued digital certificates cost money. They must be renewed regularly, and users frequently forget their access codes or lose the certificate entirely, leading to costly refreshes. This ongoing expense can deter organizations from adopting digital certificates as their primary authentication mechanism.

The final straw is that, except in certain circumstances, digital certificates don't provide a significant increase in the security of the authentication system. Digital certificates are usually stored on the user's machine and protected by a password. That password is subject to all the disadvantages of passwords that we saw earlier. Impersonators with access to the user's machine may be able to guess or crack the password being used to protect the digital certificate as easily as they can any other password.

All this doesn't mean that digital certificates have no place in an authentication strategy, but you should understand why you're using them and compare the return with the additional complexity and expense. Certificate-based authentication has found the most success in special-purpose applications where security is of particular concern. Even there, certificates are often misused. For example, we've seen that ignoring certificate-revocation lists is a common mistake.

Biometric Devices

Biometrics is the use of some physiological or behavioral trait to uniquely recognize a person. Physiological traits can include face characteristics, fingerprints, hand geometry, iris characteristics, or retinal maps. Behavioral traits are those that are learned or acquired like handwriting and signature characteristics or voiceprints. Biometric devices present the opportunity to build authentication systems that incorporate something you are as an authentication factor.

Biometric identification has long been the stuff of science fiction, but there is growing interest, primarily among government entities, in using biometrics to strengthen airport security, protect borders, and in other military and homeland security applications. You can even buy a PDA with a built-in fingerprint sensor.

As we've seen, most state-issued driver's licenses contain a biometric identification device called a picture. When the driver's license is presented as a credential, the integrated picture is used by the sophisticated face recognition technology we all carry around in our heads to ensure the credentials are being presented by the person pictured on the license. Similarly, when a biometric device is used to authenticate identity credentials, the user enters an ID or other identifying token and then, rather than entering a password, the user might touch a fingerprint recognition device or speak into a microphone.

Biometrics devices have an advantage over other authentication systems, because they are tied to a person uniquely. This property allows biometrics to be used for identification, not just authentication of credentials. To understand the difference, consider the problem of ensuring that a person receives a government entitlement like food stamps only once. Crooks can fraudulently obtain credentials and apply for entitlements under different names. Biometrics determine whether the person, rather than a set of credentials, is known to the system and whether that person has previously been enrolled. This is sometimes called negative identification, because its goal is to prove that someone isn't on a list.

This advantage also represents the most significant disadvantage of biometrics. While unlikely, biometric characteristics might be duplicated or cheated. Once a biometric identification characteristic is compromised, there is little recourse. You can't easily issue new irises or fingerprints to replace the compromised feature.

The other side of this problem is that there are individuals who don't fit into the standard patterns. For example, hand geometry devices cannot successfully identify the hand geometry of individuals with polydactylism (one or more extra fingers), yet this occurs in 0.2% of the general population. This can pose a difficult choice when system security depends on such a device. To see why, imagine a scenario in which a data center has installed hand geometry scanners at each of its doors and relies on them for perimeter security. If a polydactyl individual is hired, the company would be required to accommodate this disability, at least in the U.S. Most reasonable accommodations would create a special-purpose breach in the security wall or reduce the automation level of the authentication system.

Smart Cards

Smart cards are credit card-sized devices that contain an embedded electronic chip and a simple interface for accessing the memory or processor on the chip. Most cards have a small set of contacts on the front, and when the card is inserted into a card reader, those contacts provide power and data interfaces to the electronics on the card.

Smart cards are something you have and can be used in authentication systems in a variety of scenarios. The most obvious scenario is to use the memory on the card to store a digital certificate. The advantage to storing the digital certificate on a smart card is its portability. On a card that contains both memory and a processor, the onboard processor can be used for encryption and decryption tasks and for verifying authorized access to the private key. Using the onboard processor in this way reduces the need to transport the keys off the card, decreasing the chance that they'll be compromised.

Smart cards can also be used to implement a challenge-response system. In this use, the set of algorithms used to manipulate the challenge phrase are encoded in the card. The card can be placed in a reader attached to the user's computer or the card can be inserted into a low-cost special-purpose device that allows the user to enter the challenge phrase and displays the result of the manipulation.

Some smart cards contain a built-in thumb-print reader, creating a portable biometric device. The biometric factor is used to ensure that the owner of the smart card is the one presenting or using it. This kind of system could potentially combine cryptographically strong digital certificates in a package that offers three-factor authentication: something you are, your thumb-print; something you have, the card; and something you know, a password.

Perhaps the most widespread use of smart cards for identity is in the cell phone industry. GSM phones rely on a Subscriber Information Module (SIM) that provides an individual identity for each mobile user account. Removing the SIM from one phone and placing it in another transfers the user's identity, including her network information, phone number, and, in most cases, address and contact information to the new phone. The SIM is just a smart card that allows the electrical contacts and processor to be punched out of the larger card and inserted into a small receptacle in the phone.

Smart cards have been available for many years, but have, thus far, failed to be adopted for widespread use in identity management. The primary drawback is the additional hardware needed to read the cards. For example, deploying a smart card-based identity management system in a large organization would require outfitting each desktop workstation with a smart card reader. Beyond the capital costs, the readers have to be maintained and managed.

Authentication System Properties

There are several important characteristics that authentication systems should have. These properties can be used to create an evaluation process for authentication systems in your organization. The most effective method is to prioritize these properties based on design criteria for the overall system and then evaluate different designs against the prioritized list. The following sections describe these characteristics.

Practicality

Practicality is probably the most important feature that any authentication system can have. From the user's standpoint, the authentication system should be easy to use and non-intrusive. No one likes an authentication system that asserts itself too frequently or asks for authentication when none is needed. Users also dislike multiple authentication systems for multiple resources when the user sees those resources as related. For example, from the users' standpoint, email lives on the desktop computer, and once they've signed on to their computers, they don't want to reauthenticate to read their email.

From the enterprise's viewpoint, the authentication system should scale well, provide the appropriate level of protection, and be cost effective. Enterprises want easy-to-use systems as well, due to high support costs. Enterprises need to manage authentication by large, diverse groups. For example, customers, employees, and the employees of partners and suppliers all need access to resources that the enterprise controls. Each of these groups has unique needs, and the authentication system should adapt to those needs.

Systems that require new software to be installed on user computers or, worse yet, require new hardware (like biometric devices and smart card readers) are difficult to deploy and maintain. This adds to the ongoing operating cost of the solution.

Appropriate Level of Security

Different applications require different levels of security. As we've seen, there are many different ways to authenticate credentials with varying combinations of authentication factors. The security of an authentication scheme is directly dependent on the number and type of authentication factors used. So is the cost. Good design will match the level of authentication to security requirements.

The overall evaluation of authentication strength is subjective. Expert knowledge is needed to evaluate the weaknesses of complex systems like cryptographic key systems. Comparing two systems and judging their relative strength is easier, provided they are not too similar. Deciding that a system built on digital certificates is more secure than one based on user IDs and passwords is easy. Deciding the relative strength of two different ID and password systems that differ only in policy details, such as password length and type, is nearly impossible.

Locational Transparency

Mobility is an important factor in modern IT systems and users require access at multiple locations, some of which are not predictable or under the control of the enterprise. Locationally, transparent authentication systems can authenticate user credentials regardless of where the user may be located.

Protocol Insensitivity

Protocol-insensitive authentication systems can be used on top of multiple transport and application protocols and to access resources. Servers for HTTP, FTP, POP, SMTP, and other protocols all incorporate some kind of authentication system. Take care to ensure that the authentication system and various servers interoperate. New tools offer the developer easy access to authentication, but it may not be as easy to create systems that interoperate. Web services, J2EE, .NET, and other regimes offer authentication methodologies, but they are not necessarily compatible without effort by the enterprise.

Appropriate Level of Privacy

The extent to which user data is kept private depends on the enterprise and the resources being protected. For example, in the U.S. at least, employee access to company resources, such as desktop computers and email, can be logged and tracked to whatever extent the employer feels is appropriate. On the other hand, an authentication mechanism on a system that allows patients at a medical center to view their treatment records must provide more privacy protection because of laws and regulations such as HIPPA.

Reliability

Reliability is crucial, because the authentication system can be the foundation for access to mission-critical resources. Reliability requires appropriate redundancy, operational excellence, configuration management, close monitoring, and proactive capacity planning. When the authentication system is used by other organizations, they may require a service-level agreement that stipulates specific uptimes and penalties for failing to meet them.

Auditability

Accountability requires that the system be auditable. Transactions logs make it possible to review and track user actions and are the heart of an auditable system.

Logs can be made at various levels. Aggregate logs do not track individual transactions, but rather they aggregate data such as totals, averages, and trends. These can be useful for capacity planning and understanding the overall operation of the system.

Detailed logs track individual actions and are required for some problems like security breeches. Authentication system logs provide an important resource for dealing with system intrusions, but may be subject to legal and other restrictions and policies.

If not properly protected, detailed logs can raise privacy and security concerns, even when the data they contain seems relatively innocuous. Traffic analysis is the art of deducing information from the patterns in messages. For example, if I know that the CFO always accesses certain company investor resources before a big deal is announced and I have access to the authentication logs for those resources, I may be able to use that information to trade ahead of the market.

Manageability

Manageability means that the operator of the authentication system can easily add, update, or delete users. The system should allow new classes of users and provide for different configurations among groups. Operators will add, renew, and delete certificates; maintain licenses; and update the system as new releases of the software become available. The interfaces to the authentication system should be well documented and easy to integrate into new and legacy systems. We'll talk about directories in Chapter 9; they can provide a repository for much of the information that would be used in an authentication system. In many cases, the manageability of the authentication system will be a factor of the user interface and features of the directory systems employed by the enterprise.

Federation Support

Today's enterprise has resources that must be accessed by the employees of its partners and suppliers as well as by their customers or constituents. An authentication system that supports federation will allow those entities to be managed by their respective organizations. This requires confidence in the partner organization and significant planning.

One of the crucial factors will be agreeing with partner policies about resource access and how the partner is verifying identity when it issues credentials. If the partner's authentication system is going to be trusted to make authentication assertions, then the policies surrounding that system and the relative strength of its authentication system will need to be understood.

We'll discuss federation in more detail in Chapter 12.

Conclusion

Authentication is a fundamental action of any access-control system and one of the primary reasons for digital identity in the enterprise. Authentication verifies that an entity can lay claim to a particular identity, and that forms the basis for all future authorization and access-control determinations. Now that we're aware of how credentials can be authenticated, let's turn to how they can be used to control access to resources and actions.

Chapter 8. Access Control

One of the most fundamental concepts in the world of digital identity is access control. Access control is the process of granting certain subjects access to a resource while denying others access. Even the notion of granting access is too coarse-grained—in many cases, we must control what actions a subject is allowed take on a resource. Some examples:

We want to grant each employee access to his email box, but not to anyone else's. Email administrators are granted access to everyone's email accounts.

The bank grants me access to my bank account but limits that access in certain ways. For example, I can only withdraw up to some preset limit at the ATM. My wife has access to the same account. Bank employees have access to the account but only in controlled situations.

The software I use to manage my web site has access to the web site and can create new files and delete or update existing ones. Anyone is granted access to the files for reading.

We've seen in Chapter 7 how authentication can be performed to certify a set of credentials and their associated identity. Our ultimate goal, however, is to use that identity to control the actions that subjects can take on resources. This is called access control, and it is based on determining a set of authorizations for a given identity. In this chapter, we'll explore some of the issues, patterns, and technology surrounding access control.

Policy First

Access control is first and foremost a policy question. Access-control technology is designed to automatically enforce the policy. Policy is a reflection of business and security objectives that have been set in accordance with other organizational policies, the generally accepted practices of industrial and professional organizations, regulatory and legal requirements, and organizational goals.

Here are some simple examples of access-control policies:

Everyone is allowed to read this folder and its contents.

All users who have been authenticated can read and write to this folder and its contents.

User "Bob" is allowed to read and write table "orders" in database "sales."

All users in the marketing department can read the marketing materials on the internal web server.

HR employees who are managers or above can modify salaries during working hours as long as they are accessing the salary application from the corporate LAN.

I've purposely ordered this list so that the policies progress from simple and specific to complex and abstract. The first, for example, is relatively straightforward to implement. Some of these policies talk about the user's role rather than identifying specific users ("manager," is a role, for example).

The last policy assumes that we can not only identify which employees work in HR but what their grade is and when "working hours" are. Are working hours 8 to 5? Does it change with each employee? Can we reliably tell who is accessing the system from the corporate LAN? There are business and technology aspects to these questions; some have both. For example, the idea of working hours is a business concept, but we also have to ask if the access-control infrastructure can support locking users out of resources based on the time of day.

Responsibility

The most important questions in access control have to do with responsibility. We typically classify that responsibility into three categories: owners , custodians , and users. The owner of the resource may be the person who created it, the head of the organization that owns it, or some other person or role. Ownership can be delegated or assigned. When you can't figure out who owns a resource, the natural default is the organization itself.

Access control is more effective when owners are explicitly designated, because they will be the ones with ultimate decision making authority and the responsibility for ensuring resources under their control are appropriately accessed. In government organizations, it is not unusual for owners to be designated in statute or by regulation. Your organization may not be as legalistic, but specifically designating owners and holding them responsible is an important part of information security.

Custodians are those people who actually manage the resources day to day. Every person in the organization is likely the custodian for some set of resources. Custodians are responsible for ensuring that access-control policies are enforced and that resources are available for use by authorized users. Often the custodian and the owner for a particular resource are the same person when the resource is a document or other information created in the course of day-to-day work. Someone other than the owner usually maintains larger resources, such as databases and web sites.

Custodians also play an important role in access control, because they are the ones that will implement and monitor the access-control policies that the owner specifies. Often, custodians are system administrators or technical operations personnel. Custodians have significant responsibility and are often entrusted with numerous resources. Also, custodians usually have "superuser" powers and can access any resource under their purview. Consequently, it's important to choose custodians with care and build identity infrastructures that allow cross-checks and auditing of custodial actions.

A user is the person, group, corporation, software program, or other entity that wants access to resources. Users might be the customers or employees of the organization that owns the resource. They might also be the employees, or even the customers, of partners and suppliers. Users might be responsible for ensuring that a resource is protected while in use, becoming custodians for a time. Often, access-control systems do not or cannot have the level granularity to protect a resource completely and so it becomes the responsibility of the user to act in accordance with the owner's instructions.

As an example, most document-management systems can control access to the document itself but not individual parts of the document. The owner of a document might share it with a co-worker with specific instructions about what sections can be modified and which cannot. The co-worker, as a user of the resource, has responsibility to treat the document in accordance with the owner's instructions, but these cannot be enforced by the access-control system.

Principle of Least Privilege

One of the fundamental ideas on which access-control policies are founded is the principle of least privilege. This principle simple says that users should be given no more access to resources than they need to accomplish necessary functions. Least privilege is a good guideline to follow in creating policy and makes some decisions easier, but in practice, it has limitations that are not easily overcome by real-world authorization systems:

Implementing least privilege requires extremely fine-grained permissions. Essentially, every action that might ever be taken by any user on any resource needs a permission defined.

The types and levels of authorization necessary to perform a given task may change over time.

Any given individual will need different levels of privilege depending on the task she is currently performing.

These limitations have led to systems that implement least privilege imperfectly, sometimes to ill effect. We'll see examples of this later in this chapter.

Accountability Scales Better than Enforcement

Seeing the limitations of the principle of least privilege leads to a second principle to guide the development of access-control policies: accountability scales better than enforcement. The simplest access-control policies to implement are based on trust and accountability. User actions are logged, and the logs are audited. When the logs show an unauthorized access by a user, appropriate action is taken. Accountability is a log-processing problem that can be done offline by a separate system and thus scales very well.

As an example, consider the problem of documents shared by email. You probably have no idea whether any of your employees are using the corporate email system to send important, even vital, company secrets to your competitors. The traditional approach to this problem is to try to create some sort of access-control infrastructure that requires permissions and authentication in order to email documents outside the company. This is largely impractical.

But a system to solve this problem based on accountability is practical. Creating a system that logs email to the outside world, notes any with attachments, and records the sender, date, and a hash of the document is fairly easy to do. You may not be able to stop the document from being sent, but you will at least know about it and be able to take steps to recover.

Obviously, real-world scenarios cannot accept the risk of an access-control policy based solely on accountability. But accountability can augment the access-control policy to provide protections that are difficult or expensive using traditional permissions-based access control . Organizations should carefully consider where the risk can be tolerated, because accountability-based systems are considerably cheaper to implement and operate than enforcement systems.

Authorization Patterns

Real-world systems live somewhere in between a perfect enforcement of least privilege and a system based solely on accountability. As computing and networking technology has matured, a variety of access-control schemes have been developed to try to balance these needs. These schemes represent broad philosophical frameworks that aid the development of access control policies as well as specify implementations for a particular scheme.

In practice, most organizations use a hybrid approach to access control where the resource owner tightly controls certain resources and custodians control other resources. For example, most organizations control access to the HR system in a very formal way, while allowing individual employees to determine who will see documents that they produce within some very broad guidelines.

Mandatory and Discretionary Access Control

One of the first organizations to systematically look at access control on computer systems was the Department of Defense. A 1983 Department of Defense publication called the Trusted Computer System Evaluation Criteria (TCSEC), but commonly referred to as "the orange book" because of the color of its cover, defined two modes of access control for the Department of Defense: mandatory access control and discretionary access control. In mandatory access control (MAC), the owner (or the owner's representative) sets the policy, and custodians and users are obligated to follow it. In discretionary access control (DAC), the custodian is left to determine what users will be granted access. Further, once granted access, the user becomes, in effect, a custodian, because a user can grant access to other users.

There has been a significant body of research on military security standards with some important discoveries. One of the most important is an undecidability result that showed that a DAC-based system, judged to be initially safe with respect to some policy, cannot be shown to remain safe over time. User actions may eventually result in an unauthorized user being granted access.

Another important result involves what is known as "tapping-out information." Consider a system where there are two levels of access control: classified and unclassified. In any system with shared resources between access-control levels (e.g., classified and unclassified documents stored on the same filesystem), it is impossible to keep users of classified information from sharing that information with unclassified users. In short, enforcing MAC on a shared system is impossible, because users with access to classified data can always find ways to encode classified information in system resources. Since these resources can be viewed by both sets of users, unclassified users can decode the message and see classified data. For example, if both sets of users can see the filesystem, classified data could be encoded by manipulating the presence of a particular file or even just its size, over time.

These results may seem somewhat esoteric, but taken together, they lead to a fundamental and important conclusion: you cannot build a practical access-control system that does not rely, to some extent, on trusting custodians and users to follow the policies.

User-Based Permission Systems

Perhaps the best known and most widely used access-control scheme is a user-based permission system made popular by the Unix file permission system. Figure 8-1 shows a schematic representation of how user and group permissions work in this system. The system is conceptually simple: both users and groups have access rights to resources directly and users belong to groups.

Figure 8-1. Permission hierarchy for users and groups

As embodied in the Unix filesystem , there are three permission levels: read (r), write (w), and execute (x). These permission levels are applied as attributes of the files and directories on the system. For simplicity, we'll just speak of files here, but the concepts are just as applicable to directories.

Files belong to owners, specific Unix users on the system, and groups, collections of users. Each of these levels can be set for the file's owner, the file's group, and everyone else. So for example, it possible to set permissions on a file so that it is readable and writable by its owner and only readable by its group and not readable by everyone else. Just about any other combination you can imagine is possible as well.

User-based permission systems are fairly simple to use and administer, and they have served nicely for decades. Still, they suffer from several drawbacks:

Most users ignore groups altogether and few understand them because user-interface issues in Unix make using groups problematic. For example, each user in a group can own files and, as a consequence, control the permissions. But when users create files meant for the group, they often forget to set group permissions correctly, resulting in a flurry of emails asking that the owner fix the group permissions.

More problematic is the inflexibility of the group system. Since only one group owns a file, it is difficult to create a set of files that can be accessed by multiple groups. The only way to do this is to create a third group and put everyone in the other two groups into the new group. But because groups cannot contain groups, if the membership of one of the subordinate groups is changed, the third group would not be updated automatically.

Groups also work best for long-standing file-sharing relationships. If you only want to quickly share a file with someone, creating a new group, adding both users to the group, and making the file owned by the new group is considerable overhead. Also, on most systems, creating groups requires superuser authority, so most users can't do it.

There are few tools for managing groups, other than editing text files, and the commands that users have to issue to set up group shared directories are somewhat arcane, even for Unix users.

Probably the most difficult problem to overcome in this system is the fact that because both users and groups have access to resources, merely deleting a group does not necessarily delete the permissions of the users of the group to access the resource. In fact, because the permissions are associated directly with the resource, it is almost impossible to determine what resources any given user has access to.

All of this has combined to cause system designers to search for something more flexible and easier to understand and use.

Access-Control Lists

Access-control lists (ACLs) are an attempt to create a more flexible permissions system that grants individual users access to specific resources. Access-control lists are just exactly what they sound like: lists of specific users and groups who have access to the resource. In filesystems, ACLs are stored as attributes of the files and encompass the standard file-permissions system and expand it to enable specific users or groups to be designated as having a particular level of access.

Figure 8-2 shows a schematic representation of access-control lists. The primary difference between this diagram and Figure 8-1 is the insertion of a permissions structure between the resources and the users and groups. Rather than users and groups being directly associated with a given resource, the resource has a set of permissions that includes both users and groups. This indirection gives ACL-based permission systems additional flexibility at the cost of some additional complexity.

Figure 8-2. Permissions hierarchy for access-control lists

Because ACLs are a recent addition to many operating systems, many tools and applications do not support them fully, if at all. More problematic is the fact that permissions are stored as attributes of the resources and are thus distributed across the filesystem, making managing individual user access difficult. For example, when a user no longer requires access to a set of resources due to a job change or a process change, there is no single place where those permissions can be changed. The resources must be visited one by one, and permissions for that user removed.

Role-Based Access Control

Role-based access control (RBAC) is based on the idea that users are typically granted access to resources based on their roles in the organization. Figure 8-3 shows a schematic representation of RBAC.

Figure 8-3. Permission hierarchy for role-based access control

A key feature of the RBAC model is that all access is through roles. Contrast this with the user-based permission model shown in Figure 8-1. In the RBAC model, some authority, such as the HR department, assigns roles and the resource owner assigns permissions.

A second key feature of RBAC-based authorization is that roles can be hierarchical, as shown in Figure 8-4. If roles are created as shown in this figure, assigning an employee a role as a developer also automatically assigns roles as a member of the engineering department and as an employee. In addition to being hierarchical, roles can be parameterized to aid in role administration.

Role-based authorization schemes are based on three rules:

Role assignment. All users of the system are assigned roles; users without roles cannot take any action.

Role authentication. Before a user can take on a role, that role must be authenticated for that user.

Action authorization. A user can take an action only if that action is authorized for the current, authenticated role of the user.

Role-based authorization is more flexible than an authorization scheme based on simple groups and more secure than one in which users can be authorized independent of their group or role membership. Furthermore, as practiced, role-based authorization makes it relatively easy to add and remove a user's access to resources as his function in an organization changes, even if he changes tasks day to day.

Figure 8-4. Role hierarchy for an engineering department

Abstract Authorization Architectures

In designing identity systems, we typically talk about two abstract places where authorization decisions are made: the policy enforcement point (PEP) and the policy decision point (PDP). Figure 8-5 shows a PEP and PDP in action.

Figure 8-5. PEP and PDP actions

The PEP is the point in the system where the user requests access to a resource. For example, if a user attempts to access a web page, the web server is the PEP. The PDP is the point in the system where the decision is made as to whether or not the user will be allowed to access a resource. In many cases, the PDP is part of the same system that houses the PEP, but it needn't be. The web server could, for example, send the resource name (a URL, in this case) and the user ID to a separate system and simply get back a "yes" or "no" answer. Note that this is different from the web server asking another server to authenticate a user. That is an authentication question, not one of authorization.

Even when the PEP and the PDP are co-located in the same system or program, it is useful to see authorization as a coordinated effort between these two abstract systems. The PDP makes its determination of entitlements or permissions based on an access policy that has been set in advance.

When a PDP makes a determination regarding a particular subject's right to access a particular resource, the decision is called an authorization decision assertion (ADA). An ADA can take any form that the PEP and PDP can agree on. We'll discuss standards for communicating ADAs as well as storing access-control policies in Chapter 11.

Digital Certificates and Access Control

We've seen how digital certificates can be used in an authentication infrastructure. Because the certificate is just a data structure that can be extended, it can also be used to store permissions and other authorization information, such as roles. The signature of the certificate authority ensures that these attributes can't be tampered with. The use of certificates in this way makes two important assumptions:

The roles, permissions, and entitlements regarding the subject of the certificate are static, and thus can be encoded in a certificate that is updated infrequently.

The chain of trust from the organization to the certificate authority is such that systems needing to use the permissions in the certificate can trust that they were set in accordance with the correct access-control policy.

The inflexibility of this system is its chief drawback. Changing access-control permissions requires revoking the old certificate and issuing a new one. Its primary strength is that permissions move with the certificate in a trustworthy way, negating the need for a complicated database infrastructure to store the permissions.

Conclusion

Authorization complements authentication to form the basis for access control. In many ways, authorization is the focal point around which the enterprise identity management infrastructure revolves.

The pressures to expand authorization systems to cover more and more fine-grained resources in the enterprise is a natural outgrowth of the drive to align IT systems more fully with business purposes. These pressures lead to extremes in system complexity, however, unless they are managed and thought through carefully. The final section of this book will help you develop a strategy that will allow you to derive the most value from your identity management investment.

Chapter 9. Names and Directories

Names are one of the first things you think about when the subject of identity comes up. Of course, identity is about more than names , but we name almost every object around us, and so names become one of the most common attributes stored in an identity.

Once you've got a bunch of objects with names, you want to be able to find them. Consequently, information technology systems are full of directories . There are directories for files, directories for email addresses, directories for domain names, and even directories for running processes. The simplest directories associate a name with something else, such as a file, address, IP number, or process.

This chapter will discuss names, directories, and the role that these play in digital identity.

Utah.gov: Naming and Directories

When I was CIO of Utah, directory issues seemed to take up a lot of our time and effort. When I became CIO, the state had been using the domain name http://state.ut.us. This domain name was not particularly easy to remember, and when you tacked on one or two subdomains to identify a department or agency, the affect was almost comical. For example, my email address was pwindley@gov.state.ut.us. The Governor remarked that he could almost feel people start to dance to the rhythm when he told them his email address.

In addition to the official domain name, agencies in state government had gotten into the habit of registering domain names in the .org TLD (top-level domain) for every publicly facing web site they started, and Utah managed over 100 domain names outside the official one. This created a huge problem in building brand awareness around the state's web site and meant that it was impossible to know when you were on an official state web site and when you were not.

Shortly after I came on board, I discovered that we owned the domain name http://utah.gov—much shorter, much easier to remember, and more authoritative. By fiat and with the Governor's support, I declared that Utah was moving to http://utah.gov. Now, this is not a strategy I'd recommend as a way to endear yourself to people, but it did accomplish the goal: within a month, we were using http://utah.gov as the domain name for our primary web server and contemplating how to migrate the rest of the organization.

There were two primary issues.

http://Utah.gov represented a namespace that had been delegated to the State of Utah and within which we could manage things like server names and email addresses.

The State had never had an enterprise strategy for naming, and each department and agency ran its own directory service for email and passwords—some ran many with each division controlling its own directories.

The first problem called for the creation of a registration process and the appointment of a registrar through whom organizations within the State could reserve subdomains within http://utah.gov. In essence, the job of the registrar was to create namespaces within http://utah.gov, and ensure that the names were unique, meaningful, and correctly recorded.

The second problem was more difficult. The first step was to create a voluntary program through which people who wanted a http://utah.gov email address could reserve a name. A simple program forwarded email sent to that name on to their real mailbox. That step was only temporary while we went through the difficult process of creating a naming procedure for assigning unique names (which would become email addresses) to each employee. We finally settled on a first initial/last name scheme with a series of fallback schemes for duplicates. The policy specifically prohibited names not associated with a person's real name to prevent people having email addresses like dumbo@utah.gov (unless this person's real name happened to be Doug Umbo, of course).

We also set up a metadirectory (more on this later) so that the directories in the agencies could cooperate to form a single large logical directory. This wasn't as easy as it should have been, because software running many of the directories hadn't been updated for years and didn't support metadirectory linking. Thus, creating a single directory included upgrade projects for a number of directories around the state. Further, creating this logical directory from already existing directories meant that the names in those directories first had to be normalized according to the naming scheme we'd come up with earlier.

The use of multiple distributed directories had advantages in performance and local control, but caused some difficulties with integration to other enterprise systems such as the HR system. The ultimate goal is to provision entries in the directory and even access-control rights based on the employee's status within the HR system.

The technical problems faced in creating an enterprise directory pale in comparison to the political challenges. To begin with, you're asking many people to change their email addresses—some of which had been in use for many years. This has personal and organizational costs. Second, some people, for political reasons, cannot be asked to change their email addresses. They get first pick of email addresses if there's a conflict. One executive director even insisted on having every possible permutation of her name and initials assigned to her to prevent anyone from accidentally sending mail intended for her to someone else with a similar name.

Ultimately we were successful in establishing a single namespace within http://utah.gov for all email and logins. We even converted the State's many web servers to subdomains within the http://utah.gov domain. The effort took almost two years to complete, but once done, it enhanced our ability to brand the State's web services and gave people email addresses that they could give to people without having to break out the bongo drums.

Naming

Naming is one of the fundamental abstractions for dealing with complexity. Names provide convenient handles for large, complex things—allowing them to be manipulated and referenced by some short, easy-to-remember string, instead of a longer, unwieldy representation. Filenames, for example, let us pick a meaningful handle for what ultimately is a collection of bits located on a particular set of sectors on a particular set of tracks on a particular set of disks.

Names also disassociate the reference from the thing itself, so that the underlying representation can change without changing the name. Perhaps the most familiar example of this is domain names. The domain name http://windley.com points to some IP address. If I decide to change the machine hosting the services at http://windley.com to another one with a different IP address, it's easily done and everyone referring to the name will still end up with the services that they are looking for.

Namespaces

A namespace is the universe within which a name is guaranteed to be unique and defines where the name has meaning. For this reason, namespaces are sometimes called "domains ." A family name (usually) acts as a namespace wherein given names are unique and meaningful. In an email address, the name (the part before the @ symbol) is guaranteed to be unique within the namespace (the part after the @ symbol). Filenames are unique within the namespace of the directory in which they reside.

Namespaces can be flat or hierarchical . The usernames on a standalone computer are an example of a flat namespace. A filesystem is the most familiar example of a hierarchical namespace. Domain names are another familiar example of a hierarchical namespace. Figure 9-1 shows how hierarchical namespaces work in domain names and filesystems.

Figure 9-1. Hierarchical namespaces for domain names and filesystems

Hierarchical namespaces have some interesting properties:

A path inside the hierarchy between the root node and a leaf node can be used to specify any entry in a hierarchical namespace.

Some paths are referenced and written from root to leaf (e.g., filesystems) and some are referenced and written from leaf to root (e.g., domain names).

In some hierarchical namespaces, like domain names, names can be both nodes and leaves. For example, I can reference both http://windley.com and http://www.windley.com with windley serving as a node in one case and a leaf in the other.

In other hierarchical namespaces, like filesystems, leaves and nodes are strictly differentiated.

In many hierarchical namespaces, the hierarchy reflects some actual hierarchy in the physical world. Usually, however the hierarchy in the namespace and the organization of the objects represented by the hierarchy do not have a one-to-one correspondence. For example, a filesystem is a hierarchy that exists entirely independent of the location of the bits on the disk and is strictly for the convenience of the user. With domain names, the hierarchy sometimes mirrors the physical world, but not always. There really is an organization called Yahoo! that owns http://yahoo.com. On the other hand, http://ftp://ftp.windley.com, http://www.windley.com, and http://mail.windley.com are all the same machine.

Uniform Resource Indicators: A Universal Namespace

As I write this, I've just ordered a new laptop from Apple for my wife for Christmas. One of the items in the confirmation email I received from Apple was a URL to the package-tracking page at FedEx. Have you ever thought of this package-tracking page as the homepage for that package on the Internet? Every package shipped via FedEx, UPS, and most other companies has a homepage that is named by the URI (Uniform Resource Indicator) that is used to reference it. The URI identifies a unique location on the Web, and that URI can be linked in another document or bookmarked for later reference—just like any other web page. The package "homepage" is no different that any other homepage on the Internet in that regard.

URIs are more general versions of URLs, or Uniform Resource Locators, the "web page address" that you type in the address box on your browser. Whereas URLs represent locations and, as such, typically correspond to real resources on the Internet, URIs can be used to name things within a single, global namespace even when there's no web location associated with the name. The structure is the same, however, and so many URIs also function as URLs.

URIs are one of the most important features of the Web. Without URIs, much of what we take for granted on the Web wouldn't work. As a simple example, having a universal namespace created using URIs allows any document, anywhere on the Web, to refer to any other document, anywhere on the Web, without the authors of the two documents having to agree on the same software package or server, beyond what's inherent in the Web itself. In fact, Paul Prescod has said: "If there is one thing that distinguishes the Web as a hypertext system from the systems that preceded it, it is the Web's adoption of a single, global, unified namespace."[*]

Apart from their use to identify resources on the Web, however, URIs are finding their way into many other contexts, because the URI system represents a universal namespace. Giving off-web resources, such as database records, a URI makes them part of this same universal namespace and ensures that they can be uniquely distinguished from other resources.

URLs and URIs have three major components:

A protocol identifier followed by a colon (e.g., http:).

A domain name indicating a unique computing domain on the Internet (e.g., http://www.windley.com).

A path component indicating what specific resource in that domain is to be identified (e.g., /llp?ln=windley&lang=en).

Taken together, these components are written in the familiar fashion:

There can be other components as well, including authentication information, port numbers, etc., but these three are the most common.

Cool URIs Don't Change

The URI is the public interface to a resource and, consequently, deserves great thought. One of the key factors that should be kept in mind when designing URIs is that they should not change—ever. This is not such a radical idea if you stop to consider that the URI is the name of the resource. In general, it's a bad idea to change the name of something, because we cannot possibly know all the places where the name is being used and, consequently, have no way of notifying those places when the name (the URI) changes . Thus, the URI should be chosen so that it is meaningful and unlikely to change. As the system is updated and maintained, the non-volatility of the URIs should be preserved. Numerous tools and techniques exist to make this possible. URL rewriting is one of the most powerful, allowing servers to resolve URI references to almost any resource.

Designing the URIs for your information system should be one of the most important tasks of the design phase. It may seem unusual to think of designing URIs. After all, don't we just let the network folks tell us our domain name and let the path fall out however it may? Not in a well-designed system. The last section talked about the three components that are typically part of a URL. All three are usually under our control and should be carefully chosen.

Don't construe this principle to mean that all resources need to be permanent. Just because URIs don't change doesn't mean that the resource has to be always available. There are some resources that are transitory and some that go out of existence. Even so, we shouldn't change their name.

[*] Prescod, Paul. "Roots of the REST/SOAP Debate," http://www.prescod.net/rest/rest_vs_soap_overview/.

Directories

Information system directories are everywhere. Most systems have multiple directories for address books, password files, lists of authorized users for particular applications, and so on. Even the much-maligned Windows registry is a directory. IT departments maintain large, enterprise-wide directories. In fact, the average IT organization maintains dozens of different directories of all types.

A directory service is a network-aware directory that allows a directory to be centrally managed and, at the same time, supply directory information to distributed applications. While we typically think of directories associating information with people, directories are useful for a wide range of IT and business needs. As such, directories are a critical part of the identity management infrastructure in most organizations.

A directory service contains a structured repository of information, often with complex interrelationships. The structure is defined in a schema : the metadata that defines the overall relationship of each piece of data stored in each entry in the directory to the others. The schema defines a structure within which the data is stored.

The schema specifies what properties can be associated with an entry, the allowed format or type of the property, and whether it is optional or mandatory. Each entry is defined as an object in the directory, and a given object contains the properties associated with that entry. Attributes can be thought of as name-value pairs, because it is customary to ask the value of a property with a given name for some specific entry.

As we've seen, it is not unusual for a namespace to be hierarchical and so too with directories. The hierarchical structure of the directory is stored in the directory tree. The directory objects at the nodes of the tree are called container objects, which can contain other container objects, or leaves or terminal objects. For example, there might be a container object that represents the organization that holds other container objects for the major organizational departments and so on, until you get to the people, printers, offices, and other resources at the leaves.

A directory service provides methods for querying the directory and managing the entries. These methods may be accessed by client programs designed for human interaction or by other programs that need access to the information contained in the directory.

In practice, directories can be physically distributed and their actions coordinated to produce a single, logical directory. Directories are also often replicated for both reliability and scalability reasons.

Directories Are Not Databases

From the description just given, it may be hard to distinguish a directory service from a standard database. Indeed, directories can be built inside databases, and many of the directories in use are just that. Still, enterprise-class directories are usually different from databases in some significant ways:

Directories are usually hierarchical whereas databases are usually relational. A directory can tell you all the people whose manager is Mary Jones and all the people who work in Salt Lake, but it can't easily tell you all the people whose manager is located in Salt Lake—a trivial task with a relational database.

Retrieval is more important than updating in a directory, and consequently, directories are optimized for retrieval. Typically, about 90% of the accesses in a directory are retrievals or queries with the remainder being additions or updates.

Directories are optimized for storing and managing many millions of small objects, whereas databases are typically optimized to store smaller numbers of larger objects.

Directories do not usually support transactions, meaning that operations on the directory cannot be coordinated with the operations of other applications so that they are atomic (i.e., all happen or none happen).

Directories offer extensive support for matching, partial matching, filtering, and other query operations.

Most directories have preconfigured schemas so that they are immediately usable for common purposes and are customizable only in very specific ways. Databases typically require considerable schema work before any data can be stored.

Directories are intended for external, wide-area use by default.

Directories are simpler to manage than relational databases. Trained database administrators, who specialize in creating and managing schemas, optimizing queries, and so forth typically manage databases.

Because queries and retrievals predominate, directories are easier to replicate for redundancy and performance reasons.

Even with these differences, and the advantages directories have in storing identity information, many organizations persist in using full-scale databases for relatively simple directory work.

An Example Directory

The http://Utah.gov directory I mentioned at the beginning of this chapter was more than a simple association of email addresses and authentication information. The http://Utah.gov directory contained as complete a collection of contact information for employees, contractors, and others as we could manage.

The http://Utah.gov directory contains names, phone numbers, job titles, email addresses, and office locations. The schema of this kind of directory is fairly simple, merely defining the fields stored in the directory and which are mandatory. Mandatory fields might include email address and phone number, or at least one or the other.

Such a directory is useful for more than just letting employees search for other employees. The directory can serve as an authoritative record of the employees and drive other enterprise information systems, including the email system, the HR system, and the finance and payroll systems. Also the directory serves as the authentication and authorization repository for systems and applications.

In a perfect world, the online directory is fed directly from authoritative sources. For example , employee phone numbers should be fed from the phone system's records so that they are always as accurate as possible. Alternately, the phone system could be fed from the directory. Of course, any printed version of the phone directory should be printed directly from the directory.

In creating an authoritative directory, it is important to understand the relationships between various enterprise information systems, know who updates what information, specify what information is authoritative, or canonical, and create a schema that can service these many needs. As I mentioned in the story about the http://Utah.gov directory, the politics are often the hardest part of a directory project. We'll discuss governance in Chapter 14.

Enterprise Directory Services

There are hundreds of different directory implementations in use. There are a few however, that are pervasive, or that serve as good examples of a type. This section discusses a few of these.

Domain Name System

The Domain Name System (DNS ) is the directory that maps domain names to IP addresses. DNS is built around the hierarchical domain namespace that we discussed earlier. DNS is a distributed directory and serves as the enabling infrastructure for a single, global directory of domain names. This directory is built from thousands of servers owned by thousands of organizations around the world. The architecture of DNS allows those machines to efficiently and cooperatively answer queries regarding domain name mappings and, at the same time, provide for delegated control over the mappings for any given namespace.

When a machine needs to resolve a domain name into an IP address, it queries a DNS server, looking to one of a few, usually local, servers for the answer. The local server may know the answer because the query regards a local machine or because it regards a machine that the DNS server has recently looked up. If it does not, the hierarchical structure of the name is used to arrive at an answer.

Suppose that a distant machine is looking for http://www.windley.com (see Figure 9-2). The machine contacts its local server, but that server does not know the answer. The local server contacts what is known as the root server for the top-level domain (TLD), in this case .com. The root server does not know the mapping for http://www.windley.com, but it does know the addresses of every DNS server for the domains in its TLD. The root server refers the local server to the DNS server handling http://windley.com, and the local server contacts the http://windley.com DNS server. Since that server knows the address for http://www.windley.com, the address is returned to the local server, cached, and sent to the original requestor. Of course, domain namespaces can be more than three deep and so can the associated servers. This process just goes on longer in those cases, but an answer is eventually returned as long as the mapping exists and the servers are properly configured and registered.

Figure 9-2. DNS query, referral, and answer pattern for http://www.windley.com

RMIRegistry

RMI is the Java Remote Method Invocation facility that provides the groundwork for creating client-server architectures over a network. RMIRegistry is the RMI directory. I refer to RMIRegistry only as an example of a class of directories that are largely unseen, but important to the enterprise. RMIRegistry and its cousins provide a directory for named references to remote objects in a programming environment.

Figure 9-3 shows RMIRegistry in action. When a particular server starts, it registers with RMIRegistry, giving it a name and a reference to the method on the server. Later, when the client accesses the method, it does not use a specific reference to the method, or even the machine and port the service is running on, but rather asks the RMIRegistry to return the reference to a service with a particular name. Once the RMIRegistry has returned the reference, the client can use it to contact the server and invoke the method.

There are several advantages to using a named directory of remote references:

The client does not need to be aware of implementation and deployment-specific information. Because it is insulated from this detail, the service is free to change these details without interrupting service or requiring the clients to be reconfigured.

The indirection created by the name can be used to scale the service since multiple copies of the server could be servicing clients. Similarly, the clients could be directed to the server that is most lightly loaded or one that is closer (in a network sense) to the client.

Figure 9-3. RMIRegistry is used to refer clients to services with named services

X.500: heavyweight directory services

X.500 is sometimes referred to as the granddaddy of directory services, because its definition is the basis for many of the directories used in enterprises. X.500 is a comprehensive specification of directory services that was originally conceived as a distributed, network-independent directory service for a messaging service whose specification was called X.400. X.500 specified an online white pages for the messaging system.

X.500 is actually a family of specifications developed by the International Standards Organization (ISO) and the International Telecommunications Union (ITU). Perhaps the most familiar of this family is the X.509 authentication framework specification that we discussed in Chapter 6. As we saw, X.509 specifies the public-key infrastructure that is the basis for the use of digital certificates in many applications.

X.500 defines a distributed directory service that is hierarchical in nature and operates on a common namespace. The service is designed to be vastly scalable and extensible. The X.500 standards are a canonical reference for directory service functionality and, as such, are frequently used by industry in defining the functionality, architecture, and terminology for other directory services.

LDAP

LDAP, the lightweight directory access protocol, was created to provide simplified access to some of the functionality of X.500. Building clients to work with X.500 is complex because of all the options built into the specification. X.500 also was built and modeled on an OSI network protocol stack rather than TCP/IP, the standard protocol of the Internet. LDAP was originally conceived as a protocol that could be implemented by a gateway to an X.500 directory service. Using the lightweight protocol, clients could more easily access the X.500.

Moreover, LDAP specifies an API for clients, something that X.500 lacks. Having an API allows standard software development kits (SDKs) to be created that contain much of the code necessary to use the directory service.

LDAP has evolved to be a complete directory service, instead of just a gateway to X.500 services, and a number of native LDAP directory servers exist on the market. Like X.500, LDAP specifies a network-based server with a hierarchical namespace. LDAP also specifies a method for doing referrals to other directories so that multiple LDAP servers can cooperate to create a single virtual namespace from the namespaces of the individual servers. While most LDAP servers provide a means of replication, there is, as yet, no replication standard, and so LDAP servers from different vendors do not always interoperate.

Many commercial directories, including eDirectory from Novell and Active Directory from Microsoft, are LDAP compliant, meaning they support the LDAP client API. Consequently, applications that understand the LDAP API can use them with relative ease. For example, Brigham Young University's staff and student directory has an LDAP interface, and I was able to couple Apple's Address Book application to it in just a few minutes, allowing me to search the directory using the same application I store all my contacts in. If you're interested in exploring LDAP and how it works, I recommend OpenLDAP, an open source LDAP server that is available at http://www.openldap.org.

Aggregating Directory Information

Single sign-on (SSO) has become something of a Holy Grail in many institutions to the point where many think that that is all identity management is. Anyone who's had to remember multiple user IDs and passwords just to use the email systems and file servers at work understands the pain that comes from having to manage multiple identity credentials.

Beyond causing pain for users, scattered identity data stores cause problems for the business as well. Integrating IT systems is important to businesses because of the added context that develops about a business activity when the data in multiple data stores can be linked. For example, linking the customer billing systems and the customer service systems gives employees processing invoices as well as employees providing customer service additional context about each customer.

For these reasons and more, aggregating identity information and finding the relationship between identity records is important. To aggregate identity data, organizations have four choices:

Build a single central identity data store.

Create a metadirectory that synchronizes data from other identity data stores in the enterprise.

Create a virtual directory that provides a single integrated view of the identity data stores in the enterprise.

Federate directories by tethering identity data stores together.

The first solution is included for completeness, but it's easy to see that creating a single data store of identity data is feasible only for small organizations. The goal of the latter three solutions is to present identity data as if a centralized identity data store exists, even when identity data is distributed across the organization. We'll discuss metadirectories and virtual directories here, but we'll save the discussion of federated identity for Chapter 12.

Metadirectories

Metadirectories are collections of directory information from various, diverse directory sources. The information from those directory sources is aggregated to provide a single view of the data. As we've pointed out, the modern enterprise maintains information in dozens of directories of all sorts. Not all of it is information that should be aggregated, but much of it can be without having to re-implement all of the directories and the applications that depend on them.

In the http://Utah.gov story, I told at the beginning of the chapter, each agency maintained its own directory of its employees and their contact information. Because most of them were using Novell's eDirectory, and Novell had a good metadirectory product, we chose that route to creating an aggregated identity store.

Metadirectories allow the enterprise to collect information from existing directories into a single identity store that can be searched and queried as if all the information were stored in a single directory. Some of the benefits of metadirectory technology include:

A single point of reference provides an abstraction boundary between applications and the actual implementation so that as the organization changes directory vendors, modifies system implementations, or reorganizes data, the applications still query a single source.

A single point of administration reduces the burden of accessing multiple directories with multiple interfaces to maintain the data.

Redundant directory information can be eliminated, reducing the administrative load in managing duplicate data.

There are some significant challenges in building a metadirectory. These fall into two primary categories: governance and technical. Governance includes issues such as information ownership, interorganizational administrative responsibilities, namespace choices, data formats and schemas, legal requirements, and information security. The implementation issues, while by no means trivial, are relatively straightforward and include the architecture of the metadirectory, namespace normalization, protocols, and procedures for data synchronization.

Metadirectories work through software agents whose job is to gather defined subsets of directory information from the group of directories in the metadirectory's purview. The job may not be as easy as aggregating unconnected records. In fact, the most interesting uses of metadirectories involve the aggregation of attributes about a single subject from multiple directories to form a super record.

As an example of this, Figure 9-4 shows an example of how a metadirectory might be used to aggregate records from two directories. The metadirectory gathers data about the employee's jobs and status from the HR directory and information about the employee's payroll record from the Payroll department's directory, and aggregates the data into a record that gives a single view of the employee. Of course, the metadirectory may ignore some attributes from the HR and Payroll directories, because they aren't relevant to the objective of setting up the metadirectory.

Figure 9-4. Metadirectory aggregating data from HR and Payroll directories using different standards

In this example, we aggregated data from only two sources, but that needn't be the case. We could create a super record for the employee from as many data sources as we have available. An obvious extension to the example in Figure 9-4 would be to include phone information from the phone system and email address from the email system.

Creating such a super record presents the problem of knowing which records in the various directories to combine together. Metadirectories copy the information from the underlying directories into a local store, effectively doing a join of the data in the various directory records. The join is done using a pre-identified mapping between unique identifiers in the underlying stores, called the join point. Each directory aggregated by the metadirectory is connected to the metadirectory though a channel called a namespace connector that manages the link. Each connector can be individually configured to filter attributes as desired.

One of the most difficult tasks in creating a metadirectory is eliminating namespace conflicts between the various directories being aggregated and providing a mapping between the metadirectory namespace and the underlying namespaces. More abstract, but just as important, is the problem of mapping schemas from the underlying directories to the metadirectory so that attributes are meaningfully integrated.

Another significant problem is one of data synchronization. When implementing the metadirectory, choices must be made about where data can be modified. The data could be writable only at the directory level, only at the metadirectory level, or at both levels. Clearly which strategy is chosen depends on the application, but when data can be changed at the directory and metadirectory levels, synchronization becomes significantly more complex.

When data can be modified at the metadirectory level, complex authorization schemes may be needed to ensure that information owners can modify only their own data. In the example in Figure 9-4, only designated HR department representatives would be able to update those attributes that flow from the HR directory and similarly for Payroll representatives.

Because metadirectories can synchronize data bidirectionally, they can be used to populate one directory with attributes from another directory. They can even perform a data-cleansing function, allowing attributes to be validated and then pushed back down to the underlying identity store.

Virtual Directories

Virtual directories are similar in concept to metadirectories in that they create a single directory view from multiple independent directories. They differ in the means used to accomplish this goal. Whereas metadirectories typically use software agents to replicate and synchronize data from various directories in what might be thought of as batch processes, virtual directories create a single view of multiple directories using real-time queries based on mappings from fields in the virtual schema to fields in the physical schemas of the real directories.

Another way of looking at the difference is that metadirectories have an associated data store where the directory information from the other directories is kept; virtual directories have no separate data store. They work by turning a single query to the virtual directory into multiple queries to the physical directories and then aggregating the returned results in real time to create the result given to the user. Eliminating the identity store means that virtual directories also eliminate the problems related to data synchronization and replication.

In this way, virtual directories present a real-time interface to underlying identity data. Queries and updates happen in real time and are reflected to other applications using the data, either from the virtual directory or the underlying stores. Typically, the interface to the virtual directory is LDAP. Like a metadirectory, the connections from the virtual directory to the underlying stores could use any of a number of protocols. As a result, the virtual directory creates a standard view of the data using a standard API.

Virtual directories are used typically in cases where real-time access to frequently changing identity data is important.

Conclusion

Directories are one of the fundamental pieces of a digital identity infrastructure. Many organizations can put themselves far down the path to having an effective enterprise identity management by attacking their directory problems first.

Chapter 10. Digital Rights Management

Access control using authentication and authorization works well for limiting how people use digital resources in a controlled environment, such as the corporate network. But traditional access control schemes do not work as well when the people or resources are outside of the organization's direct control.

Documents released under non-disclosure agreements illustrate this problem. Once the document has been released to someone outside your organization, that person could make unlimited copies, send the document to your competitor, and so on. Encrypting or password protecting the document does little to deter this unwanted behavior, because the person receiving the document must unlock it to use it. The authorization schemes we've discussed don't address the problem either, because access control depends on a trusted environment. Absent another solution, we're left with trust and legal remedies.

Digital rights management (DRM) is an attempt to address these problems. Rather than merely controlling the actions that an entity can perform on digital resources, DRM provides mechanisms for controlling the particular uses to which a digital resource can be put. This is a tough problem, and as we'll see, good solutions are sufficiently draconian that they impose a significant burden on users and have raised the ire of digital rights activists.

Digital Leakage

Digital leakage is the loss, whether intentional or inadvertent, of confidential data in digital form. The loss might take the form of a trade secret sent to a competitor, the premature release of financial data to an analyst or market, or the leak of embarrassing information to the media. Digital leakage occurs from seven primary sources:

Employees sometimes steal valuable confidential information for personal use or to sell.

Confidential information is sometimes accidentally distributed. This can happen when an email containing confidential data is addressed to the wrong person.

Computer theft and hacking results in the release of confidential data despite the best efforts of computer security professionals.

Employees, partners, and customers often do not understand the real value of information that your organization has shared with them and do not adequately protect it.

Changing alliances result when relationships between the organization and employees, partners, and customers end, leaving these entities in possession of information to which they are no longer entitled.

Lost or stolen devices can result in the loss of information more valuable than the device itself. Often, companies sell used computers that contain confidential data.

Disgruntled employees and others may maliciously redistribute or otherwise release confidential information.

Digital leakage is costly. A survey published by PricewaterhouseCoopers and the American Society for in Industrial Security[*] in 1999 found that on average, large organizations lost confidential or proprietary information 2.45 times in a year and each incident cost an average of $500,000. The survey estimated that the cost of digital leakage in the Fortune 1000 in a single year was $45 billion.

[*] American Society for Industrial Security and PricewaterhouseCoopers. "Trends in Proprietary Information Loss Survey Report," http://www.pwcglobal.com/InformationLoss/.

The DRM Battle

With those kinds of statistics, you'd think DRM would be a technology that everyone could love, but it has been at the heart of some of the most acrimonious debates of the digital age. The movie and recording industries are worried that electronic distribution of their works will result in violations of their copyrights and, as a result, diminish their bottom line.

This is a classical problem for digital rights management. The producers of the digital goods want to release them to people beyond their control and give them only specific rights (e.g., to listen to, but not copy, the music).

The problem is that the needs of the copyright holders are in direct conflict with the wants of their customers. Consumers of movies and songs want open access, open formats, and access to works no longer for sale in traditional distribution channels. Napster illustrated the powerful drivers in this market. People want to be able to share music and movies with others.

Needless to say, this is a complex issue. The reason for bringing it up here is that the battle over copying movies and music has colored many people's view of DRM and created an atmosphere where any discussion of DRM creates strong feelings. DRM might be the right technology for solving critical access-control problems for your organization's digital resources. Unfortunately, DRM has become synonymous with the battle over copyrighted music and movies. You can probably avoid the DRM battle and the emotions it engenders if your motive is to control activities on digital resources rather than to use DRM as part of a business plan that restricts customer actions.

Apple iTunes: A Case Study in DRM

Apple's iTunes and its associated music store provide a real-world example of DRM in action. iTunes will play unprotected MP3 format audio files, but when a user purchases music form the Apple music store, the audio file is downloaded in a format called AAC. Apple wraps the AAC file in a DRM system called Fairplay. The standard rights allow a purchaser to listen to the song in an unlimited way on up to three computers and to burn the song to a CD.

This set of rights was chosen to try to match the value that user's place on the audio file to the price Apple wanted to charge. For example, Apple could disallow burning AAC format songs to CD, because they control the client, but that would decrease the value of the file for many people.

Apple also has to be able to administer rights remotely to provide customer service. For example, if I purchased a song, installed it on three computers, and then sold one of those computers and bought another, I can contact Apple to have the rights reset on my music collection, allowing it to be installed on my new computer. Without this ability, audio files purchased on iTunes would quickly lose their value as people upgraded their computers.

This case study is a good example of the additional burden placed on a company in controlling access to content using DRM. Restricting rights for content costs real money, because the content has to be administered and it reduces the value of the content to users.

Features of DRM

Digital rights management is, of course, about more than just protecting music and movies. DRM is a technology all of us would like to use in certain circumstances. For example, when I send my Social Security Number to my bank, I'd like to be able to control how it is used. As another example, wouldn't it be nice to be able to send your credit card number to an online merchant and attach specific rights to it: the right to use it to facilitate a single purchase and not be stored or transferred. All of us have digital information that we'd like to be able to send to someone else without giving them unlimited rights.

SealedMedia, a DRM vendor, lists some important features that DRM systems should have to be effective.

Persistent security, wherever the digital resource exists

Separation of right of access from the information itself

Management of discrete rights (viewing, printing, editing, print-screen)

Dynamic allocation and withdrawal of rights

Support for both online and offline work

Audit trail of actions and activities performed on the document

Support for multiple common document formats using the same security tools

Simple integration with existing workflow and applications

Integration with document/content management systems

A perfect DRM system with all of these features does not exist. You will likely have to prioritize these properties for your particular application and evaluate solutions on that basis. The next section describes a reference architecture that shows how some of these features can be accommodated.

DRM Reference Architecture

Figure 10-1 shows a reference architecture for a digital rights management system. The reference architecture is by Bill Rosenblatt, et al., and is discussed in some detail in the book Digital Rights Management: Business and Technology (John Wiley & Sons). The reference architecture points out the key interactions in a DRM system and also exposes some of the weaknesses in current DRM schemes.

In Figure 10-1, there are three primary participants. The client is an application invoked on behalf of the entity wanting to access and use a digital resource. The content server is the application that is invoked on behalf of the entity supplying the digital resource. The license server is the application invoked on behalf of the person who owns or controls the rights associated with the good. The license server and content server might be operated by the same entity or they might not. For example, the owner of the goods may contract with multiple distributors to supply the good but control the licensing centrally.

In the reference architecture, the client, on behalf of the user, requests a specific resource from the content server (1). The content server uses a content repository along with product information to create a content package. The content repository might be part of the content server itself or a standalone content management system. The product information specifies price and other product-specific information. It makes sense to separate the product information from the content, because the same content may be sold as different products differentiated by customer class, additional services or warranties, and so on.

Figure 10-1. A DRM reference architecture

The content is delivered in an encrypted content package that contains both the content and metadata. Whether the content is streamed or delivered as a single package is inconsequential to our discussion. The metadata usually includes information such as title, author, rights holder, and other information about the content as well as information that uniquely identifies this content and transaction.

The DRM controller (2) contacts the license server (3) associated with the content package to retrieve a license for the content. The DRM controller sends the license server information about the content package and the identity credentials for the entity that invoked it.

The license server checks the identity credentials (4) using whatever identity infrastructure is available to it for authentication and then consults a rights database (5) for authorization. We'll see an example of an XML language for expressing rights later in this chapter.

There may be a financial transaction (6) if the user is required to pay for the license. Alternately, the license server may require some other consideration such as registering and providing contact information. Once consideration for the license has been received, encryption keys (7) are retrieved based on the content package identity and these keys are used to generate a license that is sent back to the DRM controller (8) as an encrypted package containing a statement of rights and a set of keys for unlocking the content package. The license is encrypted to protect the keys used to unlock the content package and to ensure its integrity.

The DRM controller decrypts the license and uses the keys contained in it to unlock the content. The content can be sent to a rendering application (9) for display (10).

The client, in managing rights, may store information about usage in the content package. Usage data is stored with the package, rather than separately, to ensure that even if the content package and license are moved to another client, the usage restrictions are honored and audit trails are continuous.

The client application is a critical component in this scheme, because the client application, rather than the client, receives and processes the keys. This overcomes, in part, the problem of a user unlocking the digital content and then using it in an uncontrolled fashion, because the client application can ensure the permissions carried in the license are honored.

Trusted Computing Platforms

If you were applying a little creative thinking during the preceding discussion of the DRM reference architecture, you probably thought of several ways that the scheme could be defeated. That issue is the chief weakness of DRM. As we've seen, for the user to view or otherwise use the content, it has to be rendered in a usable format, and that allows ample opportunity for the content to be redirected to a use that wasn't specifically authorized.

The iTunes example illustrates some of the problems :

Once an audio file has been put on a CD, it can be ripped in another format, such as MP3, without any DRM, because the DRM wrapper can't be transferred to the CD.

Remote rights administration, needed for customer service, opens up further opportunities for people to exploit the system and get around DRM.

The Fairplay system has been cracked, and methods for playing Fairplay-protected files outside of iTunes have been published on the Internet.

Even if all of these problems were solved, the analog feed going to the speakers could always be redirected to a recording device, and the audio file could be re-encoded in another format.

These examples show just how hard it is to really protect content in a digital format. In addition to the tradeoffs made by Apple that were examined in the case study, Apple is inconveniencing their legitimate users while still allowing the rights of copyright holders to be undermined by determined crackers.

These problems have led to numerous calls for trusted computing platforms that would ensure that the DRM client was run in an environment that kept even determined attackers from gaining access to protected content illegitimately. The basic idea is to protect every component of the end-user system in a way that disallows illegitimate use. When we say "every component," we're being literal—right down to the keyboard. Building a trusted computing platform requires the cooperation and coordination of both hardware and software manufacturers in very sophisticated way.

The nature of trusted computing systems and the debate surrounding them is beyond the scope of this book, but they are being advanced by companies as powerful as Microsoft and Intel and countered by numerous user advocacy groups. Because trusted computing platforms are still in the future, DRM will remain an exercise in making the theft of unauthorized rights sufficiently inconvenient that most users will only access content legitimately.

Specifying Rights

One of the most important features of a DRM system is the ability to specify and manage rights. Rights are a special kind of authorization, and much of what we learned about authorization in Chapter 8 is applicable to DRM. The differences lie in the fact that DRM is meant to restrict actions on a much finer-grained scale than we typically deal with in a standard authorization system.

Authorization rights typically center around whether a subject is allowed to read, modify, or create objects. As we saw, we usually specify the rights for classes of users against classes of objects in order to make the task manageable. In DRM, we often want to give specific rights (for example, the right to view but not copy) to specific people (Ted in accounting or a particular customer) for specific time periods (for the next two hours or three more times). That makes the task much more difficult. The problem can be made tractable by being able to build general licenses and derive specific licenses from them automatically.

We also saw in Chapter 8 that separating authorization rights from the objects being protected increases the ability of operators to take protective action. Specifically, when rights are associated with objects, removing rights for a particular user means visiting each object the user might have had rights to. The goal of systems like RBAC is to specify rights separately, so we can remove access rights across the board with a single, reliable action.

In DRM systems, the nature of the problem does not make this solution possible. Since our problem statement is to protect content that is not directly under our control, the rights will generally be sent outside the systems we directly control to some other system that will enforce them. Offline access to protected content is usually a requirement, and so it is not practical for the client application to check back with the license server each time the content is accessed. Thus, rights can be difficult or impossible to revoke once they've been issued.

XrML

There are several proprietary DRM systems and most of them have proprietary languages or systems for specifying rights. XrML is an XML-based rights management language. We'll discuss it briefly because it is gaining widespread acceptance as an open format for specifying rights and because it illuminates the kinds of features that you want in a rights language. XrML is a large standard, and this section is not intended to be a tutorial. More detailed information on the XrML standard can be found at http://www.xrml.org. The examples given here are based on the Example Use Cases document that accompanies the XrML 2.0 specification.

The following simple example gives us a feel for XrML. In English, the license grants a specific RSA public-key holder the right to print the contents of an object identified by a URI as many times as she wants before Christmas day, 2005.

    <license>
      <grant>
        <keyHolder>
          <info>
            <dsig:KeyValue>
              <dsig:RSAKeyValue>
                <dsig:Modulus>Fa7wo6NYf...</dsig:Modulus>
                <dsig:Exponent>AQABAA=  =</dsig:Exponent>
              </dsig:RSAKeyValue>
            </dsig:KeyValue>
          </info>
        </keyHolder>
        <cx:print/>
        <cx:digitalWork>
          <cx:locator>
            <nonSecureIndirect
               URI="http://www.contentguard.com/sampleBook.spd"/>
          </cx:locator>
        </cx:digitalWork>
        <validityInterval>
          <notAfter>2005-12-24T23:59:59</notAfter>
        </validityInterval>
      </grant>
    </license>

You can see that the <keyHolder/> elements contain the user's key. The <print/> element gives the allowed action. The <digitalWork/> element identifies which resource the license applies to. The <validityInterval/> element specifies the interval for which the license is valid.

This is an example of an XrML end-user license. More complicated license specifications are possible. As an example, suppose that PDQ Records wishes to allow university libraries to allow their patrons to check out digital music. There are three types of rights that might be specified.

The first, very general type concerns one entity granting rights to a class of content to a class of entities. Here's an example:

PDQ Records allows university libraries to issue limited end-user licenses within certain parameters for any content they have purchased.

The second type is a policy specification. In a policy specification, an entity spells out specific rights that classes of users have regarding classes of content. Here's an example:

Brigham Young University will grant faculty the right to check out any PDQ Records song in its collection for up to six months. Student may checkout any PDQ Records songs in the BYU collection for three weeks. Anyone may play any PDQ Records song in the BYU collection on a library computer at any time.

The third, and most specific, type is an end-user rights license. Here's an example:

BYU grants Alice the right to play "When the Thistle Blooms" for three weeks.

Notice the hierarchy of rights contained in these examples. The first is very general and grants very broad rights to a class of entities. The rights specified in the second policy statement must fit within the rights granted in the first statement. Similarly, the rights granted in the third policy statement fall within the rights granted in the second statement, and hence those granted in the first as well.

In addition to specifying rights, this example assumes that Brigham Young University can uniquely identify itself and assert that it is a university in a way that is trusted by PDQ Records, and that Alice can uniquely identify herself and assert that she is a student in a way that BYU can trust.

XrML can be used to specify each of these cases, although the XML documents for each are lengthy and not included in the interest of brevity. Interested readers are referred to the Example Use Cases document that accompanies the XrML specification.

Conclusion

The battle over DRM and many of the controversies surrounding it are unimportant to your organization, provided that your intent in using DRM is to control confidential and sensitive data rather than using it to control the actions of your customers. The key point to remember is that DRM is not usually effective against determined attacks. The more valuable the content, the more difficult it is to adequately protect. Consequently, the cost of DRM increases linearly with the value of the content. Because no DRM system is perfect, any DRM system should be carefully evaluated for its particular application and the trade-offs examined thoroughly.

Chapter 11. Interoperability Standards

Interoperability is the most significant challenge to any enterprise contemplating building an identity management infrastructure. As a result, there are a number of standards bodies working to build a common foundation in some of the areas of digital identity management that we've already discussed, including:

Integrity and non-repudiation

Confidentiality

Authentication and authorization

Directories

Representing and managing authorization policy

This chapter briefly describes the problem domains and some of the standards being developed to address them. The idea is not to provide detailed tutorials on any standard, but rather to familiarize you with the ideas, concepts, and working models behind them.

Standards and the Digital Identity Lifecycle

This chapter will discuss several specific standards in these problem domains, including SAML, SPML, and XACML. Of these, SAML has wide industry adoption and the standard is well developed. The other two are not as widely supported. SPML has some adoption, but the standard is still undergoing transition and improvement. I'm not convinced that XACML, as it is defined now, will ever be widely adopted.

Why discuss standards that aren't fully baked? Simply because such standards represent a class that fits a problem domain. If XACML doesn't make it, something like it will. In Chapter 5, we discussed the digital identity management lifecycle. Figure 11-1 shows the lifecycle annotated with the name of a standard that supports that phase. You can see that SPML and XACML both fill important needs in the lifecycle.

Figure 11-1. Standards and the digital identity management lifecycle

These standards are all based on XML. XML is the de facto language for designing standards because of the wide variety of tools for creating, managing, and using XML. While using these standards to solve identity problems requires XML expertise, our discussion will not require much more than a passing acquaintance with XML.

Integrity and Non-Repudiation: XML Signature

XML Signature is used to ensure message integrity on all or part of an XML document. The standard doesn't define new signature methods, but instead specifies how the digital signature technology we've already discussed can be used inside XML documents. As we've seen, digital signatures can be used to ensure message integrity by showing that data has not been changed through some error during transport or as the result of a malicious attack. Digital signatures also prevent a signer from repudiating a message. XML Signature is a foundational standard that is used by other standards we'll discuss in this chapter, such as SAML, because they are also based on XML.

Like any standard, XML Signature has options for numerous contingencies that make it seem complicated, but at its heart it is quite simple. An XML Signature is contained in a <Signature/> element and consists of three main parts:

The <SignedInfo/> element contains a reference to the data that has been signed along with information about how it was made canonical, what signature method was used, relevant digest information, and any transformations that were applied.

The <SignatureValue/> element contains the actual signature.

The <KeyInfo/> element contains the key information necessary to validate the signature.

Using the XML Signature standard, parts of a document can be signed, and multiple entities can sign the same or different parts of a single document.

The following example of an XML Signature shows all three parts:

    <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

     <SignedInfo Id="fizz">
      <CanonicalizationMethod
        Algorithm=
           "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
      <SignatureMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" />
      <Reference
        URI="http://www.fizzco.com/news/2003/07/27.xml">
       <DigestMethod
         Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
       <DigestValue>f7dhfj38sdjdf89fjskfhweol=</DigestValue>
      </Reference>
     </SignedInfo>

     <SignatureValue>KLUR~HF=...Ax54</SignatureValue>

     <KeyInfo>
      <X509Data>
       <X509SubjectName>
         CN=Phil Windley,O=The Windley Group LLC,ST=Utah, C=US
       </X509SubjectName>
       <X509Certificate>
         MIID5jCCA0+gA...lVN
       </X509Certificate>
      </X509Data>
     </KeyInfo>

    </Signature>

Much of the example is self-explanatory. The signature method, digest method, and certificate data refer to the algorithms and formats that were described in Chapter 6 such as the X.509 standard; they are just enclosed in XML. Other elements require some explanation.

One such element is <CanonicalizationMethod/>. XML documents must be made canonical, because there is more than one way to represent a single base document in XML. As a simple example, consider that the element <foo/> is the same as <foo></foo>. Consequently, before the document can be signed, it has to be rendered in a canonical form so that the signatures match. Several canonization methods are available, and the <SignedInfo/> block specifies which was used.

This XML Signature used to sign the document is enclosed in the <SignatureValue/> element. You won't find the signed document here, however. The signature is applied to all or part of the XML document using the <Reference/> element. In the example, the <Reference/> element points to an XML document on http://www.fizzco.com by giving its URL. The <Reference/> element also specifies the digest method used to create the hash and its value.

Confidentiality: XML Encryption

Like any other communication on the Internet, any XML document can be encrypted in its entirety and sent across the wire to be decrypted at the other end. The problem with this, however, is that encrypting obfuscates the entire message. Frequently, parts of an XML message need to be sent in the clear. For example, SOAP is an XML format that computers use to exchange remote procedure calls over the Web. In use, all or part of the body of a SOAP message may need protection but the headers must be sent in the clear so that intermediaries can see routing and other information.

Alternately, the channel could be encrypted—using SSL, for example—ensuring that any message transferred across that channel is protected in transit. The problem with channel encryption is that the message is in the clear on any intermediate machines. To get around these problems, the XML Encryption standard is designed to allow partial encryption of an XML document.

Like the XML Signature standard, the XML Encryption standard has many parts to deal with multiple contingencies, but understanding the core functionality is not difficult. Any encrypted data in an XML document is identified using the <EncryptedData/> element. The <EncryptedData/> element consists of two parts:

An optional <EncryptionMethod/> element that gives <KeyInfo/> information. The <KeyInfo/> element is the same as the one defined for the XML Signature specification.

A <CipherData/> element that can either include the actual encrypted data inside a <CipherValue/> element or a reference to the encrypted data enclosed in a <CipherReference/> element.

As an example of how XML Encryption might be used, consider an online payment system that transmits an order by using an XML document. The order document contains all the information about the order and includes the credit card information for the purchaser in a <PaymentInfo/> element. We would like most of the order to be left in the clear so that it can be processed, but would like to protect the credit card information and decrypt it only when the payment is processed. XML Encryption allows us to do that. The following is an example of an <EncryptedData/> element inside the <PaymentInfo/> element:

    <PaymentInfo>
      <CardName>John Smith</CardName>
      <BillingAddress>...</BillingAddress>
      <EncryptedData
          Type='http://www.w3.org/2001/04/xmlenc#Element'
          xmlns='http://www.w3.org/2001/04/xmlenc#'>
        <CipherData>
          <CipherValue>sh748fjl4...</CipherValue>
        </CipherData>
      </EncryptedData>
    </PaymentInfo>

In this example, the cipher value field would hold the encrypted credit card number and expiration date. I've left out the <EncryptionMethod/> element in this example, because we can presume that the information is encrypted and decrypted by systems under the control of a single organization that has set the method and controls the keys. The values will be available only to processes that possess the private key for the payment system.

Authentication and Authorization Assertions

Automated identity systems need a way of creating and distributing authentication and authorization assertions . Kerberos, for example, is one system that does this. Recently, SAML, or the Security Assertion Markup Language, has gained considerable traction as a security credential standard. In addition to standardizing ways to use XML to represent security credentials, SAML defines a protocol for requesting and receiving credential data from a SAML authority service. We'll see in Chapter 12 that SAML is used as part of several other standards for creating federated identity systems.

In practice, SAML usage is straightforward. A client makes a request about a subject to a SAML authority, and the authority returns assertions about the identity of the subject for a particular security domain. For example, the subject might be a person identified by his email address in a DNS domain (e.g., john@windley.com). There are several common SAML usage patterns that we'll explore later in this section.

A SAML authority is an online service that responds to SAML requests. SAML responses are called assertions. SAML authorities come in three types: authentication authorities, attribute authorities, and policy decision points (PDPs). These three types of authorities return three distinct types of assertions:

SAML authentication assertions

When a SAML authentication authority receives a request about a particular subject's credentials, the result is returned as a SAML authentication assertion. An authentication authority assets that subject S was authenticated by means M at time T. For example, "Subject Alice in company http://windley.com was authenticated using a password at time 2003-05-06T13:20:00-05:00."

SAML attribute assertions

Once an authentication assertion is returned, a SAML attribute authority can be asked for the attributes associated with the subject. These are returned as a SAML attribute assertion. An attribute authority asserts that subject S is associated with attributes A, B, etc. with values X, Y, etc. For example, "Subject Bob is associated with attribute Department with value Engineering and attribute Email with value bob@engr.windley.com."

SAML authorization assertions

A PDP returns a SAML authorization assertion in response to a request about a subject's permissions with respect to certain resources. A PDP asserts that subject S has (or has not) been granted permissions for action A on resource R given evidence E. For example, "Subject http://A.com/services/foo is granted permission to read the file at http://B.com/bar as evidenced by assertions A1, A2, and A8."

In practice, a single authority can produce all three types of assertions, or authorities may produce a subset. Authorities can be both producers of assertions as well as consumers of assertions from other authorities.

Assertions contain the following common elements:

Issuer ID and issuance timestamp

A globally unique assertion ID

Subject, including a name and security domain and optionally the subject's authentication data

Optional, additional information provided by the issuing authority; this is called advice

Conditions under which the assertion is valid such as the assertion validity period (e.g., NotBefore and NotOnOrAfter)

Audience restrictions

Target restrictions such as the intended URLs for the assertion

Application-specific conditions

The following example shows a SAML attribute request:

    <samlp:Request ...>
      <samlp:AttributeQuery>
        <saml:Subject>
          <saml:NameIdentifier
            SecurityDomain="A.com"
            Name="cn=Bob"/>
        </saml:Subject>
        <saml:AttributeDesignator
          AttributeName="Department"
          AttributeNamespace="A.com"/>
      </samlp:AttributeQuery>
    </samlp:Request>

This request asks the attribute authority which department Bob@A.com is associated with.

The following XML is an example of a SAML authentication assertion:

    <samlp:Response
      MajorVersion="1" MinorVersion="0"
      RequestID="128.14.234.20.90123456"
      InResponseTo="123.45.678.90.12345678"
      StatusCode="Success">

      <saml:Assertion
        MajorVersion="1" MinorVersion="0"
        AssertionID="123.45.678.90.12345678"
        Issuer="Example Company, Inc."
        IssueInstant="2003-01-14T10:00:23Z">

        <saml:Conditions
          NotBefore="2003-01-14T10:00:30Z"
          NotAfter="2003-01-14T10:15:00Z" />

        <saml:AuthenticationStatement
              AuthenticationMethod="Password"
              AuthenticationInstant="2003-01-14T10:00:20Z">
          <saml:Subject>
            <saml:NameIdentifier
              SecurityDomain="A.com"
              Name="cn=Alice" />
          </saml:Subject>
        </saml:AuthenticationStatement>
      </saml:Assertion>
    </samlp:Response>

In this example response, the authentication authority is asserting that Alice@A.com was authenticated on January 14, 2003 at 10:00:23 using a password, and that this authentication is valid between 10:00:30 and 10:15:00 on the same day.

As you can see, SAML requests and responses do not define a wire-level protocol, but are rather carried on some other form of transport, such as HTTP, from the client to the SAML authority. There are any number of possibilities about how SAML might be used. The following section explores four likely scenarios.

Example SAML Use Cases

We'll look at four primary SAML use cases: two for web browsers and two that use SOAP. The first, called the pull profile , shows how SAML can be used to create a single sign-on between two web sites. The pull profile uses SAML artifacts (in essence, tokens) that are passed from one site to another using a URL query string. The site making the assertion (the source site) creates a link to the destination site containing the artifact in the URL, and when the user clicks on it, the destination site receives the artifact as part of the HTTP GET request. The artifact is a key that the second site can then use to pull the actual assertion from the source site.

The pull profile is illustrated in Figure 11-2. In the example,

Mary visits http://Airline.com and purchases airline tickets. During her interactions with http://Airline.com, she has logged in and has been authenticated.

At the point of purchase, http://Airline.com recommends that Mary rent a car from http://RentalCar.com and provides a link containing an embedded SAML artifact.

When Mary clicks on the link, the artifact is transferred to http://RentalCar.com.

http://RentalCar.com makes a SAML request using the artifact.

http://RentalCar.com receives an authentication assertion in return, allowing Mary to use the services on http://RentalCar.com without signing onto http://RentalCar.com directly.

Figure 11-2. Browser pull profile

These examples assume that there is a contractual arrangement between http://Airline.com and http://RentalCar.com, and that Mary has given her consent for http://Airline.com and http://RentalCar.com to federate her identity. We'll discuss those issues more in Chapter 12.

Another way of using SAML with browsers is called the push profile . Here, the source site creates a web form containing the complete assertion. When the user submits the form, it is sent to the destination site using an HTTP POST, effectively pushing the assertion from the source site to the destination site using the HTML form mechanism. In this scenario, the source site digitally signs the assertion using XML Signature so that the destination site can be assured of its authenticity.

The push profile is illustrated in Figure 11-3. In this example, the following occurs:

Mary visits http://Airline.com just as she did in the last example.

At some point in the session, http://Airline.com returns an HTML form that contains the complete, digitally signed identity assertion.

Mary submits the form to http://RentalCar.com. http://RentalCar.com checks the digital signature and, being satisfied with the credentials, processes Mary's request.

Suppose Mary decides to rent a car. http://RentalCar.com might need additional information from http://Airline.com. To get that information, http://RentalCar.com can make an attribute request, perhaps asking for Mary's credit card and address information to complete the purchase. Attribute requests and http://Airline.com's responses would be

Figure 11-3. Browser push profile

packaged and sent across the wire in the bodies of SOAP messages, as shown in Figure 11-4. This use case is called a direct request and response. In this example:

http://RentalCar.com makes a request.

http://Airline.com responds.

Figure 11-4. Direct request and response

In the example shown in Figure 11-4, the SAML requests and responses are the payload of the SOAP message, because they are the data of interest. Sometimes, however, SAML is used to authenticate a SOAP message itself. In this case, called the web services profile, the SAML assertion is about the contents of the SOAP body and is contained in the SOAP header. The assertion in the header is a SAML artifact or digitally signed assertion, just as in the pull and push profiles, that pertains to the action being taken in the body. The web services profile is illustrated in Figure 11-5.

Figure 11-5. Web services profile

The primary benefit of SAML is that the security context for a subject travels with the subject (in the form of the assertion) so that a new context doesn't need to be recreated at each associated site. This reduces the need to store and synchronize identification, authentication, and authorization information at each site. The data is more secure, single sign-on can be implemented, attributed-based authorization can be supported, and multiple service providers can be federated using the same language and protocols.

Identity Provisioning

SAML addresses the problem of how to exchange identity information between systems. That begs the question: how do these various systems set up the accounts and services that are being accessed? We learned in Chapter 5 that this happens in the provisioning and propagation phases of the digital identity lifecycle. Because a single identity may need to be used in multiple systems, automated provisioning is necessary. Automated provisioning is supported through the use of provisioning standards.

SPML , or Service Provisioning Markup Language, is an XML-based language for exchanging provisioning requests and responses. As mentioned at the beginning of this chapter, SPML is rather new and supported only by a few vendors, but it, or something like it, will be necessary to create automated identity systems. The goal of the SPML specification is to support the automation of all aspects of managing an identity throughout its entire lifecycle, including creating, amending, or revoking the identity. This section will discuss SPML and its use in automated provisioning.

SPML is defined in terms of three primary roles:

Requesting Authority (RA)

The entity making the provisioning request.

Provisioning Service Provider (PSP)

A SPML-enabled software service that responds to SPML requests from the RA.

Provisioning Service Target (PST)

The entity that performs the provisioning. Sometimes the PSP and PST are the same software agent, but they needn't be. The crucial difference is that while the PSP is required to understand SPML, the PST is not. So the PSP may be a frontend for other software services that do not understand SPML.

Like SAML, SPML defines a request-response protocol, with the RA making a request, in SPML, and the PSP returning a response or appropriate error code, in SPML.

There must be a preexisting trust relationship between the RA and the PSP. This trust relationship could be represented using SAML and transported using the web services profile shown in Figure 11-5. The SAML assertions would be carried in the SOAP header, and the SPML request and response would be transported as the payload in the SOAP body.

PSPs can make requests of other PSPs. So, for example, while the PST is not required to understand SPML, if it does, then the PSP communicating with it is functioning as an RA making a request of another PSP.

An example will serve to clarify the relationships and responsibilities of RAs, PSPs, and PSTs. Figure 11-6 diagrams an example of the provisioning activities related to creating a new account in an e-commerce system. The e-commerce sign-up process, acting as an RA, sends a SPML request to the e-commerce provisioning server, acting as the PSP, asking that a new e-commerce account be created. As we've seen, the SPML request could be carried in a SOAP message with a SAML authentication in the header establishing the identity of the RA. The e-commerce provisioning server, acting as the PSP, would use the SAML assertion to determine whether the RA is authorized to create an account of the type specified in the request and, if so, proceed.

Figure 11-6. E-commerce provisioning

The e-commerce provisioning server completes four different actions with four different PSTs to complete the provisioning action:

The e-commerce provisioning server creates an appropriate record in the account database. In this case, the account database is acting as a PST. This action is authenticated in whatever manner the database is configured to use, and the e-commerce provisioning server translates the SPML request into SQL and sends it to the account database using JDBC or something similar.

The e-commerce provisioning server creates a directory on the filesystem for storing files related to the new account using JNDI or something similar. Again, the commands and authentication are those appropriate to the PST, in this case, a filesystem.

The e-commerce provisioning server requests that the web server's authentication system, perhaps an LDAP server, create an account. Like actions 1 and 2, this task is accomplished by translating the SPML request into the native command set of the LDAP server, perhaps JNDI.

The e-commerce provisioning server, acting as an RA, sends a new SPML request to the credit card company's PSP, requesting that a merchant account be provisioned. The credit card company's PSP, in turn, makes some number of requests of other PSTs or PSPs to service the request.

Note that in all but the last task, the PSP translated the SPML request into the native API of the PST, because none of these servers understood SPML.

As a provisioning language, SPML creates and manages identifiers. There are two kinds of identifiers: those used globally within the provisioning system and those used by each of the target systems, or PSTs. These identifiers might be used to refer to subjects or resources.

The identifiers created by the PSTs need to be unique only within the PST's namespace. For example, in the e-commerce system discussed previously, the identifier in the accounts database would be the record ID. The identifiers associated with an individual PST are called Provisioning Service Target Data Identifiers (PSTD-IDs).

To be useful, PSTD-IDs must be related to some global identifier in the overall system. The SPML standard refers to this as a Provisioning Service Object Identifier (PSO-ID). The RA might choose the PSO-ID, or the PSP might manage it. In our example, the user is probably prompted for a memorable ID when she signs up, and so the RA would choose it, ensuring that it's unique. The PSP or RA must keep track of the PSO-IDs, and map them to the various PSTD-IDs associated with the identity.

SPML Requests and Responses

SPML requests take one of several forms:

<addRequest/>

Used to request the creation of an account

<modifyRequest/>

Used to request that an account be updated

<deleteRequest/>

Used to request that an account be deleted

<searchRequest/>

Used to query the PSP about accounts and their properties

<schemaRequest/>

Allows an RA to request the provisioning schema from the PSP

These requests can have operational attributes attached and can be done in batch as well as singleton mode. The requests for adding, modifying, deleting, and searching the PSP are self-explanatory—they correspond to the types of actions you would expect to see in any data store. The schema request allows an RA to discover the types of requests it is allowed to use so that it can build appropriate add, modify, delete, and search requests. Discovery allows SPML to be flexible, because RAs can, if properly fashioned, react to changing PSP provisioning schema and adjust their actions accordingly.

To see how this might work, consider an employee provisioning system that manages the accounts on a Windows domain, GroupWise system, corporate HR directory, and Unix file server. Whenever a new employee is hired, new accounts are provisioned on each of these systems from a single action on the HR system. Now, imagine that the company has added a new corporate intranet that requires that an identity be provisioned on a web server. Rather than hardcoding into the RA the list of systems on which employees should receive accounts, we could write RA to query the PSP before making its request for the list. Now, by merely adding the new system to the schema of the PSP, any RA can create the right accounts.

To give you an idea of what a SPML request-response pair looks like, consider the following example of an <addRequest/> element that creates an email account for a user:

    <addRequest>
      <attributes>
        <attr name="objectclass">
          <value>urn:...:SPML:interop:interopUser</value>
        </attr>
        <attr name="cn">
          <value>Jane Doe</value>
        </attr>
        <attr name="mail">
           <value>Jane.Doe@windley.com</value>
        </attr>
        <attr name="description">
          <value>Jane Doe interopUser Subscription</value>
        </attr>
        <attr name="memberLevel">
          <value>1</value>
        </attr>
        <attr name="company">
          <value>Jane Doe Supply Co</value>
        </attr>
        <attr name="registrationTime">
          <value>17-Nov-2004 12:00 </value>
        </attr>
      </attributes>
    </addRequest>

As usual, the XML is verbose, but perfectly readable. The PSP might respond to this request as follows:

    <addResponse result = "urn:...:SPML:1:0#success">
      <identifier type= "urn:...:SPML:1:0#EMailAddress">
        <id>Jane.Doe@windley.com</id>
      </identifier>
      <attributes>
        <attr name="mailBoxLimit">
          <value>50MB</value>
        </attr>
      </attributes>
    </addResponse>

This response returns the new identifier and an attribute giving the mailbox size. Other examples of SPML requests and responses can be found in the OASIS Core document on SPML at the Oasis Provisioning Services Technical Committee's web site.[*]

[*] See http://www.oasis-open.org/committees/spml.

Representing and Managing Authorization Policies

As we'll see in Chapter 18, policies play an important role in building an identity infrastructure, because they help define the context within which systems are built and operated. However, merely writing a policy does not ensure that it's correctly promulgated and implemented throughout the IT infrastructure.

For example, in the State of Utah, there are over 1,000 separate systems, not including desktop computers, that are affected by IT policies created by the CIO's office. What's more, several hundred people administer these systems. In this situation, there is little hope that any policy made will be consistently executed on these many disparate systems.

This problem plagues large enterprises. Access-control policies are written in English and then implemented on dozens or even hundreds of different systems individually. Each of these systems has a proprietary configuration language. Compounding the problem, policies change frequently. Every time the access control policy is changed, the entire configuration has to be redone. Only a hopeless optimist would believe that this job is done correctly.

Figure 11-7 shows how a policy server might solve this problem. In the figure, the policy is translated to some machine language and placed on the policy server where it can be sent directly to the various systems in the enterprise. As we discussed in Chapter 3, current state of the art in policy languages is a far cry from the ideal situation pictured here.

Figure 11-7. Using a policy server

eXtensible Access Control Markup Language (XACML), is one standard that is addressing this problem. XACML is an XML-based language for storing and sharing access-control policies. XACML is a language for the policy decision point (PDP). As illustrated in Figure 11-7, the goal of XACML is that each PDP in the organization could use a single policy without constant manual configuration and reconfiguration. There are significant hurdles to achieving this result, including the variety of meanings that a single policy can have in various systems and contexts. As I mentioned at the beginning of this chapter, XACML is not widely accepted yet, and there are other, competing standards, but it serves as a good example of the type of language that will fill this need.

Whereas SAML provides a format for exchanging identity and access information, XACML provides a format for describing what to do with that information. There is some overlap between SAML and XACML: both provide a request/response language. The two standards are complimentary, however, using the same definitions for subjects and actions. But XACML goes beyond SAML in creating a rule-based language for expressing access-control policies.

Because XACML is at its core a programming language, it is much more complicated than the other standards that we've discussed, which are used for merely representing data. Policy rules can be created to allow fine-grained control over access. These rules can be based on items such as:

Attributes of the user making the request (e.g., only people who work in accounting are allowed to access this document)

The action to be taken (e.g., reading a document versus updating a document)

The time of day (e.g., users can log in only between 9 a.m. and 5 p.m., or during their shifts)

The authentication mechanism (e.g., allow only users who present a digital signature as their authentication mechanism to log in)

The protocol used for access (e.g., allow HTTPS access, but not HTTP access for this resource)

These can be combined using Boolean connectives to create complex policies (e.g., allow users from accounting to update this document only over HTTPS but allow users from other departments to read it anytime over HTTP). XACML also has a concept called a "combining algorithm," which allows multiple, perhaps conflicting, policies to be applied to a resource and some action taken as a result. For example, the combining algorithm might simply state "deny access if any policy denies" or it might be more complicated.

The following example is taken from "XACML: A New Standard Protects Content in Enterprise Data Exchange" on the Sun Developer web site.[*] The XACML request states that an unstated subject wants to log into a server called "SomeServer." The request has three primary parts: it identifies the subject making the request, names the resource, and describes the action.

    <Request>
      <Subject/>
      <Resource>
        <Attribute
          AttributeId="urn:oasis:...:resource-id">
          <AttributeValue>SomeServer</AttributeValue>
        </Attribute>
      </Resource>
      <Action>
        <Attribute AttributeId="ServerAction">
          <AttributeValue>login</AttributeValue>
        </Attribute>
      </Action>
    </Request>

This request would be processed using a policy statement that is expressed in XACML's rule language. Reading through this example will give you an idea of what XACML policies look like. These policies are human readable, but for the most part, they would be created using an access control-policy tool rather than being written by hand. We'll step through one.

The top-level element in an XACML policy is <Policy/>:

    <Policy
      PolicyId="SamplePolicy"
      RuleCombiningAlgId=
      "urn:...:xacml:1.0:rule-combining-algorithm:first-applicable">

The <Policy/> element contains a <Target/> element and zero or more <Rule/> elements. The <Target/> element defines the class of subjects, resources, and actions to which the policy is applied. The <Rule/> element defines an action, permit or deny, and the conditions under which that action is taken.

Here's an example of a <Target/> element that applies to any subject, and any action, on a resource identified by the string "SomeServer."

    <Target>
     <Subjects>
       <AnySubject/>
     </Subjects>
     <Resources>
      <Resource>
       <ResourceMatch
          MatchId="urn:...:xacml:1.0:function:string-equal">
         <AttributeValue>
             SampleServer
         </AttributeValue>
         <ResourceAttributeDesignator
             AttributeId="urn:...:xacml:1.0:resource:resource-id"/>
       </ResourceMatch>
      </Resource>
     </Resources>
     <Actions>
      <AnyAction/>
     </Actions>
    </Target>

Notice that operators and types are long and unwieldy in the style of XML-based languages. This is a reflection of the truth that XACML is not designed to be written by humans, but rather by programs. After the <Target/> element, the <Policy/> contains <Rules/>. The following two rules, taken together, require that a subject log in.

The first rule requires the login and further stipulates that it must be between the hours of 9 a.m. and 5 p.m. Its effect, given as an attribute to the <Rule/> element, is to Permit. The <Rule/> begins with an ID and its effect:

    <Rule RuleId="LoginRule" Effect="Permit">

The first part of any rule can be a target that is matched to determine whether this rule applies or not. Somewhat confusingly, these conditions are also called <Target/>. The following target ensures that this rule is used only when the action is "Login."

     <Target>
      <Subjects>
       <AnySubject/>
      </Subjects>
      <Resources>
       <AnyResource/>
      </Resources>
      <Actions>
       <Action>
        <ActionMatch
           MatchId="urn:...:xacml:1.0:function:string-equal">
         <AttributeValue
             Login
         </AttributeValue>
         <ActionAttributeDesignator AttributeId="ServerAction"/>
        </ActionMatch>
        </Action>
       </Actions>
      </Target>

Also included in the <Rule/> is a condition that enables the rule's action ("permit," in this case) only if the condition is true. The following condition is true only between 9 a.m. and 5 p.m.

      <Condition FunctionId="urn:...:xacml:1.0:function:and">
       <Apply
        FunctionId=
        "urn:...:xacml:1.0:function:time-greater-than-or-equal">
       <Apply
        FunctionId="urn:...:xacml:1.0:function:time-one-and-only">
        <EnvironmentAttributeDesignator
            AttributeId=
             "urn:...:xacml:1.0:environment:current-time"/>
       </Apply>
       <AttributeValue>
        09:00:00
       </AttributeValue>
      </Apply>
      <Apply
       FunctionId=
        "urn:...:xacml:1.0:function:time-less-than-or-equal">
       <Apply
        FunctionId="urn:...:xacml:1.0:function:time-one-and-only">
        <EnvironmentAttributeDesignator
          DataType="http://www.w3.org/2001/XMLSchema#time"
          AttributeId=
            "urn:...:xacml:1.0:environment:current-time"/>
       </Apply>
       <AttributeValue>
        17:00:00
       </AttributeValue>
      </Apply>
     </Condition>

This condition looks very complicated but is, in fact, quite simple when reduced to pseudocode:

    ($ENV(current_time) >= "09:00:00")
      AND ($ENV(current_time) <= "17:00:00")

If the first rule is inapplicable because of either its target or condition, then the default action, defined by the second rule, is to deny access (note that its effect attribute is Deny). Since it has no target or condition, this rule is always applicable.

    <!-- A final, "fall-through" Rule that always Denies -->
    <Rule RuleId="FinalRule" Effect="Deny"/>

The response generated from the application of this rule is simple, and contains a decision (Permit, in this case) and a status.

    <Response>
      <Result>
        <Decision>Permit</Decision>
        <Status>
          <StatusCode Value="urn:...:xacml:1.0:status:ok"/>
        </Status>
      </Result>
    </Response>

Since XACML is a complete declarative programming language, there is much more to it than can be covered in this simple example. XACML may not, in its present form, become the standard language of the PDP, but the problem is real and requires a standardized solution, and I'm convinced that XACML or something very similar to it will eventually be available for configuring policy on multiple systems from a single specification.

[*] See http://developer.java.sun.com/developer/technicalArticles/Security/xacml/xacml.html.

Conclusion

Standards such as XML Encryption, XML Signature, SAML, SPML, and XACML are important factors in the interoperability of components in an enterprise-wide digital identity infrastructure. The wide-scale use of standardized languages by vendors of products that operate at various phases of the identity lifecycle will do much to automate the routine operational tasks of identity management.

Chapter 12. Federating Identity

Brigham Young University recognized the need for an identity infrastructure for their web-based initiatives early, and in 1996, they started a project called "Route Y." Over the years, Route Y has come to stand for many things, but from the start, it was about identity. Faculty and students were given unique, University-wide identifiers, and the directory was made available to projects inside and outside of BYU's information technology group. Over the years, as new web-based applications have been added to the campus computer systems, they've all used this common identity directory.

I recently rejoined the Computer Science faculty at Brigham Young University after being away for several years. I immediately noticed that BYU's strategy for building web-based applications had paid off. I sign in once and can do everything from accessing class rolls to turning in grades. I also noticed, however, that the convenience stops at the edge of campus. When I visit BYU's insurance provider or 401K partners, I have to log in again using a separate ID and password.

For all its power, BYU's directory-based identity infrastructure stops at the boundaries of the organization. Even technologies like virtual or metadirectories don't help. Being separate organizations, with different missions, policies, legal requirements, and security domains, BYU and its health insurance provider insist on managing their own directories of employees and customers. Even so, providing a good web experience requires that these identity domains cooperate. That's what federated identity is all about.

Centralized Versus Federated Identity

We've seen how the proliferation of digital identities creates significant challenges. Users have trouble remembering multiple usernames and passwords. IT organizations are called on to build and operate directories and other identity repositories. One potential solution to this problem is to create a strong central identity infrastructure, but as my story about BYU's directory services points out, centrally managed repositories can't solve the problem of cross-organizational authentication and authorization.

Another approach is to leave the identity resources in their various distributed locations but create a federation that links them for solving identity problems. In Chapter 9, we discussed metadirectories and virtual directories. Federation differs from these two technologies in a crucial way: federation doesn't try to create a single view of the identity infrastructure. That's really just a way of pulling the identity into a central repository, even if it's virtual. Instead, federation defines processes and supporting technology so that disparate identity stores can cooperatively solve identity tasks. Federation means that local identities and their associated data stay in place, but they are linked together through higher-level mechanisms.

The Mirage of Centralized Efficiency

At first, centralized identity management may sound appealing. However, visions that a centralized approach will promote security, cost savings, or management simplicity are a mirage. Centralized digital identity systems do not scale. Identity relationships are inherently web-like in structure, while centralized technologies like directories are hierarchical. Every individual can have relationships to many other individuals, organizations, applications, and services. Every enterprise must contend with many sets of overlapping and often changing identity relationships.

The primary tenet of centralized identity is the creation of a single, globally unique identifier. Various identities on other systems are then mapped to this global identifier. Mapping those relationships to a single identifier is conceptually simple but difficult to implement.

When I was the CIO for Utah, this problem came up time and time again as we attempted to reconcile various data stores across the state in order to create citizen web applications. There are two primary problems.

First, all of the local identifiers must be converted to a single canonical ID, or a new mapping database must be created. I attended many meetings where people got together to hash out the format for a new identifier, how the mapping would take place, and who would pay for the conversions. Anyone who's gone through a process like this will inwardly groan whenever it's mentioned.

Second, even after the system is in place, changes at any one point ripple out through the network. Adding a new user, a new application, or even a new function within an application, requires a new round of talks to ensure the central ID remains valid. There are real governance issues, and if it's hard in a single organization to decide these issues, it's nearly impossible when the problem spans organizational boundaries.

Network Effects and Digital Identity Management

You've probably heard of Metcalfe's Law, which states that the value of a network grows as the square of the number of nodes. The reason is simple: the value is the number of potential relationships, not the number of nodes. Digital identity suffers at the hands of Metcalfe's Law, because the difficulty of digital identity problems is proportional to the number of relationships.

The Internet uses a distributed, packet-switched architecture to manage the complexities arising from Metcalfe's network effects. I can't imagine a centralized architecture that would have scaled to the size of today's Internet. The only solution was to make each node smart enough so that relationships between any two hosts on the Internet could be established without any centralized coordination.

Efforts to create centralized digital identity systems fail to appreciate the lessons of the Internet's distributed architecture:

First, the distributed architecture of the Internet makes it difficult for attackers to break the network by concentrating their efforts in one place. In contrast, in a centralized system, the benefit of learning how to scam or break the system is very high, making it worthwhile for criminals to invest heavily in discovering a means of compromising the system.

Second, distributed systems are less prone to commercial or political abuse. I've discussed the governance problems I faced in creating centralized identity stores. The reason is simple: no one wants their data under someone else's control.

Third, a distributed architecture degrades gracefully, making it less susceptible to catastrophic failure. In a centralized system, by contrast, once a key part of a centralized system becomes compromised, the entire system along with all its connected data is untrustworthy.

Numerous real-world examples show how centralization is more difficult in practice than in theory. For years, enterprise software vendors have claimed strong return-on-investment from integrating customer or supply-chain data. The reality has seldom lived up to the promises. Though enterprise resource planning, customer relationship management, and enterprise application integration have delivered some value, it has seldom been without significant pain and implementation expense. The problems in integration are often ones of identity.

Beyond the IT challenges, centralized digital identity systems run into significant perceptual and user-behavior obstacles. End-users have no desire to do the work of putting all their information in one place. They don't necessarily want yet another username and password combination. Concerns that a single company could monopolize identity data, or that governments could use such a repository to gain access to personal data, inevitably dog centralized identity schemes. The backlash against Microsoft's HailStorm system, trials of wireless RFID tags by retailers, and efforts to incorporate unique IDs into Intel CPUs, are cases in point.

Ultimately, the greatest limitation of centralized identity management is that it cannot address the requirements of an increasingly distributed business environment.

Federation in the Credit Card Industry

The early days of the credit card industry provide many excellent lessons for the move from centralized to federated identity management, as well as the challenges of implementing a federated model. We will use it for illustration throughout this chapter.

Bank of America launched the first multi-merchant credit card in 1958. Previously, consumers only had credit relationships with individual merchants. BankAmericard was a way to extend small consumer loans to Bank of America customers at the time of a purchase, for any merchant who chose to participate. In essence, the bank functioned as a central clearinghouse, vouching to merchants for its customers' ability to pay.

Bank of America's charge card was so successful that it attracted rampant competition. In 1966, five other California banks collaborated to issue a competing product, MasterCharge , with a significantly larger customer base. In response, Bank of America began franchising BankAmericard to other banks nationwide. This meant Bank of America no longer had a direct relationship with all the merchants and consumers in the network. It had to establish mechanisms for merchants to verify cards through the card-issuing banks, and for the banks involved to settle transactions. What emerged was a federated financial network. Every bank controlled its own relationships with consumers and merchants. The federation allowed that data to stay in place by creating common policies for member banks to exchange information.

Benefits of Federated Identity

Federated digital identity can deliver several compelling benefits to organizations. Let's return to the example with which I started the chapter. TIAA-CREF provides 401K benefit management to BYU employees and thousands of other organizations. As we've seen, when I log into the BYU intranet, I gain access only to resources within the BYU firewall. Because BYU and TIAA-CREF do not federate their identity infrastructures, I have to log into the TIAA-CREF site whenever I follow the link from Route Y to TIAA-CREF.

Even if it were practical, TIAA-CREF has no desire to put its proprietary information or user databases inside each of the organizations they serve, and those organizations don't want to turn over their internal user information to an outside vendor. The solution is to federate the identity systems. In that scenario, when I followed the link to the TIAA-CREF page, BYU and TIAA-CREF would automatically and securely exchange identity information. My verified BYU identity would be matched with my customer record at TIAA-CREF, thereby providing direct access without a separate login.

This example suggests how federation takes the benefits of single sign-on and extends them beyond an organization's boundaries. However, there is more to federation than extending a single sign-on. Federation respects the distributed, heterogeneous architecture of the current IT environment. As we've seen, efforts to implement unique, all-encompassing identifiers inevitably fail as requirements and relationships change. By contrast, federated identity enables controlled linkages among the distributed identities of a user and allows for efficient management of digital identity in a radically distributed world. As organizations integrate more pervasively with trading partners and outsourcers, federated identity provides a flexible mechanism to authenticate users from partner organizations and provide them with seamless access to protected online resources.

Federated identity systems can address the integration needs that drive centralized identity efforts, without the associated inefficiencies and costs. Some requirements, such as basic operational standards , certification and auditing, security, fraud prevention, and privacy protection, are common across any digital identity system. A federated system provides an umbrella of common policies and mechanisms across disparate local identity systems

Digital Identity Standards

Digital identity federation requires a loosely coupled software architecture for automatically exchanging identity information between heterogeneous systems. Standards are essential for this process. We saw some of the foundational standards for this in Chapter 11. There are many more. Figure 12-1 shows the interrelationship among some of the various federation standards.

There are three primary groups creating standards for federation: an alliance between Microsoft and IBM, OASIS, and the Liberty Alliance.

Microsoft, IBM, and the WS-* Roadmap

In April 2002, Microsoft and IBM published a joint whitepaper outlining a roadmap for developing a set of web service security specifications. Commonly called WS-*, the specifications work in a modular fashion to build on each other to create an overall effect.[*]

The first jointly developed specification from IBM and Microsoft, WS-Security, offers a mechanism for attaching security tokens to messages, including tokens related to

Figure 12-1. The interrelationship among federation standards

identity. The roadmap described in the 2002 whitepaper included other specifications that support web services.

WS-Policy is a language for describing the security policy of a particular web service. For example, WS-Security can use several different security token systems such as SAML assertions or Kerberos tickets. Using WS-Policy, a web service might specify that it accepts SAML 1.1 assertions but not Kerberos tickets.

WS-Trust is a language that allows services to some trusted authority that one token be exchanged for another. This action is the basis for federation, because essentially what's happening is one site's security token is being exchanged from an equivalent one on the other site.

WS-Federation orchestrates the WS-Trust interactions to allow different security domains to federate by brokering trust of identities, attributes, and authentication between participating web services.

There are many other specifications in the WS-* constellation. Each attempts to solve a particular problem in web services interoperability.

OASIS

OASIS, the Organization for the Advancement of Structured Information Standards, is a not-for-profit, international consortium that produces e-business standards.[*] OASIS has published several important web services standards including SAML, SPML, and XACML. SAML is widely used as an identity standard in web services and, as shown in Figure 12-1, is the foundational standard for much of what's happening in federation. Our discussion of SAML in Chapter 11 highlighted use cases that showed how SAML can be used to federate identity between the web sites of an airline and a rental car company. Other standards in the figure create a context for web sites to exchange SAML tokens to enhance interoperability.

Liberty Alliance

The Liberty Alliance is a consortium of 170 companies that develops specifications for federated identity management.[*] It originally envisioned creating a single comprehensive federated identity specification. In March 2003, however, it released a new blueprint that described three separate specifications that can be used together or independently:

Identity Federation Framework (ID-FF)

Allows single sign-on and account linking between partners with established trust relationships

Identity Web Services Framework (ID-WSF)

Allows groups of trusted partners to link to other groups, and gives users control over how their information is shared

Identity Services Interface Specifications (ID-SIS)

Will build a set of interoperable services on top of the ID-WSF

Internet2 and Shibboleth

One federation standard not shown in Figure 12-1 is Shibboleth, the identity architecture project of Internet2.[†] Internet2 is a coalition of U.S. universities building a next-generation Internet. Shibboleth, which is based on SAML, enables single sign-on and federated administration of access to restricted resources. The user's site and the target site negotiate based on attributes (e.g., faculty member at a particular school, student in a particular course) rather than the unique identity of the user, an approach designed for active privacy management.

The Future of Federation Standards

So where do these standards all lead? At this point, it's not clear. While there is overlap among standards from each group, each was begun with a slightly different problem set in mind. It's clear that the OASIS standards are being adopted and used by both the Liberty Alliance and the IBM/Microsoft consortium. What's less clear is whether or not the Liberty standards and the WS-* standards will converge and, if so, how. The market and how users adopt the various standards will make the final decision.

This uncertainty needn't be a barrier for most organizations, however. Most of the products I've looked at support multiple protocols. The products will adapt as the standards change, and in many cases, your application will not be dependent on the specifics of the standard. My advice is to press forward, keeping a wary eye on the standards process and being careful about limiting your specific dependencies on any of them.

[*] See http://www-106.ibm.com/developerworks/library/ws-secroad/.

[*] See http://www.oasis-open.org/.

[*] See http://www.projectliberty.org/.

[†] See http://shibboleth.internet2.edu/.

Three Federation Patterns

Despite the compelling benefits, federation is an unfamiliar model for most organizations and, consequently, will not appear overnight. Successfully deploying federated identity systems will require software, standards, expertise, and best practices that have become widely available only in the last year or so. Moreover, there are significant challenges once the technology is in place. Those challenges will be met in a variety of ways, but it's likely that they will all fall into one of three patterns:

Ad hoc federation

Ad hoc federation is characterized by bilateral relationships between organizations wishing to create a federated identity arrangement.

Hub-and-spoke federation

Private federation islands forming around large organizations characterize the hub-and-spoke pattern.

Identity federation network

The identity federation network pattern is characterized by the formation of an independent member-owned identity platform.

Even though these patterns are independent from one another, I believe that most organizations will explore them in sequence: first entering into ad hoc relationships, then joining coalitions dominated by large players in their industry, and ultimately recognizing the benefits of joining an independent identity network.

Pattern 1: Ad Hoc Federation

The first pattern for federating identity consists of adding relationships one by one on an ad hoc basis. As noted in the previous section, there will be powerful incentives to implement federated digital identity. In the ad hoc pattern, companies will do so piecemeal, linking with individual business partners (or a small group of them) to accomplish specific goals.

Ad hoc identity federation has been going on since networks were first invented. When I was the CTO at iMall, for example, we had an agreement to resell our e-commerce services to customers of Verio Web Hosting. We created a system that allowed Verio's customers to sign on to their e-commerce accounts automatically after being authorized by Verio. The system also provisioned e-commerce accounts at iMall on the basis of an account provisioning action at Verio. The system was completely custom, because there were no standards for federating identity in 1999. We did similar partnerships with other companies, but the number was severely limited because of the initial expense of setting the system up and the cost of maintaining it as the participating companies changed their systems to roll out new products.

Standards such as SAML and SPML that are available now would have solved many of the technical hurdles, but we would have still faced significant challenges creating the legal framework and operating procedures necessary to make the partnerships work. Doing this once is not difficult, but it doesn't scale easily. As a consequence, the size of ad hoc federations will be limited by the ability of any player to negotiate and enforce bilateral trust agreements with a broad range of partners.

As an initial step, companies can be expected to federate identity internally. For example, they will tie together customer touch points through CRM implementations. At the same time, an unrelated IT project may give employees single sign-on access to the corporate intranet and their 401K information. Moving outside the firewall, organizations will connect their backend systems with other companies upstream and downstream in their supply chains. With partnerships and acquisitions, they will add new federation points.

Unfortunately, the ad hoc federation scenario does little to alleviate the problems of centralized identity management described earlier in this chapter, because the federation relationships are bilateral or, at most, limited to a few companies in a private multi-lateral arrangement. The same set of technical and legal decisions must be made for each connection. If one party prefers the Liberty Alliance specifications and another favors WS-Federation, they must negotiate an accommodation prior to establishing a new link. Questions such as security, performance standards, and liability for fraud will emerge time and time again, with no obvious answers. Such issues become increasingly intractable as ad hoc identity federations overlap. A company may believe it can manage its own identity relationships, but each of its partners has its own web of relationships, its own partners, and so forth—conflicting requirements will abound as these disparate networks come together.

Pattern 2: Hub-and-Spoke Federation

Without a clear, single set of basic federation standards and a neutral organization for establishing rules of liability, recourse, and risk management, ad hoc federation devolves to a free-for-all, with major identity players creating unique federations to meet their own needs. Smaller players will have little say in these federations, but they will participate out of necessity. The result will be archipelagos of identity domains linked by bilateral agreements. The islands in these archipelagos will, at least initially, be relatively small and isolated from one another, because bilateral trust agreements do not scale well. The company at the center will determine the policies and technical elements of the cluster. This is the idea behind hub-and-spoke federation.

As these clusters of identity federation grow, each additional agreement will bring new costs in the form of legal fees and administrative expenses, and new risks as enforcement becomes more complicated. If a federation member decides to join another federation, it must start the process again. Software, implementation work, and legal agreements from one cluster won't likely transfer to another.

A small number of powerful players will emerge as focal points of identity domains that they control. Imagine a Boeing cluster, a General Motors cluster, an http://Amazon.com cluster, and so on. Smaller organizations seeking federation will be left with almost no bargaining power, because the hubs will set rules to their own advantage. Powerful players dominating particular identity federations will be able to structure those federations to provide them with something approaching virtual centralization. Although they won't store identity information centrally, they will be able to manage access to the information distributed across the federation. Other participants will chafe at the control exerted by the central players.

At the same time, the hubs will find themselves struggling to manage networks of growing complexity. With other network members participating only grudgingly, disputes are inevitable. Both large and small participants may try to twist the system to their own advantage. The large central players, who may even compete in other areas with other members of the federation, will never fully win the trust of those subject to their policies.

Bank of America: a cautionary tale

This is precisely the scenario that unfolded in the credit card industry, once Bank of America franchised its credit card. The licensing strategy worked—to a point. Bank of America did gain a certain level of ubiquity with its card, but it also gained a system that seemed incapable of holding up under the strain put on it. The BankAmericard system was beset with security problems, delays, and outages.

What's more, the licensees were growing unhappy not only with the system, but with the licensing strategy itself. The licensees saw the need for cooperation—for a credit card federation—but they did not enjoy the fact that participating in the BankAmericard federation meant being beholden to one large bank that was getting rich off their efforts and dictating the terms under which they were cooperating.

In the days when Bank of America controlled the system, it struggled under both technical and operational burdens. Having developed the credit card for its own use, Bank of America had neither the expertise nor the inclination to devote sufficient resources to the infrastructure necessary for interchange with other banks. Participating banks delayed processing payment requests to earn undeserved interest, distorted the "merchant discounts" and other processing fees they were entitled to retain, and squabbled over responsibility to cover fraud and other losses.

Scenario 3: Identity Network

The third pattern is federation within an identity network . An identity network is an independent entity focused solely on the technical and administrative aspects of identity federation. An identity network will typically gain support once a sufficient number of individual participants have become frustrated with the challenges of operating in an ad hoc bilateral environment, or a hub-and-spoke network has begun to groan under its own weight.

That is exactly what happened in the credit card industry. Just two years after Bank of America began franchising BankAmericard, the situation had become so unworkable that it called its licensees to a meeting in Columbus, Ohio to try to address the problems. The meeting quickly turned into a session of acrimonious finger-pointing. Finally, Dee Hock, vice president at a licensee bank in Seattle, stood up and suggested that the group form a committee to study the core problem in more depth. The participants immediately created the committee and appointed him chair.

Hock's committee recommended that the banks collectively create a new kind of organization that was not only cooperative, but decentralized. Hock saw that participants in the BankAmericard federation were independent, competing organizations that needed to cooperate on standards, rules, and processes for the cross-boundary use of a device (the BankAmericard). However, the federation could not persist over time if the organization couldn't address the needs of all issuers of the BankAmericard equally.

In response to these recommendations, the BankAmericard federation became independent in 1970. The result was a unique entity, initially called National BankAmericard Inc. and later rebranded as Visa. Visa is an autonomous, member-owned organization. Visa exists to coordinate the cooperation required from an ever-expanding membership, thus enabling them to issue and manage credit cards even as they compete with one another. Visa took the islands of banks that had grown weary of the autocratic licensing system of BankAmericard, and brought them together under shared governance, a common purpose, and a new vision. It created a genuine network.

Visa's success is indicative of the benefits of an independent identity network. Challenges that are peripheral to any member of the network—ensuring the smooth interchange among participating institutions, selecting technical standards, defining liability responsibilities, determining common policies, managing security and fraud risks, enforcing privacy policies, resolving disputes among members, and interfacing with governments—are the core mission of an identity network. When federation occurs through an identity network, the network can avoid the redundancy inherent in the ad hoc and hub-and-spoke models, and can devote its full attention to ensuring that the network scales effectively and serves the needs of all its members.

An identity network could provide an ordered ecosystem for enterprises and individuals to interact, transact, and compete. Operating as a neutral, decentralized legal entity, the identity network would define common security and privacy standards for all members. Disputes among members would be settled within the network, and the member-owned network has the wherewithal to enforce its standards, rules, and judgments. Noncompliant members would be subject to liability, recertification requirements, fines, suspensions, or even expulsion.

Such a network would also facilitate interoperability among its members in three ways.

First, through information sharing and testing requirements, the identity network would allow partners within federations to implement publicly available standards more effectively.

Second, it would provide a framework for deployment of protocol translation software or web services, whether provided by the network itself or by third parties.

Third, the network's common processes, policies, and technology ground rules would allow participants to interoperate smoothly, even though particular standards are not mandated network-wide.

In contrast to hub-and-spoke identity federations controlled by powerful central players, an identity network serves the self-interest of all participants, big and small. Because the network is a general-purpose, member-owned entity, no individual member is able to design or manipulate network rules and processes to gain an unfair advantage over other members. Small companies can compete on an equal footing with large companies, and no single company can leverage network resources to gain a monopoly.

Addressing the Problem of Trust

Federated identity can operate only in an environment in which relations of trust between parties have already been established. In an ad hoc federation, trust is established one bilateral agreement at a time. Each trust relationship is a custom creation. In hub-and-spoke federations, the trust relationship is created between the central player and the smaller players. Since trust is not transitive, unless the larger player is willing to incur the liability, these smaller players also often need to establish trust relationships through legal agreements between themselves. In networked federation, trust is established through agreements with the network and a common foundation that apportions liability.

In each of these patterns, trust comes from the participants and the structure of their relationships; it cannot be created through technical specifications alone. SAML, for example, does not specify how much confidence should be placed in an identity assertion. Nor does SAML, or most other digital identity standards, directly address privacy policies. It is up to each organization to decide what level of security precautions and privacy protections are sufficient and then to negotiate baseline operational agreements with partners.

Federated identity cannot establish trust—it can only communicate it. Creating an environment in which digital identity can be strongly authenticated and thus authorized for high-value online transactions across identity domains is not simply a software engineering problem. Creating such an environment requires well-established business, legal, and social processes. For this reason, companies are likely to begin by limiting their identity interchanges to already-established federations, either through bilateral arrangements with existing business partners or through industry-specific clusters led by powerful players. However, as we've seen, neither of these arrangements produces a truly scalable trust model.

Digital identity is not something necessary for a single business process or relationship; it is a fundamental element of the emerging world of decentralized business. Ultimately, companies will need trusted federated identity mechanisms that scale to different users, partners, and applications. An identity network is the only effective means to do so while ensuring that operational, legal, and security obligations are met.

A Secure, Protected Environment

By creating a quality-controlled environment for identity federation, the identity network both mitigates the risk of fraud or security breaches and reduces the likely damages of any breaches that do occur. The network is in a better position to design and implement monitoring, certification, tracking, and compliance mechanisms than any of its individual participants. Moreover, the network's ability to enforce its security standards ensures that there will be no weak links among members. Network members who fail to adhere to policies can be subject to liability, recertification requirements, fines, suspensions, or even expulsion.

By pooling data and experience, the network can identify theft patterns and create effective protections against criminal activity more quickly and less expensively than any individual organization. Criminals tend to repeat attack patterns against various targets until vulnerabilities are recognized and closed. The common practices and information-sharing possible in an identity network give members a security advantage against organizations that do not participate in the federation.

An identity network also provides an environment perfectly suited to protecting the privacy of personal information online. In the identity network, access to personal information is permission-based. As a result, no one company will have a complete view of any individual's identity information. Indeed, the distributed nature of the identity network ensures that no one party could ever know more than one piece of the identity puzzle without the individual's express consent. Individuals will be able to control access to their personal data, providing only what is absolutely necessary to gain access to a particular online resource.

What's more, companies will be able to take advantage of personal data without actually seeing it when third-party authenticators authorize individual users. The strong privacy protections that can be established and enforced by the identity network also shield member organizations from the significant potential costs, including fines, legal awards, and damaged reputation of failures to protect privacy.

The Future of Federated Identity Networks

All this does not mean that establishing a federated identity network is an easy task; there are significant challenges. Unlike a credit card network, where a small fee can be extracted from each transaction to fund the operation of the network, federated identity networks will require that members fund them out of pocket. Also, issues like liability are more fully understood in a financial services network, and it's relatively easy to charge higher fees for riskier transactions. What's more, there is a large body of legal knowledge about financial services that helps to establish the ground rules. These problems are yet to be solved for federated identity networks.

Given these challenges, are federated identity networks really possible? I believe so, because the benefits are sufficiently large to motivate companies to overcome the obstacles. Ultimately, the creation of wide-scale identity networks will be motivated by the realization that the market for federated identity is immense and that the full potential of digital identity can be adequately tapped only by a network that is independent of any individual member company.

There are two companies that I'm aware of that are working to bring about federated identity networks. Each is going about it in a very different way.

Ping Identity, where I serve on the advisory board, is working to establish the PingID network, a member-owned, technology-neutral, identity network designed to address the business and legal issues related to wide-scale identity federation. The network is a legal entity that provides businesses and organizations a common framework within which secure, quality-assured identity interchange can take place. The network will establish and enforce minimum security and privacy standards and use pooled information and collective action to detect and respond to incidents of identity theft and fraud.

The other model is being developed by SXIP (pronounced "skip"). The SXIP Network is user-focused and allows user data to be stored in what are termed "homesites." When the user visits a web site that requires identifying information (termed a "membersite"), the membersite requests the identity attributes from the homesite. The homesite, in turn, requests that the user approve the release. Unlike the PingID network, SXIP is based on a proprietary standard and is, for now, useful only at web sites. Even so, it's a workable solution to many of the identity federation problems that web site operators face and provides exceptional privacy protection for user data.

If federated identity networks are as important as I believe they are, then the space will undoubtedly attract more players. Also, the PingID and SXIP networks will continue to evolve over the next several years as they discover new business models and solve new problems. One last lesson we can take from the credit card industry: there is room for more than one network, and if they cooperate, users will probably be happy with whichever is most convenient in a given situation.

Conclusion

Centralized, ad hoc approaches to digital identity management, whether inside an enterprise or in federations with partners, will inevitably encounter a host of problems. Many of these threats are not obvious ahead of time. However, it is critical to understand digital identity as an ongoing process subject to significant demands. Federated identity is an important underpinning for the increasingly distributed worlds of information technology and business. As companies link themselves more closely with their customers, employees, and partners, federated identity mechanisms must scale to accommodate new demands and counter a wide variety of threats.

As the early history of the credit card industry demonstrates, ad hoc and centralized approaches to federated identity are difficult to scale and can be unstable. Just as Visa succeeded in creating a foundation for the explosive growth of the credit card industry by establishing a member-owned network for managing identity-related processes and systems, an independent identity network can help its members successfully navigate the requirements of the emerging world of federated digital identity.

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.

Identity Management Architecture

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.

The Benefits of an Identity Management Architecture

An IMA provides a number of benefits to the business. One of the biggest is allowing the organization to focus on the positive aspects of digital identity in creating value. The traditional approach to security has focused on keeping the bad guys out, often at the expense of getting the job done. Identity management architectures focus on creating a digital identity infrastructure that gets employees, customers, partners, and suppliers to the resources they need.

At the same time, another important benefit is increased information security. This might seem like a contradiction, but I contend that by removing the crutch of perimeter defense and creating a comprehensive plan for managing identity and access control, security is improved. Security experts have preached for years that proper system implementation is a more reliable means of creating security than doing it as an afterthought. Identity management architectures are the road to that goal.

Increased security does not have to come at the cost of user convenience. In fact, the opposite is true. A properly implemented digital identity infrastructure allows information to flow more freely, while keeping it within the bounds set by the digital identity management policy. IMAs allow the organization to loosen the restrictions surrounding information management while gaining greater control of information access.

An IMA creates a plan that allows features such as single sign-on and federated identity management to work reliably. This significantly reduces the burden on employees, customers, partners, and suppliers who interface with the organization.

Part of creating an IMA is to design a management process for the enterprise's identity records. Many enterprises don't know what information they have and which entities regularly access it. An IMA contains inventories and structural information for identity stores and records. Furthermore, the architecture documents their relationships to one another and to the business processes they enable. These results alone can provide significant value to enterprise planners.

Most organizations don't know what costs they incur in managing identity. Creating an IMA not only sheds light on those costs, but can also reduce them. Reduced help desk costs alone can provide a significant return on investment to enterprises that take even simple steps.

Almost every enterprise contends with external requirements from partners and government regulators. In some industries, these external requirements can be quite severe (banking, health, insurance, and securities come to mind). Many of these external requirements have to do with controlling information flow and access. Often, organizations go to heroic lengths to meet these requirements, and the sad truth is that they usually fall short. IMAs provide a comprehensive plan that can take these requirements into account and ensure that systems built in the enterprise meet these requirements.

An IMA creates a plan for more closely managing information assets and controlling access. Specifically, critical assets are identified and policies put in place to protect them. The infrastructure is built so that these policies are more easily enforced. All of this reduces the chance of losing critical information from either malicious or negligent behavior.

Because the IMA is focused on the needs of the business, management participation provides a business perspective to what were previously internal IT processes. Security has traditionally been the sole purview of the IT department. Business units were just expected to live with it, regardless of inconvenience and lost opportunities. The irony is that the business is the reason for the security in the first place. Perimeter defense has to be very strong and very tight to be effective, but it's a one-size-fits-all solution. An IMA starts with a business model and relies on the ongoing participation of business managers to avoid these disconnects.

Having an IMA creates a more agile enterprise that easily accommodates changes caused by new business strategies, new products, new markets, and mergers and acquisitions. An IMA provides a blueprint for how the business manages information assets. This blueprint and the infrastructure it depicts provide a neat and easily understood system that is more flexible than the typical hodge-podge collection of identity systems that have grown up over the years. The IMA clearly outlines the policies and standards that are in place and documents the overall system design. This provides clear guidelines for integrating new systems into the legacy infrastructure.

An IMA is founded upon a clear governance process that has been agreed to by all players in the enterprise. This process guides the development of the architecture and its maintenance through the years. This governance process has uses beyond identity management, and can be exploited by the CIO and executive managers to guide other enterprise projects as well.

An IMA includes business models that are used to ensure that the identity infrastructure is aligned with what the business needs. These models are useful beyond building the infrastructure, and can form the basis for designing and building other IT systems that are aligned with business needs. As a consequence, creating an IMA leads to increased understanding of the business.

Success Factors

Success in developing an IMA depends on a number of factors:

Executive management is aware of the need for identity management, recognizes the benefit that will accrue to the organization, and has accepted their roles and responsibilities.

Resources have been committed to developing the architecture.

The IT personnel in the organization, regardless of how they are organized, understand and accept the need for coordinated identity management.

A governance process for determining roles and responsibilities, creating policy, and enforcing it has been put in place and is functioning.

All players, including business managers, have realistic expectations of short-term costs and benefits.

There is a culture in the enterprise that is forward-looking, accepting of change, and willing to endure some risk.

You may look at the list and decide that such an ideal enterprise doesn't exist. You're probably right. Even so, I've tried to keep the list realistic. By building a case for identity management, you can change some of these factors. In the coming chapters, as we discuss the steps you should take in creating your own IMA, you'll see that part of the process is building support and obtaining the resources necessary to ensure the success of the project as well as setting realistic expectations.

The final success factor, culture, may be out of your control, and changing it can be a job far larger than the one addressed in this book. If the culture is wrong, you may need to approach identity management far less holistically than the approach proffered here.

Roadblocks

Many organizations will fail in their efforts to create an IMA. The following is a partial list of roadblocks that might thwart your attempts in your enterprise.

Mistrust

This is a significant problem in many enterprises. Years of poorly managed projects and expectations may have left business units with antipathy or even hostility toward the IT organization. IT organizations, being made up of human beings, respond in kind. The end result is a dysfunctional situation that sinks any proposal from IT.

You will need to decide whether the process for creating an IMA is one that will help mend that rift or whether other, more fundamental steps need to be taken first.

Fear of loss of control

This fear is often expressed as something else, such as lack of support. IT organizations may fear that they are giving up control of decisions they've always made (like those surrounding security) to business units.

Business units may fear giving up their data. For example, if HR has always maintained the employee database and you start talking about creating a metadirectory where multiple players will have access to or, heaven forbid, the ability to change employee data, you're likely to get significant push back.

Part of the process of creating an IMA is aimed directly at giving everyone a voice and being able to work through these fears. The process should be targeted at creating consensus around key principles regarding identity processes and data, and how they're managed.

Inexperience or lack of training

Being successful requires that everyone understand each other and have a common vocabulary. Beyond that, and perhaps more importantly, each player in building the IMA must have a common set of goals and ideas surrounding what the organization is trying to achieve. The coming chapters addresses these problems.

Compulsion to over plan or find the "best" methodology

"Paralysis by analysis" is perhaps a cliché, but it is nonetheless a very real phenomenon. The roadmap presented in this book offers ample opportunity to get caught up in the process and to cycle over and over on certain points, searching for the perfect process or 100% consensus. Equally deadly is the belief by some organizations and people that success is a product of the methodology, rather than the people and their goals. The process presented here offers considerable room for creating and refining process and methodology. Some organizations get lost in creating the process and never get around to implementing it.

The solution to both these problems is twofold. First, you should have a completion goal set by a high-level executive, the CIO or perhaps even the CEO. Second, the leader of the IMA process must be strong and driven to completing it. At the same time, the leader should be sensitive to fact that the process is designed to bring people to a common understanding about how identity is managed and therefore takes time.

Severe, chronic resource shortages

If your IT organization can't seem to finish projects, has far too many critical projects for the available resources, or has a significant backlog of critical projects, then this should raise a red flag. Finishing the IMA and bringing the identity infrastructure into compliance will be impossible under these circumstances. The IMA will be looked on as one more project, piled onto the already overwhelming burden. Equally important, the business units will not likely see the architecture as a realistic project and consequently not give it the attention and resources that it requires.

The best plan in this circumstance is to attack the more significant project-planning problem head-on and return to identity management once more pressing problems are in hand.

Arrogance on the part of the IT organization—the "we know best" mentality

Let's face it—IT organizations are filled with people who think they know the answer to every problem. I've often joked that programmers and system people are even more inclined than lawyers to thinking they can do anything. Part of the reason for this mentality is that they are, in fact, usually quite bright, and their positions often insulate them from the messy realities of customers and making a profit. This is a blessing and a handicap. The blessing is that they are a source for good ideas and innovative thinking. The handicap is that they frequently express their ideas with less tact than you'd like, and they can decide that they'll force things to happen their way regardless of what people in the business units think.

The process of creating an IMA can help alleviate this problem, as it brings some of these IT people into close and frequent contact with their customers in the business units. Make sure that the thought leaders in your IT organization are part of the process so that they can help convince others of the value of an IMA. Also, be prepared to take appropriate personnel action against those who repeatedly torpedo the process.

Corporate politics and players with other motivations

This is a roadblock that you will have to deal with as it comes up. Unfortunately, you may not understand the motivations of others who fight against you well enough to effectively counter the problems.

The most effective solution is to try to understand the motivations and see if there's some way to reach a compromise. I've been in situations where I never could understand the rationale behind the motivations of others, and no amount of talking led me to a situation that we could both live with. In those cases, the only thing to fall back on is the commitment of executive leadership to the process. This stresses the need to pay close attention to receiving that support and commitment as conspicuously and unambiguously as possible.

Fixation on short-term return on investment (ROI)

Many leaders in IT organizations and business units are overly concerned with short term ROI. That's not to say that ROI is unimportant or that it can be ignored in creating an IMA. Even so, a review of the benefits from the previous section will affirm that many of them are not directly monetary. The benefits from an IMA are not predominantly returned as immediate savings, but as the long-term enablement of new business processes and models.

Be sure not to oversell an IMA as a solution to problems that it will not solve. Be realistic. If executive management can't be convinced by the real benefits, properly explained, then your organization probably isn't ready for an IMA.

Acceptance of the status quo

Some people like how things are and don't have a significant motivation to change them. Overcoming this roadblock will probably require a long and careful campaign to show why the status quo is not as rosy as everyone thinks and to paint a vision for what might be. Don't underestimate the length of time it will likely take to overcome unrealistic satisfaction.

Recent visible failure at IT planning

If your organization has recently attempted a large IT planning exercise that failed, particularly one where the business units were heavily involved, the IMA process will be met with stiff resistance.

This is one problem that only time and several small and medium successes will overcome. A scaled-down process may be a route you can take.

Identity Management Architecture Components

Building an IMA involves creating a series of interrelated components . Figure 13-1 shows a schematic diagram of these components.

The 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. Chapter 14 will outline how you can build a governance framework for your organization. Chapter 14 will also show you how to understand and document the business context.

The process architecture determines how your business accomplishes identity tasks now and how they should be accomplished. 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.

Figure 13-1. Components in an identity management architecture

Chapter 15 will discuss the identity management maturity model and show how to use it in your organization.

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. Chapter 16 will discuss this process.

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 by and used by the other components. Chapter 17 and 18 discuss interoperability framework and identity policies, respectively.

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 with each other. Chapter 19 will discuss reference architectures and show you how to build one.

Finally, Chapter 20 will summarize the process and provide timelines showing how these various pieces are sequenced.

Conclusion

Our goal in laying out the process for building the IMA is to create a system that is agile and readily adapts to changing business needs. The key to making that happen is the governance framework, so that's where we'll start.

Chapter 14. Governance and Business Modeling

When I became CIO for the State of Utah, I had very little appreciation for how much time and effort went into governance issues in a large organization. Before my stint as CIO, I'd been CTO of http://iMall.com, a company I founded; I had hired nearly everyone who worked for me. As we'd built the organization, we'd also built and shaped the vision and the culture. People naturally understood the business, because they'd seen it develop and had crucial roles in making it work. Furthermore, while we'd had our share of culture problems, we'd handled them on the fly and with decisiveness. When decisions needed to be made, we made them, and things worked marvelously.

I soon found out that the state was a different animal altogether. There were, of course, differences between the public and private sectors, but over and above those, the organization was an order of magnitude larger than what I was used to, and there was what I call "legacy lethargy." Moreover, IT was organized in a decentralized fashion so that no one really had the authority to make important decisions, even when there was clear and imminent risk.

For example, at one point, for a period of about two months, a wireless network was set up in the capitol with no access control whatsoever. Anyone with a laptop and wireless card could come to the capitol and surf the Net at taxpayers' expense. What was worse was that the network had been set up for legislators, so it was possible to monitor network traffic between legislative laptops. I knew about it almost from the beginning, and yet, I was powerless to put an end to it. The network had been put in place by another organization, and even though it presented a clear risk—not just to the people who used it, but to the entire enterprise network—there was no process in place to review plans, audit compliance with policy, or take corrective action. In short, we were stuck by our lack of a governance process.

Governance issues seemed to take up almost all my time when I was CIO. The governor had a clear vision for what he wanted IT to accomplish, but it was difficult to see how to move the organization toward those goals. Part of the problem was a lack of understanding on my part of how to use the organizational tools I had, because they were different than the tools I was used to. Part of the problem was that we needed some new tools and, most important, an enterprise-wide vision and commitment to achieving the goals of the chief executive.

After months of frustration, we finally embarked on a process to create that vision in a large cohort of the executive management, both business and IT. We were also to determine the process by which we'd govern the implementation of that vision. Those meetings, which I'd now call the "architecture initiation phase," lasted over a three-month period and involved over a hundred people in dozens of meetings. It was exhausting. Nearly everyone grumbled, including me. I wanted to build things, not spend all my time in meetings, and so did they. I've come to understand, however, how important that process is when creating enterprise-wide vision, designs, services, and systems.

In the end, we created a governance process that, looking back, had many of the required features of a good governance model but, for many reasons, failed to take hold. The process was a step forward, but it ultimately suffered from three things:

The resulting governance process was incomplete. There were crucial functions, such as auditing, that received very little attention, in part, because they were unpopular.

The model lacked a clear financial structure. IT governance, like city planning, isn't free, and resources need to be committed unambiguously for it to work.

There was insufficient buy-off by many of the people whose support was critical to the process. We should have spent even more time in meetings building consensus and communicating the vision and plans.

We could have mitigated these problems, had we had a better idea about what the initiation phase had to accomplish in order for it to succeed. At the time, I couldn't see the forest for the trees; I was too caught up in immediate goals and meetings to understand the true nature of what we had to accomplish. Looking back, I have a clearer view and can see the pitfalls and have tried to help others avoid them.

You may share my initial lack of appreciation for governance and wonder why you're reading about it in a book on digital identity. You may be itching to get to the business of building a digital identity infrastructure and be tempted to just skip all this political stuff and get to the meat. I hope the preceding story will help you overcome that temptation, and you'll spend some time understanding the governance process, along with the modeling and planning work that follows.

IMA Lifecycle

Before we get too far into discussing the IMA governance process, we should spend some time discussing the IMA lifecycle . Figure 14-1 shows that lifecycle, in general terms. The first thing to note is that a lifecycle implies a continuing process, and that's exactly what we're hoping for. The IMA should be an ever-evolving architecture that reflects current business needs. The IMA lifecycle is an up front acknowledgment that the IMA will affect the business on which it is built. As the IMA is built and put into practice, the business will change. The lifecycle feeds those changes back into the architecture to create a dynamic process.

Figure 14-1. Identity management architecture lifecycle

The cycle starts with modeling, by which we mean the process of understanding the business, data, application, and technology environments within which the identity infrastructure will exist. We will spend a great deal of time in later chapters discussing the modeling aspects of identity management architectures. Modeling is not just where we start, but where we return, time and again, to gage the vitality of the IMA and monitor the ever-changing environment.

The second phase in the lifecycle consists of planning and documenting. This is an important activity that takes the models built in the first phase into account and creates plans for meeting the identity needs of the organization. This is the phase where standards are defined or set forth, certification requirements are laid out, and policies are created and discussed.

In the third phase of the lifecycle, the plans, policies, standards, and so on that were created in the second phase are reviewed. There might be several iterations back through the modeling or planning activities before they are finally approved. Once they are, the plans and policy are considered in force and, in a healthy organization, should be considered binding.

The next phase of the lifecycle is labeled communicate. You should not interpret this to mean that the other phases are carried out in secret, and this is the first time that others in the organization are informed of what's happening. To the contrary, we'll see that the entire process is designed to involve as many people and communicate the happenings as broadly as possible, even gaining consensus around important ideas before they are approved.

However, after the plans of the second phase have been approved in the third phase, they need to be communicated as approved plans and be maintained in a way that they serve as a reference for others in the organization who used them in their work. This implies more than simply sending them out in an email and hoping that everyone keeps the most recent copy. The communication phase requires version control, authoritative storage and presentation, easy reference, and searching.

The IMA is used in the implementation phase by system architects and others in the organization. The IMA should affect what is bought, how systems are built, and how data is stored and used.

The final phase of the IMA lifecycle is one that is often overlooked, but plays a crucial role in turning what would otherwise be a dead-end planning exercise into a living, cyclic process: auditing. Auditing is, perhaps, an unfortunate name, because no one wants to be audited. Even so, the feedback that the organization gets from comparing the plans to the implementation and then suggesting changes is invaluable. Just the number of outflows from the auditing box should be a clue to its importance. The audit might suggest changes to implementations to bring them into compliance with established plans. Alternately, the audit might suggest changes to the plans themselves, because they are unworkable in certain situations or not accomplishing their goals. Lastly, the audit might suggest changes to the models based on an evaluation of existing conditions.

IMA Governance Model

Creating an IMA requires the help and cooperation of multiple people from many different organizations within the enterprise. In order to coordinate their actions and create an atmosphere where the results will be accepted and used, the process for creating the IMA, approving it, and enforcing its provisions, must be clearly delineated.

Figure 14-2 shows a sample governance model for creating an IMA. This figure does not show a new organization, but rather a relationship between roles that will be assumed by people already in the organization. We'll see how these roles interact in detail in this chapter.

The governance model presented here is certainly not the only one that will work, and it will need to be tailored to your organization. The objectives of the model are the following:

Figure 14-2. Illustrative IMA governance model

Create the identity management architecture.

Ensure that every organization in the enterprise that will be affected by the IMA has an opportunity to participate in its creation.

Yield a result consistent with the strategic goals of the organization.

Yield a result that will drive the goals and tactical implementation plans of all organizations within the enterprise as they relate to identity.

As you read the following description of roles and processes, keep these objectives in mind. That will help you determine how best to map this model onto your own organization.

At first, the information that follows may seem like overkill. The temptation will be strong to just get a few trusted people together and tell them to determine a strategy and then sell, or even announce, the new strategy to the rest of the organization. In some organizations, it may even work. Before you do that, carefully read and understand this chapter. I think you'll find that it's not as complicated as it appears at first, and the various roles and procedures serve useful purposes that are worthwhile.

Initial Steps

You can take specific steps in the initiation phase to help ensure a successful outcome of your IMA process:

Develop a vision of IMA effort, and gain executive support from both IT and business units.

Determine appropriate governance roles and responsibilities, and determine who will fill these roles.

Determine the initial scope of the IMA work, and lay out a roadmap for future efforts.

Obtain a commitment for funding the IMA effort.

The following sections describe these steps in more detail.

Creating a Vision

The first step in the initiation phase is to create a vision for what the IMA will accomplish within the organization. Creating the vision requires more than simply writing the vision down, although that's certainly necessary. Creating a vision is a collective effort among the people who will have to buy off on and participate in the IMA activity.

The first step in creating the vision is for the enterprise leader (perhaps the CEO or the CIO) to establish the need for the IMA and to issue a challenge to the organization to create one. The challenge should spell out, in high-level terms, the objectives that the IMA activity is meant to accomplish. For example, the objectives might be:

Protecting critical business information assets through the proper use of digital identity

Enabling business interactions with partners and suppliers

Understanding our customers better

Supporting safe access to critical information and processes by customers, employees, suppliers, and partners

Building a digital identity infrastructure that is flexible and agile

These objectives should be placed in a charter that is communicated widely within the enterprise, both to business and IT units.

After communicating the charter, the next task is to develop a "straw-man" vision that describes a target digital identity infrastructure fulfilling business goals and objectives in a generic way. The following are specific steps you can take to help create the straw-man vision:

Assemble background information on the business units, lines of business, its customers, partners, suppliers, objectives, people, and so on. This information can come from many sources including site visits, interviews, written reports, position papers, memos, and product literature.

Determine the business goals and objectives of business unit leadership, and identify identity issues buried within those goals and objectives.

Visit other organizations that are further along the path to creating an IMA and already have a working digital identity infrastructure.

Prepare presentations using the information gleaned in previous steps and the straw-man vision to present to key business executives within the organization.

Meet with key business leaders to ensure that your understanding of the business goals is correct and to present the plan for the IMA process. These meetings should reinforce the charter and present the straw-man vision as such.

Make commitments to business leaders about how the IMA and resulting digital identity infrastructure will positively affect their business to generate support. Such commitments will be contingent on key assumptions being met. Be sure to document these commitments and be accountable to them as the process matures.

With these steps completed, it is time for a series of meetings among those in the enterprise who are the influencers and leaders. The goal of these meetings is to establish a shared vision, translate the high-level objectives into more specific goals, and assign roles to specific members of the organization. These facilitated meetings should build from the "straw-man" vision developed earlier into a group consensus around the outcomes that will result if the IMA process is successful.

Facilitated meetings are an established way of creating shared vision, and I recommend that you employ a trained facilitator. An experienced facilitator will be able to consult with you on specific techniques for achieving the goals of the initiation phase, and can help adjust the meetings and processes accordingly.

IMA Governing Roles

Assigning roles and responsibilities for the IMA effort is an important step and should occur as a result of the meetings that create the vision. Rather than define these roles in terms of positions, we'll describe them generically with some hints as to how these generic roles map onto some common organizational structures.

The roles that we discuss in this section were influenced by the NASCIO Enterprise Architecture toolkit.[*] The NASCIO toolkit identifies eight primary and seven supporting roles in the creation of a governance model for an enterprise architecture. I've adapted those roles into an IMA process. There are two categories of roles: primary and supporting. The model in Figure 14-2 shows only primary roles for clarity. Table 14-1 shows the primary and supporting roles that support the IMA governance process.

Table 14-1. IMA governance roles

Primary roles

Supporting roles

Audience

Enterprise executive

Champion

Subject-matter expert (SME)

Overseer

Technical operations staff

Manager

Product/project teams

IMA team

Procurement manager

Communicator

Special interest groups

Advisor

Reviewer

Auditor

Primary Roles

Primary roles are those that directly perform the work of creating the IMA.

Audience

All of the stakeholders in the IMA effort take on the role of audience. These stakeholders include the enterprise executive, business executives from other parts of the organization, IT staff, partners, suppliers, and customers. Understanding the audience will provide significant guidance to the IMA effort. The audience will eventually have to live with the results of the IMA even though they are not necessarily participating directly in its creation. Communicating the IMA process, progress, and results to the audience is critical.

Champion

A champion is the person pushing the project and putting energy and resources into moving it forward. Typically, the champion will be a high-level executive (say, the CIO) who has decided that creating an IMA is an important strategic objective. That doesn't mean that the champion was the first to see the advantage of an IMA. Indeed, someone else will typically have sold the champion on the merits of digital identity.

Overseer

Overseer is a role that is typically implemented by a committee or team. The overseer's role is to provide oversight for the IMA project and ensure that the mandate of the enterprise executive is fulfilled.

Manager

The manager is the executive responsible for directing the overall IMA effort, and ensuring that the directives and requirements of the overseer are met. The manager works with the champion to select people to fill other important roles. Often the manager and the champion are the same individual. The manager needs to have sufficient standing in the organization to effectively carry out the mandates from the champion and overseer. As such, the manager is typically a senior-level IT employee. The manager has the following responsibilities:

Select people to serve as reviewers and chair the activities of the review function.

Select the communicator and ensure that the communicator has instructions about how, what, and when to communicate. The manager ensures that communication is supporting the overall IMA effort.

Select and supervise the IMA team (s).

Seek out and work with advisors to ensure that the process is following best practices.

IMA team

The IMA team is the heart of the IMA model. The IMA team does the actual work of creating the architecture and will typically consist of a few knowledgeable IT staffers. The champion and the manager should trust the IMA team. Further, members of the team should have a mature understanding of the business and its goals as well as identity technologies. The IMA team might also include in a support role, subject-matter experts, or members of the service, project or product teams. The IMA team should not be populated solely with the existing information security group, although some members of that group should either be on the team or designated as subject-matter experts.

The IMA team is charged with creating and maintaining the documents that make up the IMA. The key requirement for this function is the ability to understand the process and write clearly.

The IMA team has the following responsibilities:

Create IMA documents in consultation with the manager, reviewer, and advisor, after carefully considering the audience.

Provide the communicator with the information necessary to communicate the plan and process to stakeholders.

Provide IMA deliverable documents to the reviewer.

Update the documents according to input from the reviewer and manager.

This role can take a significant amount of time and may need to be full time in a large organization.

Communicator

The communicator's role is to provide information about the process, progress, and results of the IMA to the audience and people in supporting roles who are not involved in the day-to-day effort. We assume that those in primary roles get information about the IMA through their participation, but if that's not the case, the communications plan should include them as well.

The communicator receives information from the IMA team, the reviewer, and the manager. The communicator and the manager make this information available to the audience and others in accordance with a jointly created communications plan. The communications plan does not need to be elaborate, but should take into account the differing needs of the people in the audience and other roles. For example, the audience includes customers who may need to be told very little about the IMA itself but get detailed information during the implementation phase. The objective of the communications plan should be to ensure that members of the audience understand the IMA in the correct amount of detail. Communications should always be written to build support within the enterprise for the IMA.

Advisor

An advisor guides the manager, providing clarity and supporting best practices. The advisor could be the champion, other enterprise executives, or someone else who has knowledge about the goals and objectives of the IMA, the political landscape within the enterprise, best practices from other organizations, and so on. There may be a number of people who fill the advisor role, and their advice may be limited to areas of specialization. Often the enterprise will bring in an outside consultant who has past experience in creating an IMA to serve in the advisor role.

Reviewer

The role of reviewer is crucial to the IMA effort. The reviewer is usually a committee staffed by senior executives from the business organizations in the enterprise as well as the IT organization. The reviewer's role is to evaluate the IMA documents, recommend changes, and to approve or disapprove them.

The people assigned to these roles will change over time, and so change should be planned for and accepted as part of the process. Indeed, the make-up of the groups playing the reviewer and advisor roles is likely to change as the IMA process matures.

Supporting Roles

Supporting roles help create the IMA, but are not necessarily involved in the day-to-day process.

Enterprise executive

The enterprise executive provides the strategic reasons for creating an IMA and identifying the high-level objectives of the IMA process. The enterprise executive is typically the CEO or other high-level executive who can help the champion and manager bring other players to the table.

Subject matter expert

The process of creating an IMA will require the expertise of a number of people both inside and outside the enterprise. The manager and reviewer as well as the service, project, and product teams use subject-matter experts.

Technical operations staff

The technical operations staff is responsible for day-to-day IT operations. This is the group of people who manage the network, operate the servers, and so on. They are a user of the IMA and provide feedback to the IMA team as part of the IMA lifecycle. Moreover, the technical operations staff can provide valuable feedback to the IMA team about what is feasible and what is not.

Product and project teams

Product and project teams consist of everyone involved in implementing a project or bringing a new product to market. Typically, project teams are used on inward-facing engineering activities, and product teams are used to build things that will be bought by customers (including services). The product and project teams are users of the IMA and can provide valuable feedback to the IMA team. Product and project teams will be required to comply with the IMA in their designs and engineering, so their participation and buy-in is crucial.

Procurement manager

The procurement manager is responsible for setting and enforcing procurement policies and procedures. These policies and procedures are not part of the IMA, but they can play an important role in helping enforce the IMA, and the policies and procedures in the IMA must be consistent with those of the procurement manager.

Special interest groups

The role of special interest groups is something of a catch-all role to include those people and groups who provide advisory input to the IMA process, identifying special needs or requirements.

[*] See https://www.nascio.org/publications/index.cfm.

Resources

One of the first tasks and a critical success factor is to find and allocate resources. There are two primary resources necessary to get started: people and computer systems.

The roles discussed in the previous section will be assigned to people within the organization. Customize the roles to work within your enterprise and create an organization chart for the IMA process that mirrors the roles found in Figure 14-2.

Next, determine the time commitment for each role. In a large organization, the IMA team, manager, and communicator roles will likely be full-time assignments. Smaller organizations might assign the manager as full-time and assign IMA participation as an additional duty for everyone else. Additionally, the number of IMA team members varies with the size of the organization. I recommend a team of three to seven people, depending on the size of the organization and whether they are full-time or not. Teams larger than seven people can be unwieldy to schedule and manage. At least one person on the IMA team will need to provide clerical and reporting support.

An important part of assigning IMA roles is to contract for time with the participant's supervisor. For full-time roles, this may be a formal HR process. For part-time roles, the contract should be a written acknowledgment by the supervisor of the person's roles and responsibilities within the IMA activity and the expected time commitment each week. Executive intervention may be necessary in this stage to get commitments for the key people.

Team members must be able to easily share their data and documents. Email can fill this need, but you may find that a more formal tool for this purpose is helpful. I strongly recommend the use of a content management system for sharing results, managing document versions, distributing reports, and communicating progress. The content management system needn't be expensive. Plone, an open source product, will work fine for many organizations. Also, free or low-cost weblog software can be used to communicate progress and important information.

You'll see, as we continue through the book, that there are survey and data collection aspects to the IMA process. Survey products are available online and should be sufficient for much of the required survey work, but the data will need to be pulled from the survey and manipulated. In many instances, spreadsheets will suffice, but there may be some sophisticated data reporting requirements that require database and web skills that go beyond the ability of a small team to self-support. IT resources for managing the database and wrapping it in data entry and query forms should be committed to the IMA team as necessary.

What to Outsource

One of the primary arguments of this book is that identity is a central to the business, and business goals and IT activities can only be aligned through a new approach to managing identity. Otherwise, why would someone go to the effort of creating an IMA?

That being the case, building an in-house competency in identity and the processes for managing an IMA is crucial. Only by direct contact with the processes and systems will your organization know enough about how identity is being used in the business to have it make a strategic difference.

Early in the process, you may need to delegate critical aspects of creating the identity management architecture to outside consultants who can guide the process and have specific skills that in-house personnel do not have. Figure 14-3 illustrates the process of moving from external consultants to internal specialists over time.

Figure 14-3. Moving from external consultants to internal specialists over time

The trick to managing this is that if you turn too much over to external consultants early in the process, you may fail to learn the competencies necessary to bring the process entirely in-house. To alleviate this problem, you should avoid putting external consultants in most of the primary roles in the governance process and use them as advisors only. There may be specific tasks that need to be outsourced, such as conducting a particularly specialized set of interviews or a technical survey and analysis. Over time, however, reliance on external consultants will be costly and keep your organization from developing necessary skills. Identity driven businesses should own rather than rent their identity management architecture.

Understanding the Business Context

As part of creating the vision, we discussed the importance of gathering information about the business objectives and goals. That's a crucial first step in creating a business context within which the IMA can be fashioned.

When I was the CTO for http://iMall.com, I knew exactly what we did: we created specialty hosting solutions, including e-commerce tools, for small and medium-sized businesses. What's more, I knew exactly who was doing what, because I'd hired most of the 125 employees myself. I had, for all intents and purposes, perfect knowledge of iMall's business model.

Later, when I was CIO for the State of Utah, I had a much tougher time getting my arms around the business. First, governments are large, even the governments of relatively small states. Second, they do a lot of things. At first it seemed impossible, but there are specific things you can do to understand an organization, even one that's complex and loosely coupled.

Our model of the business will provide us with two important results: a business function matrix and a set of guiding principles for the IMA effort. Both of these are important to creating an IMA that is sensitive to business objectives.

Business Function Matrix

A business function matrix (BFM) is a matrix that documents the business functions that your organization performs and which organizations within the enterprise perform them. The steps to creating a BFM are fairly straightforward:

Document the structure of your enterprise.

Define the business functions your enterprise performs.

Map the business functions to the major organizations within the enterprise.

Creating the BFM might not take very long in a simple business like iMall. In a complex organization, the process might take considerably longer. The U.S. federal government has a BFM called the Business Reference Model that was assembled over the course of several years.

Organizations' units are arrayed along one axis of the BFM. The chief decision is how fine-grained you want to be. It's entirely reasonable to start the process with a high-level, abstract view of the organization and then drill down into more specific information as the IMA process evolves.

The goal of building a business model is to determine what functions various parts of the company are performing. If this were a business book, we'd be concerned with finding out if those activities led to competitive advantage, but that question is clearly beyond our scope. We're merely trying to find out what happens, not decide whether it's the right thing or the wrong thing. Your organization may have already performed a competitive advantage exercise, and in that case, the information about who's doing what will be readily available. In most cases, however that will not be the case, and you'll have to start from the beginning.

In the end, you should have a list of functions that the various organizations in your enterprise perform. This list should give the function a name, organization that performs it, and contain a brief description. In many cases, the description will be a list of subfunctions. Some of the functions may seem very similar to functions performed elsewhere in the organization. We'll normalize this list later.

Build the function list by talking to members of the various organizational divisions and asking the following kinds of questions:

What is the business of your organization, team, or group?

What tasks does your organization, team, or group perform?

How do the tasks your organization, team, or group performs contribute to the function of the group or organization you belong to?

As you work your way through the organization, divide each function into subfunctions by decomposing it into smaller steps. "How do you...?" is a good question to ask to get the answers that lead to decomposition.

Remember that our goal is to understand the business and how identity is used in support of business goals. As you perform the functional decomposition, make note of any functions where identity information or activities are being used. This information will be helpful in understanding identity processes that business units use to accomplish their function.

There are a few caveats:

Organizational names are not necessarily good indicators of the functions that the organization performs. For example, "Finance" isn't a function. If you asked people who work in the finance department what they do, they probably won't say "finance." They'll talk more about the tasks they perform.

Many of the tasks people perform are not functions in the sense we care about either. Examples include sending email, writing memos, and so on. You should steer people toward the reason for sending the email or the business function of the memo or spreadsheet.

Functional decomposition does not necessarily follow the organizational chart, so don't be caught up in the organization so much that you lose the functional model. Cross-functional product teams who come from many disciplines to build, deploy, and maintain a product are a good example of where organization and function do not match. The product team may not show up in a formal organization chart, but their function is a crucial part of the business.

Keep in mind that you're not trying to determine workflow or do business process modeling. The scope of those tasks is far greater than what we're after here and will mire the IMA team down.

Creating the Business Function Matrix

As we said earlier, the BFM is a matrix that maps organizations to the functions they perform. The reason we treat it as a matrix rather than a simple hierarchy, as the results of the last section would suggest, is that more than one group in the enterprise often carries out similar functions. To get a matrix, we must collapse similar functions into more general descriptions and combine definitions where appropriate. I call this process "function normalization." As you do this, and keep track of which organizations are performing the functions, you'll find that the matrix creates itself.

One of the things you'll find is that multiple organizations inside the enterprise perform the same function by description, but they do it in different ways, as indicated by the subfunctions. There are two possibilities:

The subfunctions themselves are the same, once they've been normalized.

The subfunctions are substantially different or there are additional steps in some processes.

In the first case, the function can be completely collapsed, after the two subfunction trees have been normalized.

The second case is both frustrating and the reason for doing this exercise. Our job is not to change either business unit so that they use common processes for performing the same functions, but to document what actually happens. This information will be useful when policies are created or systems are being implemented. At that point, the CIO or another appropriate manager may want to initiate discussions about whether these processes can be normalized, but we must accept the fact that often they will not be, and the IMA and related infrastructure will have to accommodate the differences.

Our ultimate goal is to create an identity management architecture and digital identity infrastructure that supports the business. Detailed functional data about how different business units accomplish similar functions in different ways is crucial to creating an IMA that will be used by the business and adds value. Imagine not creating the business model and then finding this out after you've spent a lot of money creating an infrastructure that supports one way the business does something but not the others. That's what causes many IT projects to take longer than planned, cost more than budgeted, or outright fail. Having a good business model helps avoid these issues.

IMA Principles

If you just turned to this section from the Table of Contents, you might be expecting a list of important principles for creating an IMA. Sorry to disappoint you. Rather, this section is about creating your own set of guiding principles that reflect the culture and objectives of your organization.

As I described earlier in this chapter, we created a process for defining how we'd make e-government the standard way of doing business for Utah government. One of the most important things to come out of that process was a set of principles for e-government in Utah (see "Principles for E-government in Utah").

We created these principles using a facilitated process where over 100 people broke into smaller groups, brainstormed principles, and then chose the ones they thought were most important. We brought all those groups back together, had them present their results, and then the entire group determined a short list of seven principles that were the most important.

I'm confident that we ended up with a set of principles that represented the feelings of the business and IT leaders in Utah state government. Over the coming months, these principles served as a charter of sorts that we could refer to. These principles grounded the discussion in important objectives and kept it on course.

Building a similar list of principles for your IMA process will bring the people whose support you need together and make them feel like a part of the process and the decision making. You'll be more sure that the decisions made further down the road will gain widespread support if they are based on principles that everyone helped create.

Principles for E-government in Utah

The following principles were adopted by the governor's Working Group on E-government as guides to developing e-government services for the State of Utah. In this document, customers include citizens, businesses, employees, and other government entities.

Frictionless

Design and implement services that fully, quickly, and conveniently satisfy the customer's expectations and needs.

Efficient

Design and implement services to streamline the customer's encounter with the government while minimizing cost and waste for both.

Cost-effective

Design and implement services that use shared resources while delivering quality products at a reasonable cost.

Single view of customer

Design and implement services so that the customer is recognized uniquely whether single or multiple communication channels are used to obtain the service. The customer should not be able to tell whether a single or multiple records are used to support the transaction.

Customer-focused service

Design and implement services with customer needs and requirements at their center. Services should be built from the customer's perspective, taking into account a holistic view of government services and requirements.

Accountability through success metrics

Design and implement services with a clear understanding of what success is and how it can be measured. Services are constantly evaluated to assess whether or not they are meeting these goals

Business needs drive process

Business owners must drive service design, because they are the most familiar with both the needs of the customer and the requirements of the business.

An important part of this process is the up front work to educate the participants in the crucial ideas and let them form educated opinions. We were lucky in Utah that we'd been discussing e-government for several years, so almost everyone had a core set of beliefs and ideas. In addition, Governor Leavitt had been a strong proponent of e-government, and had made his own views evident in cabinet meetings and other venues. These things made our job easier.

One way to jumpstart the process is to get people thinking about where they stand on some key, strategic choices. Burton Group has published a list of IT architecture principle areas that can be used to start a discussion of principles and guide people to an enterprise-wide set of core principles. I've adapted these to issues relevent to an IMA. The revised areas are shown in Table 14-2.

Table 14-2. IMA principles

Management

Vendor

User

Identity

Technology risk acceptance

Single vendor versus "best of breed"

Must use versus optional service

Accountability versus access control

General versus optimal solution

Second sourcing

Billing and chargeback

Partners and federation

Cost center versus competitive advantage

Proprietary versus openness

Universal service

Security versus business enabler

Degree of autonomy

Vendor risk

Privacy

Project justification

Outsourcing

Online versus Traditional

Areas in the Management column raise questions about how management feels. Is your organization risk averse? Does management expect an optimal solution? Is IT (and hence and the identity infrastructure) treated as a cost center or a means of competitive advantage? What degree of autonomy does the IT organization have? Do projects have to be justified in strict ROI terms?

Areas in the Vendor column raise questions about the enterprise's feelings toward your organization's relationships with vendors. Do you prefer to work with single vendors or are you comfortable integrating products from multiple vendors? Is it important that you have a second source for mission critical products and services? Do you prefer open solutions? What level of vendor risk is your organization comfortable with? What is your philosophy toward outsourcing?

Areas in the User column raise questions about the enterprise's feelings toward users. Are users required to use services and infrastructure created by the IMA or is such use optional? Does IT bill for services? Is IT expected to support all users or just some?

Areas in the Identity column raise questions about issues we've discussed in the earlier sections of this book. Where can your organization use accountability to augment or replace strict access control? What plans do you have for federating identity information with partners? Does your business see identity in terms of security or as a business enabler? What is the attitude toward privacy? Are you engaged in self-service-style online transactions with your customers?

Don't try to come up with a principle for each area in Table 14-2. These are just areas to jump-start your discussion. In the end, you should come up with 6 to 12 principles that are the most important to your organization. This list should be communicated widely and used as the basis for the activities that follow.

Conclusion

Creating the governance process, fashioning the business function matrix, and establishing the guiding principles for the IMA are critical steps. They form the backdrop against which we build the IMA. The next chapters will jump right into the specific components of the IMA. The first step is to understand the identity management maturity model and build a process architecture.

Chapter 15. Identity Maturity Models and Process Architectures

In the last chapter, we set up governance for the identity management architecture (IMA) process and built a business model. As we've seen, the business model is really just a comprehensive documentation of the goals, people, and processes of the business units building the IMA. The next task is to determine where your organization's current technology and practices stand with an eye to improving them. The tool we'll use is called a digital identity maturity model .

Our objective in this chapter is to distinguish mature identity processes from immature processes, develop an identity process inventory, and plan for identity process improvement. We use the word "process" quite deliberately. Organizations that view internal activities as a series of isolated tasks cannot build a digital identity infrastructure that will accomplish the objectives set forth in this book. The reason is quite simple: viewing activities as isolated tasks does not allow the results to be consistently measured and that information to be fed back into the organization so that the activity can be improved.

In an organization with immature processes, projects are executed without many guidelines by teams that are free to proceed as best they can. Project success is dependent on the efforts of a few "virtuoso performers." Predicting the success or failure of a project is difficult, and when the project is finished, it is often impossible to identify the factors that led to success or failure.

On the other hand, mature processes give project teams clear guidelines and have built-in metrics so that the result is not just repeatable, but also measurable. Metrics tell why the process produced the outcome it did and what needs to be done to improve it. Mature organizations review and update their processes as a matter of course and seek constant improvement.

Maturity Levels

The path to more mature identity management processes and infrastructure can be characterized by a series of steps that gives specific milestones. These milestones are called "maturity levels ." Each level is a reflection of certain capabilities in the organization's processes and infrastructure. Higher maturity levels reflect greater capabilities and have more advanced characteristics. The maturity model defines the key elements at each level and thus represents a path that you can follow to guide your identity management processes to more mature levels. The path we've defined includes four levels and is shown in Figure 15-1. These levels are adapted from an identity management maturity model developed by Gary Daemer of Booz Allen Hamilton.

Figure 15-1. Levels of digital identity maturity

In level 1, the organization has very few processes and the infrastructure design is tactical and ad hoc. At the focused level (2), some projects in the organization have good processes and a designed identity infrastructure, but many do not. At the standardized level (3), the organization has created enterprise-wide policies, processes, and infrastructure. With enterprise-wide policies and processes, the organization can learn from various projects and use that knowledge to improve future projects. At the integrated level (4), policies and processes are very mature and processes have been automated. The infrastructure is complete.

The Maturity Model

The following sections characterize identity management practices at each level in the maturity model. The characteristics are organized into eight areas: business goals, policies, processes, identity management, identity storage, authentication, authorization, and federation. The characteristics given are illustrative; there are more characteristics than can be enumerated here. Nevertheless, these should be sufficient to give you a clear idea of what each level looks like.

Level 1: Ad Hoc

Level 1 is the furthest away from being a best practice. In level 1, no planning or structure is applied to identity management processes and systems. The statements in Table 15-1 characterize practices at this level.

Table 15-1. Characteristics of level 1 identity management practices

Area

Characteristics

Business goals

Business units see identity management as having negative value. That is, identity management gets in the way of getting work done.

Policies

The organization has no identifiable policies about identity. Any rules that do exist are simply part of the organizational folklore.

Processes

Identity management processes are not defined or documented.

Processes are carried out in an ad hoc fashion with the desires and whims of the team or team leader being the primary driver. Any processes that do exist are informal.

Team knowledge and talents are not leveraged in a consistent manner, because the process is different each time.

The ad hoc nature of the processes denies opportunities for automation.

The ad hoc nature of the processes does not allow them to be audited for effectiveness.

No metrics are used to measure the processes, and any operational data that is collected is analyzed only in response to a problem.

Identity management

Identities are fragmented across the organization.

Fragmented identities are inconsistent.

Multiple administrators add accounts manually.

Identity storage

Identities are stored in multiple repositories.

Users have multiple, disconnected entries in the store.

Identities are stored in different kinds of stores and even when the stores are consistent, the schemas are not.

Authentication

Users have multiple usernames and passwords, including multiple identifiers on the same systems and applications.

Identity credentials are chosen randomly without clear cost and benefit analysis.

Authorization

Authorization is inconsistently applied and used.

Authorization policy is set without any evaluation of cost and risk.

There is no formal notion of resource owners or custodians.

Federation

When identities are federated with partners or between business units, the technology, processes, and agreements are all ad hoc.

Level 2: Focused

Level 2 practices presuppose a minimal amount of planning and documentation. The planning and documentation allow IT staff to carry out identity management tasks in a repeatable way, but there is little quality control, and so the results are not consistent. Practices and capabilities are fractured across projects. The statements in Table 15-2 characterize practices at this level.

Table 15-2. Characteristics of level 2 identity management practices

Area

Characteristics

Business goals

Business units see identity management as a tolerable requirement but perceive little value.

The focus of the identity infrastructure is security and operational control.

Policies

Some policies are written down, but there is little buy-in, and policies are not effectively distributed.

Policies are point specific or applicable to just one or two projects.

Policies are not enforced.

Processes

Processes are partially documented, although different groups within the same organization may carry out the same task using different processes.

Even when the same team is assigned to a task, the process definition is not sufficient to ensure that the application of a given process will have the same results each time.

Processes and activities are not audited.

Identity management

Automation occurs minimally in support of security functions and other tactical operations such as password reset.

Operational data for identity systems is inconsistently collected and analyzed.

Identity storage

Identities are stored in directories or other repositories built for a specific purpose.

Authentication

Users have multiple usernames and passwords.

Identity credentials are chosen by different projects with only project goals in mind.

Authorization

Authorization is done on an application-by-application basis.

Resource owners are assigned in high-visibility areas and make authorization policy for those resources.

Federation

Federation is still done using bilateral agreements, but standards are used to transfer identity information. Technology is implemented as needed.

Level 3: Standardized

Level 3 identity management practices are consistently executed, but they are static and do not adapt to changing business requirements. The statements in Table 15-3 characterize practices at this level.

Table 15-3. Characteristics of level 3 identity management practices

Area

Characteristics

Business goals

Business units see identity management as providing generic value to the enterprise but do not understand how it can enable their business goals.

Policies

Policies are created through a well-understood governance process. All parties know and understand what is required. Little or no formal enforcement.

Standard policies are used throughout the organization.

Processes

First-level operational metrics are recorded. By first-level, I mean direct, technology-defined measurements of operational parameters, such as "authentications performed per hour" or "authorization assertions delivered to partner X."

Service-level agreements (SLAs) are defined for first-level operational parameters. These SLA levels are largely self-defined and internal to the IT organization.

Processes, roles, and workflows are defined.

Processes and procedures for service are always followed, and consistent results are reached.

Identity management

Identity infrastructure automation is broad-based and chosen to meet strategic goals.

Identity actions are audited occasionally.

Extensive reports are produced, but feedback is rare.

Innovation occurs as the result of missing service targets or as a result of outright service failures.

Identity storage

Identity data has been cleansed and normalized.

The enterprise has established authoritative data sources.

Enterprise standards help system designers choose technologies that are interoperable.

Authentication

Passwords are synchronized across the enterprise.

Single sign-on is a reality, allowing users to move from application to application without reauthenticating.

Authorization

Access control is role based and driven by rules.

Access-control policies for different systems and applications are disconnected and manually updated.

Resource owners and custodians are formally assigned to all resources of value.

Federation

Federation processes are defined, and standard agreements are used as a basis for negotiation with partners.

Federation infrastructure exists and is usable by a variety of interests.

Federation is most likely to happen using a hub-and-spoke model.

Level 4: Integrated

Level 4 practices are repeatable, consistent, and make use of feedback from the business to adapt to changing business needs. Feedback is used to optimize the identity management practices and is based on sophisticated metrics and tools. The statements in Table 15-4 characterize practices at this level.

Table 15-4. Characteristics of level 4 identity management practices

Area

Characteristics

Business goals

Business units perceive the value of identity to their activities.

Business units are regularly consulted in determining the components of the identity infrastructure.

Business unit expectations for return on investment on the identity infrastructure are regularly exceeded.

Policies

Policies and standards are approached in a holistic fashion, evaluating needs comprehensively and crafting policies that interoperate with and enforce each other.

Identity policies are audited for effectiveness.

Identity policies are usually followed and enforced when they are not.

Policies are routinely reviewed and updated using a functioning governance process.

Processes

Processes are fully defined, documented, monitored, and measured.

SLA metrics are defined in terms of business requirements rather than technology-based activities.

Processes are regularly audited. Audit results are used to change the identity architecture.

Processes that support identity policies are consistently applied across multiple platforms.

Processes are automated.

SLA metrics are based on business value.

Identity management

Identity management activities are regularly automated.

Innovation occurs proactively, before service level failures.

Identity management activities are self-healing, incorporating organic corrective actions and improvement methodologies.

Operational results are monitored on an ongoing, perhaps even real-time basis and continuous improvement is the goal.

Identity storage

Identity data is consolidated using directory aggregation technologies such as metadirectories or virtual directories.

Internal data stores routinely share data using standard protocols and common schemas.

Authentication

Authentication is done using standard credentials that work enterprise wide.

The enterprise has a consistent approach to how credentials are used to authenticate against a standard set of security levels.

Authorization

Policy decision points base decisions on policies that are applied consistently and automatically across various devices and systems.

The enterprise supports an integrated policy distribution mechanism to support consistent policy application.

Resource owners and custodians are given a standard way to set and distribute authorization policy and understand how to do it.

Federation

Federation is networked. Adding new federation partners requires almost no effort. Federation partner provisioning may even be self-service in many instances.

The Rights Steps at the Right Time

As you go through the process of building an IMA in your organization, don't try to do too much too fast. For example, you might make the mistake of establishing policies that require activities and behaviors that aren't yet supported by the infrastructure. The way to avoid this is to have a firm grasp of where your organization is in the maturity model that is presented in this chapter, and then set goals to move to the next level in specific areas.

One thing you should remember is that most organizations will be at different levels of the maturity model for any given process or infrastructure component. For example, it's possible that a company could have a fully functioning self-service password reset functionality but not have enterprise-wide policies. The key is to assess your maturity in different areas and then set goals accordingly.

Finding Identity Processes

Evaluating the maturity level of your identity infrastructure involves evaluating business drivers, processes, systems, and user understanding for each component. As it turns out, evaluating the processes will cause you to evaluate the business drivers, systems, and user readiness, so that's where we concentrate our efforts.

The first step is to perform an identity process inventory . Starting out, you may not have many of your processes documented, so you have to go search for them. This is where the business function matrix that we discussed in Chapter 14 comes into play. One or more processes support each business function. Depending on how fine-grained you got in your decomposition of functions, you may have to dig a little deeper or come up a few levels to get to the right level for finding processes.

Processes can usually be found by looking for tasks and then asking, "How does this task get done?" For example, asking that question about the task of resetting a user's password will lead to the processes that use and update identities.

If you're organization is operating at the ad hoc or focused levels in the maturity model, you'll find the processes completely fractured according to business function, because they will have grown up independently. As your identity infrastructure matures, identity processes will cut across multiple business functions.

This discussion of processes may not seem to concentrate enough on identity. Be careful not to just pick out identity management processes, such as "password reset," or you'll miss other processes that also affect identity. For example, consider the "employee provisioning" process. On its face, this is not an identity management process, but as we'll discover in the next chapter, it's a process that is all about managing identities of various sorts.

Evaluating Processes

Once you've found the processes, the next step is to document and evaluate them. The following questions and ratings can form the basis for a process inventory:

Process name and description

List the name of the process and describe it so you can recognize it later.

Business drivers

What business functions depend on this process? What business goals are supported? Why is this process done?

Tasks

List any tasks that make up the process.

Documentation

Evaluate the documentation of workflows, roles, and systems and rank them on a scale from 1 to 10 (no documentation to stellar documentation).

Repeatability

Rank the repeatability of this process on a scale from 1 to 10 (not repeatable to fully repeatable).

Stability

Rank the stability of the process on a scale from 1 to 10 (unusable to rock solid).

Required staff and skills

List the staff (by role), unique skills, and required proficiency in those skills to perform this process. Assess and rank on a scale of 1 to 10 the proficiency level of current staff.

Systems and technology

List systems and technology that support this task.

Integration

Evaluate the level of integration of these systems and technology on a scale from 1 to 10 (not integrated to fully integrated).

Level of automation

Rank the automation level of this process on a scale from 1 to 10 (manual to fully automated).

User understanding

Rank the level of understanding that users of this process have on a scale from 1 to 10 (no understanding to perfect understanding). Note that we're not evaluating the people carrying out the process, but the people affected by it.

Metrics

List any metrics used to measure the effectiveness and performance of the process.

Feedback

Rank how the metrics listed above are used to evaluate and change the process over time on a scale from 1 to 10 (not at all to consistently).

The factors listed above are illustrative. You may find other factors that are important to you and your goals. You should customize this to suit your needs. Using the rankings that you arrived at in the evaluation should allow you to assign an overall maturity level to the process.

A team of people who are not involved in performing the process day to day should carry out the evaluation. The team can gather data through questionnaires, individual and group interviews, and reviewing documents. You will also need to create criteria that allow the team to make consistent judgments. The evaluation must be done in a way that is helpful rather than judgmental. One way to accomplish this is for the evaluation team to be transparent in its dealing with the process team, sharing data and insights freely, and thoughtfully considering feedback from the process team on the inventory.

Like everything else in the IMA, the process inventory is not a static document, but a tool that is used and updated as necessary. The inventory data is best stored in some kind of structured way (XML or a database), rather than as plaintext documents, so that it can be searched and evaluated. As you move through other activities in building your IMA, you'll find more identity processes. Have a methodology for adding them to the process inventory and incorporating them into the plan.

A Practical Action Plan

As you contemplate building an identity process inventory for your organization, you may feel overwhelmed. Most organizations have no idea how many processes they perform and are often surprised at the size of the number. The good news is that you can often make progress on the maturity of your processes in a piecemeal fashion, making the task much easier to accomplish. In the last section, I said that tasks lead to processes. Tasks are also one of the keys to prioritizing your action plan.

As you look at tasks, try to identify those tasks that are causing the organization considerable pain, because they're not performed well or those that are costing a lot to accomplish. The processes associated with these tasks are where you should start. As an example, consider that task we mentioned in the last section: resetting user passwords. Most organizations spend a lot of money on help desk-supported password resets, and there can be considerable benefit from automating the processes that support this task.

As you dive into the processes surrounding password reset, you're likely to find that there's not just one process, but many. Furthermore, they likely overlap and compete with one another. In an organization at the ad hoc or focused levels, there will be multiple password reset processes for each system and application. Furthermore, the administration of these passwords will likely be manual, requiring expensive intervention by multiple administrators.

After you've chosen the most critical processes to improve, envision the goal state for each of them. The goal state would likely include standardizing and documenting the process and replacing the manual processes on the various systems with an automated self-service system. Staffing may need to change, skills may need updating, and metrics developed. You may also move to integrate some or all of the many processes into a single process at the same time, or you may take that as a second step after the systems have been standardized.

The goal state can be documented in the same format as the process inventory given previously. Be wary of creating unrealistic goal states. For example, you may upgrade the technology platform significantly and move the automation ranking a great deal, but the stability ranking may not be able to move much until other process have been redone. Keep current skill sets, staffing levels, and budgets in mind when you're planning. Its OK to move slowly if that's all you can do. The important thing is having a process for continuous improvement.

Filling the Gaps with Best Practices

Once you have used the maturity model to assess your current state in any given area and selected a goal, the gap between these two is filled with what we can term "best practices ." The term best practice gets thrown around a lot. For our purposes, we use the term to define activities that have four characteristics:

Best practices build on the experience of others.

Best practices are usually evolutions of practices already being performed in your organization or in another. You can find out what others are doing by reading, going to conferences, networking in local and national industry associations, and hiring consultants.

Best practices are documented.

Your organization must have a methodology for documenting what it does in a way that others can follow. People should be trained in how practices are documented.

Best practices are repeatable.

Once practices have been documented, other groups can duplicate them. If the documentation is not sufficient to allow the practice to be repeated, then the documentation should be improved.

Best practices are measured.

Like any good recipe, practices that are repeated in the same way should give the same results. The only way to tell if you're getting the same results is to have some way to measure the outcome of the practice. Metrics can be used to evaluate a practice, determine why the results are not adequate, and then change the practice.

As I stated earlier, there are many things you will change in your organization as part of building a functional digital identity infrastructure, but I believe the best approach is to build the process first. As part of building the process, tools will be bought and systems will be changed, but those technology pieces are done in response to a process need rather than the other way around. Using process creation to drive tool and system changes results in clearer requirements and systems that meet business needs.

This thinking is antithetical to how many IT organizations approach solving technical problems. When faced with a gap, many turn to a vendor and product to solve the problem. Once the product has been purchased, then the organization gets down to developing a process to use the tool.

Creating a process that leads to your goal state requires several steps:

Design a process and document it. Be sure to include workflows, any necessary automation, and metrics that can be used to evaluate the effectiveness of the process.

Put the process into action. This may include hardware and software changes and upgrades, training, new staffing, and other changes.

Measure the results. Don't be afraid to change the measurements themselves if they're not giving you data that can be used to improve the process.

Feed the data back into the process design, make changes, and start again. This fine-tunes the process until the goal state is achieved.

One of the most difficult tasks is to integrate similar processes across different systems. This can require significantly greater resources and much greater political skill, but is the key step in moving from the focused level to the standardized and onto the integrated levels.

Conclusion

Building a digital identity infrastructure that is responsive to business goals requires assessing where your organization is now and where it wants to go. The identity maturity model and the associated process inventories presented here are a tool for doing that. Once you know where you want to go, processes can be designed, implemented, and fine-tuned to put best practices into place.

Chapter 16. Identity Data Architectures

As part of the State of Utah's enterprise architecture efforts, we completed an inventory of data repositories in the state in early 2002. There were over 250 databases that contained information about individuals and over 175 that contained records about businesses, and this didn't include spreadsheets, Access databases, and other minor repositories. The problem is that we couldn't really tell which records in one database were related to the records in another.

Many people are happy to hear that their government can't link database records, but it hampers many of the electronic government services that citizens would like to see. For example, there are over 20 different databases that keep track of information about health information for children in Utah. The end result is that when a mother brings her newborn in for immunization, the receptionist can't say, "I see that Johnny hasn't had his hearing and vision checked. Would you like me to schedule an appointment?" That sort of simple customer relationship management can't happen when you keep information about your customers in 250 different places.

As you think about the data in your organization, you'll probably find this story resonating with your experiences. Most organizations have volumes of data that has simply grown and expanded over time in a largely unguided fashion. While we like to think of databases as large repositories of multi-purposed information, most databases are simply persistent data storage for a single application.

Data is important in an identity management architecture (IMA), because identities are usually stored on computers as digital records of some kind. This chapter is about building data architectures for identity data. A data architecture links data to specific business goals and processes, categorizes it, identifies metadata, and defines important details about how it is represented.

Build a Data Architecture

Building a data architecture for identities requires that we consider three different concepts: categorizing identity data, exchanging identity data, and structuring identity data. Figure 16-1 shows these three components along with some of the issues we'll address for each.

Figure 16-1. Components of a data architecture for identity

As we discussed in Chapter 2, a digital identity is a record that contains one or more names as well as attributes, preferences, and traits of some person or thing. For our purposes in this chapter, we'll restrict that definition to records that contain some unique identifier. Moreover, we'll just refer to the preferences, traits, and attributes as "properties."

These identities might refer to people, applications, manufactured goods, or other things that the organization cares about. If I asked you to list the identities in your organization, you might include only records that identify people such as employee and customer records. You might miss billing records and might not even think of manufacturing data as a kind of identity data.

We commonly think of "identity management" being about authenticating and authorizing people to take certain actions, but for the purposes of this chapter, we need to expand this definition.

Processes Trump Data

We frequently hear the comment that an organization's data is one of its most valuable assets. I think that's probably true, but the fact is that data projects never go anywhere. There's never money for a project to clean up the data and create enterprise data repositories. What do businesses care about? Processes, because processes achieve business results. Let me relate a story that illustrates this.

Utah, a relatively small state, manages over $1 billion per year in federal government welfare benefits. Each state is responsible for ensuring that welfare recipients are eligible for the benefits that that state distributes. The majority of these benefits are distributed in four major programs that have different eligibility requirements. The job is made more interesting by eligibility interactions—your eligibility for one program could be affected by benefits from another.

Utah, like most other states, had four different computer systems that automated at least part of the eligibility determination process. The lack of a common identity across these four systems was costing the state real money every year in lost time and improperly paid benefits. Utah had tried years before to create a master identifier and then use that identifier in the four separate data repositories so that records could be linked. That had limited success, largely because it relied on the ability of benefits coordinators to link the individuals across four separate systems as they submitted applications.

The IT departments in the three agencies that administer these four programs could never make the case to business leaders to invest in a common identifier, even though there was real need. What ultimately solved the problem was a proposal to revamp the processes that these agencies used to determine eligibility. The new processes provided more decision support to eligibility agents, making their jobs easier and less subjective. That's something the business could understand. Utah decided to build a new eligibility system at the cost of tens of millions of dollars that served all four programs. Of course, the new system uses a single repository for client data, solving the problems with multiple identities.

When we build data architectures, we're doing so in support of business processes. Business leaders in Utah's health and human service agencies could relate to the process problems that their employees faced and saw real advantage (millions of dollars worth) in updating systems that served those processes, so they jumped on board. Process improvement drove the data architecture improvement.

The last chapter talked about using an identity management maturity model to improve processes. Our approach to data architectures is to drive identity data integrity by incrementally making the use of identities more consistent in business process. We'll use the process inventory as a starting point and process improvement as a driver for changes in the data architecture.

Processes Link Identities

The first step in creating data architectures is to gather baseline information about identities in your organization. The baseline inventory identifies high-level data sources and documents pertinent information about them. To do that, we'll start with the processes that we identified in the process inventory and find the identity records that are critical to performing those processes. Let's run through an example to see how that might work.

Employee Provisioning

Suppose you've identified "employee provisioning " as one of the processes important to your organization. That process starts when the decision is made to hire an applicant and includes steps such as the following:

Enter applicant data into the HR system.

Identify the hiring manager (e.g., the person who will be the new employee's boss).

Create a 401K account, payroll account, health insurance, and other benefits.

Assign the employee an office.

Order, install, and set up a computer including application software.

Set up an email account and access.

Set up network access.

Order and install a phone.

Update the right directory or directories with the new telephone number, email address, and office location.

Set up a voicemail account.

Establish access controls for all of the enterprise applications that the employee will need to work.

Issue a credit card for travel expenses.

When you look at the steps in this process, the employee is right up front. Consequently, it's easy to identify the employee record in the HR database as one of the identity records in this process, but there are others. Here are some of them:

Employee record in the HR system. The employee has an SSN that serves as a unique identifier. Most large organizations also assign a unique employee ID.

Employee record at the 401K, payroll, and benefit providers. These accounts would all have their own unique identifiers. The employee's SSN can be used to tie them all together depending on your privacy policy and that of your partners.

Record of offices with their location, size, and other properties. Offices might be assigned to certain groups or departments and would need to be associated with their occupants. The identifier is proprietary.

Record of the computer and any installed software. These all have serial numbers. In addition, each network adapter has a MAC address that uniquely identifies it.

Email and network access record in the proper directory or directories. There would be an email address and network identifier assigned as part of this record.

The phone system has records that identify phone lines. The telephone equipment has a serial number, and the phone number itself represents an endpoint on the telephone network. The phone number would need to be mapped to the office where it's installed.

The voicemail account would have an identifier and be tied to the phone number.

Each enterprise application that the employee needs access to (such as the CRM system) would have some way of identifying the employee.

The credit card represents a separate identity document that the company or its payment partner may track. The credit card number is the unique identifier in this case, and your financial services will likely assign others for online access to the account information.

As we consider a single business process, it's amazing to see how it can translate into multiple identity records. Process links these records even if the infrastructure does not.

The Identity Data Inventory

Going through the process inventory to find identity records creates an initial identity data inventory . The data inventory is a listing of each identity data source and its contents and other important meta-information. The following attributes should be recorded as part of creating the inventory.

Name of the data store

This could be something created at the time of the inventory, or it may be a name that the owner or custodian uses to identify the data record.

Version

Your organization might not think of data stores as something that is under version control, but it's a useful idea and one you can start with the baseline inventory.

Definition

Define the data record and its purpose; limit to one or two sentences.

Process

What process (or processes) does the data record support?

Identifiers

What fields in the data record are uniquely identifying. There can be more than one identifier. For example, in an HR data record, the SSN and employee number are both identifiers. Many database records have a record number that is unique but has no real identity meaning other than for the record itself. Avoid listing this unless it's meaningful to the business.

Properties

These are all of the other attributes, traits, preferences, and characteristics that are included in the record and are used as part of the identity.

Owner

Who is the owner of the information?

Custodian

Who is the custodian of the information?

Notes

Any other relevant information about the identity record should be recorded here.

One approach to creating the data inventory is to have business units create inventories for identity data they own and then to aggregate the results. Be careful, however, to train the people performing the inventory so that you get consistent results. You will also have to take care to ensure you don't miss data sources that are jointly owned or owned at the enterprise level. As we've seen, business function and, hence, process do not always fall within neat organizational boundaries. You may find that it's more convenient to create the baseline data inventory in conjunction with the process evaluation that we discussed in the last chapter, instead of doing it as a separate step.

Data Categorization

Once a baseline identity inventory has been created, the next step is to categorize the data. We do that using three different techniques. The first is called the identity data audit and asks additional questions about the data in the inventory. The second technique creates an identity map that specializes the identity lifecycle for each data source. The final technique is a process-to-identity matrix that helps us to easily see which identities support which processes.

Identity Data Audit

The purpose of the identity data audit is to answer additional questions about the baseline identity inventory. Identity data audits should be done periodically, say, once a year, as part of maintaining the IMA. During these audits, the inventory is updated and additional data is gathered that is useful in managing the identity data, doing risk assessments for security and privacy purposes, and protecting against loss.

Someone other than the owner or custodian of the identity data should do the audit, although it might be done on the owner's behalf. In a large organization, the CIO's office would be responsible for performing the audit. The audit consists of gathering information through a series of questions and then evaluating the information gathered. The questions we ask are very similar to the kinds of questions we discussed for privacy audits in Chapter 4. A privacy audit can easily be folded into the identity data audit, but be sure to include a specific evaluation of privacy in the results.

Here are some of the questions you might want to ask:

What is the purpose of collecting this data?

How is this data being collected?

Were special conditions on its use, such as privacy policies or non-disclosure agreements, established at any time?

Who are the data owner and custodian, if not recorded in the inventory?

Who else can make changes to or administer the data?

Who uses the data, why, and how do they usually access it (i.e., remotely, via the Web, from home, etc.)?

Where and how is it stored?

Is the data dependent on other sources of identity data (such as another directory)? If so, who owns those stores?

Is this data record the canonical or authoritative source for this information? If not, which data record is?

What is the schema for the data?

Is there a related domain model?

How large are the records?

How many records are stored? What is the maximum expected?

What are the data transactions (SQL or other queries) routinely performed on the data store?

Is any of the data stored on devices that are routinely transported off-site such as a laptop or PDA?

Are there backups? If so, you need to answer these same questions about the backups.

How critical is the data to the business?

What are the tolerances for data loss or corruption?

Where and how is encryption used in the record?

Is the data synchronized to another repository or regularly accessed through a bulk data transfer? If so, you need to answer these same questions about any other repository for this data.

Are their access logs for the data?

Where are the logs stored?

Are the logs protected and who has access and administrative rights to the logs?

What other security measures (firewalls, intrusion detection systems, and so on) are used to protect the data?

Who administers those systems?

These are only example questions. You may think of others that need to be asked that are specific to your organization or the data in the inventory. Using the results of the audit, you should evaluate the maturity level of this identity data. Don't hesitate to assign different maturity levels to different aspects of the identity data. The results of the audit should be shared with the owner and custodian of the identity data so that they can offer feedback and correct misperceptions or mistakes.

As you conduct the audits, you should be on the lookout for the following kinds of issues:

Identity data that is never used

Identity data that is owned by someone who doesn't use it

Owners at the wrong level (e.g., identity data that has strategic importance but is controlled by a small tactical organization)

Incomplete relationships between identity records or relationships that are enforced outside the system

Identity data that is not located on the same system where it is used

Identity data for which there are multiple copies and no canonical source

Audit data should be stored in a data repository to which multiple people can be given access. For example, some of the information in the audit will be useful for capacity planning, while other information will be useful for security audits. Sharing the data as widely as possible will build support for the process.

Identity Mapping

In Chapter 5, we discussed the lifecycle for digital identities. The purpose of creating an identity map is to instantiate that general model for each identity record. This should result in a flowchart that shows how and where the identity record is created, how it is used, and where it ends up. Figure 16-2 shows an example identity map for an employee record.

The map in Figure 16-2 is greatly simplified from what would really happen to an employee record in even a small organization. However, it illustrates the point that the identity map is an instance of the general lifecycle. The important parts of the diagram show:

Details about how the record is created

Specific instances of how the record used

The process by which the record is updated

How the record is eventually deleted

All of the dependencies between this record and other systems are recorded in the map, as well as the critical systems that can modify the record. Note that in this simple diagram, the HR system is the only system shown that updates the record, but that's not likely to be the typical case. For example, the payroll system may have access to and update portions of the employee record.

Figure 16-2. Example identity map for an employee record

Identity maps are especially useful when you are trying to find the interactions between identity systems and rearchitecting them as part of system or infrastructure upgrades. You may not complete identity maps for every identity record in your organization all at one time, but rather build them as process improvement plans dictate.

Process-to-Identity Matrix

The purpose of the process-to-identity matrix is to relate identities to the processes that they support in a visual way. Using the matrix, we can easily identify records that are used by multiple processes as well as identifying areas where different records are serving the same purpose in different processes and might be combined.

Table 16-1 shows an example process-to-identity matrix drawn from the employee provisioning process that we discussed earlier in this chapter. In this matrix, we can see the identity records used by the employee provisioning process as well as how some of those same records are used by the asset management process, the financial audit process, and the enterprise sales process.

Table 16-1. Process-to-identity matrix for employee records

Employee record (HR)

Employee record (payroll)

Building record

Computer inventory record

Email and network record

Software inventory record

Phone record

Voicemail record

CRM directory

Travel/card

Salesman performance record

Employee provisioning

✓

✓

✓

✓

✓

✓

✓

✓

✓

✓

Asset management

✓

✓

✓

✓

Financial auditing

✓

✓

✓

Enterprise sales

✓

✓

✓

Notice that the enterprise sales process doesn't use the employee record or phone record. At the same time, if we were to dig into the inventory and audit data for the salesman performance record, we might find that it contains employee and phone information for the sales team. This illustrates how we can use the matrix to improve processes by normalizing data so that the enterprise sales process derives important employee data from canonical sources.

Identity Data Structure and Metadata

The inventory has created a database of the identity data in use, and the audit has gathered a lot of information about each data source. One of our goals is to establish an authoritative source for each identity. One of the barriers is inconsistent usage and content for identities that should be the same. There are five basic ways that identities can be inconsistent across different data sources:

Inconsistent use of identifiers for the same data. Your organization might have several data records that are used to store customer identities. The identifier in one might be the database record number, another might use the SSN, and a third might use a company-assigned customer number.

Inconsistent values for the same data in a field. The customer's name might be stored as a single value in one identity record, split into first and last name in a second, and a third might store middle initial and suffix.

Inconsistent names for fields that carry the same data. One identity record may store the customer's last name in a field called lname and another might call it lastname. These are called synonym fields.

Inconsistent meaning for field names. Two identity records might use the field name phone, but one might use it to store the phone number of the customer and the other might use it as a flag to indicate that the salesperson should make a follow-up phone call to the customer. These are called homonym fields.

Inconsistent representation. One customer identity record might store the customer number as a number and another might store it as a series of characters.

As you identify elements of identity records that have the same business purpose, you have the opportunity solve these inconsistencies. In most organizations, this will require meetings between the respective owners and custodians of the identity records to hash out a common format for the data elements and choose an authoritative source. The owner of the authoritative source becomes the owner of this data element.

Authoritative metadata records are stored in a metadata repository. As the data elements of identity records are made consistent, metadata records for those elements should be entered in the metadata repository. New projects should be encouraged to use the metadata repository to find identity information they need. Projects should also submit new data element definitions to the metadata repository as they are defined so that other projects can use existing data element definitions instead of creating new inconsistencies that have to be ironed out later.

Even if all of the various data sources can't be made consistent right now, it's useful to create the metadata record to store the common format as a goal state so that existing projects can refer to it as legacy systems are maintained and updated.

Table 16-2 shows the metadata fields, describes their purpose, and gives examples of what might be stored in each field for a Social Security number (SSN) element in a hypothetical organization.

Table 16-2. Metadata for identity data elements

Field

Purpose

SSN example

Data element name

The field name for this data element

SSN

Element definition

The human definition of this data element

A nine-digit number used by the Social Security Administration and IRS to identify individuals

Owner

The individual (usually by role) who owns this data element

HR manager

Scope

The geographic or organizational scope where this data element has meaning

U.S.

Business format

The standard business requirement for the format of this data element

999-99-9999

Business length

The length of the standard business format

11 characters

Business type

The common way that business thinks of this data element

Number

Usage and audit requirements

List any business restrictions on using or requirements for auditing this data such as privacy policy, HIPPA, etc.

Example Company, Inc. Policy on Privacy

Exchange format

The standard format for exchanging this data in the organization

999999999

Exchange length

Length of the exchange format

9 bytes

Exchange type

The type of the exchange format

Character

Storage format

The format for storing this data element

999999999

Storage length

The length of the storage format

9 bytes

Storage type

The type of the storage format

CHAR or VARCHAR

Storage location

Location of the authoritative source

HR employee record system

Encrypted

Whether this data element should be encrypted

Yes

Encryption algorithm

The encryption method used to encrypt this data element

Blowfish

The information in the metadata repository represents a valuable resource to system developers. Using the metadata repository, they can find out where to get identity data for their applications, who owns it, and what formats should be used. The metadata repository is also the basis for exchanging identity data .

There are numerous tools and methodologies available for creating metadata repositories. Large organizations will probably have the time and money to invest in these tools and train IT personnel in their use, but even small organizations will benefit from creating a simple metadata repository as the canonical source of information about identity data elements.

In creating the repository, it's important that it be accessible and that the rules for creating or updating records not be overly onerous. The goal is to create a tool that system architects and others can use to guide their work. For example, the repository should probably be online rather than stored in a spreadsheet on someone's personal machine.

Exchanging Identity Data

Our goal of creating consistent sources of identity data, combined with the realities of modern distributed organizations, means that there is not likely to be a centralized source of all identity data. Consequently identities will be exchanged between systems, and we should plan for that as part of our data architecture.

We've discussed XML standards for exchanging identity data in Chapter 6 and 11. SAML is a standard for exchanging assertions about identity, including access-control information and properties of the identity record. SPML is used to exchange identity data for purposes of provisioning identity systems. XrML is used to exchange information about rights for digital resources.

These standards and others like them should be the basis for your data exchange strategy. Don't discount the power of standard exchange formats for your data. Whenever you need to exchange identity data, look first at the external standards that are available and choose one of those. Using an external standard is always preferable to creating proprietary internal standards for several important reasons:

You can buy tools that support those standards.

You can hire consultants who understand them.

Thousands of people all over the world are thinking of interesting ways to use them.

Also remember that many XML-based standards are extensible through namespaces and can probably be adapted to suit your needs even when they don't match exactly.

But, suppose that you can't find an external standard that meets your needs. The two documents we've created so far will help to create your own exchange format. The identity inventory gives the data elements for each identity record in your organization, and the metadata repository gives details, including preferred formats, of the structure for each data element. These two resources can be used to generate XML schema that support the exchange. If the inventory and metadata repository are structured correctly, tools can be bought or written to automatically generate the XML schema. The URL for any exchange schema should be documented in the identity inventory.

When should you avoid XML? XML's biggest drawback is not that it's verbose, although it is; it's the serialization and deserialization of the data in and out of the XML format. To maximize flexibility, you should pay the price of serialization whenever you can afford it, but always under any of the following conditions:

When the data formats have the potential to change in the future.

When the data is being exchanged with an external partner.

When the systems exchanging the data are separated by a WAN. Network latency is likely going to mask any latency introduced through serialization.

When you're using asynchronous transport for the data. Again, latency in the transport will likely mask the serialization latency.

If you do decide to forego XML, the format can still be derived from the data in the inventory and the metadata repository. Be sure to document the exchange format using some agreed upon standard and reference it in the inventory.

Principles for Identity Data

As you review, consolidate, and create identity data, there are several important principles that you should keep in mind. Some of these are adapted from The Practical Guide to Enterprise Architecture by James McGovern, et al. (Prentice Hall).

Don't replicate identities

Wherever possible, you should avoid replicating identity data and ask for it from its canonical source instead. For example, if you need the SSN for an application, it would be better to retrieve it using a SAML request or database query from the HR employee record.

Business requirements should drive identity replication

If you can't avoid replicating identity information, you should do so only because the business requirements force the replication. Application developer convenience is never a good reason for replication. One of the primary reasons for this principle is that identity data is often subject to internal and external audit, security, and privacy requirements that will have to be monitored and paid for by the business unit. Replicating identity data increases the cost of these external requirements and so that cost ought to be traded off against business requirements.

Replicated identities should be read-only

Break this principle at your own peril. As soon as multiple systems can change replicated data, the data will be guaranteed to be out of sync.

Identity data should be locationally transparent

Applications should be constructed so that they don't rely on the identity data being in a particular data source or on a particular machine. This will increase flexibility in future application changes. Using SAML, for example, to request properties of a particular identity over the network, rather than reading them using an SQL query over JDBC makes it easy to change out the database for another application without breaking the system.

Enforce the consistency and integrity of identity data with policies, processes, and tools

The more you can build consistency into the infrastructure, the more likely it is that the data will remain consistent. We'll discuss the role of policy in this principle in the next chapter.

Don't rely on a single validation to check the integrity of identities

Whenever identity data will be collected and used in multiple locations, each system should perform validity checks on the identity data as part of its processing. These checks should ensure that the identities conform to the relevant schema and any business rules documented in the inventory or metadata repository.

Use open standards rather than proprietary standards

As we've discussed, open standards have a number of advantages over proprietary standards.

Use encryption to protect sensitive identity elements

Sensitive identity data should never be stored unencrypted. Usually, encrypting the entire record is too disruptive, because it has to be unencrypted each time any part of it is used. A better strategy is to encrypt just the data elements that are sensitive. As we saw in Chapter 6, the XML Encryption standard can be used to encrypt only certain elements in an XML record.

Conclusion

We've discussed creating data architectures for identities by performing a baseline inventory, categorizing the results, creating a common data representation standard in the form of a metadata repository, and establishing exchange standards for important data. The final word of advice I'd give on data architectures is to approach them piecemeal. Nothing will kill your data architecture efforts faster than trying to create a huge monolithic project. Drive the effort from process improvement projects that fall out of the process inventory. Scope them so that no project requires "solve all our data inconsistency problems" as the first step.

Chapter 17. Interoperability Frameworks for Identity

Interoperability frameworks (IF) are nothing more than listings of accepted standards, both external and internal, that an organization uses. An IF is an essential prerequisite to enabling decentralized identity infrastructures that nonetheless work together to achieve the organization's goals and objectives. A good IF complements policies and provides a foundation on which they can be more effectively created and enforced.

An IF is created in accordance with the same governance procedures that were discussed in Chapter 14. This chapter will discuss the properties and content of a good interoperability framework.

Principles of a Good IF

An interoperability framework is a working document that systems architects, software developers, and others can use to guide their work. There are several significant principles that a good IF should follow.

Derived from current practice

A good IF is never created in a vacuum. Your organization is using particular standards and technology right now, and that's what you should start with when developing your IF. Even though the first draft may begin as a ragtag collection of disconnected and conflicting standards, over time, the list can be refined and pruned. We'll see later in this chapter how to use status designations in the IF to accomplish this goal.

Enforced

A good IF will guide the engineering of the identity infrastructure. Just as with policy, this goal is achieved only if the organization is willing to enforce the IF. As with any standard or policy, a process should be put in place for exceptions and approving deviations from the IF. Nevertheless, adherence to the IF should be expected within the organization, and the governing organization must have ways of bringing projects into compliance.

One way to do that is by controlling purchasing. The IF should guide purchasing decisions. In a large organization, this might be enforced through the purchasing department. Even in smaller organization, procedures can usually be put in place to reinforce the IF. For example, in a small organization, a single person typically has final signature authority on hardware and software purchases and thus can guide the infrastructure toward certain standards .

Understandable

Technical and business management must understand the IF. Most important is that management understands the need for standards and why certain standards have been placed on the list and others have been left off. If management does not understand the motivation behind choices in the IF, you will have a tough time getting cooperative compliance.

Complete

The IF should take into account the full context of the organization. When you create the IF, include every standard currently used by the organization. Make sure to review those and identify any gaps where there is no standard, de facto or otherwise.

Flexible

Ensure that the IF is subject to a governance process that can rapidly adapt or respond to changing business needs. The idea is not to create a straightjacket that keeps the organization from doing anything, but to channel activity into paths that lead to the interoperability of decentralized systems.

Contents of an Identity IF

As shown in Figure 17-1, an IF contains three primary kinds of standards:

External standards

Examples might be the kinds of XML standards, such as SAML, that we discussed in Chapter 11.

Software standards

These are software choices that the organization has made. An example might be a decision to support MySQL or Linux.

Hardware standards

These are specific hardware choices that affect interoperability. The organization may set some hardware standards strictly as a purchasing decision. Those would not typically be included in the IF. Inclusion in the IF should be done on the basis of interoperability benefits rather than purchasing power or efficiency.

Each of these may be broken into subareas, as necessary, and in each subarea choices are enumerated and documented. In addition to sections enumerating standards, an introductory section should contain the following information:

Figure 17-1. An interoperability framework provides the foundation for the policy stack

Guidelines for use

This section describes how the document is to be used.

Governance

This section describes the governance procedure that created the IF and how the IF can be changed. This section also describes the review cycle for the overall document.

Application

This section describes the scope of the IF and where it should be applied.

Exemptions

This section enumerates any global exemptions and provisions for requesting exemptions.

Standard Status

Each standard in the document will have a status that indicates whether following the standard is mandatory or not. There can be any number of status levels depending on the needs of the organization. The following are adapted from the status levels that we used in the State of Utah to define an IF:

Approved

An approved standard is critical to the enterprise and will be enforced.

De facto

A de facto standard identifies choices that are widely accepted because of widespread use within the enterprise and industry.

Emerging

Emerging standards may have future value within the enterprise but have proven no specific benefit at this time. The enterprise may be conducting a pilot project to establish the potential benefits and risks of selecting this standard.

Sustained

A sustained standard indicates a standard or practice that no longer shows promise but is still used or even expanded because of a prior standards solution.

Sunset

A sunset designation is given to a standard or practice that has been abandoned for a better solution. It is not a favored standard yet continues to be in use in the enterprise. Projects should plan to migrate away from solutions assigned this designation as soon as practical.

In process

An in process designation refers to a standard that is going through the governance process and awaiting approval and an assignment of status.

Approved and de facto standards represent areas where there is significant technical or monetary investment. Approved standards are the most powerful designation for creating standard environments and conventions to promote interoperability.

Sustained and sunset standards are generally nearing the end of a lifecycle and should be avoided for new development without extenuating circumstances. There will always be legacy standards in the organization. Those that the IMA intends to support should be designated as sustained. One goal of the IF is to ensure that standards don't outlive their useful period and are retired when convenient for the organization. The sunset designation is the architect's tool for moving the organization away from standards that are no longer serving a purpose and should no longer be used.

Emerging standards show promise and are likely to become approved standards after they have proven themselves in a pilot project or other demonstration. The emerging designation is the architect's tool for calling attention to new standards and encouraging their use.

Listing Standards

For each standard, the IF should list the following information:

Description

The description might be as simple as the name of the standard if sufficiently descriptive.

Reference

This would typically be a URL pointing to the location of the standard. For internal standards, the reference could be a URL for the document or other internal ID.

Status

This would give the status of the standard as discussed above.

Review cycle

This notes the recommended review schedule (e.g., annually, biannually, etc.)

Notes

This is the place to list any additional information. Use this section to describe motivation or refer to a larger document that does so. This is also where conditions for use or exceptions can be noted.

Example Interoperability Framework

An entire IF can take several dozen pages. Table 17-1 shows four entries from an interoperability framework. The example shows parts of two subareas: Encryption Standards and Federation Standards. These would be a larger table of external standards that the organization supports.

Table 17-1. Portion of an interoperability framework

2.3 Encryption Standards

Description

Reference

Status

Review

Notes

XMLsig

http://www.w3.org/TR/xmldsig-core/

Approved

Annually

XML Signature Syntax and Processing (XMLsig) is defined by W3C. W3C Recommendation 12.02.2002.

XMLenc

http://www.w3.org/TR/xmlenc-core/

Approved

Annually

XML-Encryption Syntax and Processing. W3C Recommendation

10.12.2002.

XML Encryption is used to secure encrypted transport of content. Used when security on the transport-level (such as SSL) is not sufficient.

2.4 Federation Standards

SAML (Security Assertions Markup Language) Version 1.1

http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-1.1-cd.pdf

Approved

Annually

OASIS/SSTC Version 1.1 - 22.09.2003. SAML enables single sign-on and enables federated identification mechanisms.

SAML (Security Assertions Markup Language) Version 2.0

http://www.oasis-open.org/committees/download.php/7874/sstc-saml-tech-overview-2.0-draft-01.pdf

Emerging

Quarterly

SAML 2.0 is currently a draft specification. Use in production project is subject to approval and supporting product availability.

Notice that the emerging SAML 2.0 standard is reviewed more frequently and that its use is made subject to approval by the notes. These reviews need not be lengthy or subject to the formal governance process unless something like the status is going to change.

The document shown here is formatted as a table. This is a common way to format an IF, but you can see that it suffers from some limitations because there is insufficient space to include many details. Also, simply publishing the IF as a paper document, or an Excel spreadsheet on the Web, limits its usefulness. A large IF should be put into a content management system and made available over the Web in a variety of formats, including a table-based summary for quick browsing with links to detail pages for each standard. These detail pages should contain all of the information shown in Table 17-1 along with other useful information such as supporting standards, the relationship of the standard to others, projects inside the organization that employ the standard, links to procurement information, and the contact information for subject-matter experts.

One good example of an online interoperability framework is the Danish government's Reference Profile.[*] Like any good IF, this online resource gives members of the Danish government's IT community useful information on what standards are supported and how to find out more information about them. In addition, the online application allows the IF to be searched and for each individual standard, users can retrieve a detail page, link to the standard's official reference document, save the standard in a bookmark, or write a review.

[*] See http://interoperabilityframework.info/English/index.html for the English version.

A Word of Warning

One of the real dangers of creating an interoperability framework is the temptation to be overly restrictive. Many IT managers have made the mistake of trying to home in on single technology choice on the premise that such standardization will lead to better efficiency within their organizations. In theory this is true, but in my experience, it's a rare organization that has the discipline to pull it off. Perhaps, more importantly, such single-minded devotion to specific technologies can limit agility and create an organization that is overly rigid.

As an example, most large organizations are going to be running a mixture of Linux and Windows (at least on their servers) and developing in multiple programming languages. I found as CIO for Utah that it often made real sense (and cents) to have one project using IBM's WebSphere J2EE application server, another using BEA's WebLogic, and yet another using the jBoss open source application server. You'd think that because all of these projects were based on the same standard (J2EE, in this case), they'd be able to use the same application server, but it just didn't bear up under analysis.

Here's one real scenario where that happened. We went out to bid on a $30 million project to build an eligibility determination system for welfare benefits in the state. The project would replace a 20-year-old green screen COBOL application. The winning bidder happened to be IBM. If we'd put in the Request for Proposals that the system had to use WebLogic, which many projects in the state were using at the time, IBM would not have bid and the state would have lost out on what was ultimately the best system as judged by business and technical people working on the bid.

You might conclude that it's hopeless, but I don't think so. You'll get more interoperability mileage by picking standards to support in the IF than by picking identical software and hardware or software development environments. If the software and hardware support the standards that are important to you, then you'll get interoperability anyway and still be able to reap the benefit of picking hardware or software for other reasons such as price or feature set. TCP/IP is a real example of this principle in action. This networking standard is now so pervasive that we wouldn't even think of purchasing certain hardware or software that couldn't internetwork according to the TCP/IP standard. Choosing standards within your organization can provide the same benefit in other areas.

Conclusion

An interoperability framework for your IMA is a crucial foundational document that should be created as one of the first deliverables of an IMA effort. Policies and other documents should reference the IF rather than calling out specific products and standards by name to ensure that they are modular and easy to update. Creating an IF needn't be a difficult task. The document is relatively straightforward, and you can probably gather currently used standards from your organization easily. The hardest part is likely to be the assignment of status levels to various standards, particularly those of approved and sunset, because they call for action on the part of system architects and implementers.

Chapter 18. Identity Policies

As a new CIO, I had an imperfect understanding of the role that policies, procedures, and rules played in managing a large IT organization and, more important, governing its interaction with the business. I underestimated their power and I neglected them for some time. As I became more comfortable in the role of CIO however, I realized that policies, procedures, and rules, properly enacted through a participatory and well-understood governance process, were the primary means by which I could shape the future direction of IT in a large, loosely coupled organization.

If you've completed the activities discussed in the preceding chapters, you'll understand the governance procedure that is used to create policies, have a good idea of the business context of your organization, have a good inventory of the processes and identities that exist in that context, and have an interoperability framework.

We distinguish between policies and standards. As we saw in the previous chapter, standards stipulate specific levels of performance, specify certain goods or services, set quality requirements, or describe best practices. Policies, on the other hand, are internally developed rules of conduct and behavior that are specific to the organization. Policies often refer to standards.

In this chapter, we'll discuss what policies are, how they can be written so as to be effective, how they can be implemented, and how they should be maintained.

The Policy Stack

Many technologists loathe to create policies, feeling that policies stifle creativity, impede productivity, and are nothing more than an autocratic attempt to control people. In fact, if designed correctly, policies enable action and productivity. You cannot create an IMA and reap the attendant benefits without policies. They are the heart of the architecture as well as the foundation on which effective identity management strategies are formed. Policies define appropriate behavior, specify the tools and processes that will be used, communicate a consensus, and provide a foundation for enforcement.

Many organizations have a smattering of security policies in place, and some of these touch on identity issues. In creating an identity management architecture, we're advocating separating out the identity aspects of those policies and creating a holistic approach to identity on which to build not only security policies, but also other important aspects of the business.

Figure 18-1 shows an IMA policy stack. The interoperability framework of standards undergirds identity policies. These policies include naming, passwords, encryption, authentication, privacy, access control, provisioning, directories, and federation, among others. In turn, the IMA supports activities important to the business such as software practices, security policies, software licensing, contracting, procurement, customer strategies, information protection, risk assessment, and partner interactions.

Figure 18-1. The policy stack with the interoperability framework as its foundation

Attributes of a Good Identity Policy

Since policies define appropriate behavior and form the basis for enforcement, they must have several important qualities.

Implementable

Good policies should be realizable given existing technology and resources. Technical controls are not always possible. The reason for having subject-matter experts available as one of the IMA governance roles is to provide the needed expertise to ensure that the policy being developed is workable. As you get buy-in from various groups, many of the problems that would keep the policy from being implementable will show up during the review process.

Enforceable

Enforceability requires that the policy have clear guidelines on what to do and that enforcement procedures are clearly spelled out. For example, if enforcing a particular policy requires periodic physical audits of the workplace, then the procedure for conducting the audit and the timetable should be given by inclusion or reference in the policy. Penalties for non-compliance should also be included in the policy where applicable. Creating workable enforcement provisions will usually require having legal and human resource subject-matter experts review and comment on the policy.

Understandable

The people who have to live by the policies should be able to understand them. Writing good policies requires walking a fine line between formal and informal language. Users often perceive formal language as "stuffy" or "officious." At the same time, informal language often lacks the precision necessary to clearly say what needs to be said. Regardless, the tone should be straightforward and clear, using short sentences and bulleted lists for ease in reading. Paragraphs (and subparagraphs) should be numbered so that they can be referenced easily. Policies should avoid third-person voice wherever possible, because it can obfuscate who is responsible for taking action. Most organizations will likely want to adopt a template as one of their first actions in creating policies so that subsequent policies share a common format.

Guided by the business

Policies should be tied to business goals and represent a consensus. Nothing is more important than creating consensus among the influencers in your organization around each policy. People trying to "just get the work done" will circumvent policies that are too restrictive, not understood, or perceived as being impractical. One of the primary purposes of the IMA governance procedure and of building the business model is to create a process that will avoid policies that "don't work." Remember that no matter how important you may think a particular policy is, it will be a waste of time if most people do not voluntarily adopt it. Enforcement is not a tool to force compliance so much as a tool for ensuring uniformity and gathering feedback.

Determining Policy Needs

In previous chapters we have discussed, in some detail, the process for creating a business model and inventorying processes and identities. If you have performed these activities, you should have a good idea of how the business is using identity information and what priority the business places on various resources.

Identity policies will typically come from one of four places:

Business inspired projects and processes

Security considerations

External demands

Feedback on existing policies

Business Inspired Projects and Processes

In Chapter 9, I discussed the metadirectory project that the State of Utah completed. This project was driven by a clear business need—specifically, the governor and others wanted a better URL for state web sites and shorter email addresses. This project inspired policies about naming conventions and directory interaction. This is just an example of how business projects and processes inform identity policies.

To some, driving policies from business projects and processes may seem somewhat less than pure. But in fact, that's the point. By tying your policies to the places where they are needed, you'll get better policies and avoid creating unused policies. As an example, you may determine that you can justify the creation of part of your identity infrastructure on the basis of the savings from password reset. That's a perfect opportunity to create naming, password, and directory policies. Even then, you might opt to create just the parts of those policies that you need to complete the password reset project and leave other parts of those policies for another time.

The danger in this approach is that sometimes business requirements will demand that decisions be made faster than you can accommodate with the policy creation process you've put in place. You can mitigate this problem in one of two ways:

Proactively create policy templates in the primary areas we'll discuss later, making preliminary decisions. A good example where this may be necessary is a policy on encryption. Decisions about encryption may need to be made in a matter of a few days, and waiting until the decision is needed to create the policy doesn't leave enough time.

Create an expedited procedure for solving policy questions. Use this process to create point policies on the specific questions that need to be answered immediately, and use the longer policy process, including its built-in feedback mechanism, to iterate this point policy to a more general solution.

In either event, you want to avoid two extremes. On one extreme, you delay important business decisions and their implementation with the policy process. This is certain to breed discontent and force people to work around the system, rather than within it. On the other extreme, people make decisions without any guidance from the policy process and the identity infrastructure suffers from ad hoc decisions and no structural context.

Security Considerations

One of the most important roles for identity policies is to secure organizational resources. Much has been written about information security , and most large organizations have people in place who are dedicated to this important task. You may already have security policies that touch on some of the identity issues that we're discussing.

One thesis of this book is that identity enables information security but is not subsumed by it. Indeed, there are significant security considerations that have little to do with identity such as firewall and intrusion detection policies. This implies that security policies should be separate from and built on identity policies, as shown in Figure 18-1.

Traditional security policies such as network security, acceptable use, and firewall requirements typically use concepts such as naming, authentication, encryption, and access control; but policies on those issues are frequently not aggregated together. You may find on reviewing security policies from your organization that they even contradict each other on these issues.

Separating identity policies from security policies requires that you rewrite each security policy to remove more general identity issues and reference them instead. As you do this, the requirements of your security policies will drive the contents of your identity policies.

The governance process should always include subject matter experts on security so that they can speak to information security needs as policies are developed and implemented. In fact, you may find that the governance process we've outlined in this book is useful for creating and maintaining security policies as well. Just be sure to keep those policies separate. While the needs of information security should play an important role in creating identity policies, they should not overshadow other important needs in the organization.

Meeting External Requirements

External sources such as government regulators and large partners frequently place requirements on the enterprise. These are another important place for identity policies to germinate. External requirements might be legal or regulatory requirements such as HIPPA, Sarbanes-Oxley, or the Gramm-Leach-Bliley Act. At other times, these external requirements are developed by some industry group and have the force of law for all intents and purposes (such as "generally accepted accounting principles"). Others are voluntary, but the business has concluded that they will abide by them for some reason.

In any event, your organization probably already meets, or attempts to meet, these requirements. Doing so places a burden on the identity infrastructure. Identity policies can codify and normalize these requirements as well as provide a process for meeting the many external identity requirements that are placed on your organization.

Feedback on Existing Policies

Determining what policies are needed in your organization is an iterative task, not an event. Like any good business process, the governance model discussed in Chapter 14 has a built-in feedback mechanism. If properly implemented, this feedback mechanism will give you information about what policies are working and which are not. It will also point to policies that need to be developed to answer questions that arise in the application or enforcement of existing policies.

Writing Identity Policies

We've already discussed four important attributes of a good identity policy. In addition to those specific attributes, there are important guidelines that will help ensure that your policies are implementable, enforceable, understandable, and guided by the business:

Never release a policy that you can't or won't enforce. Creating policies that people ignore weakens the process.

Build a policy review framework. The review framework is a document that gives status information and a review schedule for each policy.

Good policies are general enough to not need frequent updating. Policies should be unambiguous without being so specific that they lose their relevance with every change to the business operations of the organization.

Avoid referencing specific standards or products in your policies. Instead, use an interoperability framework to call out specific products and standards. Merely reference specific sections of the interoperability framework in the policy. This will ensure that policies don't have to be continually updated as new products and standards are released.

Policies should not specify processes or "best practices." Policies, however, should talk about "what" not "how."

Policies should not contain confidential or proprietary information, because they will be widely distributed. When this is unavoidable, be sure that the policy is properly classified and that chosen classification allows everyone who must see it to have access.

Rather than writing large, monolithic policies, break them into short, modular documents and cross-reference specific sections when needed. Develop modular policy structures just as you would modular software. The benefits are similar. Short modular policies:

Can be reused by reference from multiple places

Benefit from being written by an expert in that specific area

Are relevant for a longer period of time

Are easier to maintain

Make sure that your human resource and legal teams review policies as part of the review process. This is especially important where enforcement is concerned. Without proper review, you likely will not be able to take action against individuals.

Use a document management system for controlling the policy writing process. This same system can be used to distribute and version policies when they are complete. Writing policies in a word processor, using email for workflow, and putting together a simple web site for distribution works for small numbers of documents with infrequent modification but becomes unwieldy for more active policy maintenance processes. This needn't be an expensive proposition. Plone, an open source document management system, is certainly up to the task for almost any organization.

Rather than starting from scratch, consider buying policy templates from one of the many security vendors or consulting companies who service this market. Alternately, hiring a consultant to put together an identity policy suite specific to your organization may jump start the process and give you a number of workable policies in fairly short order. A set of sample policy templates that mirror the identity policies discussed next is available at http://www.windley.com/identity-policy.

Policy Outline

What should a policy look like? Typically, identity policies have a set of sections that follow an identifiable outline . I recommend the following sections:

Section 1: Purpose

This section is typically just a paragraph or two long and answers the question, "Why is this policy needed?"

Section 2: Scope

This section is also generally short and identifies what is covered by the policy.

Section 3: Definitions

This section is simply a list of definitions of terms used in the rest of the document. Clear definitions are important in avoiding ambiguity in later sections and avoiding lengthy explanations of concepts in the main body of the policy. Note that the point of this section is not to give dictionary definitions so much as to give definitions specific to the organization and how the words are used in the policy.

Section 4: References

This section is a list of other policies, standards, and documents that are used in the body of the policy.

Section 5: Policy

This section is the main body of the document and describes in detail the requirements of the policy. This section may have a number of subsections.

Section 6: Enforcement

This section describes what actions will be taken when the policy is violated. Some enforcement actions may be against personnel (e.g., an HR action), and others may be against organizations (e.g., a budget action). In the case of personnel actions, you typically won't include them in the policy directly, but by reference to the appropriate HR policy.

Section 7: Contacts

This section lists who is responsible for the policy and its review, modification, and enforcement. Specify this by title and position, not name, so that the policy is not outdated by irrelevant personnel actions.

Section 8: Revision History

This section documents each revision by date and the primary changes.

The specific policies you develop may have all or only some of these sections depending on the circumstance. I recommend that you develop a policy template for your organization and use it for every policy so the policies have a consistent style and format.

An Identity Policy Suite

An identity policy suite is a collection of high-level policies that deal with identity. Figure 18-1 listed many of the common ones: authentication and authorization, naming and directories, encryption, software development, software licensing, networking, privacy, and federation. The number and type of policies depends on an organization's size and purpose.

The goal in creating policies at this level is to establish the boundaries within which other policies and procedures will work. The policy suite should provide a foundation on which other policies can be based. Therefore, it is important that wherever necessary, policies in the suite grant some role in the company specific authority to regulate the area further. The policy may also assign responsibilities to the role. In many cases, the policy may create the role.

For this strategy to be effective, policies in the identity policy suite will not typically be excessively detailed. At one end of the extreme, the policy will say nothing except to appoint a governing authority and leave all decisions to that authority. At the other extreme, the policy is sufficiently detailed that there's nothing left for the governing authority to do. Strike a balance and err on the side of saying less rather than more. The policies in the suite should state what is non-negotiable and leave as much room as possible for the governing authority to meet the demands of the organization and users within those guidelines.

The following sections discuss the most common policies in an identity policy suite.

Naming and Certificates

A policy on naming and certificates forms the basis for other identity policies and for security policies. Naming can refer to many different things including domain names, usernames, uniform resource locators, documents, phone numbers, employee identity numbers, and physical assets such as conference rooms, printers, and computers. Your policy may not concern all of these, only the ones that are important now. Other facets of naming can be added as necessary or delegated to the appropriate parties.

The naming policy should be concerned with the form of names and who is responsible for naming. Most companies, for example, own one or more domain names. Other people in the organization will want subdomains from those domain names. Someone in the organization should be responsible for maintaining the domain name asset and assigning subdomain names. This role is typically called the "registrar."

Most organizations also own a number of digital certificates. As we saw in Chapter 6, digital certificates associate identity information with a public key in a signed data structure. I've chosen to include the policy information for certificates with naming, because I prefer using the registrar for managing an organization's certificates as well as domains. In common practices, most of the certificates will be associated with domain names and the asset tracking system being used to manage domain names, and subdomains can frequently be used to manage certificates as well. Another place to talk about certificates would be in the policy on encryption and digital signatures.

A policy on naming can also help enforce some of the standardization done as part of the identity data architecture in Chapter 16. A policy might include requirements to use information from the metadata repository or to use identities in established data stores in preference to creating new identities.

One of the most important naming roles a policy can perform is to grant authority for creating enterprise-wide identifiers. For example, how are email identifiers created? Who has authority to determine the format of employee numbers?

Passwords

We discussed various password strategies and options in some detail in Chapter 7. The goal of a password policy is to:

Delineate where passwords must be used.

Note any exceptions and by what authority exceptions are granted.

Provide a basis on which other policies (such as an acceptable use policy) can make more detailed requirements of users.

You will be sorely tempted to over-specify the password policy. Resist that temptation by recognizing that there are plenty of other policies dealing with security that can build on the password policy, and give specific requirements for specific applications such as user access or networks.

A minimal password policy should deal with acceptable password formats, how passwords are stored, and requirements for the creation and protection of passwords. Additionally, the password policy should require that each identifier have the ability to store a separate password.

As you use the password policy as the basis for other security policies, you will run into requirements that show up over and over again. The password policy should be changed to include these general requirements rather than repeating them in multiple places. This ensures that as the password policy is reviewed, and when these general requirements are changed, that change manifests itself in all other policies.

Encryption and Digital Signatures

Almost every modern organization relies on cryptographic technology. If nothing else, most businesses have a digital certificate for their web site or use certificates in a virtual private network (VPN). The goal of a policy on encryption and digital signatures is to clearly delineate acceptable cryptographic techniques. The policy usually will not include specific policies about digital certificates or VPNs, for example. These would be in another policy.

The policy on encryption and digital signatures will typically require that only approved products and algorithms be used. The policy should never include references to specific algorithms or products—include them in the policy by reference to the interoperability framework.

A policy on encryption and digital signatures will generally include prohibitions on using proprietary encryption schemes, because these are generally not as trustworthy as those designed by the community of cryptographic experts, which have been subjected to a significant social process to discover their weaknesses.

The encryption policy will also typically call attention to export controls and require that those laws be followed. There should be no mistake by your employees or other parties that you intend to follow the law in this matter.

Directories

Successfully creating and using an enterprise-wide directory is mostly about process, not technology. There are some factors that a policy on directories can help with.

First, establish who has accountability and authority. Appointing an enterprise directory director (EDD) as a collateral duty and giving that person sufficient authority is crucial. That role should be empowered by the policy to create and enforce rules and processes regarding the enterprise directory. The policy may not say it, but the EDD should avoid promulgating these rules and processes, but rather create them cooperatively with other participants in the enterprise directory.

One of the crucial success factors in an enterprise-wide directory is establishing a way to create a globally unique ID for records in the directory. We've already dealt with that in the policy on naming and certificates, but the directory policy should reference that, and the EDD should play a role in creating the format for IDs.

Another crucial success factor for an enterprise directory is the directory schema. The EDD should be empowered to manage the schema and make decisions regarding what is and is not included.

To create an enterprise directory through using metadirectory or virtual directory technology, a process has to be put in place to designate which records will be considered canonical. For example, records identifying an individual may show up in several directories. Which of these records will be considered the true source of information about that individual? The directory policy can establish a process for making that determination.

An enterprise may have several enterprise-wide directories. For example, there may be one for employees and one for customers. These different directories may need separate policies with different governance processes.

Privacy

Privacy policies in the identity policy suite should concentrate on the global requirements that must be followed by everyone and every project in the organization. Note that this privacy policy is different from, but governs, the privacy statement you might place on your web site. The most fundamental point in the global privacy policy is to establish the ground rules for protecting personally identifying information. This policy then forms the authoritative basis for many other security policies.

In Chapter 4, we gave 10 important principles regarding privacy. Use the governance process to establish a set of guiding principles for your organization based on these privacy principles and then make sure your privacy policy reflects them. Incorporate the principles into the policy by reference and give specific guidance where necessary.

For example, the privacy policy should establish a role such as a chief privacy officer (CPO) and empower that role to establish rules in keeping with the policy and the guiding principles.

Other items to include in a privacy policy are requirements to post privacy statements on web sites, conduct regular reviews of the identifying information being collected by each project and product, and use best practices to protect identity information from accidental disclosure and theft.

Privacy policies should require the appointment of data custodians for each repository of personally identifying information and charge that person with the requirement to meet the other requirements in the policy, such as conducting periodic reviews.

Data confidentiality should be maintained by specifically telling persons with access to repositories what they can and can't do with respect to the data. For example, copying data for testing and development could be prohibited or allowed within certain parameters. The policy would not usually include the specifics of such an agreement but assign responsibility to some role in the organization for creating and maintaining it.

Authentication

Authentication policy is built on the naming, password, and directory policies.

One of the most important factors in authentication is the creation of authentication levels. For example, a company might designate the following authentication levels with associated authentication mechanisms:

Casual

No password is required. A simple token such as a cookie is used to establish identity.

Standard

Standard ID and password combination shall be required.

Secure

A physical token shall be required in addition to ID and password.

Critical

A separate ID and password (different than those used to authenticate to access less secure systems) shall be required in addition to a physical token.

Note that these requirements say nothing about access control; rather, they specify authentication levels. This gives significant guidance to system architects and designers, because they can then count on the authentication system giving them back an authenticated user with a certain authentication level. This removes the ambiguity of trying to sort out for each system what authentication mechanism to use and what it means.

Authentication policies should provide guidance on using the enterprise directory infrastructure (if one exists) and require that systems be purchased to support the authentication infrastructure. Major system upgrades should also be evaluated for compliance issues.

Access Control

Unlike other policies that we have dealt with, access-control policies do not specify a single role to be held accountable for the performance of the policy. Access control is about thousands—even millions—of individual resources that have different owners and custodians. In many modern organizations, nearly every employee is the owner of many information resources.

Consequently, an access-control policy should define owners and custodians and spell out specific responsibilities for each. The policy should also specify responsibilities for users, so that users who violate policies knowingly can be held accountable.

As we saw in Chapter 8, owners determine what the access-control policy for a given resource will be while custodians determine how to carry out the policy set by the owner.

Information resources generally fall into one of three access-control categories:

Uncontrolled resources have no oversight whatsoever. Anyone can create, modify, or delete them. You may not think that much will fall into this category, but in fact this is unfortunately the default classification for most corporate data even when the owner would like to apply some other policy.

Audited resources are tracked so that the organization can determine which user took what action and when. These records may be audited at varying times to ensure that users are behaving in compliance with the owner's policies.

Controlled resources have access-control policies associated with them. Those access-control policies should be enforced by the information systems.

The access-control policy will not generally specify access-control methods for meeting policies because that depends a great deal on specific systems. A policy may, however, make recommendations or guide new development toward certain access-control methods.

Provisioning

As we saw in Chapter 5, there are many opportunities in the identity management lifecycle for provisioning identities. Unless your organization takes steps to ensure that provisioning is done according to standards and with an eye to automation, help desk costs can become excessive.

As a result, the goal of the provisioning policy should be to require conformance with standards listed in the interoperability framework and to require automation. Depending on the maturity of your digital identity infrastructure, the policy may be more directional than regulatory. That is, the best you can do in some cases is to require automation, where possible, because your infrastructure may not yet be up to the task. This is a good example of how policy must change depending on the status of the infrastructure it's supporting.

One of the things that a provisioning policy should always do is require that new systems be in compliance, especially in automation functions like password reset. Another important consideration is support for and requirements to use the enterprise directory.

Federation

Policies for federation are particularly important, because there can be considerable risk in connecting with external partners. At the same time, the very idea of federation implies that two or more partners are coming together and compromise will be necessary. A federation policy therefore has to distinguish between requirements that you're placing on your employees, things on which you're unwilling to compromise, and what approvals are needed for agreements that may stray from internal policies.

There are several big gotchas in federation projects that should be covered by the policy. Among the most important is the amount of trust you can place in external partners. You may choose to require that they meet external, independent security criteria, such as SAS70, or simply submit to due diligence by your own staff. Of course, they'll likely require that you meet the same requirements.

Another important aspect of a policy on federation is to ensure that agreements that initiate and govern the relationship are properly reviewed and limit your liability in case of fraud or error.

Most of the foregoing assumes a private federation agreement, that is, a custom agreement between two or more parties. In the future, you may be able to join a federation network that has standard policies and agreements. The downside of such agreements is that they will likely not be customizable to any great degree. You take what's offered. On the other hand, as we've seen, such networks will standardize the process of federation and make it easier and less costly to enter into federation relationships.

The Policy Review Framework

A policy review framework should be included in the policies that are developed as part of an IMA. The framework is really nothing more than a schedule. Consequently, it is generally short and relatively non-controversial. The review framework consists of the following parts:

Introduction stating the purpose of the document.

A table that serves as a schedule of policies. The table should include columns for policy number, policy title, responsible person or group, status (e.g., Approved, Final Draft, Draft—RFC), date approved, review cycle (e.g., yearly, biannual, etc.).

A table that serves as a calendar for the current year showing which policy will be reviewed in any given month.

Guidelines for how frequently different types of policies should be reviewed to guide policy writers in proposing a review schedule.

The schedule itself should be reviewed the last month of the calendar or fiscal year and a new review calendar created for the coming year.

Assessing Identity Policies

When initially creating a policy, and again when they come up for review or modification, policies should be assessed. This process will be most effective when done as a semiformal procedure that is carried out in a routine way with a brief report to the reviewing body. Policies of any sort can be difficult to assess. There are several criteria you might want to use to review and assess your policies.

Completeness

We would like policies to cover every situation that might come up, but that is not practical for reasons of cost and because we cannot foresee every possible problem. The best approach is to create a policy that seems complete and then add to it with discretion as problems arise. This is the approach used by the building trades to create building codes and it has served them well. The reviewing body should review any incident reports that bear on the policy and make recommendations about changes to the policy that would have prevented or lessened the severity of any related incident.

Effectiveness

To gauge effectiveness, the enterprise must have some goal that they want the overall identity policy suite to accomplish and understand how each policy in the suite contributes to that goal.

Cost

This can be difficult to assess, but it's worth at least estimating so that you can make a case for or against a policy or changes to an existing policy. The cost should estimate the cost of compliance with the policy and also the cost of not implementing the policy. Cost estimates should usually be done on policy components rather than the entire policy.

Risk

Policies can be hard to compare for relative risk. For example, is a password reset every three weeks with six-character passwords more or less secure that a password reset every two months with eight-character passwords? The best that you can usually do is to make an estimate of risk. The most important thing about evaluating risk is to use the process to build consensus among key players about risk. As a result, everyone will approach policies and their enforcement from a similar perspective.

Enforcement

There is little point in creating policies if they are not enforced. Just imagine how ineffective building codes would be if they were not enforced. Enforcement is not a duty that can fall to a committee. Neither should the same operational group that is supposed to be providing service enforce policy. It's impossible to provide good customer service and be the police force at the same time. Usually enforcement is a function of the CIO's office and separated from operations so that customers see operations as helping solve the problem, rather than causing it.

Make sure policies are promulgated effectively to those who need to see them. As part of this effort, you might consider developing a training program around your policy suite and make sure you include this program in new employee orientation, management training, and other meetings as appropriate. Sometimes things like online quizzes, with prizes for completion, can be effective for measuring employee understanding of important policies.

Include an acknowledgment statement in every policy. Sometimes this is appropriate for individual users, but also consider having the leaders of organizations affected by the policy acknowledge that they've read it and that their organization is in compliance. If they can't sign a compliance statement, be sure to have a program for helping them develop a roadmap that takes them to compliance and require milestone reporting for major milestones in the roadmap.

One of the most effective techniques for measuring and encouraging compliance is to conduct periodic audits. Here are some important points to remember when planning and carrying out audits:

Make sure you have approval to conduct the audit.

Don't exclude groups or individuals such as the IT department and executive management from audits.

Don't announce the audit ahead of time.

Find creative ways to make audits non-punitive where possible. As silly as it sounds, just leaving candy or rocks in someone's office after an audit as a measure of their compliance can alert people to problems in a non-threatening way.

Develop standard audit forms.

Develop custom audit procedures for each type of policy. For example, a password audit is very different from an audit of coding practices.

Make sure the audit does not unduly interfere with revenue producing activities.

Document and share the results.

Remember that the point of policies and enforcement is to create a context within which a working digital identity infrastructure can be built and operated. Enforcement actions should consequently be aimed at helping projects, organizations, and employees come into compliance rather than extracting punishment.

Procedures

Closely related to policies are procedures. Where policies define "what," procedures define "how." A proper policy suite serves as the basis for creating procedures. Procedures outline specific actions to take in specific situations and give instructions for how to handle events and incidents—even those that are unanticipated.

Procedures are just as important as policies, because properly defined procedures lead to repeatable results. As we saw in Chapter 15, reaching higher levels in the identity management maturity model requires not only having procedures, but also ensuring they are consistently executed.

Procedures can be created proactively under authority granted in a policy. More often, though, procedures will spring up to fill a need without any specific authorization. That's natural and proper. What's important is that the IMA provide the context within which the procedures are created. Returning to our analogy of building codes, building codes don't have to authorize a contractor to create her own building procedures, but the procedures created by the best builders are done with the building code in mind.

One of the most important general procedures you can create is an incident-handling procedure. The incident-handling procedure is a preplanning document for common, foreseeable incidents. The procedure should define areas of responsibility, actions to take, and the escalation process. Other organizations within the enterprise may define specific incident-handling procedures for their areas of responsibility, but they should be done under the umbrella of a general incident-handling procedure so that nothing falls through the cracks.

Conclusion

This chapter has outlined in some detail how to create policies and has given specific examples of what your organization might want in the policy suite that undergirds your IMA. The way to get started is to review the governance information in Chapter 14 and begin to build the organization that can build your own policy suite.

Chapter 19. Identity Management Reference Architectures

When I was CTO at http://iMall.com, we were frequently pushing technology envelopes. A lot of the web technology that people take for granted now—such as application servers, templating frameworks, and even relational databases—were either not available or not widely used in building web sites. At the same time, new technologies were being developed at breakneck speed as people tried to create the scaffolding on which the World Wide Web would ultimately be erected.

As CTO, part of my job was to develop an overall technical strategy for the company and decide not only what products we'd build, but how we'd build them. I found that just picking a technology wasn't enough. Even if I understood the technology well and could see how it would fit into our overall system, communicating that vision to the system architects and developers was difficult. What I found myself doing, over and over again, was building a small pilot project that showed how a particular technology worked, how it fit into the suite of other technology choices we'd made, and why it was beneficial. There's something about a real design and working code that grounds a technology choice and makes it real.

The last six chapters have shown you how to create an IMA for your organization that guides design and implementation so as to encourage interoperability. In Chapter 17, we saw how an identity interoperability framework, using a formal process, can make technology choices. Beyond merely making technology choices, however, an IMA should also put those technologies in perspective in the same way that my experiments did for iMall. Doing so will help system architects and software developers understand how their designs fit within the overall identity management strategy.

Reference Architectures

I didn't realize it at the time, but what I was doing at iMall was creating informal reference architectures (RA). A reference architecture is a diagram or set of diagrams that shows the distribution of system functions among components in the identity infrastructure and provides a topographical map for how those functions relate to each other. Reference architectures do not give the design for an actual system or even a detailed diagram of how those systems interact, but rather provide architectural guidance and best practice information for practitioners. The reference architecture provides technical practitioners and business planners a goal state and gives a clear picture of the infrastructure that the enterprise is building.

This chapter will present the outline of a very general reference architecture for a digital identity infrastructure. As part of building your IMA, you should adapt this reference architecture to your own needs and circumstances. This chapter will also show you how to do that.

Benefits and Pitfalls

An RA has a number of benefits for the enterprise:

Shows system architects the recommended way to structure systems.

Shows how systems tie into the larger enterprise infrastructure and put system architecture decisions in context with respect to the enterprise-wide system.

Shows how enterprise components, like directories, should be used.

Captures best practice information for system architectures.

Makes training easier because new developers can be educated using the RA. Moreover, developers transferring from project to project come up to speed more quickly because the architecture is familiar.

In addition to the benefits, RAs pose a few pitfalls :

RAs can be overkill for some projects.

RAs may stifle creative and innovative solutions to problems.

The most effective way to mitigate these downsides is to remember that an RA should never be followed by rote. A reference architecture should be evaluated for each use and proven in practice. As a component of the IMA, the RA should be subjected to the same feedback cycle shown in Figure 14-1 as other IMA components. The feedback may change the project, or it may change the RA. Feedback on how well a particular RA worked in a project is likely to affect foundational components in the IMA such as the interoperability framework (IF) as well.

One way to use an RA in a project is to adopt it piecemeal and iteratively as needed. In this practice, the project uses the RA as a reference, but only implements a subset of the architecture because of specific project needs. For example, the RA might contain multiple servers and a load balancer to create a high availability environment, but in practice, the project leaves out the load balancer and uses only one server, because high availability is not a critical factor in this particular application.

Reference Architecture Best Practices

As you develop reference architectures for use in you organization, there are several best practices that you should keep in mind.

Use the governance process

An RA is a component of the IMA and is subject to the same governance process as any other IMA component. This implies that the RA is reviewed frequently and updated as necessary.

Customize

A reference architecture should be customized to fit the organization. As we'll see, what we're calling "the" reference architecture can actually be a collection of architectural recommendations. Each recommendation should be specific to problems that your organization is facing and be the basis for systems that you care about in your business.

Implement incrementally

As we saw, in mitigating pitfalls, RAs frequently needed to be used in a piecemeal fashion. A good RA should be designed so that it can be scaled and customized to fit project needs. Recommendations for scaling and customization should be included in the RA documentation to guide system architects and developers in its application.

Prove in a pilot

Ideally, RAs are tested in a pilot scenario and retested whenever components or practices are changed. The pilot implementation should be used to test new components or practices before they are broadly recommended. Small organizations may not have the capacity to do this in a formal way and may need to rely on vendor studies, third-party analysis, or small pilot programs to verify technology combinations. Larger organizations may be able to develop formal reference architecture validity programs as part of their IT research arm or the CIO's office.

Experiment

RAs for systems typically contain specific recommendations about hardware and software components. The interoperability framework says what's allowed, but the RA says what's recommended and which combinations work well together in the enterprise system. Innovative project teams may choose to swap out some of the recommended software or hardware choices for compatible choices. There should be a process in place for feeding this valuable experimental data back into the reference architecture so that projects can benefit from the experience of other projects.

Using a Reference Architecture

Small organizations may have a single reference architecture that represents the enterprise digital identity infrastructure. In this scenario, system architects use the RA to find out how to connect to and use the enterprise infrastructure. For example, the enterprise may have a single, centrally managed directory, and the purpose of the reference architecture is to give system architects a blueprint for how they use this in their projects.

A larger organization needs to be more flexible. Large organizations will rarely be in a position where there is a single portal or set of web servers running a single authentication and authorization server connecting to a centralized corporate directory. More likely, there will be hundreds of separate projects, each of which builds some new part of the identity infrastructure as it is deployed.

In this scenario, the reference architecture needs to be deeper and more flexible as well. For example, suppose that the interoperability framework allows three different authentication and authorization servers because of scale and legacy issues. The reference architecture would need to show how any of those three servers can be used with various web server and portal products as well as how they attach to various pieces of the enterprise-wide system, such as the corporate metadirectory.

Components of a Reference Architecture

A reference architecture has three primary pieces.

A statement of technical positions that guide system architects in making technical decisions.

An enterprise-wide consolidated infrastructure blueprint (CIB) that gives a blueprint for the overall digital identity infrastructure and shows how various enterprise components are hooked together.

Individual reference architectures for specific types of systems.

The next sections will describe each of these in turn.

Technical Position Statements

A clear statement of technical position on a variety of technology questions is a big help to system architects making individual technology and design decisions. In Chapter 14, we discussed the creation of statements about business principles as part of enumerating business drivers. Technical position statements build on those principles. We would expect principles to change infrequently and follow the business strategy of the organization. Technical position statements similarly flow from the technical strategy that the organization is pursuing.

Burton Group has developed a reference architecture for identity as part of its research and advisory services. They recommend organizations take a position on the following technology issues in identity management:

Access management

How should an organization manage access to its applications and information resources?

Directory access, administration, and security

How should organizations manage and secure their directory services while giving authorized applications, users, and administrators trouble-free access?

Directory applications

What tools and interfaces should application developers use to tie applications to directory instances?

Directory content, structure, and distribution

How should organizations organize, store, and reference information in a general-purpose directory system?

Directory integration

How can an organization manage and share useful, high-quality data in multiple directory services, repositories, and other sources?

Directory tiers, instances, and roles

How can organizations use tiered directory architectures to resolve structural, political, and functional differences that accompany general-purpose directory deployments?

User management

How should an organization identify internal and external users, and manage the lifecycle of those users?

User authentication

What strategies, technologies, and mechanisms should organizations use to authenticate users and provide appropriate protection to resources in a cost-effective, manageable manner?

Public-key infrastructure

How should an organization plan and deploy tiered public-key infrastructure systems?

You may notice that some of the questions in this list look like the kinds of issues that you might take a stand on in your IF. Remember that the IF is the minimal ruleset and may not specify software and hardware choices in many instances. Technical position statements, on the other hand, are advisory and often give guidance beyond the requirements of the IF.

This list is not meant to be a complete look at every issue. As you build your IMA, you may find other technical issues on which you must take a stand to provide system architectures a firm foundation.

Making Decisions About Technical Positions

Identifying the questions, as we did previously, is one thing. Making decisions about the organization's technical position is another. As CTO of a small startup, I took technical positions after a rather informal process of research and talking to some of engineers who worked for me. As CIO for Utah, we followed a more formal process. The end goal of the process was twofold:

Gather input from as many smart people as we could.

Create a group consensus around the decision.

In a large organization, the second point can be more important than the first. Taking technical positions does no good if people are going to question and even fight them.

Whether formal or not, taking a technical position requires several steps that can be enumerated and followed.

State the problem. The list of technology issues from the last section is a good starting point for problem statements. Usually the problem statements come down to a question that needs a technology answer such as "How will we use directories in our identity infrastructure?"

Determine your organization's requirements with respect to the problem. The purpose of this step is to customize the problem stated in step 1 to the specific goals of the business. Rather than a simple list, this step can be best accomplished as a white paper that can be distributed and commented on.

List the options for solving the problem. This step enumerates the options at a high level. For example, in creating a technical position statement on directories, the options would probably come down to a large centralized directory, a metadirectory, or a virtual directory.

Research near-term future developments. This step protects you from any impending developments, and is a good point at which to check in with analysts and other outside sources about your plans.

Determine the evaluation criteria. One way to go about this is to prioritize the requirements determined in step 2 and assign point values for each.

Establish subordinate technical positions. Big technical position statements are often collections of related smaller technical positions. For example, in creating a technical position on directories, you might take technical positions about whether to rely on real-time integration or synchronization, how to create unique IDs, and whether to use packaged software or customize the integration between applications.

State positions and justify them with reasoned arguments. The final step is to state your positions. Usually, technical positions are dependent on assumptions and thus tend to be best expressed as nested IF-THEN-ELSE statements. The arguments can simply be paragraphs stating why certain choices follow from certain assumptions and are a reflection of the work in steps 1 through 6.

These steps can be followed informally by a small group or through a more rigorous process with larger groups. I've used offsite meetings and even professional facilitators. That may seem like overkill, but remember that your primary goal is to create consensus. Professional facilitators are trained to help groups do just that.

Consolidated Infrastructure Blueprint

The second component of your reference architecture is a consolidated infrastructure blueprint (CIB). A sample blueprint, courtesy of Burton Group, is shown in Figure 19-1.

Figure 19-1. A consolidated infrastructure blueprint

The blueprint in Figure 19-1 is a general-purpose view of what a company's identity infrastructure might look like. As you look at it, you should recognize many of the components and concepts we've discussed throughout the book.

There are two primary purposes for a consolidated infrastructure blueprint. The first is to show the actual components in your enterprise identity infrastructure and how they are connected to each other. To that end, the diagram shown in Figure 19-1 is only a starting point that must be customized to reflect reality in your organization. The general names given in the figure would be replaced by actual system and product names.

If your organization is like most, where identity infrastructure has been built in an ad hoc fashion over the years, the "as built" CIB may be quite messy and comprise multiple disconnected chunks. The "as built" CIB is used by system architects as they design their systems to determine how their system uses and connects to the enterprise identity infrastructure, and should thus be as accurate as possible.

Once you have an "as built" CIB, you can evaluate it against the maturity model that we introduced in Chapter 15. The CIB will show the state of identity storage, how authentication is done, and what infrastructure is in place to support authorization. Assign the CIB a maturity level. Don't hesitate to assign different maturity levels to different aspects of the CIB. Share the evaluation widely and be prepared to adjust it as necessary based on the input of others. The idea is to end up with a consensus opinion of the maturity level, not just one person's opinion.

Goal State CIBs

The second purpose of the CIB is to show goals states. In this use, the CIB shows how the infrastructure must evolve to meet organizational goals. Using the maturity evaluation as a starting point, determine what changes must be made to the CIB to advance the maturity of the infrastructure.

This kind of upgrade doesn't happen as a single monolithic project, so infrastructure planners should create a series of "goal state" CIBs showing the roadmap that they envision for the infrastructure build-out. This roadmap is also useful to system architects as they make their plans so that they can design systems with the future in mind.

CIBs should be accompanied by documentation that describes in as much detail as necessary the information in the blueprint. This is the place to document requirements, reference policy, and point system architects to other detailed information.

System Reference Architectures

In a large organization, using a single enterprise-wide identity infrastructure is often impossible for geographic, political, or technical reasons. For example, Utah runs hundreds of web servers. My goal as CIO was not to have everyone use a single enterprise infrastructure for web servers or even to use a single authentication and authorization component. Rather, we had to find ways for individual projects to build portions of the identity infrastructure and yet have them work in an interoperable fashion.

We've seen the role that policies and interoperability frameworks (IF) play in making this possible. The consolidated infrastructure blueprint that we saw in the last section also plays an important role. In addition to those important aids, we can give system architects a head start when they design a system by creating system reference architectures (SRAs) that show how an individual system can be put together from components in the IF so as to work with the CIB. The system architect can customize the SRA to the specific job at hand rather than starting from scratch.

As an example, suppose your enterprise infrastructure used a metadirectory to consolidate directory information and that you had also deployed a policy server and provisioning server from a particular vendor in accordance with your interoperability framework. A new project to build a partner portal has been launched. The project is of sufficient scope that it will need its own web servers, and the identity data will be stored on a local directory for business reasons unimportant to our discussion.

Figure 19-2 shows an architecture diagram for an SRA for web server authentication and authorization that the project might use as they make decisions about the platform. This diagram is much simplified, but gives the idea. The IF tells the project the recommended identity server and directory software to buy. Further, it gives information about how the identity server and directory need to interface with enterprise resources. Documentation with the SRA would give detailed information as well as point to other reference material. In an ideal situation, the project would know that these components had been tested together and that the recommendations were based on the experience of the organization and others in similar situations.

Figure 19-2. System reference architecture for web server authentication and authorization

Conclusion

Reference architectures are not intended to be straightjackets that restrict project choices, but reference material that system architects can use to get a head start on designing platforms to meet the needs of the business. A good reference architecture tells the system architect what technical choices the enterprise has made and how to build projects that are interoperable with the overall enterprise infrastructure. Good reference material helps projects succeed in interoperating with other systems and also saves the enterprise money by saving the project time in researching options and developing solutions.

Chapter 20. Building an Identity Management Architecture

The last seven chapters have discussed the importance of building an IMA and how to go about constructing each of the components. In this chapter, we'll discuss how to put it all together.

Scoping the Process

Scope is a critical decision in creating a process that works. In this book, we've used enterprise to refer to the organization building the IMA. As I said in the Preface, when I talk about "the enterprise," I'm referring to any mostly independent organization. Companies, government agencies, and NGOs (non-governmental organizations, such as the American Red Cross) all qualify. Even divisions within those organizations may qualify as an enterprise under this definition. The key test is whether or not you can imagine the organization developing its own digital identity strategy. So, an independent business unit probably qualifies, but the marketing department in that business unit doesn't, because its identity strategy can't be independent of the other departments with which it interacts.

As we've seen, the goal of an IMA process is to create the context within which a digital identity infrastructure can be implemented. If that infrastructure is to support the constant use and interoperability of identity data throughout the organization, then "enterprise" needs to be defined quite broadly to include every suborganization along with all their processes, identity data, and systems as well.

On the other hand, an enterprise-wide scope for the IMA effort may be overly ambitious as a starting place. Instead, you should lay out a logical progression of ever increasing areas of inclusion for the IMA process until eventually this all-encompassing scope is reached.

Which Projects Are Enterprise Projects?

Another question that IT departments frequently wrestle with is which projects and systems should be enterprise projects , built and operated for the good of multiple business units, and which are better built and operated by the business units themselves. Figure 20-1 shows a decision matrix I've found helpful for determining what activities and projects fall under the "enterprise" umbrella.

Figure 20-1. Enterprise decision matrix

The two axes in Figure 20-1 are strategic importance and the scope of an activity or project. Activities and projects farther along the horizontal axis more directly support the strategic goals of the organization, and activities and projects farther along the vertical axis are used by or affect more and more of the organization. Here are a few examples:

A financial control system that is internal to the finance department, but directly supports the CEO's goal to curb capital spending, would place high on the "strategic importance" axis and low on the "breadth" axis.

A directory project that supports an online directory of employees and eases creation of the company phone book would be placed high on the "breadth" axis, but may score low in strategic importance.

A project to implement a new customer relationship management (CRM) system would place high on both the "breadth" and "strategic" axes.

The upper-right quadrant represents activities and projects that are clearly enterprise projects. They are strategically important and affect many divisions within the organization. These activities and projects should fall under the purview of the IMA effort and are likely candidates to be planned, implemented, and maintained by the enterprise IT organization.

The lower-left quadrant, by contrast, is populated by activities and projects that are neither strategic nor large in scope. Most of these activities and project never rise to the notice of the enterprise IT group and affect very few departments. All of the spreadsheets that people create every day in support of their jobs are good examples of the extreme case. They are very tactical and support only a single person or a small group.

The band across the middle of the figure illustrates a strategy for dealing with projects that are on the borderline. The goal of an IMA is to create an environment for interoperability. Many of the projects in the upper-left and lower-right quadrants will not be conducted by the enterprise IT group, but rather by a business unit. Still, with the proper standards, policies, and procedures in place, their work should interoperate with the digital identity infrastructure that results from the IMA. Reference architectures play a critical role in supporting the interoperability of business unit-sponsored projects.

Sequencing the IMA Effort

We've spent a great deal of time talking about the individual components of the IMA, but you may be wondering about sequencing the various steps. Figure 20-2 shows the phases in building an IMA and when each of the components comes into play. I've divided the effort into three primary phases: the initiation phase, the building phase, and the implementation phase.

Figure 20-2. Phases in building an IMA

The initiation phase is when the vision for the IMA is created and the governance process is put into place. Business principles are determined at the end of this phase. The initiation phase may take a great deal of time, depending on how hard it is to create the vision for identity management in your organization.

The building phase is when most of the work gets done. The business function matrix and process inventory are created first. They overlap because as business functions are determined, some process inventory work can be started. For a large organization, this overlap might be significant. A small organization will find that the function matrix must be completed entirely before the process inventory can begin.

As the process inventory is completed and the gap analysis begins, the data inventory can be done in parallel. Remember that these two activities are complementary and may require some iteration. With the process inventory complete, the first draft of the interoperability framework (IF) can be written. This in turn allows policies to be written. Notice that drafting and reviewing policies overlap, because there are a number of them and the review of one policy can be done while another is in the drafting stage. The diagram does not show the iterative nature of the review and drafting activities.

During the final part of the building phase, the reference architecture can be completed, based on the process inventory, identity data inventory, and IF. The data structure and exchange standards can be created at this time. Also, the organization can begin to automate and improve processes as necessary.

The implementation phase is when the IMA lifecycle shown in Figure 14-1 comes into play as the components built in the second phase are used and revised.

A Piece at a Time

The IMA isn't something you build once and then simply use; it's a constantly evolving collection of information, policies, and processes. Consequently, you may find it helpful to think of creating a roadmap or timeline for the process. The roadmap looks like Figure 20-2, but turned into a project plan that repeats steps as necessary to include more and more of the of the enterprise. The roadmap will specify what the scope of the process is now and in the future. A roadmap keeps the process from trying to boil the ocean while at the same time, assuring the enterprise that important issues will eventually be dealt with. The roadmap is the high-level plan for applying the IMA process to the enterprise.

You will be tempted to split the task along organizational boundaries. This is a mistake if your organization is split into functional units such as sales and marketing, engineering, and human resources. Each of these functional departments depends on other departments and interacts with them to a large degree. Consequently, a large amount of identity information is likely being transferred in and out of these departments. Furthermore, any one department is unlikely to have a complete picture of the needed identity information and infrastructure. Thus, an IMA process for the identity functions in the human resources department, for example, will be incomplete and in danger of making assumptions that have to be radically altered in future phases on the roadmap.

A better choice is to pick a division or subsidiary that includes most of its own business functions. Such a unit will have control over its systems and the services it offers to customers as well as the bottom line from those services. Consequently, there is strong motivation to complete the IMA process and reap the benefits as well as sufficient control to ensure success.

Of course, life is never as simple as the theory espoused in a book. For example, the State of Utah had over 25 individual departments, which could have been seen as relatively self-contained business units. Any one of them would be a good environment in which to create an IMA process. The exception was that centralized HR and finance functions served every department. In this kind of hybrid organization, an IMA roadmap would have to address issues in the HR and finance departments at the same time that the IMA process was being applied in one or more business units. Every situation is different, and some creativity will need to be employed to slice the problem up into tractable chunks and lay them out on a roadmap.

An important dimension in the roadmap will be to cover what I call products and projects. I use the term product to denote all of the customer-facing services that the enterprise offers, even if they may not be for sale in the traditional sense. The enterprise portal is a good example of a product that almost every organization has. Ensure that the IMA roadmap includes not just IT projects for internal systems, but also includes products, online or offline, that have an identity component. This may be as simple as considering the customer relationship management (CRM) system in the roadmap at appropriate times. On the other hand, there may be numerous online projects that gather and use identity information independent of the CRM system. Be sure they're included in the process.

As you build the roadmap, it is important to consider the favorable and unfavorable characteristics of the organizations. Some parts of the organization may not be amenable to IMA at the present time because of one or more problems. After considering the characteristics of the business units, there should be some clear candidates for building an IMA. Pick the easy wins and get some early successes for the process. At the same time, the roadmap should include steps for dealing with unfavorable characteristics in the enterprise and mitigate them in parallel with the ongoing IMA process.

The creation of a roadmap will help alleviate fears in the organization that some parts are being left behind. Recognize that the roadmap is not a static document, but part of the overall IMA lifecycle shown in Figure 14-1 and, as such, is subject to constant review and update as the IMA process proceeds.

Conclusion: Dispelling IMA Myths

I hope that this book has given you evidence of the benefits of proactively managing identity, information about the technologies available for doing so, and a methodology for building an interoperable identity infrastructure in your organization. Still, as you contemplate the work 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, because they have to be fit into the ad hoc infrastructure that has grown up. 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. This book has described a process that 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.

You'll probably hear other objections as you move forward. Listen to them and tackle them head on. The important thing is to adapt the ideas in this book to your organization while never losing site of the goal: a flexible and interoperable identity infrastructure. Remember that flexibility and interoperability are products of an environment that guides decision making. Create that environment, and you'll get an identity infrastructure that works for your business.

Colophon

About the Author.  Phillip J. Windley is an Associate Professor of Computer Science at Brigham Young University. Dr. Windley is a nationally recognized expert in using information technology to add value to business. Windley received his PhD in computer science from the University of California, Davis in 1990. Prior to his graduate studies, Windley worked for four years as a nuclear metallurgist and a member of the technical staff at the Department of Energy's Division of Naval Reactors.

Our look is the result of reader comments, our own experimentation, and feedback from distribution channels. Distinctive covers complement our distinctive approach to technical topics, breathing personality and life into potentially dry subjects.

The cover of Digital Identity shows female masqueraders. A masquerade ball is a social gathering of participants who wear elaborate costumes to hide their true identities.

Such gatherings originally gained popularity as elaborate allegorical pageants, celebrating marriages and other dynastic events of late medieval court life. In Italy, during the 15th century, masquerade balls were extended into costumed public festivities held for members of the upper classes.

Masquerade balls are still held today, although they are less formal. "Costume parties" may very well be a descendant of this popular tradition.

Sarah Sherman was the production editor and proofreader for Digital Identity. Linley Dolby was the copyeditor. Adam Witwer and Claire Cloutier provided quality control. Lydia Onofrei provided production assistance. Johnna VanHoose Dinse wrote the index.

Ellie Volckhausen designed the cover of this book, based on a series design by Edie Freedman. The cover image is a 19th-century engraving from the Dover Pictorial Archive. Karen Montgomery produced the cover layout with Adobe InDesign CS using Adobe's ITC Garamond font.

David Futato designed the interior layout. This book was converted by Joe Wizda to FrameMaker 5.5.6 with a format conversion tool created by Erik Ray, Jason McIntosh, Neil Walls, and Mike Sierra that uses Perl and XML technologies. The text font is Linotype Birka; the heading font is Adobe Myriad Condensed; and the code font is LucasFont's TheSans Mono Condensed. The illustrations that appear in the book were produced by Robert Romano, Jessamyn Read, and Lesley Borash using Macromedia FreeHand MX and Adobe Photoshop CS. This colophon was written by Sarah Sherman.