127 lines
8.7 KiB
HTML
127 lines
8.7 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="Identity mapping" />
|
||
|
|
<meta name="abstract" content="Use this information to learn how the identity mapping process works within the single signon environment." />
|
||
|
|
<meta name="description" content="Use this information to learn how the identity mapping process works within the single signon environment." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamzconcepts.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzalv/rzalveservereimid.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzalv/rzalveserverregistry.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="../rzalv/rzalveserverassoc.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2000, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzamzidentitymapping" />
|
||
|
|
<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>Identity mapping</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzamzidentitymapping"><a name="rzamzidentitymapping"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Identity mapping</h1>
|
||
|
|
<div><p>Use this information to learn how the identity mapping process
|
||
|
|
works within the single signon environment.</p>
|
||
|
|
<p>Identity mapping is the process of using defined relationships between
|
||
|
|
user identities in an enterprise such that applications and operating systems
|
||
|
|
can map from one user identity to another, related user identity. The ability
|
||
|
|
to map between identities is essential to single signon enablement, as it
|
||
|
|
allows you to separate the process of authentication from that of authorization.
|
||
|
|
Identity mapping allows a user to log on to a system and be authenticated
|
||
|
|
based on the credentials of one user identity and then be able to access a
|
||
|
|
subsequent system or resource without having to supply new credentials. Instead,
|
||
|
|
the authenticated identity is mapped to the appropriate identity for the requested
|
||
|
|
system or resource. Not only does this make life easier for the user, who
|
||
|
|
need not supply a second credential for logging on to the second system, but
|
||
|
|
the authorizations he has for the second system are handled by the appropriate
|
||
|
|
identity.</p>
|
||
|
|
<p>To implement single signon, you need to create certain EIM data within
|
||
|
|
the <a href="../rzalv/rzalveserverdomain.htm">EIM
|
||
|
|
domain</a> to define the relationships needed to appropriately map identities
|
||
|
|
within your single signon environment. Doing so ensures that EIM can use that
|
||
|
|
data to perform <a href="../rzalv/rzalveservereimmaplookup.htm">mapping lookup operations</a> for single signon. You use
|
||
|
|
EIM to create associations to define the relationships between user identities
|
||
|
|
in your enterprise. You can create both identifier associations and policy
|
||
|
|
associations to define these relationships depending on how you want identity
|
||
|
|
mapping to work.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Identifier associations</h4><div class="p">Identifier associations
|
||
|
|
allow you to define a one-to-one relationship between user identities through
|
||
|
|
an EIM identifier defined for an individual. Identifier associations allow
|
||
|
|
you to specifically control identity mapping for user identities and are especially
|
||
|
|
useful when individuals have user identities with special authorities and
|
||
|
|
other privileges. These associations dictate how the user identities are mapped
|
||
|
|
from one to another. In a typical identity mapping situation, you create source
|
||
|
|
associations for authenticating user identities and target associations to
|
||
|
|
map the authenticating user identity to the appropriate user identities for
|
||
|
|
authorized access to other systems and resources. For example, you might typically
|
||
|
|
create the following identifier associations between an EIM identifier and
|
||
|
|
corresponding user identities for a user: <ul><li>A source association for the user's Kerberos principal, which is the identity
|
||
|
|
with which the user logs into, and is authenticated to, the network.</li>
|
||
|
|
<li>Target associations for each user identity in the various user registries
|
||
|
|
that the user accesses, such as <span class="keyword">Windows<sup>®</sup> 2000</span> user
|
||
|
|
profiles.</li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
<p>The following example illustrates how the identity mapping process
|
||
|
|
works for identifier associations. The security administrator at Myco, Inc
|
||
|
|
creates an EIM identifier (John Day) for an employee. This EIM identifier
|
||
|
|
uniquely identifies John Day in the enterprise. The administrator then creates
|
||
|
|
identifier associations between the John Day identifier and two user identities
|
||
|
|
that he routinely uses in the enterprise. These associations define how the
|
||
|
|
user identities are mapped. The administrator creates a source association
|
||
|
|
for the Windows identity, which is a Kerberos principal,
|
||
|
|
and a target association for an <span class="keyword">Windows 2000</span> user
|
||
|
|
profile. These associations enable his Windows identity to be mapped to his <span class="keyword">Windows 2000</span> user profile.</p>
|
||
|
|
<p>John Day
|
||
|
|
uses the appropriate user name and password to log on to his <span class="keyword">Windows 2000</span> workstation
|
||
|
|
each morning. Once logged on, he starts <span class="keyword">iSeries™ Access for Windows</span> to
|
||
|
|
use <span class="keyword">Windows 2000</span> to access the <span class="keyword">Windows 2000</span> system. Because single signon
|
||
|
|
is enabled, the identity mapping process uses his authenticated Windows identity
|
||
|
|
to find the associated <span class="keyword">Windows 2000</span> user
|
||
|
|
profile and transparently authenticates and authorizes him to<span class="keyword">Windows 2000</span>.</p>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Policy associations</h4><p>Policy associations allow you
|
||
|
|
to define a many-to-one relationship between a group of user identities in
|
||
|
|
one or more user registries and a specific individual target user identity
|
||
|
|
in another user registry. Typically, you use policy associations to map from
|
||
|
|
a group of users who require the same level of authority for an application
|
||
|
|
to a single user identity with the appropriate authority.</p>
|
||
|
|
<p>The following
|
||
|
|
example illustrates how identity mapping works when you define policy associations.
|
||
|
|
A number of workers in the Order Receiving Department of Myco, Inc. all need
|
||
|
|
the same type of authorization to access a Web-based application that runs
|
||
|
|
on <span class="keyword">Windows 2000</span> on the server.
|
||
|
|
These users currently have user identities for this purpose in a single user
|
||
|
|
registry named Order_app. The administrator creates a default registry policy
|
||
|
|
association to map all the users in the Order_app user registry to a single <span class="keyword">Windows 2000</span> user profile. This <span class="keyword">Windows 2000</span> user profile, SYSUSER, provides
|
||
|
|
the minimum authority needed for this group of users. Performing this single
|
||
|
|
configuration step allows the administrator to ensure that all users of the
|
||
|
|
Web-based application have the access they need with the proper level of authorization
|
||
|
|
that they need. However, the administrator also benefits because it eliminates
|
||
|
|
the need to create and maintain individual <span class="keyword">Windows 2000</span> user
|
||
|
|
profiles for each user.</p>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamzconcepts.htm" title="Use this information to learn about the underlying concepts for single signon for a better understanding of how you can plan to use single signon in your enterprise.">Concepts</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="../rzalv/rzalveservereimid.htm">EIM identifiers</a></div>
|
||
|
|
<div><a href="../rzalv/rzalveserverregistry.htm">EIM registry definitions</a></div>
|
||
|
|
<div><a href="../rzalv/rzalveserverassoc.htm">EIM associations</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|