Enterprise Identity Mapping overview

 

Use this information to learn about the problems that Enterprise Identity Mapping (EIM) can help you solve, current industry approaches to these problems, and why the EIM approach is a better solution.

Today's network environments are made up of a complex group of systems and applications, resulting in the need to manage multiple user registries. Dealing with multiple user registries quickly grows into a large administrative problem that affects users, administrators, and application developers. Consequently, many companies are struggling to securely manage authentication and authorization for systems and applications. EIM is an IBM®

e(logo)server infrastructure technology that allows administrators and application developers to address this problem more easily and inexpensively than previously possible.

The following information describes the problems, outlines current industry approaches, and explains why the EIM approach is better.

 

The problem of managing multiple user registries

Many administrators manage networks that include different systems and servers, each with a unique way of managing users through various user registries. In these complex networks, administrators are responsible for managing each user's identities and passwords across multiple systems. Additionally, administrators often must synchronize these identities and passwords and users are burdened with remembering multiple identities and passwords and with keeping them in sync. The user and administrator overhead in this environment is excessive. Consequently, administrators often spend valuable time troubleshooting failed logon attempts and resetting forgotten passwords instead of managing the enterprise.

The problem of managing multiple user registries also affects application developers who want to provide multiple-tier or heterogeneous applications. These developers understand that customers have important business data spread across many different types of systems, with each system possessing its own user registries. Consequently, developers must create proprietary user registries and associated security semantics for their applications. Although this solves the problem for the application developer, it increases the overhead for users and administrators.

 

Current approaches

Several current industry approaches for solving the problem of managing multiple user registries are available, but they all provide incomplete solutions. For example, Lightweight Directory Access Protocol (LDAP) provides a distributed user registry solution. However, using LDAP (or other popular solutions such as Microsoft® Passport) means that administrators must manage yet another user registry and security semantics or must replace existing applications that are built to use those registries.

Using this type of solution, administrators must manage multiple security mechanisms for individual resources, thereby increasing administrative overhead and potentially increasing the likelihood of security exposures. When multiple mechanisms support a single resource, the chances of changing the authority through one mechanism and forgetting to change the authority for one or more of the other mechanisms is much higher. For example, a security exposure can result when a user is appropriately denied access through one interface, but allowed access through one or more other interfaces.

After completing this work, administrators find that they have not completely solved the problem. Generally, enterprises have invested too much money in current user registries and in their associated security semantics to make using this type of solution practical. Creating another user registry and associated security semantics solves the problem for the application provider, but not the problems for users or administrators.

One other possible solution is to use a single signon approach. Several products are available that allow administrators to manage files that contain all of a user's identities and passwords. However, this approach has several weaknesses:

Despite these weaknesses, some enterprises have chosen to adopt these approaches because they provide some relief for the multiple user registry problems.

 

The EIM approach

EIM offers a new approach for inexpensively building solutions to more easily manage multiple user registries and user identities in a multiple tier, heterogeneous application environment. EIM is an architecture for describing the relationships between individuals or entities (such as file servers and print servers) in the enterprise and the many identities that represent them within an enterprise. In addition, EIM provides a set of APIs that allow applications to ask questions about these relationships.

For example, given a person's user identity in one user registry, you can determine which user identity in another user registry represents that same person. If the user has authenticated with one user identity and you can map that user identity to the appropriate identity in another user registry, the user does not need to provide credentials for authentication again. You know who the user is and only need to know which user identity represents that user in another user registry. Therefore, EIM provides a generalized identity mapping function for the enterprise.

EIM allows one-to-many mappings (in other words, a single user with more than one user identity in a single user registry). However, the administrator does not need to have specific individual mappings for all user identities in a user registry. EIM also allows many-to-one mappings (in other words, multiple users mapped to a single user identity in a single user registry).

The ability to map between a user's identities in different user registries provides many benefits. Primarily, it means that applications may have the flexibility of using one user registry for authentication while using an entirely different user registry for authorization. For example, an administrator could map a Windows® user identity in a Kerberos registry to an i5/OS® user profile in a different user registry to access i5/OS resources to which the i5/OS user profile is authorized.

EIM is an open architecture that administrators may use to represent identity mapping relationships for any registry. It does not require copying existing data to a new repository and trying to keep both copies synchronized. The only new data that EIM introduces is the relationship information. EIM stores this data in an LDAP directory, which provides the flexibility of managing the data in one place and having replicas wherever the information is used. Ultimately, EIM gives enterprises and application developers the flexibility to easily work in a wider range of environments with less cost than would be possible without this support.

EIM, used in conjunction with network authentication service, the i5/OS implementation of Kerberos, provides a single signon solution. Applications can be written that use GSS APIs and EIM to accept Kerberos tickets and map to another, associated user identity in a different user registry. The association between user identities that provides this identity mapping can be accomplished by creating identifier associations that indirectly associate one user identity with another through an EIM identifier or by creating policy associations that directly associate one user identity in a group with a single specific user identity.

The use of identity mapping requires that administrators do the following:

  1. Configure an EIM domain in the network. You can use the System i™ EIM Configuration wizard to create a domain controller for the domain and configure access to the domain. When you use the wizard you can choose to create a new EIM domain and create a domain controller on the local system or a remote system. Or, if an EIM domain already exists, you can choose to participate in an existing EIM domain.

  2. Determine which users defined to the directory server that hosts the EIM domain controller are allowed to manage or access specific information in the EIM domain and assign them to appropriate EIM access control groups.

  3. Create EIM registry definitions for those user registries that will participate in the EIM domain. Although you can define any user registry to an EIM domain, define user registries for those applications and operating systems that are EIM-enabled.

  4. Based on your EIM implementation needs, determine which of the following tasks to perform to complete your EIM configuration:

    • Create EIM identifiers for each unique user in the domain and create identifier associations for them.

    • Create policy associations.

    • Create a combination of these.

 

Parent topic:

Enterprise Identity Mapping (EIM)

 

Related information


Single Signon Information Center Topic