Identity Architecture 

Download Article

The baseline technology for managing identifiers1 is a file with the users' names mapped to their user IDs. This becomes more difficult as systems and applications proliferate, giving rise to an array of names and user IDs. The underlying difficulty is establishing that a particular identifier belongs to a particular person, or rather that a group of IDs contained in various systems are all associated with the same person. For example, I might be Steven Ross on one system, Steven J. Ross on another, Steven Jay Ross on a third and Steve Ross on a fourth. It is relatively easy for a person to discern the similarity of these names, while a great deal more difficult for a machine. However, even a person could not tell from a mere recitation of names that they all belong to Steven J. Ross the security consultant, not the CEO.

People and Resources

Thus, the goal is a method (or perhaps a series of interrelated methods) that enables individuals to identify themselves to information systems in a consistent and coherent manner. Consequently, an architecture for identifying people that is reliable, efficient and flexible enough to be used for a variety of systems is needed, preferably a wide variety of systems. It would enable identification once and authorization many times and have the ability to withdraw those authorizations when the identifier is removed. It would have an architecture much like the diagram below.

Conceptually, the architecture starts with a business event, such as hiring a new employee or obtaining a new customer, and it ends with access to applications and information. There is no particular reason why it could not begin with birth (or at least a birth certificate) and end with the stacks of money being made with the business application. However, let us continue with the architectural convention of the boundaries being the beginning and end of the information system.

Figure 1

Components of the Architecture

The business event might be hiring an employee, but the first relevant computer event is adding that employee's name into a human resource database. The database serves as the authoritative source, the designated point of origin on which all subsequent identification decisions are based. The authoritative source resolves synonymy (two people with the same name), order (first name first or last) and associations (maiden name with married name).

The identifiers might, at least in theory, be read directly from the human resources database by systems seeking to establish identity, but this is not very efficient. It works better if a separate index is maintained strictly for identification purposes, the identity repository. Identities can be associated with disparate applications and systems. They are stored and linked to provide a foundation enabling a single point of reference. While in theory this repository could be a spreadsheet, it is most likely a directory based on the Lightweight Directory Access Protocol (LDAP).

Establishing the people's identities would be sufficient, if the purpose were simply to have a census, but the intent of identity management, at least in the terms of information security, is to define what resources the people can access and use.2 Human resources or customer relations may know what the people can do, but the applications do not. Therefore, they must be provisioned with the identities and authorities of the users, hence user provisioning. While this could be done one person at a time, it is far more efficient, to say nothing of secure, to provision based on roles. Therefore, the repository is the input to a system that is the single point of control for defining user access.

Access management is the mechanism in which people, having identified themselves, gain access to resources as provisioned. It secures the extended enterprise (customers, employees, suppliers and/or other third parties) by integrating business rules and allowing for a flexible approach to authorization based on role relationships. Single sign-on is a function of access management, and it is recognized widely that a one-and-only-one identifier process is an elusive goal, but reduced sign-on can be a reality.

The role relationships mentioned previously are a function of entity identification role architecture, the establishment and management of users' roles in the enterprise and their association to established business requirements. In other words, it is role-based access control (RBAC), plus a broad-based view of how roles interact in business terms. This requires a firm grasp of organizational policy in defining who has access to what. Sadly, those who have such a broad view often are not the ones implementing identity architecture, leading to inevitable problems as the components of the architecture are put to business use.

Finally, and almost anticlimactically, there needs to be a means for protection of the identifiers, or more properly of the authenticating mechanisms associated with identifiers. Thus, passwords, certificates, tokens and biometrics are necessary, but certainly an insufficient basis for an identity architecture. Many companies have attempted to implement a technology such as a public key infrastructure (PKI) without defining the business needs and how people will interact with the technology. A lot of money has been spent and little achieved, because the process began with a means of protecting identifiers and it worked backwards (if it worked at all).

The Road to Identity Architecture

This does not mean that implementation of an identity architecture is an all-or-nothing-at-all affair. There definitely is a succession of solutions that can lead to the goal of federated identity, in which a uniquely identified and qualified individual has a single entry point to access all resources for which he/she is authorized. This would allow the interoperability of identities across companies and networks. A noble goal, perhaps unattainable.

Somewhat short of federated identity, an organization might start by integrating all its authoritative sources (e.g., human resources, customer relationship management and procurement). Defining a role-based model for access control is a valuable end in itself, and few would argue with reducing the mass of passwords we have to remember.

The implementation of an identity architecture is inexpensive. There is a wide range of products filling the components of the architecture, and implementing and integrating them can be more expensive than the cost of the software. The payback does not come from the number of administrative positions that can be eliminated but from higher productivity, integration of systems, easier regulatory compliance and the management of large, sometimes anonymous populations.

At the bottom of it all, identity architecture hinges on the fact that there is a group of individuals who have a need to access resources, and the owners of those resources have a need to control their use. It is not that difficult conceptually, people learn it at an early age:

  • What's your name?
  • Where do you come from?
  • Do you want to play?
  • What games do you want to play?
  • Is it okay with your mommy?


1 See "Identifier Management," Information Systems Control Journal, volume 3, 2003.
2 There are other reasons for identity management that have nothing to do with access to systems. These include poll lists and advertising distribution, and anything else in which having one person represented twice is considered a bad idea.

Steven J. Ross, CISA
is a director at Deloitte & Touche. He welcomes comments at