To use Enterprise Identity Mapping (EIM) to map the user identity in one user registry to an equivalent user identity in another user registry, both user registries must be defined to EIM. You must create an EIM registry definition for each application or operating system user registry that will participate in the EIM domain. User registries can represent operating system registries such as Resource Access Control Facility (RACF® ) or i5/OS™, a distributed registry such as Kerberos, or a subset of a system registry that is used exclusively by an application.
An EIM domain can contain registry definitions for user registries that exist on any platform. For example, a domain managed by a domain controller on i5/OS might contain registry definitions for non-i5/OS platforms (such as an AIX® registry). Although you can define any user registry to an EIM domain, you must define user registries for those applications and operating systems that are EIM-enabled.
You can name an EIM registry definition anything that you like as long as the name is unique in the EIM domain For example, you could name the EIM registry definition based on the name of the system that hosts the user registry. If this is not sufficient to distinguish the registry definition from similar definitions, you could use a period (.) or an underscore (_) to add the type of user registry that you are defining. Regardless of the criteria you choose to use, you should consider developing a naming convention for your EIM registry definitions. Doing so ensures that the definition names are consistent throughout the domain and are adequately descriptive of the type and instance of the user registry defined and how it is used. For example, you could choose the name of each registry definition by using a combination of the application or operating system name that uses the registry and the user registry's physical location in your enterprise.
An application that is written to use EIM may specify either a source registry alias or a target registry alias, or aliases for both. When you create EIM registry definitions you need to check the documentation for your applications to determine whether you need to specify one or more aliases for registry definitions. When you assign these aliases to the appropriate registry definitions, the application can perform an alias lookup to find the EIM registry definition or definitions that match the aliases in the application.
You may find the following sample portion of the planning work sheet helpful as a guide to use for recording information about participating user registries. You can use the actual work sheet to specify a registry definition name for each user registry, to specify whether it uses an alias, and to describe the user registry location and use. The installation and configuration documentation for the application will provide some of the information that you need for the worksheet.
| Registry definition name | User registry type | Registry definition alias | Registry description |
|---|---|---|---|
| System_C | i5/OS system user registry | See application documentation | Main system user registry for i5/OS on System C |
| System_A_WAS | WebSphere® LTPA | app_23_alias_source | WebSphere LTPA user registry on System A |
| System_B | Linux® | See application documentation | Linux user registry on System B |
| 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 |
| System_D | Kerberos user registry | app_xx_alias_source | legal.mydomain.com Kerberos realm |
| System_4 | Windows® 2000 user registry | See application documentation | Human resources application user registry on System 4 |
After you complete this section of the planning worksheet, you should develop your identity mapping plan to determine whether to use identifier associations, policy associations, or both types of associations to create the mappings that you need for the user identities in each defined user registry.