Identity Management: A System Engineering Survey of Concepts and Analytical Approaches.

  • [アーティクル]

Abstract

Identity Management is a new and emerging field where business processes and technology are combined to create identity-centric approaches to the management of users, their attributes, security privileges and authentication factors, across systems within an enterprise. (Hitachi ID Systems, Inc., 2009).

The purpose of this document is to offer a systems engineering oriented examination of the topic of Identity Management. This is accomplished by providing an ontological survey of identity theory concepts and offering two platform-agnostic identity and claims oriented analysis techniques that can be leveraged on projects involving the implementation of identity management solutions. Unlike generic requirements collection techniques which are designed for all efforts, these techniques are specialized specifically for the collection of traceable identity-oriented requirements; These techniques, which are intended to supplement existing requirements collection processes, are purposed for execution during Preliminary System Design; however, like all well documented requirements, the product of these analysis will prove itself useful during Detail, Design and Development; Production/Construction; and really throughout the remainder of the system lifecycle.

Introduction

In the 2008, Forrester Research, an independent technology and market research firm that studies trends in technology and its impact on business and consumers, released a report predicting that investments in Identity Management systems would explode over the next few years from $2.6 billion in 2006 to $12.3 billion by 2014. (Savage, 2009)They continued by also predicting that, over the course of the next seven years, the buying behaviors of businesses and consumers will migrate from point-projects to identity-suites.

Identity Management is a new and emerging field where business processes and technology are combined to create identity-centric approaches to the management of users, their attributes, security privileges and authentication factors, across systems within an enterprise. (Hitachi ID Systems, Inc., 2009).

The purpose of this document is to offer a systems engineering oriented examination of the topic of Identity Management. This is accomplished by providing an ontological survey of identity theory concepts and offering two platform-agnostic identity and claims oriented analysis techniques that can be leveraged on projects involving the implementation of identity management solutions. Unlike generic requirements collection techniques which are designed for all efforts, these techniques are specialized specifically for the collection of traceable identity-oriented requirements; These techniques, which are intended to supplement existing requirements collection processes, are purposed for execution during Preliminary System Design; however, like all well documented requirements, the product of these analysis will prove itself useful during Detail, Design and Development; Production/Construction; and really throughout the remainder of the system lifecycle.

By exploring basic identity theory and purposing methods by which to apply these concepts through analysis, it is the goal of this paper to convey the necessary information to understand and begin implementing Identity Management solutions within their own purviews.

In order to achieve this goal, this document has been organized into four parts: The first part is dedicated to establishing the fundamental concepts of identity and concludes with an example scenario which will be used for the application of these concepts. The second part introduces the first of these two analytical techniques call the Identity Workflow Mapping Analysis, which intends to apply a formal structure to the method used to analysis the example scenario in the first part of this document. The third part of this document introduces concepts of identity management, and like the first part, concludes with an example scenario against which the concepts will be applied. The fourth part this document introduces the second of these two analysis techniques call the Federated Identity Mapping Analysis, which intends to provide a formal means by which to documenting how federated identities are assembled from disparate identity stores.

Part I: Concepts of Identity

In order to fully understand the purpose of the identity mapping analysis process outlined later in this document, and before proceeding with a discussion of identity management concepts that involve the aggregate management of identities within an enterprise, it is imperative that at a basic understanding of identity theory be obtains. To this end, the following sections will provide an ontology survey of the basic concepts of identity management and conclude with an example scenario which will illustrate them. To begin, the question is posed:

What is Identity?

In examination of components of the term identity management, the component termmanagement likely does not need too much qualification; however, the term identity is vastly more abstract of a concept, and that depending on the context in which it is used, it can have a multitude of different implications and meanings; Therefore, it is difficult to define the term in a way that is universally acceptable and satisfactory to everyone. Knowing this, we will begin by examining the most top-level general use of the term as defined by the Oxford Dictionary. From the Latin from idem, meaning “same”, identity is defined as: “(1) the fact of being whom or what a person or thing is” and “(2) the characteristics determining this” (Oxford Dictionary). Surprisingly, in narrow context of Identity Management, this definition works well and allows for segue into more advanced discussion. Further reduction of the two part definition offered Oxford yields some important concepts:

