Planning Enterprise Identity Mapping associations
Associations are entries that you create in an Enterprise Identity Mapping (EIM) domain to define a relationship between user identities in different user registries.
You can create one of two types of associations in EIM: identifier associations to define one-to-one mappings and policy associations to define many-to-one mappings. You can use policy associations instead of, or in conjunction with, identifier associations.
The specific types of associations that you choose to create depends on how a user uses a particular user identity, as well as your overall identity mapping plan.
You can create any of the following types of identifier associations:
- Target associations
You define target associations for users that normally only access this system as a server from some other client system. This type of association is used when an application performs mapping lookup operations.
- Source associations
You define source associations when the user identity is the first one that a user provides to sign on to the system or network. This type of association is used when an application performs mapping lookup operations.
- Administrative associations
You define administrative associations when you want to be able to track the fact that the user identity belongs to a specific user, but do not want the user identity to be available to mapping lookup operations. You can use this type of association to track all the user identities that a person uses in the enterprise.
A policy association always defines a target association.
It is possible for a single registry definition to have more than one type of association depending on how the user registry that it refers to is used. Although there are no limits to the numbers of, or the combinations of, associations that you can define, keep the number to a minimum to simplify the administration of your EIM domain.
Typically, an application will provide guidance on which registry definitions it expects for source and target registries, but not the association types. Each end user of the application needs to be mapped to the application by at least one association. This association can be a one-to-one mapping between their unique EIM identifier and a user identity in the required target registry or a many-to-one mapping between a source registry of which the user identity is a member and the required target registry. Which type of association you use depends on your identity mapping requirements and the criteria the application provides.
Previously as part of the planning process, you completed two planning work sheets for the user identities in your organization with information about the EIM identifiers and EIM registry definitions that you need. Now bring this information together by specifying the types of associations you want to use to map the users identities in your enterprise. You need to determine whether to define a policy association for a particular application and its registry of users, or to define specific identifier associations (source, target, or administrative) for each user identity in the system or application registry. You can do this by recording information about the required association types in both the registry definition planning work sheet and in the corresponding rows of each associations work sheet.
To complete your identity mapping plan, you can use the following example work sheets as a guide to help you record the association information that describe a complete picture of how you plan to implement identity mapping.
Table 1. Example EIM registry definition information planning work sheet Registry definition name User registry type Registry definition alias Registry description Association types System_C i5/OS® system user registry See application documentation Main system user registry for i5/OS on System C Target System_A_WAS WebSphere® LTPA app_23_alias_source WebSphere LTPA user registry on System A Primarily source System_B Linux® See application documentation Linux user registry on System B Source and target System_A i5/OS system user registry app_23_alias_target app_xx_alias_target Main system user registry for i5/OS on System A Target System_D Kerberos user registry app_xx_alias_source legal.mydomain.com Kerberos realm Source System_4 Windows® 2000 user registry See application documentation Human resources application user registry on System 4 Administrative order.mydomain.com Windows 2000 user registry Main logon registry for order department employees Default registry policy (source registry) System_A_order_app Order department application Application specific registry for order updates Default registry policy (target registry) System_C_order_app Order department application Application specific registry for order updates Default registry policy (target registry)
Table 2. Example EIM identifier planning work sheet Unique identifier name Identifier or user identity description Identifier alias John S Day Human resources manager app_23_admin John J Day Legal Department app_xx_admin Sharon A. Jones Order Department Administrator
Table 3. Example identifier association planning work sheet Identifier unique name: _____John S Day______ User registry User identity Association types System A WAS on System A johnday Source Linux on System B jsd1 Source and target i5/OS on System C JOHND Target Registry 4 on Windows 2000 human resources system JDAY Administrative
Table 4. Example planning work sheet for policy associations Policy association type Source user registry Target user registry User identity Description Default registry order.mydomain.com System_A_order_app SYSUSERA Maps authenticated Windows order department user to appropriate application user identity Default registry order.mydomain.com System_C_order_app SYSUSERB Maps authenticated Windows order department user to appropriate application user identity
Parent topic:
Developing an identity mapping plan