You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2005/05/21 04:53:55 UTC
svn commit: r171188 [2/3] - in /directory/apacheds/trunk/xdocs: drafts/
drafts/draft-ietf-ldapext-acl-model-08.txt rfcs/ rfcs/rfc3642.html
rfcs/rfc3642_files/ rfcs/rfc3642_files/library.jpg rfcs/rfc3698.html
rfcs/rfc3698_files/ rfcs/rfc3698_files/library.jpg
Added: directory/apacheds/trunk/xdocs/drafts/draft-ietf-ldapext-acl-model-08.txt
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/drafts/draft-ietf-ldapext-acl-model-08.txt?rev=171188&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/drafts/draft-ietf-ldapext-acl-model-08.txt (added)
+++ directory/apacheds/trunk/xdocs/drafts/draft-ietf-ldapext-acl-model-08.txt Fri May 20 19:53:55 2005
@@ -0,0 +1,4166 @@
+
+
+
+
+
+
+
+Internet-Draft E. Stokes
+LDAP Extensions WG B. Blakley
+Intended Category: Standards Track Tivoli Systems
+Expires: 29 December 2001 R. Byrne
+ Sun Microsystems
+ R. Huber
+ AT&T Laboratories
+ D. Rinkevich
+ Momenta
+ 29 June 2001
+
+ Access Control Model for LDAPv3
+ <draft-ietf-ldapext-acl-model-08.txt>
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet Engineering Task
+Force (IETF), its areas, and its working groups. Note that other groups
+may also distribute working documents as Internet-Drafts. Internet-
+Drafts are draft documents valid for a maximum of six months and may be
+updated, replaced, or obsoleted by other documents at any time. It is
+inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+Comments and suggestions on this document are encouraged. Comments on
+this document should be sent to the LDAPEXT working group discussion
+list:
+
+ ietf-ldapext@netscape.com
+
+COPYRIGHT NOTICE
+
+Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ABSTRACT
+
+This document describes the access control model for the Lightweight
+Directory Application Protocol V3 (LDAPv3) directory service. It
+includes a description of the model, the schema for the model, and the
+LDAP control to the LDAP protocol. The current LDAP APIs are sufficient
+for the access control operations. A separate requirements document for
+access control exists [REQTS]. The access control model used the
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 1]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+requirements document as a guideline for the development of this
+specification and are reflected in this specification to the extent that
+the working group could agree on an access control model.
+
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" used in this document
+are to be interpreted as described in [Bradner97].
+
+
+
+1. Introduction
+
+The ability to securely access (replicate and distribute) directory
+information throughout the network is necessary for successful
+deployment. LDAP's acceptance as an access protocol for directory
+information is driving the need to provide an access control model
+definition for LDAP directory content among servers within an enterprise
+and the Internet. Currently LDAP does not define an access control
+model, but one is needed to ensure consistent secure access,
+replication, and management across heterogeneous LDAP implementations.
+The major objective is to provide a simple, usable, and implementable,
+but secure and efficient access control model for LDAP accessible
+directory content while also providing the appropriate flexibility to
+meet the needs of both the Internet and enterprise environments and
+policies. This document defines the model, the schema, and the LDAP
+control.
+
+This model does not (and cannot) fully specify the behavior of the
+Access Control Model in a distributed environment (e.g. propagating
+access control information across servers and ACI administration)
+because there is no LDAP standard defining how to distribute directory
+data between LDAP servers. The behavior of the Access Control Model in
+distributed environments is beyond the scope of this model.
+
+The following topics are deemed interesting and useful for future work,
+but are also beyond the scope of this model:
+
+ - Permissions based on object class
+
+ - Application permissions
+
+ - How to get initial entryACI and subtreeACI attributes in the
+ directory is server specific
+
+ - Use of prescriptive ACIs and scoping via use of a ldapACISubEntry
+
+ - Required permissions for LDAP extended operations and LDAP
+ controls, such as a proxy permission and permission extensibility
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 2]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ - The access rights required for the creation of the first entry in
+ the directory
+
+ - filter use in ACI
+
+ - Mapping of SASL authentication identities (whose form is mechanism
+ specific) to LDAP authorization identities (which are used for
+ access control purposes)
+
+
+
+2. The LDAPv3 Access Control Model
+
+Access Control mechanisms evaluate requests for access to protected
+resources and make decisions about whether those requests should be
+granted or denied. In order to make a grant/deny decision about a
+request for access to a protected resource, an access control mechanism
+needs to evaluate policy data. This policy data describes security-
+relevant characteristics of the requesting subject and the rules which
+govern the use of the target object.
+
+No mechanism is defined in this document for storage of access control
+information at the server beyond indicating that the attribute holding
+access control information is an operational attribute.
+
+The access control model defines
+
+ - What flows on the wire for interoperability
+
+ The existing LDAP protocol flows for ldap operations are used to
+ manipulate access control information. These same flows on the wire
+ apply when ACI is transmitted during replication. A set of
+ permissions and their semantics with respect to ldap operations is
+ defined. The permissions parallel the defined set of ldap
+ operations. Encoding of access control information on the wire is
+ per the LDAPv3 specifications.
+
+ There is a LDAP control defined, GetEffectiveRights. LDAP clients
+ use the control to manage and administer access control policy
+ enforced by LDAP servers.
+
+ Servers may store access control information in any way they
+ choose. In particular, servers may use the access control
+ mechanisms of their datastores to store and enforce LDAP access
+ control, or they may implement/exploit access control managers
+ external to their datastores. Datastores and external access
+ control managers MAY implement any access control rule syntax and
+ semantics they choose, but the semantics MUST be compatible with
+ those defined in the section titled "Required Permissions for Each
+ LDAP Operation".
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 3]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ - Attributes and classes for application portability of access
+ control information. Portable (LDAP) applications should only use
+ the ACI in this model.
+
+ Two access control information attributes (entryACI and subtreeACI)
+ for application portability. These attributes are used as input to
+ the LDAP APIs so access control information can be addressed
+ uniformly independent of how that information is accessed and
+ stored at the server. These same attributes appear in LDIF output
+ for interchange of access control information.
+
+ An access control information subentry class (ldapACISubEntry) and
+ a set of attributes (supportedAccessControlSchemes which is used in
+ the rootDSE, and accessControlSchemes which is used in the subentry
+ ldapACISubEntry) to identity the access control mechanisms
+ supported by a server and in a given part of the namespace,
+ respectively.
+
+ - A mechanism to control access to access control information: The
+ access control information operational attributes, entryACI and
+ subtreeACI, are also used to control access to access control
+ information (controls access to itself). How to get initial
+ entryACI and subtreeACI attributes in the directory is server
+ specific and beyond the scope of this model.
+
+Servers can support multiple access control mechanisms, but MUST be
+capable of supporting the LDAP Mechanism in the DIT scoped by the
+rootDSE (entire server's DIT) for that server and SHOULD be capable of
+supporting the LDAP mechanism in an arbitrary part (subtree) of the DIT.
+
+The accessControlSchemes attribute in the ldapACISubEntry indicates
+which access control mechanisms are in effect for the scope of that
+ldapACISubEntry. The supportedAccessControlSchemes attribute in the
+rootDSE indicates which access control mechanisms are supported by the
+server; those mechanisms are in effect in that server's DIT unless
+overridden by a mechanism defined in a ldapACISubEntry elsewhere in that
+DIT.
+
+Changing the value(s) of either the supportedAccessControlSchemes or
+accessControlSchemes attributes changes the mechanism(s) in effect for
+the scope of those attributes (where scope is either that of the rootDSE
+or ldapACISubEntry).
+
+Through the use of the supportedAccessControlSchemes attribute in the
+rootDSE and the accessControlSchemes attribute in the ldapACISubEntry,
+it is possible to run multiple mechanisms in either the same subtree or
+separate subtrees. This might occur if the underlying datastore for the
+directory was accessible via LDAP and other applications. In this case,
+LDAP access should always be subjects to the LDAP access controls
+described in this document.
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 4]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+3. Access Control Mechanism Attributes
+
+Two attributes are defined to identify which access control mechanisms
+are supported by a given server and by a given subtree:
+supportedAccessControlSchemes and accessControlSchemes. (We chose these
+names based on the X.500 attribute, AccessControlScheme which is
+single-valued and defined in X.501).
+
+
+3.1 Root DSE Attribute for Access Control Mechanism
+
+The server advertises which access control mechanisms it supports by
+inclusion of the 'supportedAccessControlSchemes' attribute in the root
+DSE. This attribute is a list of OIDs, each of which identify an access
+control mechanism supported by the server. By default, these are also
+the mechanisms in effect in subtrees beneath the root in that server
+unless overridden by a ldapACISubEntry (see section "Subentry Class
+Access Control Mechanism").
+
+ (<OID to be assigned>
+ NAME 'supportedAccessControlSchemes'
+ DESC list of access control mechanisms supported
+ by this directory server
+ EQUALITY objectIdentifierMatch
+ SYNTAX OID
+ USAGE dSAOperation
+ )
+
+The access control mechanism defined is:
+ LDAPv3 <OID to be assigned>
+
+Other vendor access control mechanisms MAY be defined (by OID) and are
+the responsibility of those vendors to provide the definition and OID.
+
+
+3.2 Subentry Class Access Control Mechanism
+
+A given naming context MUST provide information about which access
+control mechanisms are in effect for that portion of the namespace.
+This information is contained in a subentry (ldapACISubEntry class),
+derived from [SUBENTRY]. ldapACISubEntry MAY be used to define the
+scope of an access control mechanism. The value(s) held in the rootDSE
+attribute, supportedAccessControlSchemes, are the mechanisms in effect
+in subtrees beneath the root in that server unless overridden in a
+ldapACISubEntry further down the tree held by that server. The scope of
+that ldapACISubEntry is to the end of the subtree held by that server or
+until another ldapACISubEntry is encountered in that subtree held by
+that server. The ldapACISubEntry class is defined as:
+
+
+ ( <OID to be assigned>
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 5]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ NAME 'ldapACISubEntry'
+ DESC 'LDAP ACI Subentry class'
+ SUP ldapSubEntry STRUCTURAL
+ MUST ( accessControlSchemes )
+ )
+
+The accessControlSchemes attribute MUST be in each ldapACISubEntry entry
+associated with a naming context whose access control mechanism is
+different from adjacent naming contexts supported by that directory
+server. accessControlSchemes lists the values (list of OIDs) that
+define the access control mechanisms in effect for the scope of that
+ldap access control subentry (either until another ldapACISubEntry is
+encountered in that subtree or end of subtree is reached on the server).
+Although, in general, this attribute will define only a single mechanism
+(single value), more than one mechanism MAY be in effect for the scope
+of that subentry.
+
+ (<OID to be assigned>
+ NAME 'accessControlSchemes'
+ DESC list of access control mechanisms supported
+ in this subtree
+ EQUALITY objectIdentifierMatch
+ SYNTAX OID
+ USAGE dSAOperation
+ )
+
+
+
+4. The Access Control Information Attributes, Syntax, and Rules
+
+The access control information syntax and attributes, entryACI and
+subtreeACI, are defined as:
+
+ (<OID-aci-syntax>
+ DESC 'attribute syntax for LDAP access control information'
+ )
+
+ (<OID to be assigned>
+ NAME 'entryACI'
+ DESC 'ldap access control information, scope of entry'
+ EQUALITY directoryComponentsMatch
+ SYNTAX <OID-aci-syntax>
+ USAGE directoryOperation
+ )
+
+ (<OID to be assigned>
+ NAME 'subtreeACI'
+ DESC 'ldap access control information, scope of subtree'
+ EQUALITY directoryComponentsMatch
+ SYNTAX <OID-aci-syntax>
+ USAGE directoryOperation
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 6]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ )
+
+
+Section 4.1 defines the ABNF and ASN.1 for these attributes, entryACI
+and subtreeACI.
+
+The intent of the attribute definitions is to define a common
+interchange format and have a separation of responsibilities to allow
+different people to administer the different attribute types. (X.500
+overcomes this by allowing access control on a per-value basis, which is
+complex). Any given LDAP server should be able to translate the defined
+attribute into meaningful requests. Each server should be able to
+understand the attribute; there should not be any ambiguity into what
+any part of the syntax means.
+
+While the end goal is to have a common behavior model between different
+LDAP server implementations, the attribute definitions alone will not
+ensure identical ACL processing behavior between servers. Applicability
+and precedence rules for making access decisions are defined later in
+this section. The semantics of how a server interprets the ACI syntax
+are defined in the "Required Permissions for Each LDAP Operation"
+section of this document. Additionally, while the server must recognize
+and act on the attribute when received over the wire, there are no
+requirements for the server to physically store these attributes in this
+form.
+
+The attribute definitions maintain an assumption that the receiving
+server supports ACI inheritance within the security model. If the server
+does not support inheritance, the receiving server must expand any
+inherited information based on the scope flag.
+
+The attributes are defined so access control information (ACI) can be
+addressed in a server in an implementation independent manner. These
+attributes are used in typical LDAP APIs, in LDIF output of ACI and in
+transfer of ACI during replication. These attributes may be queried or
+set on all directory objects. The ABNF and definitions are given below.
+
+
+4.1 The ABNF and ASN.1
+
+
+4.1.1 ACI UTF-8 String Representation
+
+The LDAP string encoding of values of the ACI syntax (<OID-aci-syntax>)
+is described by the following ABNF [ABNF]. This string representation
+MUST be supported.
+
+
+ ACI = rights "#" attr "#" generalSubject
+
+ rights = (("grant:" / "deny:") permissions) /
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 7]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ ("grant:" permissions ";deny:" permissions)
+
+ permissions = 1*(permission)
+
+ permission = "a" / ; add
+ "d" / ; delete
+ "e" / ; export
+ "i" / ; import
+ "n" / ; renameDN
+ "b" / ; browseDN
+ "v" / ; view (entry level read permission)
+ "t" / ; returnDN
+ "r" / ; read
+ "s" / ; search filter
+ "p" / ; search filter (presence only)
+ "w" / ; write (mod-add)
+ "o" / ; obliterate (mod-del)
+ "c" / ; compare
+ "m" / ; make
+ "u" / ; unveil (disclose on error permission)
+ "g" ; getEffectiveRights
+
+ ; permissions r, w, o, s, p, c, m work on attributes
+ ; permissions a, d, e, i, n, b, v, t, u, g work on entries
+ ; permissions for attributes and permissions for entries are
+ ; never found in a single ACI
+
+ attr = "[all]" / "[entry]" / (attribute *("," attribute))
+
+ attribute = AttributeDescription
+ ; The <AttributeDescription> rule is defined
+ ; in Section 4.1.5 of [LDAPv3]
+
+ generalSubject = context pureSubject
+
+ context = "authnLevel:" authnLevel ":"
+
+ pureSubject = anySubject / machineSubject / idBasedSubject
+
+ anySubject = "public:"
+
+ machineSubject = "ipAddress:" ipAddressRange *( "," ipAddressRange ) /
+ "dns:" partialdomainname *( "," partialdomainname )
+
+ partialdomainname = [ "*." ] domainname
+
+
+ idBasedSubject = thisSubject /
+ oneSubject /
+ setOfSubjects
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 8]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ thisSubject = "this:"
+ oneSubject = ( "authzId-" authzId )
+ setOfSubjects = ( "role:" dn ) /
+ ( "group:" dn ) /
+ ( "subtree:" dn )
+
+ authnLevel = "none" /
+ "weak" /
+ "limited" /
+ "strong"
+
+ ; The <authzId> rule is defined in [AuthMeth]. It is
+ ; repeated below for convenience.
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id.
+ dnAuthzId = "dn:" dn
+
+ dn = utf8string ; with syntax defined in [UTF]
+
+ ; unspecified userid, UTF-8 encoded.
+ uAuthzId = "u:" userid
+ userid = utf8string ; syntax unspecified
+ ; A utf8string is defined to be the UTF-8 encoding of
+ ; one or more ISO 10646 characters.
+
+ ipAddress = IPv6address
+
+ ; following is excerpted from [IPV6]
+ IPv6address = hexpart [ ":" IPv4address ]
+ IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+ hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
+ hexseq = hex4 *( ":" hex4)
+ hex4 = 1*4HEXDIG
+
+ ipAddressRange = ipAddress [ HYPHEN ipAddress ] ; IPv6 address range
+
+ domainname = domaincomponent *( "." domaincomponent )
+
+ OUTER = ALPHA / DIGIT
+ INNER = ALPHA / DIGIT / HYPHEN
+ HYPHEN = %x2D
+ domaincomponent = OUTER [ *61( INNER ) OUTER ]
+
+
+Note that the colon following the "public" and "this" subject options
+exist only to simplify string parsing.
+
+If an ACI is attempted to be added with an authz that is not understood,
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 9]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+then the server MUST reject that entryACI or subEntryACI value. This
+clarifies the statement in [AuthMeth] that allows for authzId may be
+expanded in the future.
+
+See section titled 'ACI Examples' for examples of the string
+representation.
+
+
+
+4.1.2 ACI Binary Representation
+
+The ASN.1 type ACI is used to represent this syntax when transferred in
+binary form. This binary form SHOULD be supported.
+
+
+ LDAP-Access-Control-Model
+ DEFINITIONS EXTENSIBILITY IMPLIED ::=
+ BEGIN
+
+ IMPORTS
+ AttributeType, DistinguishedName, CONTEXT
+ FROM InformationFramework; -- from [X501]
+
+ ACI ::= SEQUENCE {
+ rights SEQUENCE {
+ grant Permissions OPTIONAL,
+ deny [1] Permissions OPTIONAL }
+ (WITH COMPONENTS { ..., grant PRESENT } |
+ WITH COMPONENTS { ..., deny PRESENT }),
+ -- at least one of grant or deny must be present --
+ attr CHOICE {
+ all NULL,
+ entry [1] NULL,
+ attributes SET (1..MAX) OF AttributeTypeAndOptions },
+ authnLevel ::= ENUMERATED {
+ none (0),
+ weak (1),
+ limited (2),
+ strong (3)}
+ subject GeneralSubject
+ }
+
+ -- An X.500 representation for an LDAP Attribute Description --
+ AttributeTypeAndOptions ::= SEQUENCE {
+ type AttributeType,
+ type-name UTF8String OPTIONAL,
+ -- A hint of what LDAP textual name to use when encoding an
+ -- AttributeTypeAndOptions as an <AttributeDescription>.
+ options SEQUENCE SIZE (1..MAX) OF CONTEXT.&Assertion OPTIONAL
+ -- A future revision will constrain CONTEXT.&Assertion to be
+ -- the context assertion syntax of the CONTEXT information
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 10]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ -- object defined by the X.500 working group to represent
+ -- LDAP attribute options in the X.500 protocols.
+ -- This is likely to be the UTF8String type.
+ }
+
+ GeneralSubject ::= CHOICE {
+ anySubject NULL,
+ machineSubject [1] MachineSubject,
+ idBasedSubject [2] IDBasedSubject
+ -- may be expanded per [AuthMeth] --
+ }
+
+ MachineSubject ::= CHOICE {
+ ipAddress IPAddress,
+ dns [1] DomainName
+ }
+
+ IPAddress ::= UTF8String
+
+ -- The character contents of an IPAddress string are encoded
+ -- according to the <ipAddress> rule in Section 4.1.1.
+
+
+ DomainName ::= UTF8String
+
+ -- The character contents of a DomainName string are encoded
+ -- according to the <partialdomainname> rule in Section 4.1.1.
+
+ IDBasedSubject ::= CHOICE {
+ thisSubject NULL,
+ oneSubject [1] OneSubject,
+ setOfSubjects [2] SetOfSubjects
+ }
+
+ OneSubject ::= CHOICE {
+ dn DistinguishedName,
+ user UTF8String
+ }
+
+ SetOfSubjects ::= CHOICE {
+ role DistinguishedName,
+ group [1] DistinguishedName,
+ subtree [2] DistinguishedName
+ }
+
+
+ Permissions ::= BIT STRING {
+ add (0),
+ delete (1),
+ export (2),
+ import (3),
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 11]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ renameDN (4),
+ browseDN (5),
+ viewEntry (6),
+ returnDN (7),
+ read (8),
+ search (9),
+ searchPresence (10),
+ write (11),
+ obliterate (12),
+ compare (13),
+ make (14),
+ unveil (15),
+ getEffectiveRights (16)
+ (CONSTRAINED BY { -- at least one bit must be set -- })
+ }
+
+ -- permissions read, write, obliterate, search,
+ -- searchPresence, compare, make work on attributes
+ -- permissions add, delete, export, import, renameDN,
+ -- browseDN, viewEntry, returnDN, unveil,
+ -- getEffectiveRights work on entries
+
+ END
+
+
+
+4.2 The Components of entryACI and subtreeACI Attributes
+
+This section defines components that comprise the access control
+information attributes, entryACI and subtreeACI.
+
+The access control information in the entryACI attribute applies only to
+the entry in which it is contained.
+
+The access control information in the subtreeACI attribute applies to
+each entry down the subtree unless it is overridden by an entry-specific
+entryACI whose values are more specific or another subtreeACI lower in
+the tree.
+
+Use of prescriptive ACIs and scoping via use of a ldapACISubEntry is
+outside the scope of this document.
+
+
+4.2.1 Access Rights and Permissions
+
+Access rights can apply to an entire object or to attributes of the
+object. Access can be granted or denied. Either or both of the actions
+"grant" | "deny" may be used when creating or updating entryACI and
+subtreeACI.
+
+Each of the LDAP access permissions are discrete. One permission does
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 12]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+not imply another permission. The permissions which apply to attributes
+and the entry parallel the type of ldap operations that can be
+performed.
+
+Permissions which apply to attributes:
+
+ r Read Read attribute values
+ w Write Modify-add values
+ o Obliterate Modify-delete values
+ s Search Search entries with specified
+ attributes
+ p searchPresence Presence only filters
+ c Compare Compare attributes
+ m Make Make attributes on a new entry below
+ this entry
+
+
+ 1. r Read
+
+ If granted, permits attributes and values to be returned in a read
+ or search operation.
+
+ 2. w Write
+
+ If granted, permits attributes and values to be added in a
+ modify-add operation.
+
+ 3. o Obliterate
+
+ If granted, permits attributes and values to be deleted in a
+ modify-delete operation.
+
+ 4. s Search
+
+ If granted, permits attributes and values to be included in the
+ search filter of a search operation.
+
+ 5. c Compare
+
+ If granted, permits attributes and value to be used in a compare
+ operation.
+
+ 6. p SearchPresence
+
+ If granted permits attributes and values to be included in
+ presence tests in a search filter.
+
+ 7. m Make
+
+ The attribute permission "m" is required for all attributes that
+ are placed on an object when it is created. Just as the "w" and
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 13]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ "o" permissions are used in the Modify operation, the "m"
+ permission is used in the Add operation. Additionally, note that
+ "w" and "o" have no bearing on the Add operation and "m" has no
+ bearing on the Modify operation. Since a new object does not yet
+ exist, the "a" and "m" permissions needed to create it must be
+ granted on the new object's parent. This differs from "w" and "o"
+ which must be granted on the object being modified. The "m"
+ permission is distinct and separate from the "w" and "o"
+ permissions so that there is no conflict between the permissions
+ needed to add new children to an entry and the permissions needed
+ to modify existing children of the same entry.
+
+Note: Modify-replace values of an attribute require both "w" and "o"
+permission.
+
+Permissions that apply to an entire entry:
+
+ a Add Add an entry below this entry
+ d Delete Delete this entry
+ e Export Export entry & subordinates to new
+ location
+ i Import Import entry & subordinates below this
+ entry from some location
+ n RenameDN Rename an entry's DN
+ b BrowseDN Browse an entry's DN
+ v ViewEntry A read level entry permission
+ t ReturnDN Allows DN of entry to be disclosed in
+ an operation result
+ u Unveil This is the discloseOnError permission
+ g GetEffectiveRights This is get effective rights
+ permission
+
+
+ 1. a Add
+
+ If granted, permits creation of an entry in the DIT subject to
+ access control on all attributes and values to be placed in the
+ new entry at time of creation. In order to add an entry,
+ permission must also be granted to add all attributes that exist
+ in the add operation.
+
+ 2. d Delete
+
+ If granted, permits the entry to be removed from the DIT
+ regardless of controls on attributes within the entry. Delete
+ only works on leaf entries (same as X.500).
+
+ 3. e Export
+
+ If granted, permits an entry and its subordinates (if any) to be
+ exported; that is, removed from the current location and placed in
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 14]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ a new location subject to the granting of suitable permission at
+ the destination. If the last RDN is changed, Rename is also
+ required at the current location. In order to export an entry or
+ its subordinates, there are no prerequisite permissions to
+ contained attributes, including the RDN attributes; this is true
+ even when the operation causes new attribute values to be added or
+ removed as the result of the changes of RDN.
+
+ 4. i Import
+
+ If granted, permits an entry and its subordinates (if any) to be
+ imported; that is, removed from some other location and placed
+ below the location to which the permission applies subject to the
+ granting of suitable permissions at and below the source location.
+ In order to import an entry or its subordinates, there are no
+ prerequisite permissions to contained attributes, including the
+ RDN attributes; this is true even when the operation causes new
+ attribute values to be added or removed as the result of the
+ changes of RDN.
+
+ 5. n RenameDN
+
+ Granting Rename is necessary for an entry to be renamed with a new
+ RDN. There are many cases here surrounding the use of this
+ permission. See the section on 'Modify DN Operation'.
+
+ 6. b BrowseDN
+
+ If granted, permits entries to be accessed using directory
+ operations which do not explicitly provide the name of the entry.
+
+ 7. v ViewEntry
+
+ If granted, permits entries to be accessed. This entry level read
+ permission is useful as it is not dependent on the scope or
+ aliasing properties of the entry.
+
+ 8. t ReturnDN
+
+ If granted, allows the distinguished name of the entry to be
+ disclosed in the operation result.
+
+ 9. u Unveil
+
+ If granted, allows the presence of the entry to be disclosed in
+ the case where access is denied to the entry according to the
+ access control rules.
+
+ 10. g getEffectiveRights
+
+ If granted, allows the effective rights on that entry and the
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 15]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ attributes within that entry to be returned, for _any_ subject.
+
+
+4.2.2 Attributes
+
+Attribute describes an attribute name in the form of a dotted decimal
+OID for that <attr>. If the string (OID) refers to an attribute not
+defined in the given server's schema, the server SHOULD report an error.
+The use of "[entry]" or "[all]" helps to focus the permissions to either
+entry or attribute quickly, and hence helps in parsing.
+
+"[entry]" means the permissions apply to the entire object. This could
+mean actions such as delete the object, or add a child object. When
+used in subtreeACI, the specified permissions (on the entry set of
+permissions are legal here - see the ABNF) apply to each entry in the
+subtree.
+
+"[all]" means the permission set applies to all attributes of the entry.
+When used in subtreeACI, "[all]" applies to all attributes of each entry
+in the subtree.
+
+If the keyword "[all]" and another attribute are both specified within
+an ACI, the more specific permission set for the attribute overrides the
+less specific permission set for "[all]".
+
+
+4.2.3 Subjects and Associated Authentication
+
+The following subjects are defined and MUST be supported:
+
+ - authzId, defined per [AuthMeth]
+
+ - group, defined as the distinguished name of a groupOfNames or
+ groupOfUniqueNames entry
+
+ - role, asserts a subject's organizational position and entitlement
+ to perform the operations appropriate to that organizational
+ position. It is implementation defined how the association between
+ authorization id and the role dn is made.
+
+ - subtree, defined as some distinguished name of a non-leaf node in
+ the DIT
+
+ - ipAddress, in IPv6 text format [IPV6]
+
+ - dnsName, a domain name or a wildcarded (left-most name or most
+ specific part) domain name (see ABNF)
+
+ - public, defined as public access
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 16]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ - this, defined as the user whose name matches that of the entry
+ being accessed
+
+Other parties MAY define other subjects. It is the responsibility of
+those parties to provide the definition. Adding new subjects may
+inhibit interoperability.
+
+A subject may be qualified by the level of authentication required for
+access to a given attribute(s) or entry. authnLevel defines the minimum
+requestor authentication level required for a given ACI. For a
+requestor's authentication level to exceed a minimum requirement, the
+requestor's level must meet or exceed that specified in the ACI.
+
+The authentication levels defined, in increasing order of
+authentication, are:
+
+ - none - no name and no password, or name but no password
+
+ - weak - authentication mechanisms that are prone to both passive and
+ active attacks [ATTACK]; for example, simple authentication (name
+ and password)
+
+ - limited - authentication mechanisms that protect against passive
+ attacks but may be prone to active attacks; for example, DIGEST-MD5
+
+ - strong - authentication mechanisms that protect against both
+ passive and active attacks; for example, Kerberos with per-
+ authentication or PKI authentication
+
+The authnLevel applies to a subject as follows:
+
+ - If the ACI is a grant, then the authnLevel applies if the subject
+ is authenticated at or above that level.
+
+ - If the ACI is a deny, then the authnLevel applies to that subject
+ if authenticated at that level AND to all other subjects
+ authenticated with levels below that.
+
+Authentication level is always specified in an ACI. For grant, this
+means that you are granted access if you can prove your authentication
+via a strong authentication mechanism, such as a digital signature. For
+deny, the meaning of this is "you are denied access if you are Mr. X and
+you can prove it with a digital signature". If you are not Mr. X you
+are not denied access only if you can prove it (authenticate yourself)
+with a digital signature. In other words, everyone who does not
+authenticate with a digital signature is denied access. Everyone who
+authenticates with a digital signature is allowed access except Mr. X.
+
+A recommended categorization of authentication mechanisms per
+authentication level may be offered separately. For each mechanism
+categorized in the recommendations, implementations SHOULD NOT assign a
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 17]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+higher authentication level, but MAY assign a lower authentication
+level. For mechanisms not covered by the recommendation, the
+implementation SHOULD specify a conservative level. Implementations
+SHOULD provide a means for the directory administrator to disable and/or
+lower the authentication level associated with a mechanism.
+
+Two interesting subjects not explicitly included, but can be composed
+using subject and authnLevel are anonymous and authenticated.
+
+ - anonymous: authnLevel=none + anySubject(public)
+
+ - authenticated: authnLevel=weak + anySubject(public)
+
+
+4.3 Access Control Decision Making
+
+The ultimate goal of the Access Control Model is to define the way in
+which an LDAP server determines an access control decision for a given
+requested LDAP operation. In fact, a requestor may require several
+individual permissions in order to be authorized to carry out an LDAP
+operation and we define these in section 5. In this section we
+introduce the concepts and algorithm that allow the server to decide if
+a requestor has an individual permission on an individual resource. The
+concepts we require are firstly, the parameters which must be provided
+in order for the Access Control Decision Algorithm to determine whether
+the access is allowed or not. Secondly, we define precisely when a
+given ACI value will be involved in a given access control decision.
+Thirdly, this model defines some precedence rules which the Algorithm
+will use when dealing with more than one ACI value. Finally, we can
+define the Access Control Decision Algorithm which will determine the
+access decision. Throughout, we use the ABNF, when we need to refer to
+portions of individual ACI values.
+
+4.3.1 The Parameters to the Access Decision Algorithm
+
+The decision algorithm answers the question "Does the specified
+requestor have the specified permission on the specified resource?" The
+resource may be an entry (as for the Delete operation) or it may be an
+attribute within an entry (as for the Modify operation) so we
+characterize the resource like this: (targetEntry, targetAttribute
+OPTIONAL).
+
+The requestor is identified primarily by his authorization ID (which may
+be omitted if the requestor has bound anonymously), but also includes
+other context information about the requestor so it is represented like
+this: (authzId OPTIONAL, ipAddress, dnsName, authnLevel).
+
+The permission is one of the valid permissions defined by the model.
+
+So, the parameters to the Access Control Decision Algorithm, which we
+will refer to collectively as "the decision parameters" are:
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 18]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ - resource: (targetEntry, targetAttribute OPTIONAL)
+
+ - permission: permissionParameter
+
+ - requestorSubject: (authzId OPTIONAL, ipAddress, dnsName,
+ authnLevel)
+
+If permissionParameter is an attribute-level parameter then
+targetAttribute must be specified; if it is an entry-level permission
+then targetAttribute is ignored.
+
+The output is either "Access Allowed" or "Access Denied".
+
+
+4.3.2 Applicability Rules
+
+The applicability rules define whether a given ACI value, or portions of
+it, apply to some given decision parameters.
+
+
+4.3.2.1 Applicability Rules for Scope Types
+
+These rules determine whether a specific ACI applies to the targetEntry
+part of the decision parameters.
+
+ - If the ACI in question is an entryACI, then ACI applies to the
+ resource if the ACI is an attribute of the entry targetEntry.
+
+ - If the ACI in question is a subtreeACI, then ACI applies to the
+ resource if targetEntry is part of the subtree defined by the entry
+ containing the ACI.
+
+
+4.3.2.2 Applicability Rules for Permissions
+
+If permissionParameter is an entry-level permission, then the ACI in
+question applies if permissionParameter is mentioned in the permissions
+list of the ACI.
+
+If permissionParameter is an attribute-level permission, then the ACI in
+question applies if permissionParameter is mentioned in the permissions
+list and the ACI's attribute list applies to the target attribute per
+"Applicability Rules for Attributes".
+
+Note that for an ACI which contains both grant and deny permissions
+lists, the grant permission list may not be available for the purposes
+of this applicability rule--see point 3 in the "Applicability Rules for
+Subjects".
+
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 19]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+4.3.2.3 Applicability Rules for Attributes
+
+If an attribute is not specified as part of the resource, then this rule
+does not apply. If an attribute is specified, then the ACI in question
+applies if its attribute list is [all] or if targetAttribute is
+explicitly mentioned in the ACI's attribute list.
+
+In the case where targetAttribute is an attribute type with options
+(e.g. sn;lang-en;lang-uk), it is applicable if the ACI's attribute list
+mentions a less specific form of targetAttribute. For example, if the
+list contained "sn;lang-en", then that list applies to the attribute
+"sn;lang-en;lang-uk", but not the attribute "sn".
+
+4.3.2.4 Applicability Rules for Subjects
+
+Call the subject portion of the ACI in question aciSubject. Then to
+determine if aciSubject applies to requestorSubject we apply the
+following rules:
+
+ 1. The ACI in question is a grant ACI. Then the ACI applies if both
+ the context and pureSubject portions of aciSubject apply, as
+ defined in "Applicability Rules for Context" and "Applicability
+ Rules for pureSubject" below.
+
+ 2. The ACI in question is a deny ACI. There are three possibilities:
+
+ a. The pureSubject part applies (according to "Applicability
+ Rules for pureSubject"). Then the ACI applies to
+ requestorSubject.
+
+ b. The pureSubject part does not apply. Then the ACI applies
+ to any requestorSubject with an authnLevel less than the
+ authnLevel of the ACI.
+
+ c. Otherwise the ACI does not apply.
+
+ 3. The ACI in question is both a deny and grant ACI. There are three
+ possibilities:
+
+ a. aciSubject applies when evaluated as a grant ACI (per 1
+ above). Both the grant permissions and deny permissions of
+ the ACI are available for the purpose of the "Applicability
+ Rules for Attributes and Permissions".
+
+ b. aciSubject does not apply as a grant ACI but does apply as a
+ deny ACI (per 2 above). The deny permissions of the ACI are
+ available for the purpose of the "Applicability Rules for
+ Attributes" and the "Applicability Rules for Permissions".
+
+ c. aciSubject does not apply when evaluated as either a grant
+ ACI or a deny ACI. The ACI does not apply to
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 20]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ requestorSubject.
+
+Note: the deny behavior with authnLevel deserves explication. In the
+case where an ACI denies access to a given subject with a given
+authnLevel, then naturally it will deny access to that given subject
+authenticated at authnLevel or above. Similarly, another user
+authenticated at authnLevel or above, to which the pureSubject part does
+not apply, will not be denied those rights by that ACI.
+
+The interesting case is a user authenticated at a lower level than
+authnLevel. For such a user the ACM takes the view that as that user
+has not proved to the system, to a sufficient degree of confidence, that
+the pureSubject portion does not apply to him, then to be safe, he will
+be denied those rights.
+
+So if you deny access to a particular authzId with authnLevel of "none",
+then that authzId will be denied access at any authentication level, but
+it will not affect any other requestors. On the other hand, if you deny
+access to a particular authzId with an authnLevel of "strong", then that
+will deny access to that user when authenticated strongly AND deny
+access to ANY users authenticated with lower authentication levels.
+
+
+4.3.2.5 Applicability Rules for pureSubject
+
+If aciSubject is of type anySubject, then it applies to
+requestorSubject.
+
+If aciSubject is of type machineSubject, then if the ipAddress or dns
+name from requestorSubject matches the ipAddress or dns name range in
+aciSubject, then the ACI applies to requestorSubject if it is a deny ACI
+or the deny part of a grant/deny ACI. A grant ACI (or the grant part of
+a grant/deny ACI) never applies if the subject is ipAddress: or dns:.
+The note at the end of the "Precedence of Subjects within a Scope"
+explains the reasoning behind this rule.
+
+If the aciSubject is of type idBasedSubject, then it applies according
+to the definition in "Applicability Rules for idBasedSubject".
+
+4.3.2.6 Applicability Rules for Context
+
+The context of aciSubject applies to requestorSubject if authnLevel from
+requestorSubject is greater than or equal to the authnLevel specified in
+the context part of aciSubject.
+
+
+4.3.2.7 Applicability Rules for idBasedSubject
+
+If idBasedSubject is of type thisSubject, then it applies to
+requestorSubject if authzId from requestorSubject is of type "dn" and is
+equal to the DN of the resource.
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 21]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+If idBasedSubject is of type oneSubject, then it applies to
+requestorSubject if authzId from requestorSubject is equal to the
+authzId specified in aciSubject.
+
+If idBasedSubject is of type setOfSubjects, then it applies to
+requestorSubject if authzId from requestorSubject is defined to be in
+the set specified in aciSubject (i.e. is in that group, role or
+subtree). The "Precedence of Subjects within a Scope" includes rules
+for determining membership in a setOfSubjects.
+
+
+4.3.3 Precedence Rules
+
+The precedence rules allow the Access Control Decision Algorithm to
+determine which ACI values should take precedence over others.
+
+
+4.3.3.1 Precedence of Scope Types
+
+
+ 1. Entry
+
+ 2. Subtree
+
+
+4.3.3.2 Precedence of Position in the DIT
+
+For a given subject DN (including authentication level) and target DN,
+subtreeACI lower in the tree take precedence over those higher in the
+tree.
+
+
+4.3.3.3 Precedence of Subjects within a Scope
+
+
+ 1. ipAddress or dns in a deny ACI or the deny part of a grant/deny
+ ACI
+
+ 2. authzId distinguished name ("authzId-dn:") or authzId userid
+ ("authzId-u:")
+
+ 3. this
+
+ 4. role
+
+ If the DN of a role or a group appears in a role (e.g. appears as
+ a value of roleOccupant in an organizationalRole), it is
+ recursively expanded. For determination of precedence, the
+ resulting expanded collection of names is considered to have come
+ from a role regardless of the original source.
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 22]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ 5. group
+
+ If the DN of a role or a group appears in a group, it is
+ recursively expanded. For determination of precedence, the
+ resulting expanded collection of names is considered to have come
+ from a group regardless of the original source.
+
+ 6. subtree
+
+ Subtrees may contain groups and/or roles. They should be
+ recursively expanded. For determination of precedence, members of
+ groups or occupants of roles that apply because (after recursive
+ expansion) the group or role is contained in a subtree are
+ considered to have come from the subtree regardless of the
+ original source.
+
+ 7. public
+
+The precedence of ipAddress and DNS names are treated specially, and
+depend on the type of ACI involved. Typical situations are:
+
+ - If an ACL says to grant on the basis of IP address but deny on the
+ basis of some other attribute (username, group, etc....), then the
+ behavior we want is "deny". Rationale: the user is prohibited from
+ access, regardless of where he's sitting.
+
+ - If an ACL says to deny on the basis of IP address but grant on the
+ basis of some other attribute (username, group, etc....), then the
+ behavior we want is also "deny". Rationale: the user is allowed
+ access, but not from where he's sitting.
+
+In addition, a grant to an ipAddress with no other applicable ACI is
+very dangerous from a security point of view, since it would grant
+permissions to ANY user who has access to the machine with the given
+address. Thus ipAddress and dns subjects can be used only to deny
+permission, not to grant them. The "Applicability Rules for
+pureSubject" enforce this.
+
+
+4.3.3.4 Precedence of Attribute Specifications
+
+Access controls specifying "[all]" attributes are of lower precedence
+than specific lists.
+
+
+4.3.3.5 Precedence of grant/deny
+
+Deny takes precedence over grant.
+
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 23]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+4.3.3.6 Default
+
+Deny is the default when there is no access control information or when
+evaluation of the access control information yields no result that
+allows the requester access.
+
+
+4.3.4 Access Control Decision Algorithm
+
+The Access Control Decision Algorithm takes as input the decision
+parameters defined above and produces a grant or a deny decision.
+
+In the case where we are interested in the permission set for a set of
+entries and attributes (as in the case of evaluating the effective
+rights in section 9), then we must apply the algorithm for each
+entry/attribute and permission pair we are interested in. Naturally
+implementers are free to implement any algorithm which produces the same
+decision given the same input and ACI values in a DIT.
+
+The algorithm has two phases. First, all the potentially applicable ACI
+values are sorted into an ordered list of sets of ACI values of the same
+precedence. Then this list is scanned in order to find the set of ACIs
+which will determine the access decision.
+
+Phase 1: Order the potentially applicable ACI values
+
+ 1. Determine all the entryACI and subtreeACI values that apply to
+ targetEntry, according to the "Applicability Rules for Scope
+ Types".
+
+ 2. Sort these ACIs into a list of sets of ACIs of equal precedence,
+ according to the "Precedence of Scope Types" and "Precedence of
+ Position in the DIT" rules.
+
+ 3. Determine which of the collected ACI values from step 1 apply to
+ requestorSubject using the "Applicability Rules for Subjects".
+ All the ACI values which do not apply to this subject are
+ discarded.
+
+ 4. The list of sets is sorted according to subject type from the
+ "Precedence of Subjects within a Scope" rules.
+
+ 5. Now we split the list into two separate lists keeping the same
+ relative ordering of sets--one list has the sets that just contain
+ ACI values that refer to entry-level permissions and the other has
+ the sets that just contain ACI values that refer to attribute-
+ level permissions.
+
+ 6. Each set in the attribute-level list of sets is further divided
+ into a list of sets of equal precedence according to "Precedence
+ of Attributes Specification".
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 24]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+Note: At this point we have two lists of sets of ACI values, one dealing
+with entry-level permissions the other dealing with attribute-level
+permissions. The lists have been sorted according to Scope, Position,
+Subject and (for the attribute-level list) Attribute Specification
+precedence rules.
+
+Phase 2: Scan the lists to determine the access decision:
+
+ 1. If permissionParameter is an entry-level permission (so that the
+ optional targetAttribute field is not specified), then scan the
+ list of entry-level sets in order. The first set in the list that
+ contains an ACI that applies to permissionParameter (as defined in
+ the "Applicability Rules for Permissions" rules) determines the
+ access decision--if an ACI in the set grants permissionParameter
+ and no other denies it, then access is granted, otherwise access
+ is denied.
+
+ 2. If permissionParameter is an attribute-level permission then scan
+ the list of attribute-level sets in order. The first set in the
+ list that contains an ACI that applies to permissionParameter AND
+ applies to targetAttribute (as defined in the "Applicability Rules
+ for Attributes" and "Applicability Rules for Permissions")
+ determines the access decision--if an ACI in the set grants
+ permissionParameter and no other denies it, then access is
+ granted, otherwise access is denied.
+
+
+4.3.5 Precedence/Inheritance Access Decision Example
+The examples in this section refer to the following directory tree:
+
+ dc=com
+ |
+ +--------+---------------+
+ | |
+ dc=tivoli dc=sun
+ | |
+ cn=ellen cn=rob
+
+The ACI at dc=com:
+
+ 1. subtreeACI:grant:rsc#[all]#authnLevel:none:public:
+ 2. subtreeACI:deny:rsc#userPassword,subtreeACI,entryACI,salary#
+ authnLevel:none:public:
+ 3. subtreeACI:grant:bvt#[entry]#authnLevel:none:public:
+ 4. subtreeACI:grant:rscmow#[all]#authnLevel:strong:
+ authzID-dn:cn=rob,dc=sun,dc=com
+ 5. subtreeACI:grant:bvtugeinad#[entry]#authnLevel:strong:
+ authzID-dn:cn=rob,dc=sun,dc=com
+
+The ACI at dc=tivoli,dc=com:
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 25]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ 6. subtreeACI:grant:rsc;deny:mow#[all]#authnLevel:strong:
+ authzID-dn:cn=rob,dc=sun,dc=com
+ 7. subtreeACI:deny:einad#[entry]#authnLevel:strong:
+ authzID-dn:cn=rob,dc=sun,dc=com
+
+The ACI at cn=ellen,dc=tivoli,dc=com
+
+ 8. entryACI:grant:wo#[all]#authnLevel:strong:
+ authz-ID-dn:cn=ellen,dc=tivoli,dc=com
+ 9. entryACI: deny: wo#entryACI,subtreeACI,salary#authnLevel:strong:
+ authz-ID-dn:cn=ellen,dc=tivoli,dc=com
+
+Example #1
+
+ subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, strong):
+ resource: ("cn=ellen,dc=tivoli,dc=com", salary)
+ permission: "w"
+
+Phase 1: Find all applicable ACI based on the Applicability of Scope
+ Types.
+
+ {1, 2, 3, 4, 5, 6, 7, 8, 9}
+
+ Sort by Precedence of Scope Type and Precedence of Position in
+ DIT:
+
+ {8, 9}, {6, 7}, {1, 2, 3, 4, 5}
+
+ Determine which ACI are applicable based on the Subject:
+
+ {6, 7}, {1, 2, 3, 4, 5}
+
+ Sort by Precedence of Subjects within Scope:
+
+ {6, 7}, {4, 5}, {1, 2, 3}
+
+ Separate permissions applicable to entry and those applicable
+ to attributes:
+
+ Entry: {7}, {5}, {3}
+ Attr: {6}, {4}, {1, 2}
+
+ Sort the permissions applicable to attributes by precedence of
+ attribute specification:
+
+ Entry: {7}, {5}, {3}
+ Attr: {6}, {4}, {2}, {1}
+
+Phase 2: Since "w" is an attribute permission, look at the Attr list.
+ ACI 6 in the first sub-list mentions "w" and salary (via
+ [all]) so this set defines the access--which is deny.
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 26]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+Example #2
+
+ subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
+ resource: ("cn=ellen,dc=tivoli,dc=com", salary)
+ permission: "w"
+
+Phase 1: First the ACIs are ordered into the following sets whose
+ subject matches the subject tuple:
+
+ Entry: {7}, {3}
+ Attr: {6}, {2}, {1}
+
+Phase 2: For ACI 6 in the first set, which matched the subject because
+ of the deny portion and limited < strong, the permissions
+ available are "mow". So, this ACI applies to "w" and salary
+ (via [all]) and the access is "deny".
+
+Example #3
+
+ subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
+ resource: ("cn=ellen,dc=tivoli,dc=com", salary)
+ permission: "r"
+
+Phase 1: First the ACIs are ordered into the following sets whose
+ subject matches the subject tuple:
+
+ Entry: {7}, {3}
+ Attr: {6}, {2}, {1}
+
+Phase 2: As the grant portion of ACI 6 is not active, the first set
+ that contains an ACI that applies to "r" and salary is {2}.
+ As 2 denies access, access is denied.
+
+Example #4
+
+ subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
+ resource: ("cn=ellen,dc=tivoli,dc=com", cn)
+ permission: "r"
+
+Phase 1: First the ACIs are ordered into the following sets whose
+ subject matches the subject tuple:
+
+ Entry: {7}, {3}
+ Attr: {6}, {2}, {1}
+
+Phase 2: As the grant portion of ACI 6 is not active, the first set
+ that contains an ACI that applies to "r" and cn is {1}. As 1
+ grants access, access is granted.
+
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 27]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+5. Required Permissions for each LDAP Operation
+
+This section defines the required permissions for each LDAP operation.
+Even if these requirements are satisfied, the server may refuse to carry
+out the operation due to other implementation specific security
+considerations. For example, a server may refuse to modify an entry
+because the database where that entry resides is in read only mode.
+Another example might be that although LDAP access control has been
+specified on the userPassword attribute a server may refuse
+modifications due to some server specific policy governing access to
+passwords.
+
+Here, we specify the rights required by a user when performing an LDAP
+operation in terms of the LDAP permissions specified above. Recall that
+"a, d, e, i, n, b, v, t, u" are permissions that apply to entries as a
+whole while permissions "r, s, p, w, o, c, m, g" apply to attributes
+within entries.
+
+Required permissions for LDAP extended operations and LDAP controls
+SHOULD be defined along with their specifications. These requirements
+could be expressed in terms of this model, for example by requiring one
+of the existing permissions on some particular entry or attribute. This
+version of the LDAP access control model does not offer any mechanism to
+extend the permission set or aci syntax to accommodate extended
+operations or controls.
+
+For the following, assume that the authorization identity of the user
+doing the operation is authzId.
+
+
+5.1 Bind Operation
+
+This model does not require any permissions to allow a bind operation to
+proceed.
+
+
+5.2 Search Operation
+
+Recall that the parameters of the Search operation per RFC 2251 [LDAPv3]
+Section 4.5 are:
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 28]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
+
+Suppose a server is processing a search request from user authzId with
+parameters as above and is processing the entry with dn candidateDN to
+decide if it may be returned or not.
+
+Then the permissions required by authzId that need to be evaluated are
+as follows:
+
+
+ 1. permission "b" to the entry candidateDN if the entry is in the
+ scope of the search but is not the base entry.
+
+ If this permission is not granted then the dn candidateDN MUST NOT
+ be returned nor any attribute type nor attribute value from this
+ entry.
+
+ Note: the "b" permission is included to allow different browsing
+ or discovery rights to be assigned to different classes of users.
+
+ 2. permission "v" to the entry candidateDN
+
+ If this permission is not granted then the dn candidateDN MUST NOT
+ be returned nor any attribute type nor attribute value from this
+ entry.
+
+ Note A: The "v" permission is the entry level read permission.
+ This is included as it is useful to have one simple permission
+ (not dependent on scope or aliasing) that protects all the
+ components of an entry; the dn and the attributes.
+
+ Note B: Disclosing the full distinguished name of an entry will
+ inevitiably reveal the names of its ancestors. This issue is
+ discussed in detail below.
+
+ 3. permission "p" or "s" to each attribute appearing in a search
+ filter presence test during the evaluation of the search filter.
+ permission "s" is required on attributes appearing in non-presence
+ tests (see RFC2254, section 3: equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, present, approxMatch,
+ extensibleMatch) during the evaluation of the search filter.
+
+ The above statement covers the case where the attributes are being
+ evaluated as part of an extensibleMatch (RFC 2251 section 4.5.1)
+ which appears in the filter. In the case where the dnAttributes
+ field of the extensibleMatch is true (and so the filter test is
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 29]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ applied to the naming attributes in the dn of the entry) then we
+ do not require any access checks to the attributes of the dn as
+ access to these is taken to be granted by the "v" permission,
+ which has already been required above.
+
+ If there is an attribute in a filter element to which the required
+ permission is not granted then that filter element evaluates to
+ "Undefined" of the three-valued-logic of X.511(93).
+
+ Note: The motivation for the "p" permission is that if you have
+ full filter rights on an attribute then in some cases that could
+ be operationally the same as having read permission i.e. you could
+ quickly determine the attribute value, and this may not be
+ desirable. For example, if the type of the attribute was integer
+ then with full filter permissions you could quickly determine the
+ value by doing a sequence of binary chop style searches using ">"
+ and "<". Whereas, with just the presence test ability, you would
+ not have right to do those kind of searches, but you would be able
+ to test for the presence of the attribute.
+
+ 4. permission "r" to each attribute in the attribute list
+ AttributeDescriptionList (or all attributes in the entry
+ candidateDN if AttributeDescriptionList is *) whose type and/or
+ value will be returned.
+
+ Note A: The presence of an attribute in an entry is only ever
+ volunteered by the server if "r" permission is granted to it,
+ though a user may infer the presence of an attribute with "s" or
+ "p" permission by using a presence test on that attribute in the
+ search filter.
+
+ Note B: Although both "r" and "s" permissions will typically be
+ granted to attributes we keep both permissions as there are cases
+ where the distinction is useful. A reverse telephone lookup is an
+ example of granting "r" but not "s" permission.
+
+ 5. permission "t" to the entry candidateDN
+
+ If this permission is not granted then the dn candidateDN MUST NOT
+ be returned. If the server knows of an alias for the entry, this
+ alias may be returned instead. If no alias name is available then
+ the entry candidateDN MUST be omitted from the search results.
+
+ Note: Disclosing the full distinguished name of an entry will
+ inevitiably reveal the names of its ancestors. This issue is
+ discussed in detail below.
+
+ 6. Disclose on error for the Search operation
+
+ If there is no entry in the scope of the search which satisfies
+ item 1 (browse right on the candidate entry) and item 2 (read
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 30]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ level permission on the entry) and item 3 (right to use the filter
+ on that entry) then the "u" permission on the base entry must be
+ evaluated. If "u" (disclose on error) is not granted to the base
+ entry then the operation MUST fail with a "no such object error"
+ and the matchedDN of the LDAPResult MUST be set to "". If "u" is
+ granted to the baseObject then the empty set of results is
+ returned.
+
+ Note: the point here is that if you do not have the right to
+ discover at least one entry in the scope of the search then the
+ disclose on error mechanism is there to prevent you discovering
+ the base entry of the search. The "t" permission is not
+ considered here as it is not conceptually a permission involved in
+ the discovery of entries but rather in how they are returned (dn
+ vs. alias).
+
+
+5.2.1 Protecting the naming attributes of DNs
+
+Protecting the naming attributes in an entry's dn presents a problem for
+access control. The issue is that if access is granted to the dn of a
+given entry, then via the naming attributes this dn contains, access is
+also also granted to attribute values in other entries. In addition,
+knowledge about the existence of ancestor entries of a given entry is
+also disclosed by the entry's dn.
+
+It could be argued that there should be consistency in the ability of a
+given requestor to see attribute values in the dn of an entry and his
+ability to see those attributes in the entry where they actually reside.
+Similarly, it could be argued that there should be consistency in the
+ability of a requestor to see an entry and his ability to see its
+ancestor entries.
+
+The main reason we do not require such cross checking of permissions is
+because of the extra work it entails for the server. There is a trade
+off between the consistency this cross checking guarantees and the work
+it takes to do that cross checking.
+
+For LDAP servers the trade off has been to go in favor of speed. In
+addition there are some other points which mitigate these kind of
+inconsistencies. Firstly, it appears to be difficult to produce a real
+world example where they really cause a problem. Secondly there are
+other methods of hiding DNs (and hence protecting the naming attribute
+and ancestor information they contain) which are outside the scope of
+access control, for example aliasing and LDAP proxying.
+
+
+5.3 Modify Operation
+
+Recall that the parameters of the Modify operation per RFC2251 [LDAPv3]
+Section 4.6 are:
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 31]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+Then the permissions required by authzId that need to be evaluated are
+as follows:
+
+
+ 1. permission "w" to each attribute being added to object
+
+ If this permission is not granted to such an attribute, then the
+ operation MUST fail.
+
+ 2. permission "o" to each attribute for which a value is being
+ deleted from object
+
+ If this permission is not granted to such an attribute, then the
+ operation MUST fail.
+
+ 3. permissions "o" and "w" to each attribute being replaced in object
+
+ If each of these items is satisfied then the operation is allowed
+ by the access control model. If one of these items is not
+ satisfied, then the operation MUST fail. In this case, if "u"
+ (discloseOnError) is granted to object, then the usual error codes
+ (such as noSuchObject, attributeOrValueExists, noSuchAttribute and
+ insufficientAccess) and matchedDN value may be returned; if "u" is
+ not granted to object then nosuchObject MUST be returned and
+ matchedDN set to "".
+
+
+5.4 Add Operation
+
+Recall that the parameters of the Add operation per RFC2251 [LDAPv3]
+Section 4.7 are:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 32]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ vals SET OF AttributeValue }
+
+Then the permissions required by authzId that need to be evaluated are
+as follows:
+
+
+ 1. permission "a" to the parent of entry
+
+ The access rights required for the creation of a root entry in the
+ Directory are beyond the scope of this document. They will be
+ vendor specific.
+
+ 2. permission "m" to the parent of entry for each attribute being
+ added to entry
+
+If each of these items is satisfied then the operation is allowed by the
+access control model. If one of these items is not satisfied, then the
+operation MUST fail. In this case, if "u" (discloseOnError) is granted
+to the parent of entry, then the usual error codes (such as
+noSuchObject, entryAlreadyExists, and insufficientAccess) and matchedDN
+value may be returned; if "u" is not granted to the parent of entry,
+then nosuchObject MUST be returned and matchedDN set to "".
+
+Note A: We require "m" permission to each attribute to prevent an entry
+from acquiring "unintended" rights (via group or role membership), to
+stop a "rogue" ACI being added that would prevent even admins deleting
+the entry, and for general consistency with the MODIFY operation.
+
+
+5.5 Delete Operation
+
+Recall that the parameters of the Delete operation per RFC2251 [LDAPv3]
+Section 4.10 are:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+Then the permissions required by authzId that need to be evaluated are
+as follows:
+
+
+ 1. permission "d" to the entry in the Delete request
+
+If each of these items is satisfied then the operation is allowed by the
+access control model. If one of these items is not satisfied, then the
+operation MUST fail. In this case, if "u" (discloseOnError) is granted
+to the entry to be deleted, then the usual error codes (such as
+noSuchObject, and insufficientAccess) and matchedDN value may be
+returned; if "u" is not granted to object then nosuchObject MUST be
+returned and matchedDN set to "".
+
+Note: One could also require the "o" permission to be granted to allow
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 33]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+the operation to proceed, but customer experience has shown that the
+requirement of the additional permission is not useful nor expected, and
+X.500 requires only the "d" permission.
+
+
+5.6 Modify DN Operation
+
+Recall that the parameters of the Modify DN operation per RFC2251
+[LDAPv3] Section 4.6 are:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+The variants of the ModifyDN operation are listed below. Combinations
+of the write, obliterate, import, export and renameDN permissions are
+needed for each variant.
+
+ 1. Rename an entry by moving the conceptual RDN flag between two
+ existing attribute values, without altering any attribute values
+ at all. Permissions needed are renameDN.
+
+ 2. Rename an entry by adding a new attribute value. Permissions
+ needed are renameDN and write.
+
+ 3. Rename an entry using an existing attribute value and delete the
+ current attribute value. Permissions needed are renameDN and
+ obliterate.
+
+ 4. Rename an entry adding a new attribute value and deleting the
+ current attribute value. Permissions needed are renameDN, write,
+ and obliterate.
+
+ 5. Move an entry to a new place in the DIT, keeping its existing RDN
+ as is. Permissions needed are import and export.
+
+ 6. Move an entry to a new place coupled with 1. above Permissions
+ needed are import, export, and renameDN.
+
+ 7. Move coupled with 2. above. Permissions needed are import,
+ export, renameDN, and write.
+
+ 8. Move coupled with 3. above. Permissions needed are import,
+ export, renameDN, and obliterate.
+
+ 9. Move coupled with 4. above. Permissions needed are import,
+ export, renameDN, write, and obliterate.
+
+For a given case, if the required permissions are granted, then the
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 34]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+operation is allowed by the access control model. If, for a given case,
+the required permissions are not granted, then the operation MUST fail.
+If the access control failure is due to a missing attribute or entry
+permission on entry, then if "u" (discloseOnError) is granted to entry,
+then the usual error codes (such as noSuchObject, attributeOrValueExists
+and insufficientAccess) and matchedDN value may be returned; if "u" is
+not granted to entry then nosuchObject MUST be returned and matchedDN
+set to "". Similar logic applies if the access control failure was due
+to a missing permission on newSuperior.
+
+
+5.7 Compare Operation
+
+Recall that the parameters of the Compare operation per RFC2251 [LDAPv3]
+Section 4.10 are:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+Then the permissions required by authzId that need to be evaluated are
+as follows:
+
+
+ 1. permission "c" to the attribute in entry on which the comparison
+ is being made.
+
+If each of these items is satisfied then the operation is allowed by the
+access control model. If one of these items is not satisfied, then the
+operation MUST fail. In this case, if "u" (discloseOnError) is granted
+to entry, then the usual error codes (such as noSuchObject, and
+insufficientAccess) and matchedDN value may be returned; if "u" is not
+granted to entry then nosuchObject MUST be returned and matchedDN set to
+"".
+
+
+5.8 Abandon Operation
+
+Recall that the parameters of the Abandon operation per RFC2251 [LDAPv3]
+Section 4.6 are:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+authzId always has the right to send an Abandon Operation for an
+operation he previously initiated.
+
+
+5.9 Extended Operation
+
+Recall that the parameters of the Extended operation per RFC2251
+[LDA{v3] Section 4.12 are:
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 35]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+The access required for an Extended Operation is beyond the scope of
+this document. The required access will normally be defined by the
+implementer of the extended request.
+
+
+
+6. Required Permissions for Handling Aliases and References
+
+Use of aliases and referrals are part of LDAPv3. However, neither is
+particularly well-defined. Alias objects and attributes are defined in
+RFC 2256 as derived from X.500, but LDAPv3 does not explicitly define
+their semantics or behavior. X.500 does define alias semantics and
+behavior with respect to access control; we define its behavior in
+LDAPv3 based on the X.511 (1993) [X511], section 7.11.1. Referrals and
+knowledge information are still under design in LDAPv3; they are defined
+in X.500, however, X.500 does not specify their semantics and behavior
+with respect to access control. We define their semantics and behavior
+in LDAPv3 in terms that should be independent of the future LDAPv3
+definition of referrals and knowledge information.
+
+
+6.1 ACI Distribution
+
+Currently there is no LDAP standard defining how to distribute directory
+data between LDAP servers. Consequently this model cannot fully specify
+the behavior of the Access Control Model in a distributed environment.
+The case of distribution via referrals is treated in the "Referrals"
+section below. In the case of chaining (where one LDAP server forwards a
+request to another on behalf of a client) then it is server specific how
+the access control model behaves in this environment. Similarly it is
+server specific how the server determines whether the chaining of an
+operation is permitted in the first place. For example, the
+implementation may choose to regard the local naming context and the
+remote subordinate naming context as separate Access Control Specific
+Areas, or it may regard the DIT as one Access Control Specific Area and
+implement mechanisms to propagate access control information between the
+two servers. The behavior of the Access Control Model in distributed
+environments such as these is beyond the scope of this model.
+
+
+6.2 Aliases
+
+There are two things to protect with respect to aliases: the real name
+of the aliased object and the location of the server holding it.
+
+If alias de-referencing is required in the process of locating a target
+entry, no specific permissions are necessary for alias de-referencing to
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 36]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+take place. Access control is enforced at the object pointed to by the
+alias.
+
+If alias de-referencing would result in a continuationReference (e.g.
+from a search operation), then browse permission is required to the
+alias entry and read permission is required to the attribute. Requiring
+these permission closes the hole of discovery.
+
+
+6.3 Referrals
+
+If a referral is to be followed, no specific permissions are necessary
+for the ldap client to follow the referral. Access control is enforced
+at the referenced object. If a referral is returned, then browse is
+required on the entry and read permission is required to the attribute
+containing the referral (we cannot name this attribute exactly today
+because there are no RFCs on this). If the server implements a default
+referral, then no special permissions are required to read and return
+that referral. Requiring these permissions closes the hole of
+discovery. In the default case, it is assumed that a default referral
+is public.
+
+
+
+7. Controlling Access to Access Control Information
+
+The entryACI and subtreeACI attributes are used to specify control for
+who has permission to set/change access control information (entryACI
+and subtreeACI). The entryACI and subtreeACI attributes/OIDs are just
+another attribute described with set of rights and permissions, and
+subject as a value of the entryACI and subtreeACI attributes. (See the
+example in the "ACI Examples" section).
+
+If the policy for controlling the entryACI and subtreeACI attributes are
+not specified for any object in the tree, behavior is implementation
+defined. For instance, if no object anywhere in the tree defines the
+access for entryACI/subtreeACI within the entryACI/subtreeACI
+attributes, then the server could simply assert that the 'root DN' is
+considered the policy owner (controller for controlling access control)
+for all objects.
+
+
+
+8. ACI Examples
+
+Note that in the examples, the form "OID.<attrname>" refers to the OID
+in dotted decimal form for the attribute <attrname>. This shorthand
+notation is used only for the examples. In implementation, the dotted
+decimal form of the OID is used.
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 37]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+8.1 Attribute Definition
+
+The following examples show the access required to control access to the
+entryACI and subtreeACI attributes. The first example shows controlling
+the access control on an individual entry and its attributes. The
+second example shows controlling the access control on a subtree. The
+authnLevel is set so that a reasonably secure form of authentication is
+required, since changing ACI has significant security consequences.
+
+ entryACI: grant:rwo#
+ OID.entryACI#authnLevel:limited:role:cn=aciAdmin
+
+ subtreeACI: grant:rwo#
+ OID.subtreeACI#authnLevel:limited:role:cn=aciAdmin
+
+The next example shows a subtreeACI attribute where a group "cn=Dept
+XYZ, c=US" is being given permissions to read, search, and compare
+attribute attr1. The permission applies to the entire subtree below the
+node containing this ACI.
+
+ subtreeACI: grant;rsc#
+ OID.attr1#authnLevel:weak:group:cn=Dept XYZ,c=US
+
+The next example shows an ACI attribute where a role
+"cn=SysAdmins,o=Company" is being given permissions to browseDN,
+viewEntry, and returnDN for objects below this node. The role is also
+being given permission to read, search, and compare to attribute attr2
+and read, search, compare, write, obliterate to attr3. The permissions
+apply to the entire subtree below the node containing this ACI.
+
+ subtreeACI: grant:bvt#
+ [entry]#authnLevel:weak:role:cn=SysAdmins,o=Company
+
+ subtreeACI: grant:rsc#
+ OID.attr2#authnLevel:weak:role:cn=SysAdmins,o=Company
+
+ subtreeACI: grant:rscwo#
+ OID.attr3#authnLevel:weak:role:cn=SysAdmins,o=Company
+
+
+8.2 Modifying the entryACI and subtreeACI Values
+
+Modify-Replace works as defined in the ldap operation modify. If the
+attribute value does not exist, create the value. If the attribute does
+exist, replace the value. If the entryACI/subtreeACI value is replaced,
+all entryACI/subtreeACI values are replaced. To modify the
+entryACI/subtreeACI attributes requires you to have 'w' and 'o'
+permission on the entryACI/subtreeACI attribute (recall that a value of
+entryACI/subtreeACI specifies entryACI/subtreeACI so one can control
+access to the entryACI/subtreeACI attribute). The examples in this
+section assume that you have access to control entryACI/subtreeACI.
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 38]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+A given subtreeACI for an entry:
+
+ subtreeACI: deny:rw#[all]#authnLevel:weak:group:cn=Dept ABC
+
+ subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
+
+perform the following change:
+
+ dn: cn=someEntry
+ changetype: modify
+ replace: subtreeACI
+ subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
+
+The resulting ACI is:
+
+ subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
+
+( subtreeACI values for Dept XYZ and ABC are lost through the replace )
+
+During an ldapmodify-add, if the ACI does not exist, the create the ACI
+with the specific entryACI/subtreeACI value(s). If the ACI does exist,
+then add the specified values to the given entryACI/subtreeACI. For
+example a given ACI:
+
+ subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
+
+with a modification:
+
+ dn: cn=someEntry
+ changetype: modify
+ add: subtreeACI
+ subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
+
+would yield an multi-valued ACI of:
+
+ subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
+
+ subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
+
+To delete a particular ACI value, use the regular ldapmodify - delete
+syntax
+
+Given an ACI of:
+
+ subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
+ subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: subtreeACI
+ subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 39]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+would yield a remaining ACI on the server of
+
+subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
+
+The attributes which are defined for access control interchange may be
+used in all LDAP operations.
+
+Within the ldapmodify-delete operation, the entire acl may be deleted by
+specifying
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: entryACI
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: subtreeACI
+
+In this case, the entry would then inherit its ACI from other nodes in
+the tree depending on the inheritance model.
+
+Similarly, if all values of entryACI and subtreeACI are deleted, then
+the access control information for that entry is defined by the
+inheritance model.
+
+
+8.3 Evaluation
+
+These examples assume that the ACI entries listed in each example are
+the only ACI which applies to the entry in question; if backing-store
+ACI also exists, the effective policy may be different from that listed
+in each example.
+
+Assume cn=jsmith is a member of group cn=G1. Assume cn=jsmith is a
+member of group cn=G2.
+
+
+Example #1
+
+ dn: o=XYZ, c=US
+ subtreeACI: grant:r#attr2
+ #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
+ subtreeACI: grant:w#attr2
+ #authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
+
+What rights does cn=jsmith have to attr2 of o=XYZ,c=US? Read-write (rw)
+access; ACI is combined because both subjects (group) have same
+precedence.
+
+
+
+
+
+
+Stokes, et al Expires 29 December 2001 [Page 40]
+
+
+
+
+
+Internet-Draft Access Control Model 29 June 2001
+
+
+
+Example #2
+
+ dn: o=XYZ, c=US
+ subtreeACI: grant:rw#OID.attr3
+ #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
+ subtreeACI:
+deny:w#OID.attr3#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
+
+What rights does cn=jsmith have to attr3 of o=XYZ, c=US? Read access;
+write is denied (deny has precedence over grant).
+
+
+Example #3
+
[... 1586 lines stripped ...]