146 lines
9.3 KiB
HTML
146 lines
9.3 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 xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="dc.language" scheme="rfc1766" 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. -->
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
|
<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))' />
|
|
<title>Directory Server (LDAP) - Access evaluation</title>
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
|
</head>
|
|
<body>
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
|
|
|
|
|
<a name="rzahyaccesseval"></a>
|
|
<h4 id="rzahyaccesseval">Access evaluation</h4>
|
|
<p>Access for a particular operation is granted or denied based on the subject's
|
|
bind DN for that operation on the target object. Processing stops as soon
|
|
as access can be determined.</p>
|
|
<p>The checks for access are done by first finding the effective <span class="bold">entryOwnership</span> and <span class="bold">ACI</span> definition, checking
|
|
for entry ownership, and then by evaluating the object's ACI values.</p>
|
|
<p>Filter-based ACLs accumulate from the lowest containing entry, upward along
|
|
the ancestor entry chain, to the highest containing entry in the DIT. The
|
|
effective access is calculated as the union of the access rights granted,
|
|
or denied, by the constituent ancestor entries. The existing set of specificity
|
|
and combinatory rules are used to evaluate effective access for filter based
|
|
ACLs.</p>
|
|
<p>Filter-based and non-filter-based attributes are mutually exclusive within
|
|
a single containing directory entry. Placing both types of attributes into
|
|
the same entry is not allowed, and is a constraint violation. Operations
|
|
associated with the creation of, or updates to, a directory entry fail if
|
|
this condition is detected.</p>
|
|
<p>When calculating effective access, the first ACL type to be detected in
|
|
the ancestor chain of the target object entry sets the mode of calculation.
|
|
In filter-based mode, non-filter-based ACLs are ignored in effective access
|
|
calculation. Likewise, in non-filter-based mode, filter-based ACLs are ignored
|
|
in effective access calculation.</p>
|
|
<p>To limit the accumulation of filter-based ACLs in the calculation of effective
|
|
access, an <span class="bold">ibm-filterAclInherit</span> attribute
|
|
set to a value of "false" can be placed in any entry between the highest and
|
|
lowest occurrence of <span class="bold">ibm-filterAclEntry</span> in
|
|
a given subtree. This causes the subset of <span class="bold">ibm-filterAclEntry</span> attributes above it in the target object's ancestor chain to be ignored.</p>
|
|
<p>In filter-based ACL mode, if no filter-based ACL applies, the default ACL
|
|
applies (cn=anybody is granted read, search, and compare access to attributes
|
|
in the <tt class="xph">normal</tt> access class). This situation can occur
|
|
when the entry being accessed does not match any of the filters specified
|
|
in the <span class="bold">ibm-filterAclEntry</span> values. You might
|
|
want to specify a default filter ACL like the following if you do not want
|
|
this default access control to apply:</p>
|
|
<pre class="xmp">ibm-filterAclEntry: group:cn=anybody:(objectclass=*):</pre><p class="indatacontent">This example grants no access. Change it to provide the access you want
|
|
applied.</p>
|
|
<p>By default, the directory administrator and the master server or the peer
|
|
server (for replication) get full access rights to all objects in the directory
|
|
except write access to system attributes. Other <span class="bold">entryOwners</span> get full access rights to the objects under their ownership
|
|
except write access to system attributes. All users have read access rights
|
|
to system and restricted attributes. These predefined rights cannot be altered.
|
|
If the requesting subject has <span class="bold">entryOwnership</span>,
|
|
access is determined by the above default settings and access processing stops.</p>
|
|
<p>If the requesting subject is not an entryOwner, then the ACI values for
|
|
the object entries are checked. The access rights as defined in the ACIs
|
|
for the target object are calculated by the specificity and combinatory rules.</p>
|
|
<dl>
|
|
<dt class="bold">Specificity rule </dt>
|
|
<dd>The most specific aclEntry definitions are the ones used in the evaluation
|
|
of permissions granted/denied to a user. The levels of specificity are:
|
|
<ul>
|
|
<li>Access-id is more specific than group or role. Groups and roles are on
|
|
the same level.</li>
|
|
<li>Within the same <span class="bold">dnType</span> level, individual attribute
|
|
level permissions are more specific than attribute class level permissions.</li>
|
|
<li>Within the same attribute or attribute class level, <span class="bold">deny</span> is more specific than <span class="bold">grant</span>.</li></ul>
|
|
</dd>
|
|
<dt class="bold">Combinatory rule </dt>
|
|
<dd>Permissions granted to subjects of equal specificity are combined. If
|
|
the access cannot be determined within the same specificity level, the access
|
|
definitions of lesser specific level are used. If the access is not determined
|
|
after all defined ACIs are applied, the access is denied.
|
|
<a name="wq66"></a>
|
|
<div class="notetitle" id="wq66">Note:</div>
|
|
<div class="notebody">After a matching access-id level <span class="bold">aclEntry</span> is found in
|
|
access evaluation, the group level aclEntries are not included in access calculation.
|
|
The exception is that if the matching access-id level <span class="bold">aclEntries</span> are all defined under cn=this, then all matching group level <span class="bold">aclEntries</span> are also combined in the evaluation.</div>
|
|
</dd>
|
|
</dl>
|
|
<p>In other words, within the object entry, if a defined ACI entry contains
|
|
an access-id subject DN that matches the bind DN, then the permissions are
|
|
first evaluated based on that aclEntry. Under the same subject DN, if matching
|
|
attribute level permissions are defined, they supersede any permissions defined
|
|
under the attribute classes. Under the same attribute or attribute class
|
|
level definition, if conflicting permissions are present, denied permissions
|
|
override granted permissions. </p>
|
|
<a name="wq67"></a>
|
|
<div class="notetitle" id="wq67">Note:</div>
|
|
<div class="notebody">A defined null value permission
|
|
prevents the inclusion of less specific permission definitions.</div>
|
|
<p>If access still cannot be determined and all found matching aclEntries
|
|
are defined under "cn=this", then group membership is evaluated. If a user
|
|
belongs to more than one groups, the user receives the combined permissions
|
|
from these groups. Additionally, the user automatically belongs to the cn=Anybody
|
|
group and possibly the cn=Authenticated group if the user did an authenticated
|
|
bind. If permissions are defined for those groups, the user receives the
|
|
specified permissions. </p>
|
|
<a name="wq68"></a>
|
|
<div class="notetitle" id="wq68">Note:</div>
|
|
<div class="notebody">Group and Role membership
|
|
is determined at bind time and last until either another bind takes place,
|
|
or until an unbind request is received. Nested groups and roles, that is
|
|
a group or role defined as a member of another group or role, are not resolved
|
|
in membership determination nor in access evaluation.</div>
|
|
<p>For example, assume attribute1 is in the sensitive attribute class, and
|
|
user cn=Person A, o=IBM belongs to both group1 and group2 with the following
|
|
aclEntries defined: </p>
|
|
<ol type="1">
|
|
<li>aclEntry: access-id: cn=Person A, o=IBM: at.attributel:grant:rsc:sensitive:deny:rsc</li>
|
|
<li>aclEntry: group: cn=group1,o=IBM:critical:deny:rwsc</li>
|
|
<li>aclEntry: group: cn=group2,o=IBM:critical:grant:r:normal:grant:rsc</li></ol><p class="indatacontent">This user gets: </p>
|
|
<ul>
|
|
<li>Access of 'rsc' to attribute1, (from 1. Attribute level definition supersedes
|
|
attribute class level definition).</li>
|
|
<li>No access to other sensitive class attributes in the target object, (from
|
|
1).</li>
|
|
<li>No other rights are granted (2 and 3 are NOT included in access evaluation).</li></ul>
|
|
<p>For another example, with the following aclEntries: </p>
|
|
<ol type="1">
|
|
<li>aclEntry: access-id: cn=this: sensitive</li>
|
|
<li>aclEntry: group: cn=group1,o=IBM:sensitive:grant:rsc:normal:grant:rsc</li></ol><p class="indatacontent">The user has: </p>
|
|
<ul>
|
|
<li>no access to sensitive class attributes, (from 1. Null value defined under
|
|
access-id prevents the inclusion of permissions to sensitive class attributes
|
|
from group1).</li>
|
|
<li>and access of 'rsc' to normal class attributes (from 2).</li></ul>
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
|
</body>
|
|
</html>
|