Lock IT Down: Anatomy of an identity

We hear about identity theft a lot these days, but as CIOs we need to think about the issue from the point of view of the enterprise entrusted with the "identities" of our users and customers. CIOs need to know how to manage identities and securely facilitate relationships to business applications.

Identity management vs. identity security and access
The concept of identity security and access is different from identity management. Identity security and access deals with the problems associated with the use of a network identity. Applications work with a network identity to authenticate the user. By the very nature of the challenge and response, you are who you say you are. The system may also use that identity to deduce the level of privileges and rights you have to information through the authorization process. A policy is used to allow certain actions within the authorization. You authenticate as an account holder to manage your savings and checking account information, for example, and you are allowed to pay bills with money from each. It may be bank policy, however, that funds deposited within the last five business days cannot be used for withdrawals to pay bills.

Identity management furnishes the information about you that allows you to perform the authentication as well as the authorization. It is, obviously, important that the information that makes up the identity object is not only correct, but that it is in a form that allows the application processes to interpret the information. It is clear that provisioning (and any associated workflow) isn't the only means to "manage" an identity; information gleaned from the identity access process will affect information within the identity object. In the example above, it is identity management that created the information that allowed authentication and governed the policy associated with the associated authorization.

Starting out: How to name the identity object
If you consider that the information for an identity—that is, all the attributes and values associated with the attributes—needs to be retained in some data store, then the initial definition of that identity object is its name in the data store. The name of the identity object must be unique and persistent, although information within the object may be transient, or, at a minimum, less than persistent. It is unique as a constraint of the data store; it is immutable to avoid confusion that it might, potentially, represent another identity.

Assigning a name based upon a variable element contained within the identity object is fraught with difficulties. Using a first name and last name combination is not unique and could very well change. Using a more stable data element tied closely to the user's identity would cause security problems, as it might divulge key details about the person's identity.

The name of the entry should not be determinable and must be constructed uniquely, since it is bound to the constraints of the data store. It is transparent to the identity access process except as a "handle" to access further information within the identity object according to the security policies. An application can search the data store based on the identity key or link, which is furnished as part of the challenge process of authenticating, to return the handle (an internal name of the identity object). A subsequent read of the data store based upon the internal name can then be controlled (allowed or denied) by the data store. The internal name is a result of standards applied by the data architect. The application only derives the name of the identity object, subject to rules of uniqueness and any restriction placed upon it for access of information, through a search within the data store.

In a corporate enterprise, where control of an employee number assures uniqueness, it would be reasonable to use the employee number within the name of the identity object. For security reasons, you may want to one-way encrypt that and hash it as part of the naming convention, especially if it has significance to revealing any personal information. Anonymous access is sometimes given for searching of "telephone directory"-type information, but it may, inadvertently, display the name of the identity object also and reveal information that you thought was hidden. On a public Web site, which allows for self-membership, it might be a random number or date and time.

The user's identity key (user identification) can be multivalued and the data store should allow the identity object to be searched on any number of keys. The context of the identity key may be unstructured in syntax, or even multi-attributed, with multiple elements that need to be combined into the identity link. A user may have multiple credentials used for different methods of access, or may change credentials during the life of the identity, such as using a PKI certificate rather than a user identification and password.

Sources and uses of information in an identity object
An authoritative source is a supplier of trusted information. The obvious example is a Human Resource system providing employee number or work status. The employee number is assigned by the system; the work status is derived from the presentation of government documentation attesting to a legal standing. The database of record is the Human Resource system, since it clearly controls that element of information. The actual information may be derived through a set of transformations, such as a workflow process or construction based upon values found in other authoritative sources.

Information that is primary from an authoritative source or derived and stored in the authoritative source is still considered the "owner" of that information in the context of usage by the data store for identity objects. No two sources may "own" a single element/attribute within the identity object. It might be more of a political issue than a technical issue, but all information stored within an identity object must have an owner.

An authoritative source need not be a database, but may be from a process that inserts information into the identity object. Identity access could provide elements, such as user password or a user-created identification. Or it could derive elements based upon values placed in the identity, such as the person's postal code, or from a direct query such as a questionnaire presented to the user upon registration. It is meant to enhance the user's experience.

Implementation
Identity access and identity security depend on the proper implementation of an identity management solution. Identifying and creating data mappings provide the foundation of what should be supplied within an identity object.

In the next part of this series, we deal with the planning of the structure of the identity object so that it has the capability to be used efficiently. A careful design of the identity object's structure will make it consistent and reliable.

TechRepublic originally published this article on 26 January 2004.