Identity and Access Management - Part II - Identity Management

Before we go too far on the path to understand what its management is about, let us define what identity is.

What is Identity? (I am not Dave, that is just my Name)

Incase you read the link that I provided in Part I, you have the basic idea about how identity has been defined so far as an abstract concept. In order to map this to more real-world scenario I have interpreted the three tier system in the digital world as follows

• Core Identity: This is the digital representation of an entity in the domain. This needs to be unique in the particular domain and can be a UUID, email-id, employee id, or something that uniquely identifies the user in the domain.
• "Action" Identity: This defines the identities that the core identity uses to perform its work. So for example the core user can use unix root id or a NYSE trader role. These identities are representation of the core identity in specific resource(s). Typically these identities are used by the resource manager to identify the user. These identities are typically mapped to core identity(or vise versa) during provisioning.
• "About" Identity : Every identity has some information associated with it (like name, address, and so on). This information helps the resource managers in the domain to understand the core identity better and provide the resource based on the policies defined. I like to categorize this information into the following sets.

What is identity Management?

The basic idea behind identity management is to manage the three tiers of the identities that represent the entity in the domain. The core identity is the basic representation of the entity in the domain. The resource managers (which provide the functionality and data to the entity) due to various reasons may not recognize the the entity as the core identiy but as a completely different user id (for example root id on unix) or by the role the core identity has been assigned (for example unix admin role or NYSE trader role). These identities (the "Action" identity) would help resource manager recognize the user in its context instead of bothering about the core identity. This simplifies the job of resource manager in the sense that it does not need to know core identity of each and every entity to serve the entity. Once the resource manager has recognized the core identity in its own realm, it may need additional information about the identity to make decisions based on the resource manager policies. These decision can be about whether it should give access to required resource or what resources should it serve to the entity and so on... I like to classify this "additional information" in to three types.

1. Authentication Information - This information is needed by the authentication system of the resource itself or that trusted by resource to make sure that the entity is who it claims to be. This information can be
   • What entity knows (like password)
   • What entity has (like token generator, smart card, certificate)
   • What entity is (like finger print)
   The entity in this case can be a physical entity like user or a logical entity like an application.
2. Domain Information - The domain specifies that each and every entity's representation has a basic set of information associated with it. This may be information like name, address and so on. The decision about what , is typically made at domain level.
3. Resource information - This information is relevant only for particular resource only and does not make sense in case of another resource manager or will be used in different context in another resource. For example, the trade limit may make sense for an security trading application, but would not be relevant in a tax application and at the same time, may have different connotation in a forex application. This is typically defined by the resource group itself.

In the next section I will try to define what component typically come into play during the runtime i.e. when entity is interacting with resource manager to get access to resource and during management.

Runtime

The Identity management system should be able to help the resource manager identifing and authenticating the entity at runtime.

Components

The authentication mechanism can be broken down into two component -

1. Process: This is the moving part of the system which typically performs the following functions
   • Retrieved the authentication/identification information using the configured procedure. This can be achieved by using a wide variety of ways like Basic Authentication, Forms based, fat clients, CSI-IIOP, Certificate, fingerprint scanner, IRIS scanner, Challenge Response like SPNEGO, SecurID and so on. An important part of the retrieval process is to ensure that confidentiality and integrity of the authentication information is not compromized in the process.
   • Once the information has been retrieved, this information may need to be processed using specific algorithm (like hashing algorithm for one-way password or CRL validation for certificates) before information is in the form that can be compared to information in the database corresponding to entity.
   • Besides that it validates whether the security policies regarding inactive account expiration, authentication information expiry(incase it is not biometric), number of logon trials, time and location of access by entity are being followed.
   • Eventhough not part of core authentication, process generates the authentication audit events as configured.
2. Database/Directory: The trusted source of the authentication information with keyword being "trusted".
   • The database should be designed so that the integrity and confidentiality of the authentication information can be maintained.
   • The process uses the database to validate whether the information provided by the entity matches the information present in database. Most of the time this distinction about database being separate from process is not made. But it is important to realize that as we move toward SSO a very important strategy may comprise of having Single Database which is shared by different process which themselves are embedded in the legacy applications.
   • These databases can be LDAP based directory, Active Directory, RDBMS, file system, ACE Server database, certificate store, to name a few.
   • Once the distinction between Database and process is well understood, the next idea that should be kept in mind is how process interacts with database i.e. what are the databases that "process" supports, does the "process" provides facility to map the existing data structure/schema to its datastructure or does database schema need to be specific to the "process" being used.

Most of the times in the discussions, some thing that I have found missing is the concept of session. Basically, this is an important part of authentication and authorization but at the same time is not addressed in most of the specification. Typically it may be hard to define the concept of session, but in most of the cases the session can be defined as the duration during which the entity was interacting "actively" with the resource manager. The definition of "actively" is very subjective which may vary from few minutes for a user application's to days for long batch processing transactions. But for most of the applications, the concept of session inactivity timeout and session failover should always be kept in mind while considering the authentication which typically gets tied to session management.

