directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject 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
Date Sat, 21 May 2005 02:53:55 GMT

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 ...]


Mime
View raw message