ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzalv_5.4.0.1/rzalv_identifier_associations.htm

223 lines
16 KiB
HTML
Raw Permalink Normal View History

2024-04-02 14:02:31 +00:00
<?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>