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:
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.
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.
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 you need to 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 you need to describe a complete picture of how you plan to implement identity mapping.
| 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) |
| 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 |
| 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 |
| 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 |