Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

Whitepapers

Identity Management: Is Directory Inside or Outside?

19th September 2007

Purpose

The role of directory varies considerably in different Identity Management solutions. This includes:

• Systems where directory is a central and highly visible component.
• Systems where directory is used, but is not really visible.
• Systems that do not use directory.

This paper examines the role of directory in Identity Management, with particular focus on functionality where an externally visible directory can play a part.

What is Identity Management?

Identity Management is a rather nebulous concept, and means different things to different people. It generally relates to management of users (people), roles, accounts, access to systems and services, information on people, authentication, and authorization.

A number of product components are used in Identity Management solutions. Major elements are:

• Directory Servers & Databases.
• Directory synchronization (meta directory) products, that keep information co-ordinated between multiple directory servers and databases.
• Public Key Infrastructure (PKI) components, including smart cards.
• Biometric technology.

Other capabilities are also sometimes included in the scope of identity management:

• Workflow automation.
• Access control and authorization, including policy and role based access control.
• Delegated administration.
• Login and single sign-on.
• Password synchronization.
• Password re-set (self service).
• Virtual directory.
• Identity federation.
• Directory enabled networking.

Product companies will tend to focus identity management descriptions on their primary products; for example Isode discussions tend to be directory-centric. Some other companies and integrators keep descriptions at a very high level and focus on a solution rather than the components that comprise that solution. This makes it hard for organizations to work out what they really need and make appropriate purchase decisions.

Enterprise Oriented Identity Management

Many large IT suppliers offer identity management solutions, including CA, IBM, Novell, Oracle, SAP, Siemens and Sun. A major target for these suppliers is medium and large organizations that will generally be facing a number of user account and identity related problems, such as increasing security of access or improving remote access to a range of services.

A problem faced by most organizations is the diversity of systems and applications that need to be supported, with users registered in different ways and in different places with different authentication mechanisms. Systems need to provide approaches to addressing organizational problems in the context of this complexity, whilst avoiding "big bang" transitions that negatively impact user productivity.

Providing coherency of all this information will generally result in a system which brings identity information into a central repository. This will quite likely be a directory, but may also be a relational database. It will often be a central synchronization point, used to co-ordinate information with other databases and directories which are used directly by users. The primary goal of a directory within many enterprise-centric identity management solutions is to provide central internal co-ordination. The dominant feature of identity management becomes "connectors" for various applications and systems, and synchronization functionality.

The Directory-Centric Organization

For a directory vendor such as Isode, the ideal (and in practice less common) organization will place a directory at the centre of an organization's user and identity management system. This approach is promoted by Isode and by identity management vendors with strong directory components such as Novell, Siemens and Sun. It places the (most likely distributed) directory as the master central repository of all identity, authentication and authorization information. Applications make direct use of this information using LDAP access into the directory.

The key element of this vision is that authoritative information on users and accounts is held in the directory and that the directory becomes the hub for accessing and managing identity and authentication information for the enterprise. The directory is the "real" location of identity, and not just a repository for synchronization between other places.

When executed properly, the directory is a key component. Applications and provisioning tools need to be directory enabled, but the needs for connectors and synchronization is removed. For a directory-centric organization, the features of many Identity Management solutions are not needed.

Why PKI and Smart Cards drive Directory

When an organization moves from using username/password authentication to use of smart cards and authentication based on X.509 Public Key Infrastructure (PKI) this has a substantial impact on naming and use of directory. The reason for this is that the X.509 Certificates that are central to a PKI are used to validate a name. This means that a smart card will essentially identify the name of an account or user. The primary name identified in a certificate is a directory name, and most PKI implementations make use of directory to hold Certificates and other PKI information.

PKI and Smart cards work most cleanly where there is unified naming across an organization. When a smart card is used for validation, it is the name associated with that smart card that gets validated. To be useful, this name has to be meaningful at the point of validation. For many organizations, the biggest issue to overcome as a part of PKI deployment is sorting out uniform naming. Because of the close fit between PKI and Directory naming, and PKI vendor choice to use directory, it is a natural and easy path to use Directory to support PKI.

