One of the most important tasks of CIOs is managing the identities of their company’s customers and securely facilitating relationships to business applications.

The first part of an examination of the anatomy of an identity was to select the correct kind of information that should be placed within it. Of most importance was to ensure, through proper selection of an authoritative source of information, that it was correct, and to provide some method to maintain its correctness and assure its consistency. We covered this in “Get IT Done: Anatomy of an Identity.”

The second part of the process is to build the correct structure that facilitates the Identity Access, that is, the most efficient means to obtain authentication and authorization information. If the object is malformed (i.e., it has misplaced data or incorrectly stored data), the process of Identity Access is, at best, inefficient and, at worst, risky and insecure. The structure of the identity, how and where it is stored, completes the identity management process.

Integrating the information: How to structure the Identity Object
While the major portion of Identity Management is to assemble the information from many authoritative sources or to control what information may be placed into the Identity Object, it is important that it structure the information in such a manner as to allow the relevant application to interpret the information properly. This has two forms: (1) the encoding of the data (syntax) to ease the processing of application processes; and (2) the placement of information within the Identity Object (semantics) such that it provides a logical presentation of the information to be transmitted to the application.

While there are no firm rules for managing syntax of elements, there are some best practices that might help. The following are a few of the most obvious ones:

  1. The data from the authoritative sources is assumed to be correct as part of the workflow process. The purpose of Identity Management is to assemble the data into the Identity Object and not to perform complicated verification or transformation.
  2. Any transformation should be simple. If it is relevant, use a menu or drop-down list and do not allow free form. Manipulation of the data from an authoritative source typically leads to unsatisfactory results.
  3. The content of the information may not be the same as what is seen, since some information may have an alias tagged to it. In addition, the data must have a clear definition and should not be “overloaded,” (i.e., have multiple meanings).
  4. The logical presentation of the information to the application for authentication and authorization is provided through the policy construction and is not a function of the provisioning function.

Having multiple authoritative sources feeding into a single Identity Object will create inconsistent context and confusion to an application, which is determining authorization without some method of governing semantics (i.e., which is looking at multiple elements and their multiple values to make an authorization decision). The best way of untangling this is to use a layer of abstraction in the form of policy definitions that apply the proper rules and priority of information. The application receives a name of a policy statement as a result.

In simple terms, the “and” and “or” conditions of existing information within each user’s Identity Object gives the resulting value to an attribute or element. As an example, the Identity Object of a person contains a passport number to attest to U.S. citizenship and a verification number from a Federal database for security clearance. A policy for the role of research scientist for a top-secret project can be derived from the existence of, or the values within, the attributes or elements.

In a complicated environment, this would be evaluated using a decision model based upon the subject-condition-rule definition (an extension of the J2EE policy, used by Sun™ ONE Identity Server). For a set of resources, such as a URL, the policy would evaluate to either an allow or deny based upon the following:

  • [Subject]: The set of user’s based upon an explicit selection or those that met a certain criteria. For instance, this may be all that belong to the European Community.
  • [Rule]: The intersection of information over the entire population of users’ Identity Objects that would form the appropriate set of users who may access the resource. For instance, a rule could specify that it applies to all users whose Identity Object contains information indicating that they live in France and Germany.
  • [Condition]: The set of environmental properties associated with the requested access of the resource necessary to allow the use of the resource. Typically, this is a limitation based upon time (only between certain hours) or origin of access (a specific set of IP addresses).

Assembling the information: How to secure the Identity Object
The biggest challenge of the Identity Management is to store the Identity Object securely and maintain confidentiality of the information within the object. While a lot can be said on the subject, in general, the Identity Object should only store what is appropriate for access, and that which is stored should be encrypted where appropriate. For instance, salary information should never be part of an Identity Object, even if derivable from an authoritative source. Identification information such as a user’s password is always encrypted one way and never stored in clear text.

Typically, access to the information within the Identity Object is done indirectly using one or more elements as individual keys (as long as they are unique) that allow the search for the name of the Identity Object. The name of the object becomes irrelevant, hiding the purpose of the Identity Object. Each key, or identity link, may be derived from many different sources, either through an authoritative source (provisioned) or prompting of the user with control of uniqueness by an application.

The authentication is done on behalf of the person being challenged by taking the user name as a key to find the name of the Identity Object and then attempting a bind with the pass code(s), such as user password or PKI information. The result is an “allow or deny” decision and an implicit access privilege. Divulging information with the Identity Object is controlled by the access privilege of the authenticated reader. For instance, sensitive information may only be allowed for the owner (user bind) of the information.

Authorization information is provided to the authenticated reader using the abstract construction of a policy definition based upon many pieces of accumulated information. The application need not even know, or be allowed to access, the underlying information as long as it can access the name of the policy definition.

Identity Access and Identity Security depend on the proper implementation of an Identity Management solution. But just having Identity Management software to use to construct an Identity Object is only the tool. Identifying and providing data mappings provides the foundation of what should be supplied within an Identity Object. The planning of the structure of the Identity Object is what provides the capability to use the Identity Object efficiently. Moving information into an Identity Object from multiple authoritative sources does not mean that the Identity Object is consistent or even reliable. But applying careful design of the structure of the Identity Object, especially how the attributes/elements may be used in policy statements, will remove the ambiguity when accessing the Identity Object for authentication and authorization.