Identity mapping

Identity mapping is the process of using defined relationships between user identities in an enterprise such that applications and operating systems can map from one user identity to another, related user identity.

The ability to map between identities is essential to single sign-on enablement, as it allows you to separate the process of authentication from that of authorization. Identity mapping allows a user to log on to a system and be authenticated based on the credentials of one user identity and then be able to access a subsequent system or resource without having to supply new credentials. Instead, the authenticated identity is mapped to the appropriate identity for the requested system or resource. Not only does this make life easier for the user, who need not supply a second credential for logging on to the second system, but the authorizations he has for the second system are handled by the appropriate identity.

To implement single sign-on, you need to create certain EIM data within the EIM domain to define the relationships needed to appropriately map identities within your single sign-on environment. Doing so ensures that EIM can use that data to perform mapping lookup operations for single sign-on. You use EIM to create associations to define the relationships between user identities in your enterprise. You can create both identifier associations and policy associations to define these relationships depending on how you want identity mapping to work.

Identifier associations

Identifier associations allow you to define a one-to-one relationship between user identities through an EIM identifier defined for an individual. Identifier associations allow you to specifically control identity mapping for user identities and are especially useful when individuals have user identities with special authorities and other privileges. These associations dictate how the user identities are mapped from one to another. In a typical identity mapping situation, you create source associations for authenticating user identities and target associations to map the authenticating user identity to the appropriate user identities for authorized access to other systems and resources. For example, you might typically create the following identifier associations between an EIM identifier and corresponding user identities for a user:

A source association for the user's Kerberos principal, which is the identity with which the user logs into, and is authenticated to, the network.
Target associations for each user identity in the various user registries that the user accesses, such as Windows 2000 user profiles.

The following example illustrates how the identity mapping process works for identifier associations. The security administrator at Myco, Inc creates an EIM identifier (John Day) for an employee. This EIM identifier uniquely identifies John Day in the enterprise. The administrator then creates identifier associations between the John Day identifier and two user identities that he routinely uses in the enterprise. These associations define how the user identities are mapped. The administrator creates a source association for the Windows identity, which is a Kerberos principal, and a target association for an Windows 2000 user profile. These associations enable his Windows identity to be mapped to his Windows 2000 user profile.

John Day uses the appropriate user name and password to log on to his Windows 2000 workstation each morning. After he has logged on, he starts IBM® i Access for Windows to use Windows 2000 to access the Windows 2000 system. Because single sign-on is enabled, the identity mapping process uses his authenticated Windows identity to find the associated Windows 2000 user profile and transparently authenticates and authorizes him toWindows 2000.

In previous releases of IBM i single sign-on only supported mapping to one local user identity in Enterprise Identity Mapping (EIM) per system. Currently, single sign-on supports selecting from multiple local user identity mappings for the same system, using the IP address of the target system to select the correct local user identity mapping on that system.

Policy associations

Policy associations allow you to define a many-to-one relationship between a group of user identities in one or more user registries and a specific individual target user identity in another user registry. Typically, you use policy associations to map from a group of users who require the same level of authority for an application to a single user identity with the appropriate authority.

The following example illustrates how identity mapping works when you define policy associations. A number of workers in the Order Receiving Department of Myco, Inc. all need the same type of authorization to access a Web-based application that runs on Windows 2000 on the server. These users currently have user identities for this purpose in a single user registry named Order_app. The administrator creates a default registry policy association to map all the users in the Order_app user registry to a single Windows 2000 user profile. This Windows 2000 user profile, SYSUSER, provides the minimum authority needed for this group of users. Performing this single configuration step allows the administrator to ensure that all users of the Web-based application have the access they need with the proper level of authorization that they need. However, the administrator also benefits because it eliminates the need to create and maintain individual Windows 2000 user profiles for each user.