Use this example to learn how the search flow works for a lookup
operation that returns a target user identity in a user registry that is a
member of a group registry definition.
An administrator wants to map a Windows® user to an i5/OS™ user profile.
Kerberos is the authentication method that Windows uses and the name of the Kerberos
registry as the administrator defined it in Enterprise Identity Mapping (EIM)
is Desktop_A. The user identity that the administrator wants
to map from is a Kerberos principal named jday. The name
of the i5/OS registry
definition as the administrator defined it in EIM is Group_1 and
the user identity that the adminstrator wants to map to is a user profile
named JOHND which exists in three individual registries: System_B,
System_C, and System_D. Each of the individual registries is a member
of the Group_1 group registry definition.
The administrator creates an EIM identifier named John Day. He then adds
two associations to this EIM identifier:
- A source association for the Kerberos principal named jday in
the Desktop_A registry.
- A target association for the i5/OS user profile named JOHND in
the Group_1 registry.
This configuration allows a mapping lookup operation to map from the Kerberos
principal to the i5/OS user
profile as follows:
Source user identity and registry |
---> |
EIM Identifier |
---> |
Target user identity |
jday in Desktop_A registry |
---> |
John Day |
---> |
JOHND (in Group_1 group
registry definition) |
The lookup operation search flows in this manner:
- The user (jday) logs on and authenticates to Windows on Desktop_A.
- The user opens iSeries™ Navigator to access data on System_B.
- i5/OS uses
an EIM API to perform an EIM lookup operation with a source user identity
of jday, a source registry of Desktop_A,
and a target registry of System_B.
- The EIM lookup operation checks whether mapping lookups are enabled for
the source registry (Desktop_A) and target registry (System_B).
- The lookup operation checks for a specific individual source association
that matches the supplied source user identity of jday in
a source registry of Desktop_A.
- The lookup operation uses the matching source association to determine
the appropriate EIM identifier name, which is John Day.
- The lookup operation uses this EIM identifier name to search for an individual
target association for the EIM identifier that matches the specified target
EIM registry definition name of System_B. (There is none.)
- The lookup operation checks to see if the source registry (Desktop_A)
is a member of any group registry definitions. (It is not.)
- The lookup operation checks to see if the target registry (System_B)
is a member of any group registry definitions. It is a member of the Group_1 group
registry definition.
- The lookup operation uses the EIM identifier name to search for an individual
target association for the EIM identifier that matches the specified target
EIM registry definition name of Group_1.
- There is such an individual target association and the lookup operation
returns the target user identity of JOHND as defined in the
target association.
Note: In some cases, the EIM lookup operation returns
ambiguous
results when more than one target user identity matches the specified
lookup operation criteria. Because EIM cannot return a single target user
identity, EIM-enabled applications, including i5/OS applications and products, that are
not designed to handle these
ambiguous
results may fail or give unexpected results. You may need to take action
to resolve this situation. For example, you may need to either change your
EIM configuration or define
lookup information for
each target user identity to prevent multiple matching target user identities.
You can
test a mapping to determine
whether the changes you make work as expected.