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.
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.
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 IBM® i user profile because this form of user identity determines what resources and privileges the user has on a specific IBM i platform. 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 IBM i platform to perform a number of tasks. Users logon to their desktops by using a Kerberos principal and logon to the IBM i platform by using an IBM i user profile. You want to create a single sign-on environment in which users authenticate to their desktops by using their Kerberos principal and no longer have to manually authenticate to the IBM i platform.
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 IBM i user profile for each user and that user's EIM identifier. This configuration ensures that IBM i can perform a mapping lookup operation to determine the correct user profile needed for a user that accesses the IBM i platform after he has authenticated to his desktop. IBM i 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.
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 IBM i user profile in the
registry. These associations provide a means for applications to obtain
an unknown user identity (the target,
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
To extend the
example, suppose the EIM administrator realizes that John Day uses
the same IBM i user
jsd1, on five different systems. In this
situation, the administrator must create six associations for the
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
Desktop_A user registry and five target
jsd1, the IBM i 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
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,
in the five user registries represented as members of the group registry
definition based on a known user identity (the source,
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 manages 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.
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.
7 shows an example of an administrative association. In this example,
an employee named John Day has a user identity of
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
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