Implementation

Based on the components that are described above the authentication runtime implementations can be broken down into following categories.

• standalone component like Web SSO products or Desktop authentication where the authentication of the identity can happen even without the entity connecting to resource manager. In such scenarios the resource manager trusts the authentication mechanism and uses the identity(and additional information) passed to it to construct entity's identity. Incase of the standalone component it is important to understand the mechanism and security behind the transfer of user's identity to the resource manager from authentication process. This transfer can happen via Header variables(in case of Web applications), SAML, Privilege Certificates(PAC) and so on. Besides that resource may use different identity to identify the entity, in which case the user identity mapping would had to be performed by either the authentication mechanism or the resource manager.
• Integrated component like built-in security module where the authentication happens when user tries to access the resource by contacting the resource manager. This is the most prevelant implementation before the Single Sign On concept came into the picture. The resource manager in this case has a built-in module that provides the identification and authentication facility. In addition to that these component provide the management facility(like identity creation, password reset). It is important that these applications are part of the single point Identity management strategy. Most of the provisioning product support the concept of adapters/connectors which allow you to integrate the identity solutions into these integrated component using component specific APIs or standard protocol. Incase the database of the component is built using a standard RDBMS or Directory, Meta-Directory products are available which can synchronize the information between the products. A very important point to remember is that the identity information can flow both ways i.e. from central repository to resource manager's identity database and vise versa.
• Shared database This catagory falls between the two approaches described above. A lot of new inhouse applications typically take this approach. It allows the authentication process to be integrated with the resource manager but uses a database that is not under complete control of resource. A good example would be Unix box using LDAP/Kerberos for authentication purpose. The process uses the available database (which may be managed via other process) for validation of authentication information.

Management

The identity management deals with the process of addition/modification/deletion of the identities and associated information. There is nothing new with this concept, and for years the resource managers have provided built-in components that do exactly the same and enterprises have developed systems in their operations department that use workflow applications to manage this process. These systems typically work as follows

A request paper work was submitted or a ticket was create via helpdesk. The help desk/operations department used the workflow product (like REMEDY) to send the ticket to appropriate administrator. The administrator then performed the identity management operation on the application using the application's administration interface.

This approach has two things missing

1. End-to-end automation Due to the human factor a lot of time the tracking, auditing, accountablitity is not exactly the best thing about the process. So it would really be great to have an end-to-end system that can allows tracking, auditing the complete process and give accurate status of the process. One of the ways is to automate the complete workflow and include all the entities involved in the process(users, their manager, resource owner). This is an important contribution of the latest breed of provisioning systems. This frees the administrators of the dreaded work of reseting password and concentrate on application administration.
2. User Interaction An important part of the previous workflow systems was dependency on third-parties like help desk/ system administrator for the completion of the work. The new products bring in the concept of self-service where the user can perform the basic administration tasks like password reset, creation of accounts to some systems( once they have basic privilege) without requiring input from third parties. It is very important to design the workflow so that the confidentiation and integrity of the systems is not compromised for example the password reset workflow should be designed so that only the person who is the owner of the account is able to perform the reset(this is typically implemented in variety of ways like using known email id, personal question/answer).

Components

Most of the client being used to concept of ticket tracking expect similar functionality from the identity management systems. Most of the old ticketing systems allowed users to provide free-text input which was meant to be for human administrators. This is I think the biggest hurdle in new systems where the complexity of the ticket that can be generated during the process is very limited and should improve over some time. Eventhough the level of functionality may vary with implementation, most of the products have the following component in some form or other as part of their implementation.

1. Interface is, understandably, an important part of the identity management. There are two parts of the interface - input and notification. The input basically deals with interface(like web based, fat client, APIs, Web Service, SPML) using which the users and other process can interact with the identity management application to provide input required for the workflow to complete. Most of the workflow have various points at which it needs user input(like approval of a request, additional information) and at those point the IDM application needs to notify the user via different kind of interfaces (like email, lotus notes, groupware, pager, and so on). So it is very important that identity management should have an appropriate blend of the two interfaces.
2. Delegation is an important part of the operations. This allows the help desk to manage a lot of the basic facilities and free the application administrator from it.
3. Rule/Policy Engine Most of product support some sort of rule engine. This is important part that helps designing the rules that can be associated with input validation and choice of workflows and so on while implementing complex processes.
4. Workflow engine This is one of the most basic thing that every identity management product that provides complete solution has. This helps the defining the business process for identity management and automate them.
5. Trusted Repository Most of the enterprises already have a separate systems that manages the employees(HR ERP), customers (CRM) and so on. These identity must be accepted by the identity management system as trusted identity and hence the concept of trusted repository.
6. Reconciliation/provisioning Adapters/Connectors Well these are the components that complete the automation. Basically these are the components that connect to the resource managers or its security database and add the identity information to it.

These components typically form part of the identity management systems. Next time I will try to take up the Access/Authorization Management systems.