Referring back to its original Latin root meaning “same”, the first part of its definition, “the fact being whom or what a person or things is,“ suggests that identity requires a “sameness” of categorically membership. In other words, an identity refers to one of many like things. For example, an identity can refer to an individual person of among many people, or a single computer of an entire network. An identity refers to a distinct entity of a group of like entities.

The second part, “the characteristics determining this” infers that an identity’s uniqueness within its domain is established by attributes that differ from those of others, and thereby they serve to distinguish it from everything else. In Identity Management, an identity it is a representation of its associated entity that is defined by all the attributes necessary to establish its uniqueness within its respective domain (See the section on Identifiers) and those only concerned with further describing itself. This also includes the means by which to verify that its bearer is the entity that the identity represents.

When an identity asserts an attributes value to establish its uniqueness or to authenticate of its bearer, the assertion is referred to as a claim (Camerok, Posch, & Rannenberg, 2008).

Claims

Returning to another top-level general definition of a claim, it is “a statement that something is the case” (Oxford Dictionary). In Identity Management, a claim is the use of an identity’s attributes presence or values for sake of asserting that something is true (Cameron, 2008) The following are examples of the kinds of truths that a claim might be asserting; •

  • To convey an identifier (see identifiers section below) that establishes their uniqueness within a domain. For example, a medical insurance policy number could be used to uniquely identify a patient within a medical system. Assertions of this type are the basis of how many existing identity systems work. (Cameron, 2008)
  • To assert that the entity knows a specific key or private identifier (PID) for sake of authentication. For example, the whispering a rearranged password to the doorman of a speakeasy would indicate were welcome by someone inside it would be an example of this type of assertion.
  • To assert that the identity belongs is a member of a group. For example, law enforcement agents often will show a badge to assert that they are a member of the law enforcement agency that the badge represents.
  • To assert that the identity should be bestowed certain rights (or restrictions). Reusing the previous example, the demonstration of a badge by a law enforcement agent would assert that its bearer had the arresting powers afforded to all officers of the court Like identities, claims are only relevant to the domain in which they occur. The claims assertions listed above were conducted within the physical world by physical identities. Within the context of the digital world, which consists of information systems, the assertion of one’s claims is the means by which identity is expressed and validated. Within identity management, this concept is referred to as the digital identity. (Digital Identity, 2009)

Digital Identity, Subjects and Identifiers

Digital identity refers to the use of information technologies and systems to represent the attributes that define an entity within the context of a domain (e.g. a computer system or enterprise) for sake of facilitating its interaction with other identities and systems for some purpose. If digital identities were the blueprint schemas by which identity is defined and verified; then the instantiation of a digital identity, by way of active claims assertion of an identity, is referred to as the digital subject. Therefore, the digital identity is the concept of “a set of claims made by one digital subject about itself or another digital subject”. (Cameron, 2008)

As mentioned previously, the uniqueness of an identity within the scope of its domain is established by attributes’ values that uniquely distinguish it from all like entity types. In Identity Management, attributes of this type are referred to as identifiers and they are used as the keys by which the uniqueness of an entity is establish and agree upon by all parties involved. Within the context of a system, an example of an identifier would be the unique username attribute of a digital identity. Identifiers come in two classifications:

omnidirectional versus unidirectional and resolvable versus unresolvable . (Digital Identity, 2009)

Resolvable identifiers are those whose values can be dereferenced of the entity they represent or convey state information. An example of such a type of identifier would be an email address, a bit-flag based enumeration that conveys status, or anything that is ultimately machine understandable. Unresolvable identifiers are quite the opposite. They consist of values which are not ultimately machine understandable, but can be used for comparison and equivalence testing. An example of an identifier of this type would be the last name of an entity.

 

Omnidirectional identifiers are those which are intended to be publically known. An example of an omnidirectional identifier would be an entity’s username. Unidirectional identifiers are those which are not intended to be publically available and are only used within the context of a specific relationship. An example of this type would be the three/four digit security code found on the back of most credit cards today.

