Developing an Enterprise Identity Mapping registry definition naming plan

 

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, 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 check the documentation for your applications to determine whether 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.

Table 1. Sample EIM registry definition information planning work sheet

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

Association types for each registry will be determined later in the planning process.

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.

 

Parent topic:

Planning Enterprise Identity Mapping for eServer