223 lines
16 KiB
HTML
223 lines
16 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE html
|
||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html lang="en-us" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow" />
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<meta name="DC.Type" content="concept" />
|
||
|
<meta name="DC.Title" content="Identifier associations" />
|
||
|
<meta name="abstract" content="Use this information to learn about how to use identifier associations to describe relationships between an Enterprise Identity Mapping (EIM) identifier and the user identities in user registries that represent that person. An identifier association creates a direct one-to-one mapping between an EIM identifier and a specific user identity. You can use identifier associations to indirectly define a relationship between user identities through the EIM identifier." />
|
||
|
<meta name="description" content="Use this information to learn about how to use identifier associations to describe relationships between an Enterprise Identity Mapping (EIM) identifier and the user identities in user registries that represent that person. An identifier association creates a direct one-to-one mapping between an EIM identifier and a specific user identity. You can use identifier associations to indirectly define a relationship between user identities through the EIM identifier." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzalveserverassoc.htm" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002, 2006" />
|
||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002, 2006" />
|
||
|
<meta name="DC.Format" content="XHTML" />
|
||
|
<meta name="DC.Identifier" content="rzalv_identifier_associations" />
|
||
|
<meta name="DC.Language" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
<title>Identifier associations</title>
|
||
|
</head>
|
||
|
<body id="rzalv_identifier_associations"><a name="rzalv_identifier_associations"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Identifier associations</h1>
|
||
|
<div><p>Use this information to learn about how to use identifier associations
|
||
|
to describe relationships between an Enterprise Identity Mapping (EIM) identifier
|
||
|
and the user identities in user registries that represent that person. An
|
||
|
identifier association creates a direct one-to-one mapping between an EIM
|
||
|
identifier and a specific user identity. You can use identifier associations
|
||
|
to indirectly define a relationship between user identities through the EIM
|
||
|
identifier.</p>
|
||
|
<p>An EIM identifier represents a specific person or entity in the enterprise.
|
||
|
An EIM identifier association describes a relationship between an EIM identifier
|
||
|
and a single user identity in a user registry that also represents that person.
|
||
|
When you create associations between an EIM identifier and all of a person's
|
||
|
or entity's user identities, you provide a single, complete understanding
|
||
|
of how that person or entity uses the resources in an enterprise. </p>
|
||
|
<p>User identities can be used for authentication, authorization, or both. <em>Authentication</em> is
|
||
|
the process of verifying that an entity or person who provides a user identity
|
||
|
has the right to assume that identity. Verification is often accomplished
|
||
|
by forcing the person who submits the user identity to provide secret or private
|
||
|
information associated with the user identity, such as a password. <em>Authorization</em> is
|
||
|
the process of ensuring that a properly authenticated user identity can only
|
||
|
perform functions or access resources for which the identity has been given
|
||
|
privileges. In the past, nearly all applications were forced to use the identities
|
||
|
in a single user registry for both authentication and authorization. By using
|
||
|
EIM lookup operations, applications now can use the identities in one user
|
||
|
registry for authentication while they use associated user identities in a
|
||
|
different user registry for authorization.</p>
|
||
|
<p>The EIM identifier provides an indirect association between those user
|
||
|
identities, which allows applications to find a different user identity for
|
||
|
an EIM identifier based on a known user identity. EIM provides APIs that allow
|
||
|
applications to find an unknown user identity in a specific (target) user
|
||
|
registry by providing a known user identity in some other (source) user registry.
|
||
|
This process is called identity mapping. </p>
|
||
|
<p>In EIM, an administrator can define three different types of associations
|
||
|
to describe the relationship between an EIM identifier and a user identity.
|
||
|
Identifier associations can be any of the following types: source, target,
|
||
|
or administrative. The type of association that you create is based on how
|
||
|
the user identity is used. For example, you create source and target associations
|
||
|
for those user identities that you want to participate in mapping <a href="rzalveservereimmaplookup.htm#rzalveservereimmaplookup">lookup
|
||
|
operations</a>. Typically, if a user identity is used for authentication,
|
||
|
you create a source association for it. You then create target associations
|
||
|
for those user identities that are used for authorization. </p>
|
||
|
<p>Before you can create an identifier association, you first must create
|
||
|
the appropriate EIM identifier and the appropriate EIM registry definition
|
||
|
for the user registry that contains the associated user identity. An association
|
||
|
defines a relationship between an EIM identifier and a user identity by using
|
||
|
the following information: </p>
|
||
|
<ul><li>EIM identifier name</li>
|
||
|
<li>User identity name</li>
|
||
|
<li>EIM registry definition name</li>
|
||
|
<li>Association type</li>
|
||
|
<li>Optional: lookup information to further identity the target user identity
|
||
|
in a target association. </li>
|
||
|
</ul>
|
||
|
<div class="section"><h4 class="sectiontitle">Source association</h4><p>A source association allows the
|
||
|
user identity to be used as the source in an EIM lookup operation to find
|
||
|
a different user identity that is associated with the same EIM identifier. </p>
|
||
|
<p>When
|
||
|
a user identity is used for <em>authentication</em>, that user identity should
|
||
|
have a source association with an EIM identifier. For example, you might create
|
||
|
a source association for a Kerberos principal because this form of user identity
|
||
|
is used for authentication. To ensure successful mapping lookup operations
|
||
|
for EIM identifiers, source and target associations must be used together
|
||
|
for a single EIM identifier. </p>
|
||
|
</div>
|
||
|
<div class="section"><h4 class="sectiontitle">Target association</h4><p>A target association allows the
|
||
|
user identity to be returned as the result of an EIM lookup operation. User
|
||
|
identities that represent end users normally need a target association only.</p>
|
||
|
<p>When
|
||
|
a user identity is used for <em>authorization</em> rather than for authentication,
|
||
|
that user identity should have a target association with an EIM identifier.
|
||
|
For example, you might create a target association for an i5/OS™ user profile
|
||
|
because this form of user identity determines what resources and privileges
|
||
|
the user has on a specific iSeries™ system. To ensure successful mapping lookup
|
||
|
operations for EIM identifiers, source and target associations must be used
|
||
|
together for a single EIM identifier.</p>
|
||
|
</div>
|
||
|
<div class="section"><h4 class="sectiontitle">Source and target association relationship</h4><p>To ensure
|
||
|
successful mapping lookup operations, you need to create at least one source
|
||
|
and one or more target associations for a single EIM identifier. Typically,
|
||
|
you create a target association for each user identity in a user registry
|
||
|
that the person can use for authorization to the system or application to
|
||
|
which the user registry corresponds.</p>
|
||
|
<p>For example, users in your enterprise
|
||
|
normally logon and authenticate to Windows<sup>®</sup> desktops and access an iSeries server
|
||
|
to perform a number of tasks. Users logon to their desktops by using a Kerberos
|
||
|
principal and logon to the iSeries server by using an i5/OS user profile. You want to create
|
||
|
a single signon environment in which users authenticate to their desktops
|
||
|
by using their Kerberos principal and no longer have to manually authenticate
|
||
|
to the iSeries server. </p>
|
||
|
<p>To
|
||
|
accomplish this goal, you create a source association for the Kerberos principal
|
||
|
for each user and that user's EIM identifier. You then create a target association
|
||
|
for the i5/OS user
|
||
|
profile for each user and that user's EIM identifier. This configuration ensures
|
||
|
that i5/OS can
|
||
|
perform a mapping lookup operation to determine the correct user profile
|
||
|
needed for a user that accesses the iSeries server after he has authenticated
|
||
|
to his desktop. i5/OS then
|
||
|
allows the user access to resources on the server based on the appropriate
|
||
|
user profile without requiring the user to manually authenticate to the server.</p>
|
||
|
<p>Figure
|
||
|
6 illustrates another example in which an EIM administrator creates two associations,
|
||
|
a source association and a target association, for the EIM identifier <samp class="codeph">John
|
||
|
Day</samp> to define the relationship between this identifier and two associated
|
||
|
user identities. The administrator creates a source association for <samp class="codeph">jsday</samp>,
|
||
|
a Kerberos principal in the <samp class="codeph">Desktops</samp> user registry. The administrator
|
||
|
also creates a target association for <samp class="codeph">JOHND</samp>, the i5/OS user profile
|
||
|
in the <samp class="codeph">System_C</samp> user registry. These associations provide
|
||
|
a means for applications to obtain an unknown user identity (the target, <samp class="codeph">JOHND</samp>)
|
||
|
based on a known user identity (the source, <samp class="codeph">jsday</samp>) as part
|
||
|
of an EIM lookup operation. </p>
|
||
|
<p><strong>Figure 6:</strong> EIM target and source
|
||
|
associations for the EIM identifier <samp class="codeph">John Day</samp></p>
|
||
|
<p><br /><img src="rzalv513.gif" alt="Example of EIM target and source associations for the EIM identifier John Day" /><br /></p>
|
||
|
<p><img src="./delta.gif" alt="Start of change" />To extend
|
||
|
the example, suppose the EIM administrator realizes that John Day uses the
|
||
|
same i5/OS user
|
||
|
profile, <samp class="codeph">jsd1</samp>, on five different systems. In this situation,
|
||
|
the administrator must create six associations for the EIM identifier <samp class="codeph">John
|
||
|
Day</samp> to define the relationship between this identifier and an associated
|
||
|
user identity in five user registries: a source association for <samp class="codeph">johnday</samp>,
|
||
|
a Kerberos principal in <samp class="codeph">Desktop_A</samp> user registry and five
|
||
|
target associations for <samp class="codeph">jsd1</samp>, the i5/OS user profile in the five user registries: <samp class="codeph">System_B,
|
||
|
System_C, System_D, System_E, and System_F</samp>. To reduce the amount
|
||
|
of work that he must perform to configure EIM mapping, the EIM administrator
|
||
|
creates a <a href="rzalvgroupregistrydef.htm">group registry definition</a>.
|
||
|
Members of the group registry definition include the registry definition names
|
||
|
of <samp class="codeph">System_B, System_C, System_D, System_E, and System_F</samp>.
|
||
|
Grouping members together enables the administrator to create a single target
|
||
|
association to the group registry definition and user identity, rather than
|
||
|
multiple associations to individual registry definition names. The source
|
||
|
and target associations provide a means for applications to obtain an unknown
|
||
|
user identity (the target, <samp class="codeph">jsd1</samp>) in the five user registries
|
||
|
represented as members of the group registry definition based on a known user
|
||
|
identity (the source, <samp class="codeph">johnday</samp>) as part of an EIM lookup operation.<img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
<div class="p">For
|
||
|
some users, it may be necessary to create both a target and a source association
|
||
|
for the same user identity. This is required when an individual uses a single
|
||
|
system as both a client and a server or for individuals who act as administrators. <div class="note"><span class="notetitle">Note:</span> User
|
||
|
identities that represent typical users normally need a target association
|
||
|
only.</div>
|
||
|
</div>
|
||
|
<p><img src="./delta.gif" alt="Start of change" />For some users, it may be necessary to create
|
||
|
both a target and a source association for the same user identity. This is
|
||
|
required when an individual uses a single system as both a client and a server
|
||
|
or for individuals who act as administrators. <img src="./deltaend.gif" alt="End of change" /></p>
|
||
|
<p>For example, an administrator
|
||
|
uses the Management Central function in iSeries Navigator to manage a central
|
||
|
system and several endpoint systems. The administrator performs various functions
|
||
|
and these functions can originate on the central system or on an endpoint
|
||
|
system. In this situation you would create both a source association and a
|
||
|
target association for each of the administrator's user identities on each
|
||
|
of the systems. This ensures that, whichever system the administrator uses
|
||
|
to originate access to one of the other systems, the user identity used to
|
||
|
originate access to the other system can be mapped to the appropriate user
|
||
|
identity for the subsequent system the administrator accesses.</p>
|
||
|
</div>
|
||
|
<div class="section"><h4 class="sectiontitle">Administrative association</h4><p>An administrative association
|
||
|
for an EIM identifier is typically used to show that the person or entity
|
||
|
represented by the EIM identifier owns a user identity that requires special
|
||
|
considerations for a specified system. This type of association can be used,
|
||
|
for example, with highly sensitive user registries.</p>
|
||
|
<p>Due to the special
|
||
|
nature of administrative associations, this type of association can not participate
|
||
|
in EIM mapping lookup operations. Consequently, an EIM lookup operation that
|
||
|
supplies a source user identity with an administrative association returns
|
||
|
no results. Similarly, a user identity with an administrative association
|
||
|
is never returned as the result of an EIM lookup operation.</p>
|
||
|
<p>Figure 7
|
||
|
shows an example of an administrative association. In this example, an employee
|
||
|
named John Day has a user identity of <samp class="codeph">John_Day</samp> on System
|
||
|
A and a user identity of <samp class="codeph">JDay</samp> on System B, which is a highly
|
||
|
secure system. The system administrator wants to ensure that users authenticate
|
||
|
to System B by using only the local user registry of this system. The administrator
|
||
|
does not want to allow an application to authenticate <samp class="codeph">John Day</samp> to
|
||
|
the system by using some other authentication mechanism. By using an administrative
|
||
|
association for the <samp class="codeph">JDay</samp> user identity on System B, the EIM
|
||
|
administrator can see that John Day owns an account on System B, but EIM does
|
||
|
not return information about the <samp class="codeph">JDay</samp> identity in EIM lookup
|
||
|
operations. Even if applications exist on this system that use EIM lookup
|
||
|
operations, they cannot find user identities that have administrative associations.</p>
|
||
|
<p><strong>Figure
|
||
|
7:</strong> EIM administrative association for the EIM identifier <samp class="codeph">John
|
||
|
Day</samp></p>
|
||
|
<p><br /><img src="rzalv514.gif" alt="Example of EIM administrative association for the EIM identifier John Day" /><br /></p>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalveserverassoc.htm" title="This information explains how you can use associating identities in different user registries.">EIM associations</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|