Claims Providers, Transformers, and Relying Parties

In Identity Management, the digital subject that asserts a claim to a system or service is referred to as a claims provider. The recipient of the claim is referred to as the relying party. (Camerok, Posch, & Rannenberg, 2008) The relying party gets its name from the idea that it relying on claims providers to asserting claims about a subject to control access to a system or service.

Occasionally, a relying party can be also be a claims provider when it is designed accept and verify one set of claims for sake of producing and asserting a new set; claims providers of this type are referred to as claims transformers, for they transform one set of claims into another.

Claims Approval

Much like how a bouncer will verify the age of a young patron before allowing them into the nightclub, once a relying party (or claims transformer) receives a set of claims from a provider, it will evaluate the claims to ensure their validity; often the resulting issuance of another set of claims, as in the stamping of the patron’s hand by the bouncer. In Identity Management, this evaluation/verification process is referred to the Claims Approval process and comes in two general types: authentication processes and authorization processes.

Authentication process are those claims approval processes that are used to authenticate the validity of identities (i.e. verify the that claims provider is whom he claims he is) by comparing the value asserted claim, called an identifier, against the value stored within a specific database of identity values, called an identity store.

Authorization processes are those claims approval processes associated with granting or denial of access by the assertion of a new set of claims that are trusted within the domain (e.g. a Kerberos token) that is used for automated decision or mapping to an a type of identifier known as an application specific identifier.

At this juncture, several abstract concepts have been introduced and so as to prevent becoming figuratively lost-in-the-reeds, it is productive to offer an example scenario against which these concepts can be applied. Hopefully be doing so, it will solidify an understanding of them, but also is important development step in learning to apply system engineering principles in the analysis of identity management solutions.

Example Scenario I

The scenario detailed in the next few sections will be offered in two parts. The first part will consists of an extremely elementary scenario that will facilitate easy

identification of concepts. The second part will be slightly more complex and consist of a claims transformation.

The approach that will be used in analyzing this scenario will first consist of unstructured walk through of the scenario, where the concepts discussed will be identified and placed within an identity context. Following will introduce an analytical technique called Identity Claims Process Mapping Analysis, which will provide a structured approach to this analysis, which can be levered on Identity Management projects.

Alice is a systems analyst working on on-site on a secret project for the Department of Defense. Every morning, she starts her day by logging into the military network by entering in her domain username and password into a login form on her computer. When she presses enter, the credentials she supplied are sent to the networks domain controller, where network services will check the values stored in her user object in the network’s LDAP directory against the values Alice provided. Finding that they are a match, the domain controller returns to Alice a security token.

In the first part of the scenario, Alice is acting as an identity provider, which through the use of her username (an omnidirectional and unresolvable identifier) and her password (an unidirectional and unresolvable identifier), she asserts a claim to the network, which is acting as the relying party, that she is indeed Alice and should be allowed on the network. The network’s claims approval process first begins with an authentication process, which involves comparing the credentials Alice supplied against the stored in the networks LDAP directory, which is acting as the identity store. Finding that that the credentials match, the claims approval process finishes with an authorization process that involves sending Alice’s computer a security token, which she will use access other claims-aware applications in her domain.

 Part II: Identity Claims Chain Mapping Analysis

The in the implementation of identity management systems, it is important to understand the chain of claims exchanges between workflow processes. In previous example scenario, Alice’s asserted one set of claims to gain access to the network. This workflow consisted of the authentication and authorization processes necessary to verify her identity and to grant her continued access.

The security token that was issued to Alice at the end of this process could theoretically be used to assert new claims of identity to resources on the domain that are designed to accept them. For instance, access to resources on an intranet web server, such as a web portal, could be restricted to those whom have the security token.

Claims can further be by chained by continuing their transformation and adding systems that can accept them. For instances, if the intranet web portal were to encode an identity into a cookie, theoretically an extranet website could be altered to accept them, and therefore achieving a single-sign-on effect between the two -- and the rest of the enterprise discussed thus far.

