Use this information to learn about how to use identifier associations to describe relationships between an Enterprise Identity Mapping (EIM) identifier and the user identities in user registries that represent that person. An identifier association creates a direct one-to-one mapping between an EIM identifier and a specific user identity. You can use identifier associations to indirectly define a relationship between user identities through the EIM identifier.
An EIM identifier represents a specific person or entity in the enterprise. An EIM identifier association describes a relationship between an EIM identifier and a single user identity in a user registry that also represents that person. When you create associations between an EIM identifier and all of a person's or entity's user identities, you provide a single, complete understanding of how that person or entity uses the resources in an enterprise.
User identities can be used for authentication, authorization, or both. Authentication is the process of verifying that an entity or person who provides a user identity has the right to assume that identity. Verification is often accomplished by forcing the person who submits the user identity to provide secret or private information associated with the user identity, such as a password. Authorization is the process of ensuring that a properly authenticated user identity can only perform functions or access resources for which the identity has been given privileges. In the past, nearly all applications were forced to use the identities in a single user registry for both authentication and authorization. By using EIM lookup operations, applications now can use the identities in one user registry for authentication while they use associated user identities in a different user registry for authorization.
The EIM identifier provides an indirect association between those user identities, which allows applications to find a different user identity for an EIM identifier based on a known user identity. EIM provides APIs that allow applications to find an unknown user identity in a specific (target) user registry by providing a known user identity in some other (source) user registry. This process is called identity mapping.
In EIM, an administrator can define three different types of associations to describe the relationship between an EIM identifier and a user identity. Identifier associations can be any of the following types: source, target, or administrative. The type of association that you create is based on how the user identity is used. For example, you create source and target associations for those user identities that you want to participate in mapping lookup operations. Typically, if a user identity is used for authentication, you create a source association for it. You then create target associations for those user identities that are used for authorization.
Before you can create an identifier association, you first must create the appropriate EIM identifier and the appropriate EIM registry definition for the user registry that contains the associated user identity. An association defines a relationship between an EIM identifier and a user identity by using the following information:
- EIM identifier name
- User identity name
- EIM registry definition name
- Association type
- Optional: lookup information to further identity the target user identity in a target association.
Source association
A source association allows the user identity to be used as the source in an EIM lookup operation to find a different user identity that is associated with the same EIM identifier.
When a user identity is used for authentication, that user identity should have a source association with an EIM identifier. For example, you might create a source association for a Kerberos principal because this form of user identity is used for authentication. To ensure successful mapping lookup operations for EIM identifiers, source and target associations must be used together for a single EIM identifier.
Target association
A target association allows the user identity to be returned as the result of an EIM lookup operation. User identities that represent end users normally need a target association only.
When a user identity is used for authorization rather than for authentication, that user identity should have a target association with an EIM identifier. For example, you might create a target association for an i5/OS™ user profile because this form of user identity determines what resources and privileges the user has on a specific iSeries™ system. To ensure successful mapping lookup operations for EIM identifiers, source and target associations must be used together for a single EIM identifier.
Source and target association relationship
To ensure successful mapping lookup operations, you need to create at least one source and one or more target associations for a single EIM identifier. Typically, you create a target association for each user identity in a user registry that the person can use for authorization to the system or application to which the user registry corresponds.
For example, users in your enterprise normally logon and authenticate to Windows® desktops and access an iSeries server to perform a number of tasks. Users logon to their desktops by using a Kerberos principal and logon to the iSeries server by using an i5/OS user profile. You want to create a single signon environment in which users authenticate to their desktops by using their Kerberos principal and no longer have to manually authenticate to the iSeries server.
To accomplish this goal, you create a source association for the Kerberos principal for each user and that user's EIM identifier. You then create a target association for the i5/OS user profile for each user and that user's EIM identifier. This configuration ensures that i5/OS can perform a mapping lookup operation to determine the correct user profile needed for a user that accesses the iSeries server after he has authenticated to his desktop. i5/OS then allows the user access to resources on the server based on the appropriate user profile without requiring the user to manually authenticate to the server.
Figure 6 illustrates another example in which an EIM administrator creates two associations, a source association and a target association, for the EIM identifier John Day to define the relationship between this identifier and two associated user identities. The administrator creates a source association for jsday, a Kerberos principal in the Desktops user registry. The administrator also creates a target association for JOHND, the i5/OS user profile in the System_C user registry. These associations provide a means for applications to obtain an unknown user identity (the target, JOHND) based on a known user identity (the source, jsday) as part of an EIM lookup operation.
Figure 6: EIM target and source associations for the EIM identifier John Day
To extend
the example, suppose the EIM administrator realizes that John Day uses the
same i5/OS user
profile, jsd1, on five different systems. In this situation,
the administrator must create six associations for the EIM identifier John
Day to define the relationship between this identifier and an associated
user identity in five user registries: a source association for johnday,
a Kerberos principal in Desktop_A user registry and five
target associations for jsd1, the i5/OS user profile in the five user registries: System_B,
System_C, System_D, System_E, and System_F. To reduce the amount
of work that he must perform to configure EIM mapping, the EIM administrator
creates a group registry definition.
Members of the group registry definition include the registry definition names
of System_B, System_C, System_D, System_E, and System_F.
Grouping members together enables the administrator to create a single target
association to the group registry definition and user identity, rather than
multiple associations to individual registry definition names. The source
and target associations provide a means for applications to obtain an unknown
user identity (the target, jsd1) in the five user registries
represented as members of the group registry definition based on a known user
identity (the source, johnday) as part of an EIM lookup operation.
For some users, it may be necessary to create
both a target and a source association for the same user identity. This is
required when an individual uses a single system as both a client and a server
or for individuals who act as administrators.
For example, an administrator uses the Management Central function in iSeries Navigator to manage a central system and several endpoint systems. The administrator performs various functions and these functions can originate on the central system or on an endpoint system. In this situation you would create both a source association and a target association for each of the administrator's user identities on each of the systems. This ensures that, whichever system the administrator uses to originate access to one of the other systems, the user identity used to originate access to the other system can be mapped to the appropriate user identity for the subsequent system the administrator accesses.
Administrative association
An administrative association for an EIM identifier is typically used to show that the person or entity represented by the EIM identifier owns a user identity that requires special considerations for a specified system. This type of association can be used, for example, with highly sensitive user registries.
Due to the special nature of administrative associations, this type of association can not participate in EIM mapping lookup operations. Consequently, an EIM lookup operation that supplies a source user identity with an administrative association returns no results. Similarly, a user identity with an administrative association is never returned as the result of an EIM lookup operation.
Figure 7 shows an example of an administrative association. In this example, an employee named John Day has a user identity of John_Day on System A and a user identity of JDay on System B, which is a highly secure system. The system administrator wants to ensure that users authenticate to System B by using only the local user registry of this system. The administrator does not want to allow an application to authenticate John Day to the system by using some other authentication mechanism. By using an administrative association for the JDay user identity on System B, the EIM administrator can see that John Day owns an account on System B, but EIM does not return information about the JDay identity in EIM lookup operations. Even if applications exist on this system that use EIM lookup operations, they cannot find user identities that have administrative associations.
Figure 7: EIM administrative association for the EIM identifier John Day
