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

125 lines
9.0 KiB
HTML
Raw 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="Default registry policy associations" />
<meta name="abstract" content="This information explains how to establish a mapping relationship for all the user identities in a single registry." />
<meta name="description" content="This information explains how to establish a mapping relationship for all the user identities in a single registry." />
<meta name="DC.Relation" scheme="URI" content="rzalv_policy_associations.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_registry_policy" />
<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>Default registry policy associations</title>
</head>
<body id="rzalv_registry_policy"><a name="rzalv_registry_policy"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Default registry policy associations</h1>
<div><p>This information explains how to establish a mapping relationship
for all the user identities in a single registry.</p>
<p>A default registry policy association is one type of policy association
that you can use to create many-to-one mappings between user identities. You
can use a default registry policy association to map a source set of multiple
user identities (in this case those in a single registry) to a single target
user identity in a specified target user registry. In a default registry policy
association, all users in a single registry are the source of the policy
association and are mapped to a single target registry and target user.</p>
<p>To use default registry policy associations, you must enable mapping lookups
using policy associations for the domain. You must also enable mapping lookups
for the source registry and enable mapping lookups and the use of policy associations
for the target user registry of the policy association. When you configure
this enablement, the user registries in the policy association can participate
in mapping lookup operations.</p>
<p>The default registry policy association takes effect when a mapping lookup
operation is not satisfied by identifier associations, certificate filter
policy associations, or other default registry policy associations for the
target registry. The result is that all user identities in the source registry
are mapped to the single target user identity as specified by the default
registry policy association. </p>
<p>For example, you create a default registry policy association that has
a source registry of <samp class="codeph">my_realm.com</samp>, which are principals in
a specific Kerberos realm. For this policy association, you also specify
a target user identity of <samp class="codeph">general_user1</samp> in target registry <samp class="codeph">i5/OS_system_reg</samp>,
which is a specific user profile in an i5/OS™ user registry. In this case, you
have not created any identifier associations or policy associations that apply
to any of the user identities in the source registry. Therefore, when <samp class="codeph">i5/OS_system_reg</samp> is
specified as the target registry and <samp class="codeph">my_realm.com</samp> is specified
as the source registry in lookup operations, the default registry policy
association ensures that the target user identity of <samp class="codeph">general_user1</samp> is
returned for all user identities in <samp class="codeph">my_realm.com</samp> that do
not have any specific identifier associations or certificate filter policy
associations defined for them.</p>
<p>You specify these three things to define a default registry policy association:</p>
<ul><li><strong>Source registry</strong>. <span class="break">This is the registry definition
that you want the policy association to use as the source of the mapping.
All the user identities in this source user registry are to be mapped to the
specified target user of the policy association. </span></li>
<li><strong>Target registry</strong>. <span class="break"> The target registry that
you specify is the name of an Enterprise Identity Mapping (EIM) registry definition.
The target registry must contain the target user identity to which all user
identities in the source registry are to be mapped.</span></li>
<li><strong>Target user</strong>. <span class="break"> The target user is the name
of user identity that is returned as the target of an EIM mapping lookup operation
based on this policy association.</span></li>
</ul>
<p>You can define more than one default registry policy association. If two
or more policy associations with the same source registry refer to the same
target registry, you must define unique <a href="rzalvlookupinfodef.htm#lookup_info_def">lookup
information</a> for each of these policy associations to ensure that mapping
lookup operations can distinguish among them. Otherwise, mapping lookup operations
may return multiple target user identities. As a result of these ambiguous
results, applications that rely on EIM may not be able to determine the exact
target identity to use. </p>
<p>Because you can use policy associations in a variety of overlapping ways,
you should have a thorough understanding of EIM <a href="rzalv_map_pol_support.htm#rzalv_map_pol_support">mapping policy support</a> and how <a href="rzalveservereimmaplookup.htm#rzalveservereimmaplookup">lookup operations</a> work before you create and use policy
associations.</p>
<div class="note"><span class="notetitle">Note:</span> <img src="./delta.gif" alt="Start of change" />You might want to create a default registry policy association
with a target user identity that exists within a group registry definition.
All users in the source user registry are the source of the policy association
and are mapped to a target user identity in a target group registry definition.
The user identity that you define in the default registry policy association
exists within the members of the group registry definition.<p>For example,
John Day uses the same i5/OS user profile, <samp class="codeph">John_Day</samp>, on five
different systems: System_B, System_C, System_D, System_E, and System_F. To
reduce the amount of work that he must perform to configure EIM mapping, the
EIM administrator creates a group registry definition called <samp class="codeph">Group_1</samp>.
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 the individual registry definitions.</p>
<p>The EIM
administrator creates a default registry policy association that has a source
registry of <samp class="codeph">my_realm.com</samp>, which are principals in a specific
Kerberos realm. For this policy association, he also specifies a target user
identity of <samp class="codeph">John_Day</samp> in target registry <samp class="codeph">Group_1</samp>.
In this case, no other identifier associations or policy associations apply.
Therefore, when <samp class="codeph">Group_1</samp> is specified as the target registry
and <samp class="codeph">my_realm.com</samp> is specified as the source registry in lookup
operations, the default registry policy association ensures that the target
user identity of <samp class="codeph">John_Day</samp> is returned for all user identities
in <samp class="codeph">my_realm.com</samp> that do not have any specific identifier
associations defined for them.</p>
<p></p>
<img src="./deltaend.gif" alt="End of change" /></div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalv_policy_associations.htm" title="Use this information to learn about how to use policy associations to describe a relationship between multiple user identities and a single user identity in a user registry.">Policy associations</a></div>
</div>
</div>
</body>
</html>