The purpose of this exercise is to identify these chains of identity claims exchanges. The value of it is that allows for the documentation of claims transformations within an enterprise; Moreover, it allows for the identification of pockets of isolation where, where claims cannot be exchanged; therefore, yielding opportunities for further integration.

Below is a matrix called the Identity Change Transformation Matrix (see Appendix A – Identity Claims Transformation Matrix). The claims exchange relationship between Alice’s three systems (i.e. network, intranet portal, extranet portal) is completed below for demonstrative purposes:

[TABLE]

Field Names
The following is an explanation of each of the field found in the matrix and their purpose:

  • ID - A unique identifier used to represent the workflow atomically for sake beign able to make references to it.
    Description - A brief description of the process.

  • Provider - This field denotes who is asserting the claim. This can have the value of Entity, which would indicate that the entity themselves is asserting the claim; or it can contain a reference to another workflow for which it is depending on a claim to initiate.

  • Claims Asserted - This field contains the values or descriptions of the claims asserted. Generally, an identifier would be placed here that referenced the claims schema in detail.

  • Relying Party - This field denotes who is receiving the claim.

  • Authentication Processes - This field contains a list of the processes that are used to authenticate the validity of the claims asserted. Generally, this field would include an identifier that would detail the process indepth along with a high-level description. The processes can also include other workflow chains.

  • Authorization Processes - This field contains a list of the processes that are used to grant access, or complete the objective, of the workflow process. This generally will also include any output for the process, such as the creation of a security token.

Part III: Concepts of Identity Management

What is Identity Management?

Identity Management is a new and emerging field where business processes and technology are combined to create identity-centric systems, design to the manage and administrate the identified identities within the scope of a domain, \such as a state,network or enterprise By associating the rights and restrictions of users with their corresponding identities, Identity Management systems are often also involved in the controlling of access to resources by users within that enterprise.

Identity Management is concerned with the tracking of three general types of data: personal information, attributes that describe the entity that the identity represents (e.g. name, age, etc.); legal information, attributes that describe the legal or business relationship of the identity to the enterprise (e.g. start date, etc.); and finally security information, this type includes group memberships, passwords, credentials (etc.)

The DMV of any given jurisdiction offers a classic example of an Identity Management system: The identities of licensed driver are represented by a unique ID number. That ID number is used to define the uniqueness of each identity, or licensed driver, within the system for sake of their individual administration and management. Any of other attributes associated with that identity (e.g. weight, height, etc.), including those that describe restrictions of the use of the license (e.g. must be wearing glasses) are associated with this identifier.

Identity Management system could be leveraged to automate administrative tasks such as the as resetting passwords or the changing the profiles of identities (e.g. updates to job title, marital status, etc.). By enabling users to update the profiles of their own identities instead of relying on IT resources, such as help desks, this can lead to significant cost savings.

The Identity Lifecycle

Conceptually speaking, within the scope of its respective domain (e.g. such as that of a corporate IT enterprise), digital identities exist within a finite three stage lifecycle (Quest Software, 2008). An identity enters the scope of a domain; continues to exist within it, often evolving and otherwise changing during this period; and then finally exiting the scope.

For example, a person is hired as an employee at an organization. They work at this organization for a period of time, where often their characteristics of the identity change (e.g. marital status, get promoted, change titles, change passwords, etc.). Then finally they eventually they leave the organization. In Identity Management, this concept is referred to as the identity lifecycle; and it is the administration and management of identities throughout their lifecycles, within the scope of its domain, that is the primary fundamental purpose of identity management systems. The three sequential phases of the identity lifecycle are referred to as: onboarding, change and maintenance, and the termination phases.

Onboarding

This is the initial phase of the identity lifecycle. Activities within this phase are concerned with the initial introduction of an entity’s identity profile, referred to its projection, into the enterprise. The particulars of this authorization process , to include which systems within the enterprise their identity requires representation (e.g. entry into a corporation pay role system, their HR system, etc.), will vary greatly depending on the nature of the identity’s relationship to the enterprise (e.g. contractor versus employee) and the role they are to serve within it.

Change and Maintenance

