200 lines
10 KiB
HTML
200 lines
10 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) - AclEntry and ibm-filterAclEntry</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="rzahyaclentry"></a>
|
||
|
<h4 id="rzahyaclentry">AclEntry and ibm-filterAclEntry</h4>
|
||
|
<a name="wq54"></a>
|
||
|
<h5 id="wq54">Subject</h5>
|
||
|
<p>A subject (the entity requesting access to operate on an object) consists
|
||
|
of the combination of a DN (Distinguished Name) type and a DN. The valid
|
||
|
DN types are: access-id, Group and Role.</p>
|
||
|
<p>The DN identifies a particular access-id, role or group. For example,
|
||
|
a subject might be access-id: cn=personA, o=IBM or group: cn=deptXYZ, o=IBM.</p>
|
||
|
<p>Because the field delimiter is the colon ( : ), a DN containing colons
|
||
|
must be surrounded by double-quotation marks ( "" ). If a DN already
|
||
|
contains characters with double-quotation marks, these characters must be
|
||
|
escaped with a backslash (\).</p>
|
||
|
<p>All directory groups can be used in access control.</p>
|
||
|
<a name="wq55"></a>
|
||
|
<div class="notetitle" id="wq55">Note:</div>
|
||
|
<div class="notebody">Any group of <span class="bold">AccessGroup</span>, <span class="bold">GroupOfNames</span>, <span class="bold">GroupofUniqueNames</span>, or <span class="bold">groupOfURLs</span> structural objectclasses
|
||
|
or the <span class="bold">ibm-dynamicGroup</span>, <span class="bold">ibm-staticGroup</span> auxiliary objectclasses can be used for access control.</div>
|
||
|
<p>Another DN type used within the access control model is role. While roles
|
||
|
and groups are similar in implementation, conceptually they are different.
|
||
|
When a user is assigned to a role, there is an implicit expectation that the
|
||
|
necessary authority has already been set up to perform the job associated
|
||
|
with that role. With group membership, there is no built in assumption about
|
||
|
what permissions are gained (or denied) by being a member of that group.</p>
|
||
|
<p>Roles are similar to groups in that they are represented in the directory
|
||
|
by an object. Additionally, roles contain a group of DNs. Roles that are
|
||
|
used in access control must have an objectclass of <span class="bold">AccessRole</span>.</p>
|
||
|
<a name="wq56"></a>
|
||
|
<h5 id="wq56">Pseudo DN</h5>
|
||
|
<p>The LDAP directory contains several pseudo DNs. These are used to refer
|
||
|
to large numbers of DNs which at bind time share a common characteristic,
|
||
|
in relation to either the operation being performed, or the target object
|
||
|
on which the operation is being performed.</p>
|
||
|
<p>Currently, three pseudo DNs are defined: </p>
|
||
|
<dl>
|
||
|
<dt class="bold">group:cn=anybody </dt>
|
||
|
<dd>Refers to all subjects, including those that are unauthenticated.
|
||
|
All users belong to this group automatically.
|
||
|
</dd>
|
||
|
<dt class="bold">group:cn=authenticated </dt>
|
||
|
<dd>Refers to any DN which has been authenticated to the directory. The
|
||
|
method of authentication is not considered.
|
||
|
</dd>
|
||
|
<dt class="bold">access-id:cn=this </dt>
|
||
|
<dd>Refers to the bind Dn which matches the target object's DN
|
||
|
on which the operation is performed.
|
||
|
</dd>
|
||
|
</dl>
|
||
|
<a name="wq57"></a>
|
||
|
<h5 id="wq57">Object filter</h5>
|
||
|
<p>This parameter applies to filtered ACLs only. The string search filter
|
||
|
as defined in RFC 2254, is used as the object filter format. Because the
|
||
|
target object is already known, the string is not used to perform an actual
|
||
|
search. Instead, a filter-based compare on the target object in question
|
||
|
is performed to determine if a given set of ibm-filterAclEntry values apply
|
||
|
to it.</p>
|
||
|
<a name="wq58"></a>
|
||
|
<h5 id="wq58">Rights</h5>
|
||
|
<p>Access rights can apply to an entire object or to attributes of the object.
|
||
|
The LDAP access rights are discrete. One right does not imply another right.
|
||
|
The rights can be combined together to provide the desired rights list following
|
||
|
a set of rules discussed later. Rights can be of an unspecified value, which
|
||
|
indicates that no access rights are granted to the subject on the target object.
|
||
|
The rights consist of three parts: </p>
|
||
|
<dl>
|
||
|
<dt class="bold">Action: </dt>
|
||
|
<dd>Defined values are <span class="bold">grant</span> or <span class="bold">deny</span>. If this field is not present, the default
|
||
|
is set to <span class="bold">grant</span>.
|
||
|
</dd>
|
||
|
<dt class="bold">Permission: </dt>
|
||
|
<dd>There are six basic operations that can be performed on a directory
|
||
|
object. From these operations, the base set of ACI permissions are taken.
|
||
|
These are: add an entry, delete an entry, read an attribute value, write an
|
||
|
attribute value, search for an attribute, and compare an attribute value.
|
||
|
<p>The possible attribute permissions are: read ( r ), write ( w ), search (
|
||
|
s ), and compare ( c ). Additionally, object permissions apply to the entry
|
||
|
as a whole. These permissions are add child entries ( a ) and delete this
|
||
|
entry ( d ).</p>
|
||
|
<p>The following table summarizes the permissions needed
|
||
|
to perform each of the LDAP operations. </p>
|
||
|
<a name="wq59"></a>
|
||
|
<table id="wq59" width="100%" summary="" border="1" frame="border" rules="all" class="singleborder">
|
||
|
<thead valign="bottom">
|
||
|
<tr class="tablemainheaderbar">
|
||
|
<th id="wq60" align="left" valign="top"> Operation</th>
|
||
|
<th id="wq61" align="left" valign="top">Permission Needed</th>
|
||
|
</tr>
|
||
|
</thead>
|
||
|
<tbody valign="top">
|
||
|
<tr>
|
||
|
<td headers="wq60">ldapadd</td>
|
||
|
<td headers="wq61">add (on parent)</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td headers="wq60">ldapdelete</td>
|
||
|
<td headers="wq61">delete (on object)</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td headers="wq60">ldapmodify</td>
|
||
|
<td headers="wq61">write (on attributes being modified)</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td headers="wq60">ldapsearch</td>
|
||
|
<td headers="wq61">
|
||
|
<ul>
|
||
|
<li>search, read (on attributes in RDN)</li>
|
||
|
<li>search (on attributes specified in the search
|
||
|
filter)</li>
|
||
|
<li>search (on attributes returned with just names)</li>
|
||
|
<li>search, read (on attributes returned with values)</li></ul></td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td headers="wq60">ldapmodrdn</td>
|
||
|
<td headers="wq61">write (on RDN attributes)</td>
|
||
|
</tr>
|
||
|
<tr>
|
||
|
<td headers="wq60">ldapcompare</td>
|
||
|
<td headers="wq61">compare (on compared attribute)</td>
|
||
|
</tr>
|
||
|
</tbody>
|
||
|
</table>
|
||
|
<a name="wq62"></a>
|
||
|
<div class="notetitle" id="wq62">Note:</div>
|
||
|
<div class="notebody">For search operations, the subject is required to
|
||
|
have search access to all the attributes in the search filter or no entries
|
||
|
are returned. For returned entries from a search, the subject is required
|
||
|
to have search and read access to all the attributes in the RDN of the returned
|
||
|
entries or these entries are not returned.</div>
|
||
|
</dd>
|
||
|
<dt class="bold">Access Target: </dt>
|
||
|
<dd>These permissions can be applied to the entire object (add child entry,
|
||
|
delete entry), to an individual attribute within the entry, or can be applied
|
||
|
to groups of attributes (Attribute Access Classes) as described in the following.
|
||
|
<p>Attributes requiring similar permissions for access are grouped together in
|
||
|
classes. Attributes are mapped to their attribute classes in the directory
|
||
|
schema file. These classes are discrete; access to one class does not imply
|
||
|
access to another class. Permissions are set with regard to the attribute
|
||
|
access class as a whole. The permissions set on a particular attribute class
|
||
|
apply to all attributes within that access class unless the individual attribute
|
||
|
access permissions are specified.</p>
|
||
|
<p>IBM defines three attribute classes
|
||
|
that are used in evaluation of access to user attributes: <span class="bold">normal</span>, <span class="bold">sensitive</span>, and <span class="bold">critical</span>. For example, attribute <span class="bold">commonName</span> falls into the normal class, and attribute userpassword belongs to the
|
||
|
critical class. User defined attributes belong to the normal access class
|
||
|
unless otherwise specified.</p>
|
||
|
<p>Two other access classes are also defined:
|
||
|
system and restricted. The system class attributes are:</p>
|
||
|
<ul>
|
||
|
<li><span class="bold">creatorsName</span></li>
|
||
|
<li><span class="bold">modifiersName</span></li>
|
||
|
<li><span class="bold">createTimestamp</span></li>
|
||
|
<li><span class="bold">modifyTimestamp</span></li>
|
||
|
<li><span class="bold">ownerSource</span></li>
|
||
|
<li><span class="bold">aclSource</span></li></ul><p class="indatacontent"> These are attributes maintained by the LDAP server and are read-only
|
||
|
to the directory users. <span class="bold">OwnerSource</span> and <span class="bold">aclSource</span> are described in the Propagation section
|
||
|
(see<a href="rzahypropagation.htm#rzahypropagation">Propagation</a>).</p>
|
||
|
<p> The restricted class of attributes
|
||
|
that define the access control are:</p>
|
||
|
<ul>
|
||
|
<li><span class="bold">aclEntry</span></li>
|
||
|
<li><span class="bold">aclPropagate</span></li>
|
||
|
<li><span class="bold">entryOwner</span></li>
|
||
|
<li><span class="bold">ownerPropagate</span></li>
|
||
|
<li><span class="bold">ibm-filterAclEntry</span></li>
|
||
|
<li><span class="bold">ibm-filterAclInherit</span></li>
|
||
|
<li><span class="bold">ibm-effectiveAcl</span></li></ul><p class="indatacontent"> All users have read access to the restricted attributes but only <span class="bold">entryOwners</span> can create, change, and delete these
|
||
|
attributes.</p>
|
||
|
<a name="wq63"></a>
|
||
|
<div class="notetitle" id="wq63">Note:</div>
|
||
|
<div class="notebody">The attribute, <span class="bold">ibm-effectiveAcl</span>, is read-only.</div>
|
||
|
</dd>
|
||
|
</dl>
|
||
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
</body>
|
||
|
</html>
|