A practical consequence of this is that it will generally make sense for an organization to move to a directory-centric model as a pre-cursor to deploying PKI. This will provide unified naming across the organization, and an infrastructure to store information needed to support the PKI.

Authentication between Organizations

We've so far considered an enterprise-centric model, looking at how an enterprise will manage its own identity information, typically relating to employees but perhaps also customer data. This is identity information that will generally be used by the organization, and where the organization will deal with authentication (both for local users, and for users accessing services from outside the organization). Many organizations only need to deal with authentication of “their own” users.
For some organizations, there is a growing need to provide authentication services between organizations. For example:

• The US Government with its HSPD-12 (Homeland Security Presidential Directive 12) requires smart card based authentication between agencies (organizations). A government employee from one agency should be able to gain access to premises of another agency (by using the smart card for personal identification) or to online services of another agency.
• A military organization needs to share documents as part of a coalition action. Digital signatures on documents need to be verified between organizations.

These are examples of a growing requirement for authentication between organizations, often coupled with a requirement for PKI and digital signatures.

Password based authentication can be shared between organizations. This can be achieved using federated identity approaches, as discussed in the Isode white paper "Federated Identity, Distributed PKI and Smart Cards".

For organizations using smart cards and PKI, there is a natural use between organizations. Organizations using smart cards will issue certificates using a Certification Authority (CA). Within an organization, smart card trust is linked back to the local CA. Trust between organizations can be represented using cross certificates. This enables (policy controlled) trust to be established between an organization and a user from a remote organization presenting a smart card.

In order for this to work, PKI information (Cross Certificates and Certificate Revocation Lists (CRLs)) needs to be published by the issuing organization so that the peer organization can perform full verification. Directory is the natural and generally preferred mechanism to publish this information. To achieve this, the directory needs to be accessible from outside the organization. Although the information to be published is not large, it is critical for the PKI to work and CRLs are frequently updated.

Information Sharing between Organizations

There is often a need to share information between organizations in a structured manner, as distinct from unstructured information which might be exchanged using an appropriate Web site. This section looks at situations where there may be a substantial benefit in exchanging information by use of a directory service, and how additional information stored in the directory can add value to the core authentication service.

Information relating to users authenticating using strong authentication is a good candidate for sharing, as it is likely to be in a directory and there is an application framework to use it. This includes:

• End User Certificates. These are generally not needed for authentication, as most protocols using strong authentication allow the certificate to be included. Although this can increase communication costs, it makes things easier for systems doing authentication. However, in order to encrypt a message or document to send to a person or role, you need to have the end user certificate. The directory provides a convenient mechanism to make these certificates available to anyone needing them.
• Communication and general purpose information. If there is a mechanism to browse the directory to obtain end user certificates of target users or roles, it may also be useful to make available additional communication information (e.g., phone number or email address).
• Information for authorization. Attributes stored in the directory may be useful for determining user authorization. This might include special attributes specifically designed for authorization, or general purpose attributes such as contractor/employee status.
• Security label, which determines the user’s clearance. This may be considered a specialised type of information for authorization.
• Information to help verify a user being validated by smart card. Consider the scenario where a smart card is presented for physical access to a facility. The directory can be used to provide additional information to the person checking the person.

Commercial Enterprises & Government Agencies

For many commercial organizations, an enterprise-centric model for Identity works well. Identity needs to deal with entities where identity is managed by the enterprise (e.g., staff) and entities that have a special identity managed in the context of the enterprise (e.g., customers).

Government agencies share a lot of the identity requirements with commercial organizations, and in many ways operate as independent organizations. However, there are often additional requirements placed on Government Agencies to work together. They have a need for internal management of identity, but also have a need to recognize and deal with identities managed by other agencies, often with high levels of security. The inter-organizational requirements discussed here are much more likely to apply to Government.

Conclusions

Directory is a key component of many identity management systems. For many enterprise-centric systems, the directory acts as a hidden internal deployment. In many situations, particularly Government related, there are requirements to share secure identity between organizations. In order to do this, exposing the directory externally to the organization becomes important.