This is second of the identity lifecycle phases, and as its name suggests, is dedicated to the change management of an identity’s profile within the enterprise for the time that the identity continues to reside in it. These changes range from routine password management activities, to domestic profile changes (e.g. marital status), to complex workflows associated with the changing of one’s role within the enterprise.

Termination

As in the case of when an employee retires, the final phase of the identity lifecycle is concerned with those activities involved in the eventual exit/removal of an identity from an enterprise. The activities generally involve the deactivation of user accounts, updating of associated systems and so on.

Identity Store Proliferation and Identity Federation

Often, as the size of an organization grows, the price of success is the corresponding additional amount of work that is placed on its respective operational (e.g. human resources, legal, account) and its functional (e.g. engineering) business units. This leads business units to begin seeking solutions from information systems that will assist them in automating tasks with hopes of increasing the efficiency and easy at which they can complete their respective functions; However, often these systems are often designed at the department-level and frequently little consideration is given to their role in the enterprise beyond what they are designed to accomplish. This leads to an enterprise consisting isolated stove-piped systems, frequently of a heterogeneous platforms (e.g. Unix and Windows).

Since identity exists at the enterprise-level and since often these systems require use of identity data, yet are not designed to share it between them, implementation of these systems effectively results in the creation of additional identity stores. This identity store proliferation, particularly in the absence of an identity management system, can negatively impact organizations as they then face having to manually update numerous systems, in a coordinated manner, to supports the changes to the identities throughout their lifecycle. In effect management of this process can result in systems’ identity stores becoming out-of-sync from one another and reflecting different states of identity information.

As the number of identity stores in a domain increase, the tendency for identity profile data (e.g. personal, legal and security data) to be more greatly distributed and disbursed among these often stove-piped systems increases. This hinders the ability for an organization to see the aggregate profile of an identity without resorting to consulting each system that contains fragment components of it.

Another common side effect of identity store proliferations is that, as the number of identity stores increase, so does the tendency for these stovepipe systems to duplicate identity data. This is due to the fact that common identity attributes, such as an entity’s name, are required in many of the processes in an organization. This further complicates matters for an organization in dealing with identity changes. For example, a simple change, such as the marital status of a female employee, may require the manual update of each system that stores a copy of her last name.

Identity management systems address the issues associated with identity store proliferation by leveraging system APIs and other means to programmatically keeping isolated identity data in-sync with one another. By the same means, they are able to assemble the disjoined components of digital identities across the systems and provide a federated digital identity. (Digital Identity, 2009). The following example scenario will demonstrate how Identity management systems can accomplish this:

Example Scenario II

As before, the following scenario will be offered for sake of allowing for the application of the concepts learned here so far through a subsequent analysis.

Company ABC developed a large scale web-based collaboration portal for its employees. This collaboration portal resides in a Unix environment, where users authenticate using accounts stored in an network LDAP repository. This company also has an email system, which resides in a Microsoft, which users authenticate using accounts stored in Active Directory. Presently, updates to identity information (e.g. addition of new employees, password changes, etc.) are performed manually by IT teams and help desks dedicated to each respective repository and are driven by calls received from HR.

Users in the UNIX directory include the following attributes: their ABC employeeID, their job title, their user name and password, and their full name. Accounts in the email system consist of the following attributes: employeeID, job title, user name and password, first name, last name, email address, and email display name.

In analyzing this scenario, a few things become apparent. First, identity data is disbursed between the two identity stores within the enterprise: the two LDAP repositories, despite being LDAP based, are both incapable of exchanging and accepting each other’s claims (e.g. authentication, identity attribute queries, etc.). Second, there is a considerable amount of identity data duplication between the repositories. Finally, in the absence of an Identity Management system, it is apparent that the two IT teams bear the brunt of the burden in the administration of its organization’s identities’ lifecycles.

Implementing an Identity Management solution would provide the following potential benefits: One, while the ability to access and exchange claims is likely never to occur, an Identity Management System could implement password synchronization between the two environments. Second, onboarding and termination processes could be automated, to include programmatic provisioning (and deprovisioning) of accounts from both environments. Third, an Identity Management System would allow the normalization of data across the identity stores, permitting transparency and an aggregate view of the enterprises federated identities. Finally, and perhaps more significantly, if the Identity Management System provides a suitable user interface by managed identity can be administrated, then alleviates much of the burden and cost associated with IT performing the duties and allows those duties to return to those whom are the more appropriate owners of them (i.e. HR and the people themselves.)

