Lookup operation examples: Example 4

Edit online

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 IBM® i 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 IBM i 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 IBM i user profile named JOHND in the Group_1 registry.

This configuration allows a mapping lookup operation to map from the Kerberos principal to the IBM i 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:

  1. The user (jday) logs on and authenticates to Windows on Desktop_A.
  2. The user opens a 5250 emulator session in IBM i Access Client Solutions to access data on System_B.
  3. IBM i 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.
  4. The EIM lookup operation checks whether mapping lookups are enabled for the source registry (Desktop_A) and target registry (System_B).
  5. 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.
  6. The lookup operation uses the matching source association to determine the appropriate EIM identifier name, which is John Day.
  7. 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.)
  8. The lookup operation checks to see if the source registry (Desktop_A) is a member of any group registry definitions. (It is not.)
  9. 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.
  10. 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.
  11. 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 IBM i 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.