Identity correlation is, in information systems, a process that reconciles and validates the proper ownership of disparate user account login IDs (user names) that reside on systems and applications throughout an organization and can permanently link ownership of those user account login IDs to particular individuals by assigning a unique identifier (also called primary or common keys) to all validated account login IDs. The process of identity correlation validates that individuals only have account login IDs for the appropriate systems and applications a user should have access to according to the organization's business policies, access control policies, and various application requirements. In the context of identity correlation, a unique identifier is one that is guaranteed to be unique among those used for a group and for a specific purpose. There are three main types, each corresponding to a different generation strategy:
Serial numbers, assigned incrementally Random numbers, selected from a number space much larger than the maximum (or expected) number of objects to be identified. Although not unique, some identifiers of this type may be appropriate for identifying objects in many practical applications and so are referred to as “unique” within this context Names or codes allocated by choice but forced to be unique by keeping a central registry such as the EPC Information Services of the EPCglobal Network For identity correlation, a unique identifier is typically a serial or random number. In this context, a unique identifier is typically represented as an additional attribute in the directory associated with each particular data source. However, adding an attribute to each system-specific directory may affect application or specific business requirements, depending on the requirements of the organization. Under these circumstances, unique identifiers may not be an acceptable addition.
Basic requirements of identity correlation Identity correlation involves several factors:
Linking disparate account IDs across multiple systems or applications Many organizations must find a method to comply with audits that require them to link disparate application user identities with the actual people who are associated with those user identities. Some individuals may have a fairly common first and/or last name, which makes it difficult to link the right individual to the appropriate account login ID, especially when those account login IDs are not linked to enough specific identity data to remain unique. A typical construct of the login ID, for example, can be the 1st character of givenname + next 7 of a serial number, with incremental uniqueness. This would produce login IDs like jsmith12, jsmith 13, jsmith14, etc. for users John Smith, James Smith, and Jack Smith, respectively. Conversely, one individual might undergo a name change either formally or informally, which can cause new account login IDs that the individual appropriates to appear drastically different in nomenclature from the account login IDs that the individual acquired prior to any change. For example, a woman could get married and decide to use her new surname professionally. If her name was originally Mary Jones but she is now Mary Smith, she could call HR and ask them to update her contact information and email address with her new surname. This request would update her Microsoft Exchange login ID to mary. smith to reflect that surname change, but it might not actually update her information or login credentials in any other system she has access to. In this example, she could still be mjones in Active Directory and mj5678 in RACF. Identity correlation should link the appropriate system account login IDs to individuals who might be indistinguishable, as well as to those who appear to be drastically different from a system-by-system standpoint. Still, it should be associated with the same individual.
Discovering intentional and unintentional inconsistencies in identity data Inconsistencies in identity data typically develop over time in organizations as applications are added, removed, or changed and as individuals attain or retain an ever-changing stream of access rights as they matriculate into and out of the organization. Application user login IDs do not always have a consistent syntax across different applications or systems. Many user login IDs are not specific enough to directly correlate back to one particular individual within an organization. User data inconsistencies can also occur due to manual input errors, non-standard nomenclature, or name changes that might not be identically updated across all systems. The identity correlation process should consider these inconsistencies to link up identity data that might seem unrelated upon initial investigation.
Identifying orphan or defunct account login IDs Organizations can expand and consolidate through mergers and acquisitions, which increases the complexity of business processes, policies, and procedures. As an outcome of these events, users are subject to moving to different parts of the organization, attaining a new position within the organization, or matriculating out of the organization altogether. At the same time, each new application that is added has the potential to produce a new, completely unique user ID. Some identities may become redundant, others may violate application-specific or more widespread departmental policies, others could be related to non-human or system account IDs, and still others may no longer be applicable to a particular user environment. Projects that span different parts of the organization or focus on more than one application become difficult to implement because user identities are often not properly organized or recognized as defunct due to business process changes. An identity correlation process must identify all orphan or defunct account identities that no longer belong to such drastic shifts in an organization's infrastructure.
… excerpt ends here. Continue reading the full article.