Part IV: Federated Identity Mapping Analysis

In implementing an Identity Management System, it is important to have a clear understanding of how the federated identities are assembled from identity data stored in the enterprise’s various identity stores. The purpose of this exercise is to derive a relational model that shows how each attribute of an entity’s identity is stored within each identity store. The value of this exercise is that allows for the creation of a normalized view of a conceptual unified identity-centric data structure that spans the entire domain. This allows for an understanding of how and which identity stores, and therefore their associated systems, are affected by identity attribute changes. This, in turn, proves invaluable in subsequent analysis of mapping identity change workflows.

The output of this exercise is a matrix called the Federated Identity Attribute Map. It is a matrix lists each of the attributes of the assembled digital identity maps to their source attributes in each of the respective identity stores. Using the scenario listed previous (see: Example Scenario II), below is a completed version of the matrix:

[TABLE_II]

Field Names

  • Identity Type - The name of the identity type depicted. Field is use useful for distinguishing one type from another in an enterprise.

  • Attribute Name - The name of the identity attribute. There should be one for each attribute in the federated digital identity.

  • Directional Flow - This field is useful for conveying authoritative sources. It has three possible values: import, which denotes that associated identity store is the authoritative source for the federated identity attributes value (i.e. it is imported from this source); export, which denotes just the opposite that it receives its value from the Identity Management System; and Import/Export, which denotes that all values are synchronized with each other based on each other.

  • Transformation Process - This field conveys whether there is a need to transform the data from one source to another. This field can have two values: direct, which denotes that no manipulation is required (i.e. as in a direct copying of value); and programmatic, which denotes that some programmatic process is required to parse the data, usually to match some desired format. IDs can be added to the value of these fields’ additional designs on these on these programmatic processes.

  • Identity Store - The name of the identity store that hosts the application attribute. This field can also be assigned an ID that references a more detailed account of the identity store.

  • Application Attribute Name - The name of that attribute in the system (e.g. SQL table field, LDAP attribute, XML node address, etc.) that holds its copy of the value of the identity attribute.

References

 

Camerok, K., Posch, R., & Rannenberg, K. (2008, October 5). Proposal for a Common Identity Framework: A User-Centric Identity Metasystem. Retrieved July 3, 2010, from The Identity Blog: https://www.identityblog.com/wpcontent/images/2009/06/UserCentricIdentityMetasystem.pdf

Cameron, K. (2008, May). The Laws of Identity. Retrieved July 1, 2010, from MSDN: https://msdn.microsoft.com/en-us/library/ms996456.aspx

Digital Identity. (2009, June 1). Retrieved July 10, 2010, from Wikipedia: https://en.wikipedia.org/wiki/Digital_identity

Hitachi ID Systems, Inc. (2009). Defining Enterprise Identity Management. Retrieved July 4, 2010, from from Hitachi ID Systems: Identity Management Solutions: https://password-manager.hitachi-id.com/docs/defining-enterprise-identitymanagement.
html

Oxford Dictionary. (n.d.). Claim (Definition). Retrieved July 21, 2010, from AskOxford.com: https://www.askoxford.com/concise_oed/claim?view=uk

Oxford Dictionary. (n.d.). Identity (Definition). Retrieved July 20, 2010, from AskOxford.com: https://www.askoxford.com/concise_oed/identity?view=uk

Quest Software. (2008, December). Finding Complete Idenity Lifecycle Managment That Fits. Retrieved July 3, 2010, from ZDNet: https://whitepapers.zdnet.com/abstract.aspx?docid=940509

Savage, M. (2009, June 28). Changing the Face of Identity Management. Retrieved July 2, 2010, from Systems Management News: https://www.sysmannews.com/%28S%28zjxeotmnfwojhb2y4hjpis3c%29%29/SearchResult/32577