- Internet-Draft E. Stokes
- LDAP Extensions WG D. Byrne
- Intended Category: Standards Track B. Blakley
- Expires: 15 October 1999 IBM
- 15 April 1999
+Internet-Draft E. Stokes
+LDAP Extensions WG B. Blakley
+Intended Category: Standards Track Tivoli Systems
+Expires: 14 January 2001 D. Rinkevich
+ IBM
+ R. Byrne
+ Sun Microsystems
+ 14 July 2000
- Access Control Model for LDAP
- <draft-ietf-ldapext-acl-model-02.txt>
+ Access Control Model for LDAPv3
+ <draft-ietf-ldapext-acl-model-06.txt>
- STATUS OF THIS MEMO
+STATUS OF THIS MEMO
- This document is an Internet-Draft and is in full
- conformance with all provisions of Section 10 of RFC2026.
+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."
+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 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.
+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:
+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
+ ietf-ldapext@netscape.com
- ABSTRACT
+COPYRIGHT NOTICE
- This document describes the access control model for the
- Lightweight Directory Application Protocol (LDAP)
- directory service. It includes a description of the
- model, the LDAP controls, and the extended operations to
- the LDAP protocol. A separate document defines the
- corresponding application programming interfaces (APIs).
- RFC2219 [Bradner97] terminology is used.
+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 LDAP controls, and the extended operations to the LDAP
+protocol. The current LDAP APIs are sufficient for most
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 1]
+
+
+Stokes, et al Expires 14 January 2001 [Page 1]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+access control operations. An API (in a separate document)
+is needed for the extended operation getEffectiveAccess. A
+separate requirements document for access control exists
+[REQTS]. The access control model used the requirements
+documents 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
+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 is needed to ensure consistent
- secure access across heterogeneous LDAP implementations.
- The major objective is to provide a simple, but secure,
- highly efficient access control model for LDAP while also
- providing the appropriate flexibility to meet the needs
- of both the Internet and enterprise environments and
- policies. This document defines the model and the
- protocol extensions (controls and extended operations).
- A separate document defines the corresponding application
- programming interfaces (APIs).
+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 while also providing the appropriate
+flexibility to meet the needs of both the Internet and
+enterprise environments and policies. This document defines
+the model and the protocol extensions (controls and extended
+operations).
+This draft 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 draft.
- 2. Overview
- 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.
- This proposal defines the protocol elements for
- transmission of this access control policy data in an
- LDAP environment and an attribute that defines the access
- control mechanism in effect for a given part of the LDAP
- namespace. The instantiation of an access control model
- at the directory server is not defined in this document.
- By defining only what flows on the wire allows existing
- access control mechanisms to be used at the directory
- server.
+2. The LDAPv3 Access Control Model
- No mechanisms are defined in this document to control
- access to access control information or for storage of
+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
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 2]
+Stokes, et al Expires 14 January 2001 [Page 2]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- access control information at the server; this is vendor
- dependent.
+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.
- A separate requirements document for access control
- exists. The access control model used the requirements
- documents 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.
+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
+The access control mechanisms specified in this document are
+neutral with respect to policy inheritance mechanisms,
+explicit vs. implicit denial, and group nesting.
- - A wire protocol for interoperability: The existing
- LDAP protocol flows for add, delete, modify, etc are
- used to manipulate access control information.
- There are additional LDAP controls and extended
- protocol operations defined to further help
- management of access control information:
- getEffectiveRights, listSubjectRights, and
- specifyCredentials.
+The access control model defines
- - LDAP Directory Interchange Format (LDIF) for
- application portability: The LDIF is defined for
- access control information (ACI). This LDIF is also
- used as input to the LDAP APIs so access control
- information can be addressed uniformly independent
- of how that information is stored and addressed at
- the server.
+ - What flows on the wire for interoperability
- - A set of attributes to identity the access control
- mechanisms supported by a server.
+ The existing LDAP protocol flows for ldap operations
+ are used to manipulate access control information. A
+ set of permissions and their semantics with respect to
+ ldap operations is defined. The permissions parallel
+ the types of ldap operations defined. What is
+ transmitted is exactly what is read back. Encoding of
+ access control information on the wire is per the
+ LDAPv3 specifications.
- Encoding of access control information on the wire is per
- the LDAPv3 specifications.
+ There is an additional LDAP control and extended
+ protocol operation defined, getEffectiveRights. LDAP
+ clients use the control and extended operation 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
+ 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 "Operational
+ Semantics of Access Control Operations".
+
+ - Attributes and classes for application portability of
+ access control information
+
+ An access control information attribute (ldapACI) for
+ application portability: This attribute is used as
+ input to the LDAP APIs so access control information
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 3]
+\f
- 3. Terminology
- An "access control list" contains the access control
- policy information controlling access to an object or
- collection of objects. An access control list consists
- of a set of access control list entries.
- An "access control list entry" defines a single subject
- security attribute's granted rights for the objects
+Internet-Draft Access Control Model 14 July 2000
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 3]
+
+ can be addressed uniformly independent of how that
+ information is addressed and stored at the server.
+ This same attribute appears 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.
+
+ - An attribute in the rootDSE, discloseOnError, to
+ control whether it is permissible for the server to
+ return the name of an entry or attribute in an error
+ (or empty set) operation result. This closes a hole on
+ the ability to discover information you are not
+ authorized to discover.
+
+ - A mechanism to control access to access control
+ information: The access control information attribute,
+ ldapACI, is used to control access to access control
+ information (controls access to itself). How to get an
+ initial ldapACI 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 mechanism is in effect for
+the scope of that ldapACISubEntry. The
+supportedAccessControlSchemes attribute in the rootDSE
+indicates which acess 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 mechanism rootDSE attribute and
+ldapACI subentry, it is possible to run multiple mechanisms
+in either the same subtree or separate subtrees. If two
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 4]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+mechanisms are run in the same subtree, it is desirable that
+the result be the same independent of mechanism, but
+definition and discussion of this is beyond the scope of
+this model.
- governed by the access control list to which it belongs.
- The "access control policy information" (acpi) for an
- object or a collection of objects defines which subject
- security attributes entitle a subject to which granted
- rights. The access control policy information for an
- object is stored in an access control list.
- An "access decision" is a boolean-valued function which
- answers the question: "can the subject with these subject
- security attributes perform this operation on this
- object?"
+3. Access Control Mechanism Attributes
- An "access decision function" is an algorithm which makes
- an access decision based on subject security attributes,
- access control policy information, an object identifier,
- and an operation name (possibly augmented by additional
- contextual information).
+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).
- An "access decision function interface" is a programmatic
- interface through which applications can request an
- access decision.
- An "access identity" is an identity which is used by an
- access decision function to make an access decision.
+3.1 Root DSE Attribute for Access Control Mechanism
- An "audit identity" is an identity which does not, in the
- absence of additional information, enable a party
- receiving and examining it to determine which subject it
- belongs to.
+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").
- A "credential" is a collection of subject security
- attributes.
+ (<OID to be assigned>
+ NAME 'supportedAccessControlSchemes'
+ DESC list of access control mechanisms supported
+ by this directory server
+ SYNTAX LDAPOID
+ USAGE dSAOperation
+ )
- "effective rights" are the complete set of rights a
- subject is entitled to based on all access control lists
- which apply to a specific object and based on all of the
- subject's security attributes.
+The access control mechanism defined is:
+ LDAPv3 <OID to be assigned>
- "granted rights" are the complete set of rights an access
- control list entitles a subject to based on a specific
- subject security attribute.
+Other vendor access control mechanisms MAY be defined (by
+OID) and are the responsibility of those vendors to provide
+the definition and OID.
- A "group" is a privilege attribute asserting a subject's
- membership in the collection of subjects whose name is
+3.2 Root DSE Attribute for Control of Disclosing Errors
+The server specifies whether it is permissible for the name
+of an entry or attribute to be disclosed in an error (or
+empty) operation result. This rootDSE attribute is
+discloseOnError. The default for discloseOnError is false
+(0) or not to disclose on error. The lack of this attribute
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 4]
+
+
+Stokes, et al Expires 14 January 2001 [Page 5]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+in the rootDSE is interpreted as the default.
+
+ (<OID to be assigned>
+ NAME 'discloseOnError'
+ DESC specify whether to return the name of an
+ entry or attribute in an error (or
+ empty) operation result; 0=do not
+ disclose (default); 1=disclose
+ SYNTAX LDAPString
+ USAGE dSAOperation
+
+
+3.3 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>
+ NAME 'ldapACISubEntry'
+ DESC 'LDAP ACI Subentry class'
+ SUP ldapSubEntry STRUCTURAL
+ MUST ( accessControlSchemes )
+ )
+
+The accessControlSchemes attribute MUST be in each ldap
+access control subentry 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. 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
- that of the group.
- An "identity" is a subject security attribute which is
- unique to a single subject.
+Stokes, et al Expires 14 January 2001 [Page 6]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
- An "object" is the target of operations in an information
- system.
- An "operation" is the result of executing the code
- accessed through a named entry point in an information
- system.
+ SYNTAX LDAPOID
+ USAGE dSAOperation
+ )
- An "operation name" is the name of the entry point
- through which an operation is invoked in an information
- system.
- A "privilege attribute" is a subject security attribute
- which may be shared by several subjects.
- "required rights" are the complete set of rights needed
- to authorize a requester to perform a specific operation
- on an object of a specific type.
+4. The Access Control Information Attribute (ldapACI)
- A "right" is the basic unit of access control policy
- administration. For each object type in an information
- system, a security administrator defines a set of
- required rights for each operation. For each object in
- the system, a security administrator defines a set of
- granted rights for each subject security attribute. When
- an access decision is required, an access decision
- function checks to make sure that the requester's subject
- security attributes have been granted all required rights
- needed to perform the requested operation on the
- specified target object.
+The access control information attribute, ldapACI, is
+defined as:
- A "role" is a privilege attribute asserting a subject's
- organizational position and entitlement to perform the
- operations appropriate to that organizational position.
+ (<OID to be assigned>
+ NAME 'ldapACI'
+ DESC 'ldap access control information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX directoryString
+ USAGE directoryOperation
+ )
- A "subject" is an entity which intiates actions in an
- information system.
+The intent of the attribute definition is to design a common
+interchange format. Any given LDAP server should be able to
+translate the below defined attribute into meaningful
+operation requests. Each server should be able to understand
+the attribute; there should not be any ambiguity into what
+any part of the syntax means.
- A "subject security attribute" is a defined property
- which is used by a security policy evaluation system to
- make policy decisions.
+While the end goal is to have a common behavior model
+between different LDAP server implementations, the attribute
+definition alone will not ensure identical ACL processing
+behavior between servers. The semantics of how a server
+interprets the ACI syntax are defined in the "Operational
+Semantics of Access Control" 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 this
+attribute.
+The attribute definition maintains an assumption that the
+receiving server supports 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. If the server does not support partial
+inheritance and both the entry and subtree scope are used,
+then entry is the prevailing scope. (It is possible for two
+values in the ldapACI attribute to have different scopes
+given the syntax of ldapACI; one might contain 'entry' and
+another might contain 'subtree'. This implies that some
+ldapACI values inherit down the DIT and othersdo not - hence
+partial inheritance of the ldapACI attribute.)
+The attribute is defined so access control information (ACI)
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 5]
+
+
+Stokes, et al Expires 14 January 2001 [Page 7]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+can be addressed in a server independent of server
+implementation. This attribute is used in typical LDAP APIs
+and in LDIF output of ACI. This attribute may be queried or
+set on all directory objects. The BNF and definitions are
+given below.
- 4. The Model
+4.1 The BNF
- 4.1 Access Control Activity Lifecycle
- The access control proposal described in this draft
- addresses four activities:
+4.1.1 ACI String Representation
- - Creation of subject security attribute information
- and access control policy information
+ Values of this syntax are encoded according to the
+ following BNF which follows the BNF encoding
+ conventions described in [ABNF]:
- - Retrieval of subject security attribute information
- at the time an access request is made
+ ldapACI = scope "#" rights "#" attr "#" subject
- - Evaluation of access requests against policy,
- resulting in an access decision
+ scope = "entry" / "subtree"
- - Replication of access control policy information
- from one server to another
+ rights = (("grant:" / "deny:") permissions) /
+ ("grant:" permissions ";deny:" permissions)
- 4.2 Access Control Information Model
+ permissions = [permission *("," permission)]
- This document does not define formats for storage of
- access control information; it does define the
- operational semantics of access control operations.
+ permission = "a" / ; add
+ "d" / ; delete
+ "e" / ; export
+ "i" / ; import
+ "n" / ; renameDN
+ "b" / ; browseDN
+ "t" / ; returnDN
+ "r" / ; read
+ "s" / ; search
+ "w" / ; write (mod-add)
+ "o" / ; obliterate (mod-del)
+ "c" / ; compare
+ "m" / ; make
+ attr = "[all]" / "[entry]" / (attribute *("," attribute))
+ attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38)
+ ; from [ATTR]
+ subject = ["authnLevel:" authnLevel ":"]
+ (("authzID-" authzID) /
+ ("role:" dn) /
+ ("group:" dn) /
+ ("subtree:" dn) /
+ ("ipAddress:" ipAddress) /
+ "public:" /
+Stokes, et al Expires 14 January 2001 [Page 8]
+\f
+
+
+Internet-Draft Access Control Model 14 July 2000
+ "this:")
+ authnLevel = "any" /
+ "simple" /
+ sasl
+ sasl = "sasl:"
+ ("any" /
+ mechanism)
+ mechanism = ; sasl mechanism from 4.2 of [LDAPv3]
+ authzID = ; authzID from [AuthMeth] 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
+ ipAddress = printableString
+ ; dotted decimal form (e.g. 10.0.0.6)
+ ; or use wildcards such as 12.3.45.* to
+ ; specify a specific subnetwork
+ ; or 123.45.6.*+255.255.255.115 to
+ ; specify a subnetmask
+ ; or use a wildcard domain name such as
+ ; *.airius.com to specify a specific
+ ; DNS domain
+ printableString ; printableString syntax from [ATTR]
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 6]
+Note that the colon following the "public" and "this"
+subject options exist only to simplify string parsing.
+
+Note also that per [AuthMeth], authzID may be expanded in
+the future.
+
+See section titled 'ACI Examples' for examples of the string
+representation.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 9]
\f
- Internet-Draft Access Control Model 15 April 1999
-
-
-
- The diagram below illustrates the componentry of an LDAP
- system and the placement of the function specified in
- this draft.
-
- +-------------+
- | Application |
- +-------------+
- +--------+
- | LDAP |
- | Client |
- +--------+
- |
- |
- | <-- LDAP Extended Access Control
- Controls
- | or Extended Access Control
- Operations
- v
- +-----------------------------+
- | LDAP Server (e.g. SLAPD) |
- +-----------------------------+
- . |
- . |
- . |
- . |
- v v
- +----------+ +-----------+
- | Access | | |
- | Control |<.....| Datastore |
- | Manager | | |
- +----------+ +-----------+
-
- LDAP clients use the controls and extended operations
- specified in this document to 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 access control managers
- external to their datastores. Datastores and external
- access control managers may implement any access control
- rule syntax and semantics they choose, as long as the
- semantics is compatible with that defined in the section
- titled "Operational Semantics of Access Control
- Operations" (found after the control and extended
-
-
-
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 7]
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+4.1.2 ACI Binary Representation
+
+ The following ASN.1 data type is used to represent this
+ syntax when transferred in binary form:
+
+ ldapACI ::= SEQUENCE {
+ scope ENUMERATED {
+ entry (0),
+ subtree (1) },
+ rights SEQUENCE OF CHOICE {
+ grant [0] Permissions,
+ deny [1] Permissions },
+ attr CHOICE {
+ all [0] NULL,
+ entry [1] NULL,
+ attributes [2] SEQUENCE OF Attribute },
+ subject SEQUENCE {
+ authnLevel CHOICE {
+ any [0] NULL,
+ simple [1] NULL,
+ sasl [2] CHOICE {
+ any [0] NULL,
+ mechanism [1] LDAPString -- from [LDAPv3]
+ }
+ },
+ subject CHOICE {
+ dn [0] DN,
+ user [1] utf8String
+ role [1] DN,
+ group [2] DN,
+ subtree [3] DN,
+ ipAddress [4] IPAddress,
+ public [6] NULL,
+ this [7] NULL }, } -- may be expanded
+ per [AuthMeth]
+
+ Permissions ::= SEQUENCE OF ENUMERATED {
+ add (0),
+ delete (1),
+ export (2),
+ import (3),
+ renameDN (4),
+ browseDN (5),
+ returnDN (6),
+ read (7),
+ search (8),
+ write (9),
+ obliterate (10),
+ compare (11),
+ make (12) }
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 10]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ Attribute ::= AttributeType -- from [LDAPv3]
+ IPAddress ::= PrintableString -- (e.g. 10.0.0.6)
- operation definition).
- The access control administration mechanisms specified in
- this document are neutral with respect to policy
- inheritance mechanisms, explicit vs. implicit denial,
- and group nesting.
+4.2 The Components of ldapACI Attribute
- 4.3 Bind and Credentials
+This section defines components that comprise the access
+control information attribute, ldapACI.
- A bind authenticates a principal to the directory. A
- principal is represented by a DN. A principal has a set
- of credentials that are used for determining whether
- access to resources specified in ldap operations. These
- credentials may be pushed to the server by the client or
- may be pulled by the server from the directory data.
- Credentials may be local with respect to the server. If
- not local (owned by another server or administrative
- scope), then the server may decide to define a trust
- model that states how to evaluate the trust of a
- credential at bind time. The definition of such a trust
- model is outside the scope of this document.
+4.2.1 Scope
- 5. Access Control Information Schema
+Two scopes for access control information are defined:
+ - entry - the access control information in the ldapACI
+ attribute applies only to the entry in which it is
+ contained
- 5.1 Attributes
+ - subtree - the access control information in the ldapACI
+ attribute applies to each entry down the subtree unless
+ it is overridden by an entry-specific ldapACI whose
+ values are more specific.
+Use of prescriptive ACIs and scoping via use of a
+ldapACISubEntry is outside the scope of this document.
- 5.1.1 Root DSE Attribute for Access Control Mechanism
- The following attribute may be included in the Root DSE.
+4.2.2 Access Rights and Permissions
- (<OID to be assigned>
- NAME 'supportedACIMechanisms'
- DESC list of access control mechanisms supported
- by this directory server
- SYNTAX LDAPOID
- )
+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 ldapACI.
- Two access control mechanisms are defined by this
- document:
- LDAPv3 <OID to be assigned>
- X500 <OID to be assigned>
+Each of the LDAP access permissions are discrete. One
+permission does 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
+ c Compare Compare attributes
+ m Make Make attributes on a new entry below
+ this entry
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 8]
+
+
+Stokes, et al Expires 14 January 2001 [Page 11]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 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 operation.
+
+ 3. o Obliterate
+
+ If granted, permits attributes and values to be
+ deleted in a modify operation.
+
+ 4. s Search
+
+ If granted, permits attributes and values to be
+ included in a search operation.
+ 5. c Compare
+ If granted, permites attributes and value to be used
+ in a compare operation.
- Other vendor access control mechanisms can be defined (by
- OID) and are the responsibility of those vendors to
- provide the definition and OID.
+ 6. m Make
- 5.1.2 Subschema Attribute for Access Control Mechanism
+ The attribute permission "m" is required for all
+ attributes that are placed on an object when it is
+ created. Just as the "w" and "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.
- A given naming context must provide information about
- which access control mechanism is in effect for that
- portion of the namespace. The following attribute must
- be in each subschema entry associated with a naming
- context whose access control mechanism is different from
- adjacent naming contexts supported by that directory
- server.
+Note: Modify-replace values of an attribute requires "w"
+and "o" permission.
- - aCIMechanism lists the value (an OID) that defines
- the access control mechanism in effect for the scope
- of that subschema entry
+Permissions that apply to an entire entry:
- 5.2 Other Defined Parameters/OIDs
+ a Add Add an entry below this entry
- 5.2.1 Rights Families and Rights
- The following rights families are defined:
- LDAPv3 <OID to be assigned>
- X500 <OID to be assigned>
- Other parties can (and will) define other rights
- families. It is the responsibility of those parties to
- provide the definition and OID.
+Stokes, et al Expires 14 January 2001 [Page 12]
+\f
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ d Delete Delete this entry
+ e Export Export entry & subordinates to new
+ location
+ i Import Import entry & subordinates from some
+ location
+ n RenameDN Rename an entry's DN
+ b BrowseDN Browse an entry's DN
+ t ReturnDN Allows DN of entry to be disclosed in
+ an operation result
+
+
+ 1. a Add
+
+ If granted, permits creation of an entry in the DIT
+ subject to 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 at least the mandatory attributes.
+
+ 2. d Delete
- 5.2.1.1 LDAPv3 Rights Family
+ If granted, permits the entry to be removed from the
+ DIT regardless of controls on attributes within the
+ entry.
- Access rights can apply to an entire object or to
- attributes of the object. Each of the LDAP access rights
- are discrete. One permission does not imply another
- permission. The rights may be ORed together to provide
- the desired rights list.
+ 3. e Export
- Rights which apply to attributes are:
+ If granted, permits an entry and its subordinates (if
+ any) to be exported; that is, removed from the current
+ location and placed in 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 attributed, 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.
- 1 Read Read attribute values
- 2 Write Write attribute values
- 4 Search Search entries with specified attributes
- 8 Compare Compare attributes
+ 4. i Import
+ If granted, permits an entry and its suordinates (if
+ any) to be imported; that is, removed from some other
+ location and placed a t the location to which the
+ permission applies subject to the granting of suitable
+ permissions at the source location. In order to
+ import an entry or its subordinates, there are no
+ prerequisite permissions to contained attributed,
+ 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.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 9]
+
+Stokes, et al Expires 14 January 2001 [Page 13]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- Rights that apply to an entire object are:
+ 5. n RenameDN
- 16 Add Add an object below this object
- 32 Delete Delete this object
+ Granting Rename is necessary for an entry to be
+ renamed with a new RDN, taking into account
+ consequential changes to the distinguished names of
+ subordinate entries, if any; if the name of the
+ superior is unchanged, the grant is sufficient. In
+ order to rename an entry, there are no prerequisite
+ permissions to contained attributed, 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.
- Rights that apply to the object to which the directory
- object points are:
+ 6. b BrowseDN
- 64 Manage Perform a privileged operation; used to
- restrict access to operations which
- read or write especially sensitive data
- 128 Use Execute; useful in controlling access to
- the objects referred to by directory
- entries than in controlling access to
- the directory entries themselves
- 256 Get Get retrieves the attribute values
- 512 Set Set writes the attribute values
+ If granted, permits entries to be accessed using
+ directory operations which do not explicitly provide
+ the name of the entry.
- 5.2.1.2 The X.500 Rights Family
+ 7. t ReturnDN
- <define the rights for X.500>
+ If granted, allows the distinguished name of the entry
+ to be disclosed in the operation result.
- 5.2.2 DN Types
+All permissions (for grant and deny) for an attribute/entry
+and a given subject MUST be contained within one ldapACI
+value, i.e. (in abbreviated form)
- The following DN Types are defined:
+ ldapACI: ...grant OID.attr1 subjectA
+ ldapACI: ...deny OID.attr1 subjectA
- - access-id, OID=<OID to be assigned>
+must be ldapACI: ...grant ... deny... OID.attr1 subjectA
- - group, OID=<OID to be assigned>
+Using the defined BNF it is possible for the permission
+string to be empty. The ACI
- - role, OID=<OID to be assigned>
+ ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US
- access-id, group, and role MUST be supported. An acess-
- id is a non-collection (non-group and non-role objects)
- DN that can be authenticated.
+ ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US
- Other parties can (and will) define other DN Types. It
- is the responsibility of those parties to provide the
- definition and OID.
+means that this group (Dept XYZ) is granted permission to
+read and search all attributes except OID.attr1 because
+OID.attr1 is more specific than "[all]".
- 6. Access Control Parameters for LDAP Controls & Extended
- Operations
+4.2.3 Attributes
- This section defines the parameters used in the access
+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. "[entry]" means
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 10]
+Stokes, et al Expires 14 January 2001 [Page 14]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+the permissions apply to the entire object. This could mean
+actions such as delete the object, or add a child object.
+"[all]" means the permission set apply to all attributes of
+the entry.
+
+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.4 Subjects and Associated Authentication
+The following subjects are defined and MUST be supported:
- control LDAP controls and extended operations in this
- document.
+ - authzID, defined per [authmeth]
- targetDN specifies the initial directory entry in DN
- syntax on which the control or extended operation is
- performed.
+ - group, defined as the distinguished name of a
+ groupOfNames or groupOfUniqueNames entry
- whichObject specifies whether the access control
- information which is get/set is for the target directory
- entry (ENTRY) or the target directory entry and its
- subtree (SUBTREE).
+ - role
- rightsFamily specifies the family of rights that will be
- get/set for the control or extended operation performed.
- A rights family has a defined set of rights.
+ - subtree, defined as the distinguished name of a non-
+ leaf node in the DIT
- rightsList in the SearchResultEntry is of the form
- specified in the LDIF BNF for <right>.
+ - ipAddress,
- dnType speficies the type of subject security attribute.
- Defined types are access-id, group, and role.
+ - public, defined as public access
- subjectDN is a LDAP string that defines the subject or
- value of the dnType. The subjectDN may be a DN or
- another string such as IPAddress (dotted-decimal string
- representation) on which access control is get/set. If
- the subject is an entry in the directory, then the syntax
- of the LDAP string is DN. We define two well-known
- subjectDNs, the strings
+ - this, defined as the user whose name matches that of
+ the entry being accessed
- - public - meaning public access for all users
+Other parties MAY define other subjects. It is the
+responsibility of those parties to provide the definition.
- - this - meaning the user whose name matches the entry
- being accessed
+A subject may be qualified by the type of authentication
+required for access to a given attribute(s) or entry. If no
+authnLevel is present, then no specific type of
+authentication is additionally required for access. If
+authnLevel is specified, then that type of authentication is
+additionally required for access. The authnLevels parallel
+the authentication mechanisms specified for LDAPv3: simple,
+SASL (any type of SASL mechanism), and a SASL-specific
+mechanism. The authnLevel of is not an acceptable mechanism
+for this case) as part of obtaining access.
- Four operations are defined:
- - ACI_GRANT grants the rights specified in the
- rightsList for the given subject. If an access
- control list does not exist for the specified
- entry/attribute, then the access control list is
- created with the granted rights for the given
- subject. If the access control list already exists
- for the specified entry/attribute, then the access
- control list is modified to grant the rights for the
+4.3 Grant/Deny Evaluation Rules
+The decision whether to grant or deny a client access to a
+particular piece of information is based on several pieces
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 11]
+
+Stokes, et al Expires 14 January 2001 [Page 15]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- given subject.
+of information found within the ldapaci value. Throughout
+the decision making process, there are guiding principals.
- - ACI_DENY denies the rights specified in the
- rightsList for the given subject. No implementation
- is implied for this operation. For example, denial
- of rights may be implemented as explicit denial
- (negative rights) on the access control list or
- removal of rights from the access control list.
+ - Specificity: More specific policies MUST override less
+ specific ones (e.g. individual user entry in ACI takes
+ precedence over group entry).
- - ACI_REPLACE replaces the entire access control list
- for the specified entry/attribute. If an access
- control list does not exist for the specified
- entry/attribute, then the access control list is
- created with the granted rights for the given
- subject.
+ - Deny takes precedence over Grant.
- - ACI_DELETE deletes the entire access control list
- for the specified entry/attribute.
+ - When there are conflicting ACI values, deny takes
+ precedence over grant.
- attrs specifies the list of attributes against which the
- operation is performed. attrs can be defined using a
- LDAP filter expression.
+ - Deny is the default when there is no access control
+ information.
+Precendence of Scope Types (highest to lowest)
- 7. Access Control Information (ACI) Controls
+ - entry
- The access control information controls provide a way to
- manipulate access control information in conjunction with
- an LDAP operation such as ldap_add, ldap_modify, or
- ldap_search. Three LDAP controls are defined for
- transmission of access control information. These
- controls allow access control information to be get/set
- while manipulating other directory information. The
- controls are:
+ - subtree
- - getEffectiveRights to obtain the effective rights
- for a given directory entry(s) for a given subject
- during a ldap_search operation
+Precedence of Subjects within a Scope (highest to lowest):
- - listSubjectRights to get the access control
- information for a given directory entry(s) during a
- ldap_search operation
+ - ipAddress
- - specifyCredentials to specify a set of credentials
- for the bind identity (DN) during a ldap_bind
+ - authzID, this
+ - group, role, this, public
+ - subtree, public
+
+Although other types MAY be defined given the BNF, use of
+the well-known types aids in interoperability and
+operational consistency.
+
+Access Decision algorithm:
+
+ 1. Determine all the ldapACI values which could apply to
+ the target DN which is being accessed. This is the DN
+ of the entry which is being queried in a search,
+ modified, deleted, etc. When determining all the
+ ldapACI values, the scope field should be used. All
+ ldapACI values with a scope of 'entry' take precedence
+ over ldapACI values with a scope of 'subtree'.
+
+ 2. Determine which ldapACI (of the set determined in step
+ 1) apply to the bound DN. This is determined by
+ looking at the subject (combination of subject type
+ and subject value) and bind type. If no bind is in
+ effect (this is possible in ldapv3), then treat this
+ lack of bind as if bound as anonymous. Start with the
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 12]
-\f
+Stokes, et al Expires 14 January 2001 [Page 16]
+\f
+
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- operation
- 7.1 getEffectiveRights Control
+ most specific subject type. If at any time, at least
+ one ldapACI value exists for a specificity level, then
+ processing stops; the exception here is 'this' because
+ this may also be combined with group to use power of
+ 'this'. Evaluation should take place on set of
+ ldapACI values which are all of the same specificity
+ level. Subjects of the same precedence are combined
+ using union semantics.
+ 3. Evaluate the remaining ldapACI values and determine a
+ grant/deny decision. If conflicting ldapACI value
+ exists for the same attribute, or attributes (i.e. one
+ ldapACI grants permission and another denies
+ permission), then deny takes precedence over grant.
+ For example, if one is granted permission to
+ "objectclass" in one ldapACI value by being a member
+ of group cn=Admin, and denied permission by being a
+ member of cn = NontrustedAdmins, then the bound user
+ would not receive permission to objectclass.
- 7.1.1 Request Control
+ The rule of specificity also applies to the
+ attributes. If one is denied permission to "[ all ]"
+ attributes, but granted permission to "objectclass"
+ then the more specific value of "objectclass" takes
+ precedence over the less specific value of "[ all ] ".
+ In this case the user would be granted permission to
+ "objectclass" but denied permission to all other
+ attributes.
- This control is included in the ldap_search message as
- part of the controls field of the LDAPMessage, as
- defined in Section 4.1.12 of [LDAPv3].
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE) at the client's option. The
- controlValue is an OCTET STRING, whose value is the BER
- encoding of a value of the following SEQUENCE:
- getEffectiveRightsRequest ::= SEQUENCE {
- targetDN LDAPDN,
- effectiveRightsRequest SEQUENCE OF SEQUENCE {
- rightsFamily LDAPOID | "*",
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- dnType LDAPOID | "*",
- subjectDN LDAPString,
- }
- }
+5. Required Permissions for each LDAP Operation
- The targetDN specifies the initial directory entry in DN
- syntax on which the getEffectiveRights control is
- performed. request is a set of sequences that state the
- whichObject (entry or entry plus subtree) and specifics
- of the control request to be performed. One or more
- rightsFamily can be be obtained for a given subjectDN ad
- dnType. A "*" in the rightsFamily field indicates that
- the rights for all rights families defined for the
- subjectDN / dnType are to be returned. This control is
- applied to the scope set by the ldap_search operation,
- i.e. base, one-level, subtree.
+This section defines the required permissions for each LDAP
+operation but 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 the access control is
+available to the userPassword attribute a server may refuse
+modifications due to some server specific policy governing
+access to passwords.
- 7.1.2 Response Control
+Here, we specify the rights required by a user when
+performing an LDAP operation in terms of the LDAP
+permissions specified in section 6.1. Recall that "a, d,
+e, i, n, b,t" are permissions that apply to entries as a
+whole while permissions "r, s, w, o, c, m" apply to
+attributes within entries.
- This control is included in the ldap_search_response
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 13]
+Stokes, et al Expires 14 January 2001 [Page 17]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+Required permissions for LDAP extended operations and LDAP
+controls are beyond the scope of this draft.
+There is a requirement that a user should not be able to
+infer the existence of data in the Directory, if the user
+does not have the required access rights to that data. An
+example of this requirement would be in a hosting
+environment where you would not want any users from the coke
+subtree to be able to even discover that the pepsi tree was
+hosted on the same server. This "discloseOnError" feature
+will be set once for server in the rootDSE advertised by the
+attribute discloseOnError. The default for discloseOnError
+is false (0). The lack of this attribute in the rootDSE is
+interpreted as the default. The details of its effects are
+addressed below, operation by operation.
- message as part of the controls field of the LDAPMessage,
- as defined in Section 4.1.12 of [LDAPv3].
+For the following, assume that the authorization identity of
+the user doing the operation is authzID.
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE). The controlValue is an OCTET
- STRING, whose value is the BER encoding of a value of the
- following SEQUENCE:
- getEffectiveRightsResponse ::= {
- result ENUMERATED {
- success (0),
- operationsError (1),
- unavailableCriticalExtension (12),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- invalidAttributeSyntax (21),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
- }
- }
+5.1 Bind Operation
- The effective rights returned are returned with each
- attribute returned by the search result. So, the result
- for ldap_search is:
+This draft does not require any permissions to allow a bind
+operation to proceed.
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- rightsAttributes PartialEffectiveRightsList }
- PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
- rightFamily LDAPOID,
- rightsList ENUMERATED,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- }
- }
+5.2 Search Operation
- Although this extends the search operation, there are no
- incompatibilities between versions. LDAPv2 cannot send a
- control, hence the above structure cannot be returned to
- a LDAPv2 client. A LDAPv3 client cannot send this
- request to a LDAPv2 server. A LDAPv3 server not
+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),
+ 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.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 14]
+
+
+Stokes, et al Expires 14 January 2001 [Page 18]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- supporting this control cannot return the additional
- data.
- 7.1.3 Client-Server Interaction
+ 1. permission "b" to the entry candidateDN
- The getEffectiveRightsRequest control requests the rights
- that MUST be in effect for requested directory
- entry/attribute based on the subject DN. The server that
- consumes the search operation looks up the rights for the
- returned directory information based on the subject DN
- and returns that rights information.
+ If this permission is not granted then the dn
+ candidateDN MUST not be returned nor any attribute
+ type nor attribute value from this entry.
- There are six possible scenarios that may occur as a
- result of the getEffectiveRights control being included
- on the search request:
+ If this permission is granted then the dn candidateDN
+ MAY be returned.
+ Note: The idea of the "b" permission is to say "a user
+ has discovery rights" at a certain entry in the
+ directory. Assuming that the further required
+ permissions below are satisfied then having "b" right
+ is enough to allow the server to return candidateDN.
+ Of course candidateDN contains in it's components,
+ attributes and attribute values for all the ancestors
+ of candidateDN. This can lead to the slightly odd
+ situation that we can discover the naming attribute of
+ an entry and that attribute's value by virtue of
+ having the required searching permissions to it's
+ child but not by searching the entry directly.
- 1. If the server does not support this control and the
- client specified TRUE for the control's criticality
- field, then the server MUST return
- unavailableCriticalExtension as a return code in
- the searchResponse message and not send back any
- other results. This behavior is specified in
- section 4.1.12 of [LDAPv3].
+ 2. permission "s" to each attribute appearing in a
+ presence test during the evaluation of the search
+ filter. permission "r" to each attribute appearing in
+ non-presence tests (see rfc1960, section 3:
+ equalityMatch, substrings, greaterOrEquial,
+ lessOrEqual, present, approxMatch, extensibleMatch)
+ during the evaluation of the search filter.
- 2. If the server does not support this control and the
- client specified FALSE for the control's
- criticality field, then the server MUST ignore the
- control and process the request as if it were not
- present. This behavior is specified in section
- 4.1.12 of [LDAPv3].
+ 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 then we do not
+ require any access checks to the attributes of the dn
+ candidateDN as access to these is taken to be granted
+ by the "b" permission, which has already been required
+ above.
- 3. If the server supports this control but for some
- reason such as cannot process specified
- rightsFamily and the client specified TRUE for the
- control's criticality field, then the server SHOULD
- do the following: return
- unavailableCriticalExtension as a return code in
- the searchResult message.
+ 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).
- 4. If the server supports this control but for some
- reason such as cannot process specified
- rightsFamily and the client specified FALSE for the
- control's criticality field, then the server should
- process as 'no rights returned for that family' and
+ Note A: Although both "r" and "s" permissions will
+ typically be granted to attributes we keep both
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 15]
+Stokes, et al Expires 14 January 2001 [Page 19]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- include the result Unavailable in the
- getEffectiveRightsResponse control in the
- searchResult message.
+ permissions as there are cases where the distinction
+ is useful. For example, the ability to grant the
+ right to discover that a user entry contains a
+ userPassword attribute, but not to read it's value
+ ("s" but not "r"). The converse, granting "r" but not
+ "s" permission is less easy to motivate.
- 5. If the server supports this control and can return
- the rights per the rightsFamily information, then
- it should include the getEffectiveRightsResponse
- control in the searchResult message with a result
- of success.
+ Note B: There is an unusual behaviour with respect to
+ naming attributes illustrated in the following
+ example:
- 6. If the search request failed for any other reason,
- then the server SHOULD omit the
- getEffectiveRightsResponse control from the
- searchResult message.
+ Suppose I have "b" rights to cn=fred,o=sun.com and "r"
+ rights to attribute objectclass but not "r" rights to
+ cn then with search filter (objectclass=*) I get back
+ the dn and objectclass (and so can see the value of
+ cn), but with a search filter of (cn=fred) I do not
+ get anything.
- The client application is assured that the correct rights
- are returned for scope of the search operation if and
- only if the getEffectiveRightsResponse control returns
- the rights. If the server omits the
- getEffectiveRightsResponse control from the searchResult
- message, the client SHOULD assume that the control was
- ignored by the server.
+ 3. permission "r" to each attribute in the attribute list
- The getEffectiveRightsResponse control, if included by
- the server in the searchResponse message, should have the
- getEffectiveRightsResult set to either success if the
- rights are returned or set to the appropriate error code
- as to why the rights could not be returned.
+ AttributeDescriptionList (or all attributes in the
+ entry candidateDN if AttributeDescriptionList is *)
+ whose type and/or value will be returned.
- The server may not be able to return a right because it
- may not exist in that directory object's attribute; in
- this case, the rights request is ignored with success.
+ Note: 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" permission by using a presence
+ test on that attribute in the search filter.
- 7.2 listSubjectRights Control
+ 4. 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.
- 7.2.1 Request Control
- This control is included in the ldap_search message as
- part of the controls field of the LDAPMessage, as
- defined in Section 4.1.12 of [LDAPv3].
+ 5. Disclose on error for the Search operation
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE) at the client's option. The
+ If every entry in the scope of the search fails to
+ satisfy item 1 (browse right on the candidate entry)
+ or item 2 (right to use the filter on that entry) and
+ if discloseOnError is not granted to the baseObject
+ entry then the operation MUST fail with a "no such
+ object error" and the matchedDN of the LDAPResult MUST
+ be set to "". If every entry in the scope of the
+ search fails to satisfy items 1 or 2 above and
+ discloseOnError is granted to the baseObject then the
+ empty set of results is returned.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 16]
+Stokes, et al Expires 14 January 2001 [Page 20]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+5.3 Modify Operation
+
+Recall that the parameters of the Modify operation per
+RFC2251 [LDAPv3] Section 4.6 are:
+
+ 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:
- controlValue is an OCTET STRING, whose value is the BER
- encoding of a value of the following SEQUENCE:
- listSubjectRightsRequest ::= SEQUENCE {
- targetDN LDAPDN,
- listRightsRequest SEQUENCE OF SEQUENCE {
- rightsFamily LDAPOID | "*",
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- dnType LDAPOID | "*",
- listSubjectDN LDAPString | "*",
- }
- }
+ 1. permission "w" to each attribute being added to object
- The targetDN specifies the initial directory entry in DN
- syntax on which the listSubjectRights control is
- performed. request is a set of sequences that state the
- whichObject (entry or entry plus subtree) and specifics
- of the control request to be performed. One or more
- rightsFamily can be be obtained for a given subjectDN ad
- dnType. A "*" in the rightsFamily field indicates that
- the rights for all rights families defined for the
- subjectDN / dnType are to be returned. A "*" in the
- dnType field indicates that all dnTypes are processed by
- this request. A "*" in the subjectDN field indicates
- that all subjectDNs are processed by this request. The
- scope of the operation is controlled by the scope set in
- the ldap_search operation.
+ If this permission is not granted to such an
+ attribute, then the operation MUST fail. In this
+ case, if discloseOnError is not granted to the entry
+ then "no such object" error is returned; if
+ discloseOnError is granted to the entry and a
+ duplicate attribute value is being added then
+ "attribute value already exists" error is returned; if
+ discloseOnError is granted to the entry and no
+ duplicate value is being added then an "insufficient
+ access" error is returned.
- 7.2.2 Response Control
+ 2. permission "o" to each attribute for which a value is
+ being deleted from object
- This control is included in the ldap_search message as
- part of the controls field of the LDAPMessage, as defined
- in Section 4.1.12 of [LDAPv3].
+ If this permission is not granted to such an attribute
+ then the operation MUST fail. In this case, if
+ discloseOnError is not granted to the entry then "no
+ such object" error is returned; if discloseOnError is
+ granted to the entry and the attribute or one of the
+ values to be deleted does not exist then a "no such
+ attribute or value" error is returned; if
+ discloseOnError is granted to the entry and the
+ attribute and all values specified to be deleted exist
+ then an "insufficient access" error is returned.
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE). The controlValue is an OCTET
- STRING, whose value is the BER encoding of a value of the
- following SEQUENCE:
- listSubjectRightsResponse ::= {
- result ENUMERATED {
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 17]
+Stokes, et al Expires 14 January 2001 [Page 21]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- success (0),
- operationsError (1),
- unavailableCriticalExtension (12),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- invalidAttributeSyntax (21),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
- }
- }
+ 3. permissions "o" and "w" to each attribute being
+ replaced in object
- The subjects' rights returned are returned with each
- attribute returned by the search result. So, the result
- for ldap_search is:
+ If one of these these permissions is not granted to
+ such an attribute then the operation MUST fail. In
+ this case, if discloseOnError is not granted to the
+ entry then a "no such object" error is returned; if
+ discloseOnError is granted to the entry then
+ "insufficient access" error is returned.
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialSubjRightsAttributeList }
- PartialSubjRightsAttributeList ::= SEQUENCE OF SEQUENCE
- {
- rightFamily LDAPOID,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subjectDnType LDAPOID,
- subjectDN LDAPString,
- rightsList ENUMERATED
- }
+5.4 Add Operation
- Although this extends the search operation, there are no
- incompatibilities between versions. LDAPv2 cannot send a
- control, hence the above structure cannot be returned to
- a LDAPv2 client. A LDAPv3 client cannot send this
- request to a LDAPv2 server. A LDAPv3 server not
- supporting this control cannot return the additional
- data.
+Recall that the parameters of the Add operation per RFC2251
+[LDAPv3] Section 4.7 are:
- 7.2.3 Client-Server Interaction
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
- The listSubjectRightsRequest control specifies the rights
- that MUST be returned for the scope of the search. The
- server that consumes the search operation looks up the
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 18]
+ 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.
+
+ 1. permission "m" to the parent of entry for each
+ attribute being added to entry
+
+If any of these permissions are not granted then the
+operation MUST fail. In this case if discloseOnError is on
+and the entry to be added does not already exist then
+"insufficient access" is returned. If it does exist then
+"Entry already exists" is returned. If discloseOnError is
+off then "No such object" is returned (meaning the parent
+object).
+
+If they are all granted then the operation MAY proceed.
+
+Note: We require "m" permission to each attribute to prevent
+an entry from aquiring "unintended" rights (via group or
+role membership), to stop a "rogue" ACI being added that
+would prevent even admins deleting the entry and general
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 22]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+consistency with the MODIFY operation.
+
+Note: The access rights required for the creation of the
+first entry in the directory are beyond the scope of this
+document.
+5.5 Delete Operation
- rights for the returned directory information and returns
- the result as search information associated with the
- scope of that search.
+Recall that the parameters of the Delete operation per
+RFC2251 [LDAPv3] Section 4.10 are:
- There are six possible scenarios that may occur as a
- result of the listSubjectRights control being included on
- the search request:
+ DelRequest ::= [APPLICATION 10] LDAPDN
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- 1. If the server does not support this control and the
- client specified TRUE for the control's criticality
- field, then the server MUST return
- unavailableCriticalExtension as a return code in
- the searchResponse message and not send back any
- other results. This behavior is specified in
- section 4.1.12 of [LDAPv3].
- 2. If the server does not support this control and the
- client specified FALSE for the control's
- criticality field, then the server MUST ignore the
- control and process the request as if it were not
- present. This behavior is specified in section
- 4.1.12 of [LDAPv3].
+ 1. permission "d" to the entry in the Delete request
- 3. If the server supports this control but for some
- reason such as cannot process specified
- rightsFamily and the client specified TRUE for the
- control's criticality field, then the server SHOULD
- do the following: return
- unavailableCriticalExtension as a return code in
- the searchResult message and omit the
- listSubjectRightsResponse control in the
- searchResult message.
+If this permission is not granted, then the operation MUST
+fail. In this case if discloseOnError is on and the entry
+to be deleted exists then "insufficient access" is returned.
+If it does not exist then "No such Object" is returned. If
+discloseOnError is off then "No such object" is returned
+(meaning the parent object).
- 4. If the server supports this control but for some
- reason such as cannot process specified
- rightsFamily and the client specified FALSE for the
- control's criticality field, then the server should
- process as 'no rights returned for that family' and
- include the result Unavailable in the
- listSubjectRightsResponse control in the
- searchResult message.
+If this permission is granted, then the operation MAY
+proceed.
- 5. If the server supports this control and can return
- the rights per the rightsFamily information, then
+Note: One could also require the "o" permission to be
+granted to allow 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
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 19]
+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 }
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 23]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 1. If newSuperior is not present (ie. only the RDN is
+ being renamed) then permission "n" to entry is
+ required.
+
+ 2. If newSuperior is present then permission "e" to entry
+ and permission "i" to newSuperior are required.
+
+If any of these permissions are not granted then the
+operation MUST fail. In this case, if discloseOnError is on
+then an "insufficient access error" is returned. Otherwise,
+"No such object" is returned.
+
+If they are all granted then the operation MAY proceed.
+Note A: We do not require any additional permissions in the
+case where deleteoldrdn is TRUE.
+Note B: These permissions allow the naming attribute of an
+entry (or entries) to be changed even though "o" and "w"
+permissions are not available on the entry. Distinguishing
+the permissions like this allows us to grant permissions for
+the ModifyDN operation, but not the Modify operation and
+vice versa.
- it should include the listSubjectRightsResponse
- control in the searchResult message with a result
- of success.
- 6. If the search request failed for any other reason,
- then the server SHOULD omit the
- listSubjectRightsResponse control from the
- searchResult message.
+5.7 Compare Operation
- The client application is assured that the correct rights
- are returned for the scope of the search operation if and
- only if the listSubjectRightsResponse control returns the
- rights. If the server omits the
- listSubjectRightsResponse control from the searchResponse
- message, the client SHOULD assume that the control was
- ignored by the server.
+Recall that the parameters of the Compare operation per
+RFC2251 [LDAPv3] Section 4.10 are:
- The listSubjectRightsResponse control, if included by the
- server in the searchResponse message, should have the
- searchResult set to either success if the rights were
- returned or set to the appropriate error code as to why
- the rights could not be returned.
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
- The server may not be able to return a right because it
- may not exist in that directory object's attribute; in
- this case, the rights request is ignored with success.
+Then the permissions required by authzID that need to be
+evaluated are as follows:
- 7.3 specifyCredentials Control
+ 1. permission "c" to the attribute in entry on which the
+ comparison is being made.
- 7.3.1 Request Control
+If any of these permissions are not granted then the
+operation MUST fail. In this case, if discloseOnError is on
+then an "insufficient access error" is returned. Otherwise,
+"No such object" is returned.
- This control is included in the ldap_bind message as
- part of the controls field of the LDAPMessage, as
- defined in Section 4.1.12 of [LDAPv3].
+If they are all granted then the operation MAY proceed.
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE) at the client's option. The
- controlValue is an OCTET STRING, whose value is the BER
- encoding of a value of the following SEQUENCE:
- specifyCredentialRequest ::= SEQUENCE {
- credential LDAPString
- }
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 20]
+
+
+Stokes, et al Expires 14 January 2001 [Page 24]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+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.
- }
- The credential specifies the credential (e.g. groups,
- roles, etc) that the client is requesting be associated
- with the bind DN for access control determination in
- subsequent ldap operations. This provides a 'push' model
- for credentials where the client attempts to 'push' the
- credential to the server. The server may process at bind
- time as follows:
+5.9 Extended Operation
- - server may unconditionally ignore
+Recall that the parameters of the Extended operation per
+RFC2251 [LDA{v3] Section 4.12 are:
- - server may unconditionally accept
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
- - server may define trust model and evaluate of the
- trust of each credential
+The access required for an Extended Operation is beyond the
+scope of this document. The required access will normally
+be defined by the implementor of the extended request.
- If this control is not used, it is assumed that the
- server determines (pulls) the credentials associated with
- the bind DN when needed in subsequent ldap operations to
- provide access control.
- 7.3.2 Response Control
- This control is included in the ldap_search message as
- part of the controls field of the LDAPMessage, as defined
- in Section 4.1.12 of [LDAPv3].
+6. Required Permissions for Handling Aliases and References
- The controlType is set to <OID to be assigned>. The
- criticality MAY be either TRUE or FALSE (where absent is
- also equivalent to FALSE). The controlValue is an OCTET
- STRING, whose value is the BER encoding of a value of the
- following SEQUENCE:
- specifyCredentialsResponse ::= {
- result ENUMERATED {
- success (0),
- operationsError (1),
- unavailableCriticalExtension (12),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
- }
- }
+Use of aliases and referrals are part of LDAPv3. However,
+neither is particularly well-defined. Alias
+objects/attributes are defined in RFC 2256 as derived from
+X.500, but LDAPv3 does not explicitly define its 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, section 7.11.1. Referrals and
+knowledge information are still under design in LDAPv3; they
+are defined in X.500, however, X.500 punts on 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 draft 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"
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 21]
+
+
+Stokes, et al Expires 14 January 2001 [Page 25]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+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 seperate 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 draft.
- No data is returned; just the result is returned.
- Although this extends the bind operation, there are no
- incompatibilities between versions. LDAPv2 cannot send a
- control. A LDAPv3 client cannot send this request to a
- LDAPv2 server. A LDAPv3 server not supporting this
- control cannot return the additional data.
+6.2 Aliases
- 7.3.3 Client-Server Interaction
+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.
- The specifyCredentialsRequest control specifies the
- credentials that the client was the server to use for
- access control in subsequent ldap operations. The server
- that consumes the bind operation may unconditionally
- accept, ignore, or evaluate the trust of the specified
- credentials at bind time and returns only a success or
- failure response (no data returned).
+If alias de-referencing is required in the process of
+locating a target entry, no specifc permissions are
+necessary for alias de-referencing to take place. Access
+control is enforced at the object pointed to by the alias.
- There are six possible scenarios that may occur as a
- result of the specifyCredential control being included on
- the bind request:
+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 'aliasedObjectName' attribute.
+Requiring these permission closes the hole of discovery.
- 1. If the server does not support this control and the
- client specified TRUE for the control's criticality
- field, then the server MUST return
- unavailableCriticalExtension as a return code in
- the bindResponse message. This behavior is
- specified in section 4.1.12 of [LDAPv3].
+6.3 Referrals
- 2. If the server does not support this control and the
- client specified FALSE for the control's
- criticality field, then the server MUST ignore the
- control and process the request as if it were not
- present. This behavior is specified in section
- 4.1.12 of [LDAPv3].
+If a referral is to be followed, no specifc 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 - only drafts). 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.
- 3. If the server supports this control but for some
- reason such as cannot process specified credential
- (e.g. server decided to evaluate the trust of that
- credential and the result is the server not
- trusting all the credentials or unconditionally
- ignores the credential) and the client specified
- TRUE for the control's criticality field, then the
- server SHOULD do the following: return
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 22]
+
+
+Stokes, et al Expires 14 January 2001 [Page 26]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+7. Controlling Access to Access Control Information
- unavailableCriticalExtension as a return code in
- the bindResult message and omit the
- specifyCredentialResponse control in the bindResult
- message.
+The ldapACI attribute is used to specify control for who has
+permission to set/change access control information
+(ldapACI). The ldapACI attribute/OID is just another
+attribute described with a scope, set of rights and
+permissions, and subject as a value of the ldapACI
+attribute. (See the example in the "ACI Examples" section).
- 4. If the server supports this control but for some
- reason such as cannot process specified credential
- (e.g. server decided to evaluate the trust of that
- credential and the result is the server not
- trusting all the credentials or unconditionally
- ignores the credential) and the client specified
- FALSE for the control's criticality field, then the
- server should process as 'credential ignored' and
- include the result Unavailable in the
- specifyCredentialResponse control in the bindResult
- message.
+If the policy for controlling the ldapACI attribute is 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 ldapACI within the
+ldapACI attribute, then the server could simply assert that
+the 'root DN' is considered the policy owner (controller for
+controlling access control) for all objects.
- 5. If the server supports this control and evaulates
- the trust of that credential and the result is the
- server trusting all the credentials, then it should
- include the specifyCredentialResponse control in
- the bindResult message with a result of success.
- 6. If the bind request failed for any other reason,
- then the server SHOULD omit the
- specifyCredentialResponse control from the
- bindResult message.
- The client application is assured that the correct
- credentials are used by the server when specified by the
- client for subsequent ldap operations if and only if the
- specifyCredentialResponse is successful. If the server
- omits the specifyCredentialResponse control from the
- searchResponse message, the client SHOULD assume that the
- control was ignored by the server.
+8. ACI Examples
- The specifyCredentialResponse control, if included by the
- server in the bindResponse message, should have the
- bindResult set to either success if the credentials were
- accepted by the server or set to the appropriate error
- code as to why the credentials were not accepted.
+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.
+8.1 Attribute Definition
+The following examples show the access required to control
+access to the ldapACI attribute. 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.
+ ldapACI: entry#grant:r,w#
+ OID.ldapACI#authnLevel:any:role:cn=aciAdmin
+ ldapACI: subtree#grant:r,w#
+ OID.ldapACI#authnLevel:any:role:cn=aciAdmin
+The next example shows a ldapACI 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.
+Authentication of a specified type is not required.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 23]
+ ldapACI:subtree#grant;r,s,c#
+ OID.attr1#group:cn=Dept XYZ,c=US
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 27]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+The next example shows an ACI attribute where a role
+"cn=SysAdmins,o=Company" is being given permissions to add
+objects below this node and read, search, and compare
+attributes attr2 and attr3. The permission applies to the
+entire subtree below the node containing this ACI.
+ ldapACI: subtree#grant:a#
+ [entry]#role:cn=SysAdmins,o=Company
- 8. Access Control Extended Operations
+ ldapACI: subtree#grant:r,s,c#
+ OID.attr2#role:cn=SysAdmins,o=Company
- Two extended operations (analogous to the controls) are
- defined for transmission of access control information.
- These operations help with the management of access
- control information independent of manipulating other
- directory information. The extended operations are:
+ ldapACI: subtree#grant:r,s,c#
+ OID.attr3#role:cn=SysAdmins,o=Company
- - LDAP Get Effective Rights to obtain the effective
- rights for a given directory entry for a given
- subject
- - LDAP List Subject Rights to get the access control
- information for a given directory entry
+8.2 Modifying the ldapACI Values
- 8.1 LDAP Get Effective Rights Operation
+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 ldapACI value is replaced, all ldapACI values are
+replaced.
- ldapGetEffectiveRightsRequest ::= [APPLICATION 23]
- SEQUENCE {
- requestName [0] <OID to be assigned>,
- requestValue [1] OCTET STRING OPTIONAL }
+A given ldapACI for an entry:
- where
+ ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC
- requestValue ::= SEQUENCE {
- targetDN LDAPDN,
- updates SEQUENCE OF SEQUENCE {
- rightsFamily LDAPOID | "*",
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- dnType LDAPOID | "*",
- subjectDN LDAPString,
- }
- }
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+perform the following change:
- The requestName is a dotted-decimal representation of the
- OBJECT IDENTIFIER corresponding to the request. The
- requestValue is information in a form defined by that
- request, encapsulated inside an OCTET STRING.
+ dn: cn=someEntry
+ changetype: modify
+ replace: ldapACI
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
- The server will respond to this with an LDAPMessage
- containing the ExtendedResponse which is a rights list.
+The resulting ACI is:
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
+( ldapACI values for Dept XYZ and ABC are lost through the
+replace )
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 24]
+During an ldapmodify-add, if the ACI does not exist, the
+create the ACI with the specific ldapACI value(s). If the
+ACI does exist, then add the specified values to the given
+ldapACI. For example a given ACI:
+
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 28]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+with a modification:
- ldpGetEffectiveRightsResponse ::= [APPLICATION 24]
- SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] <OID to be assigned> OPTIONAL,
- effectiveRights [11] OCTET STRING OPTIONAL }
+ dn: cn=someEntry
+ changetype: modify
+ add: ldapACI
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
- where
+would yield an multi-valued ACI of:
- effectiveRights ::= SEQUENCE OF SEQUENCE {
- rightFamily LDAPOID,
- rightsList ENUMERATED,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subjectDnType LDAPOID,
- subjectDN LDAPSTRING
- }
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
- If the server does not recognize the request name, it
- MUST return only the response fields from LDAPResult,
- containing the protocolError result code.
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
- 8.2 LDAP List Subject Rights
+To delete a particular ACI value, use the regular ldapmodify
+- delete syntax
- ldapListSubjectRightsRequest ::= [APPLICATION 23]
- SEQUENCE {
- requestName [0] <OID to be assigned>,
- requestValue [1] OCTET STRING }
+Given an ACI of:
- where
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
- requestValue ::= SEQUENCE {
- targetDN LDAPDN,
- updates SEQUENCE OF SEQUENCE {
- rightsFamily LDAPOID | "*",
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- dnType LDAPOID | "*",
- listSubjectDN LDAPString | "*",
- }
- }
+ dn: cn = some Entry
+ changetype: modify
+ delete: ldapACI
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+would yield a remaining ACI on the server of
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+The attributes which are defined for access control
+interchange may be used in all LDAP operations.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 25]
+Within the ldapmodify-delete operation, the entire acl may
+be deleted by specifying
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: ldapACI
+
+In this case, the entry would then inherit its ACI from some
+other node in the tree depending on the server inheritance
+model.
+
+Similarly, if all values of ldapACI are deleted, then the
+access control information for that entry is defined by that
+implementation's inheritance model.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 29]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+8.3 Evaluation
- The requestName is a dotted-decimal representation of the
- OBJECT IDENTIFIER corresponding to the request. The
- requestValue is information in a form defined by that
- request, encapsulated inside an OCTET STRING.
+These examples assume that the ldapACI 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.
+See section 10 for a discussion of the semantics of ldapACI
+entries when backing-store ACI administration is also used.
- The server will respond to this with an LDAPMessage
- containing the ExtendedResponse which is a result code.
+Assume cn=jsmith is a member of group cn=G1. Assume
+cn=jsmith is a member of group cn=G2.
- ldapListSubjectRightsResponse ::= [APPLICATION 24]
- SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] <OID to be assigned> OPTIONAL,
- subjectRightsList [11] OCTET STRING OPTIONAL }
+ Example #1
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r#attr1
+ #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#grant:w#attr1
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
- where
+ What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
+ Read (r) access; authzID is higher precedence than
+ group.
- subjectRightsList ::= SEQUENCE OF SEQUENCE {
- rightFamily LDAPOID,
- whichObject ENUMERATED {
- LDAP_ENTRY (1),
- LDAP_SUBTREE (2)
- },
- subjectDnType LDAPOID,
- subjectDN LDAPString,
- perms SEQUENCE OF SEQUENCE {
- rightsList ENUMERATED,
- attrs LDAPSTRING
- }
- }
- }
- If the server does not recognize the request name, it
- MUST return only the response fields from LDAPResult,
- containing the protocolError result code.
+ Example #2
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r#attr2
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#grant:w#attr2
+ #group:cn=G2,ou=ABC,o=XYZ,c=US
+ What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
+ Read-write (r,w) access; ACI is combined because both
+ subjects (group) have same precedence.
- 9. Operational Semantics of Access Control Operations
+ Example #3
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r,w#attr3
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#deny:w#attr3#group:cn=G2,ou=ABC,o=XYZ,c=US
- The semantics of access control operations described in
- this document are defined operationally in terms of
- "histories". A history is a sequence of actions (x1, x2,
- ..., xN).
+ What rights does cn=jsmith have to attr3 of o=XYZ, c=US?
+ Read access; write is denied (deny has precedence over
+ grant).
+ Example #4
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:w#attr4
+ #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 26]
+Stokes, et al Expires 14 January 2001 [Page 30]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+ ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US
- We consider five types of actions:
+ What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
+ Write (w); rights given to an authzID take precedence
+ over those given to a subtree.
- - LDAP Access Control Policy Update actions:
- invocations of the LDAP Update Access Extended
- Operation or LDAP Update Access Control.
- - LDAP Access Control Policy Query operations:
- invocations of the LDAP Get Effective Access
- Extended Operation, LDAP Get Effective Access
- Control, LDAP List Subject Rights Extended
- Operation, or LDAP List Subject Rights Control.
+ Example #5
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:m#OID.attr5
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:m#OID.cn
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:m#OID.sn
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:a#[entry]
+ #authzID-dn:#cn=jsmith,o=ABC,c=US
- - Datastore Access Control Policy Update Actions: any
- operation implemented by the server which LDAP is
- using as its datastore which changes the access
- policy enforced with respect to attempts to access
- LDAP directory entries and their attributes.
+ What rights does cn=jsmith have to o=XYZ, c=US?
+ Make(m) on attributes attr5, cn, and sn and Add(a)
+ on the entry. These are the minimal yet sufficient
+ permissions to create a new object,
+ cn=New, o=XYZ, c=US with values for the attr5, cn,
+ and sn attributes. This example illustrates how the
+ "m" permission can be used to limit the attributes
+ that can be created on a new entry.
- - LDAP Access Request operations: invocations of LDAP
- entry or attribute access operations (Read, Update,
- Search, Compare, etc...).
+ Example #6
+ dn: c=US
+ ldapACI: subtree#grant:m#[all]#subtree:c=US
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:a#[entry]#
+ authzID-dn:cn=jsmith,o=ABC,c=US
- - Other operations: anything else, including Datastore
- operations which do not change the access policy
- enforced by the server.
+ What rights does cn=jsmith have to o=XYZ, c=US?
+ Make(m) on attributes all attributes and Add(a) on the
+ entry. These are sufficient permissions to create a new
+ object, cn=New, o=XYZ, c=US with values any desired
+ attributes. For administrators who do not wish to limit
+ the attributes that can be created on new entries, this
+ example shows how a single ldapACI at the top of the
+ domain solves the problem.
- The semantics of histories are defined as follows:
- - LDAP Update (Replace), LDAP Query
+9. Operational Semantics of Access Control Operations
- The Query will show that the subject has all rights
- granted by the Update operation, and no rights not
- granted by the Update operation.
+The semantics of access control operations described in this
+document are defined operationally in terms of "histories".
+A history is a sequence of actions (x1, x2, ..., xN).
- - LDAP Update (Grant), LDAP Query
- The Query will show that the subject has all rights
- granted by the Update operation. The Query may show
- that the subject also has other rights not granted
- by the Update operation, depending on the policy in
- force before the Update operation.
- - LDAP Update (Deny), LDAP Query
+Stokes, et al Expires 14 January 2001 [Page 31]
+\f
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 27]
-\f
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 15 April 1999
+9.1 Types of actions
+We consider five types of actions:
+ - LDAP Access Control Policy Update actions: invocations
+ of ldap modify when used to add, delete, or replace the
+ aci attribute; invocations of ldap add when used to add
+ an entry with an aci attribute. A LDAP Access Control
+ Policy Update action may replace the policy (by
+ completely replacing the aci attribute with new policy
+ information) or it may grant or deny specific rights
+ while leaving others unaffected.
- The Query will show that the subject does not have
- any right denied by the Update operation. The Query
- may show that the subject has rights not denied by
- the Update operation, depending on the policy in
- force before the Update operation.
+ - LDAP Access Control Policy Query operations:
+ invocations of ldap search when used to retrieve the
+ aci attribute; invocations of ldap search with the
+ getEffectiveRightsRequest control; invocations of the
+ ldapGetEffectiveRightsRequest extended operation.
- - LDAP Update (Replace), LDAP Access Request
+ - Datastore Access Control Policy Update Actions: any
+ operation implemented by the server which LDAP is using
+ as its datastore which changes the access policy
+ enforced with respect to attempts to access LDAP
+ directory entries and their attributes.
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request will fail with an access-
- denied exception if it requires any right not
- granted by the Update operation.
+ - LDAP Access Request operations: invocations of LDAP
+ entry or attribute access operations (Read, Update,
+ Search, Compare, etc...).
- - LDAP Update (Grant), LDAP Access Request
+ - Other operations: anything else, including Datastore
+ operations which do not change the access policy
+ enforced by the server.
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request may succeed if it requires
- rights not granted by the Update operation,
- depending on the policy in force before the Update
- operation.
- - LDAP Update (Deny), LDAP Access Request
+9.2 Semantics of Histories
- The Request will fail with an access-denied
- exception if it requires any right denied to the
- requesting subject by the Update operation. If the
- Request requires only rights which were not denied
- by the Update operation, it may succeed, depending
- on the policy in force before the Update operation.
+The semantics of histories are defined as follows:
- - LDAP Update (Replace), Other, LDAP Query
+ - LDAP Update (Replace), LDAP Query
- The Query will show that the subject has all rights
- granted by the Update operation, and no rights not
- granted by the Update operation.
+ The Query will show that the subject has all rights
+ granted by the Update operation, and no rights not
+ granted by the Update operation.
- - LDAP Update (Grant), Other, LDAP Query
+ - LDAP Update (Grant), LDAP Query
- The Query will show that the subject has all rights
- granted by the Update operation. The Query may show
- that the subject also has other rights not granted
- by the Update operation, depending on the policy in
- force before the Update operation.
+ The Query will show that the subject has all rights
+ granted by the Update operation. The Query may show
+ that the subject also has other rights not granted by
+ the Update operation, depending on the policy in force
+ before the Update operation.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 28]
+Stokes, et al Expires 14 January 2001 [Page 32]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- - LDAP Update (Deny), Other, LDAP Query
+ - LDAP Update (Deny), LDAP Query
- The Query will show that the subject does not have
- any right denied by the Update operation. The Query
- may show that the subject has rights not denied by
- the Update operation, depending on the policy in
- force before the Update operation.
+ The Query will show that the subject does not have any
+ right denied by the Update operation. The Query may
+ show that the subject has rights not denied by the
+ Update operation, depending on the policy in force
+ before the Update operation.
- - LDAP Update (Replace), Other, LDAP Access Request
+ - LDAP Update (Replace), LDAP Access Request
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request will fail with an access-
- denied exception if it requires any right not
- granted by the Update operation.
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request will fail if it requires any
+ right not granted by the Update operation.
- - LDAP Update (Grant), Other, LDAP Access Request
+ - LDAP Update (Grant), LDAP Access Request
- The Request will succeed if it requires only rights
- granted to the requesting subject by the Update
- operation. The Request may succeed if it requires
- rights not granted by the Update operation,
- depending on the policy in force before the Update
- operation.
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request may succeed if it requires
+ rights not granted by the Update operation, depending
+ on the policy in force before the Update operation.
- - LDAP Update (Deny), Other, LDAP Access Request
+ - LDAP Update (Deny), LDAP Access Request
- The Request will fail with an access-denied
- exception if it requires any right denied to the
- requesting subject by the Update operation. If the
- Request requires only rights which were not denied
- by the Update operation, it may succeed, depending
- on the policy in force before the Update operation.
+ The Request will fail if it requires any right denied
+ to the requesting subject by the Update operation. If
+ the Request requires only rights which were not denied
+ by the Update operation, it may succeed, depending on
+ the policy in force before the Update operation.
- - LDAP Update (Replace), Datastore Update, LDAP Query
+ - LDAP Update (Replace), Other, LDAP Query
- The result of the Query is not defined.
+ The Query will show that the subject has all rights
+ granted by the Update operation, and no rights not
+ granted by the Update operation.
- - LDAP Update (Grant), Datastore Update, LDAP Query
+ - LDAP Update (Grant), Other, LDAP Query
- The result of the Query is not defined.
+ The Query will show that the subject has all rights
+ granted by the Update operation. The Query may show
+ that the subject also has other rights not granted by
+ the Update operation, depending on the policy in force
+ before the Update operation.
- - LDAP Update (Deny), Datastore Update, LDAP Query
+ - LDAP Update (Deny), Other, LDAP Query
- The result of the Query is not defined.
+ The Query will show that the subject does not have any
+ right denied by the Update operation. The Query may
+ show that the subject has rights not denied by the
+ Update operation, depending on the policy in force
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 29]
+Stokes, et al Expires 14 January 2001 [Page 33]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+ before the Update operation.
- - LDAP Update (Replace), Datastore Update, LDAP Access
- Request
+ - LDAP Update (Replace), Other, LDAP Access Request
- The result of the Access Request is not defined.
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request will fail if it requires any
+ right not granted by the Update operation.
- - LDAP Update (Grant), Datastore Update, LDAP Access
- Request
+ - LDAP Update (Grant), Other, LDAP Access Request
- The result of the Access Request is not defined.
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request may succeed if it requires
+ rights not granted by the Update operation, depending
+ on the policy in force before the Update operation.
- - LDAP Update (Deny), Datastore Update, LDAP Access
- Request
+ - LDAP Update (Deny), Other, LDAP Access Request
- The result of the Access Request is not defined.
+ The Request will fail if it requires any right denied
+ to the requesting subject by the Update operation. If
+ the Request requires only rights which were not denied
+ by the Update operation, it may succeed, depending on
+ the policy in force before the Update operation.
+ - LDAP Update (Replace), Datastore Policy Update, LDAP
+ Query
+ The result of the Query is not defined.
- 10. LDIF Syntax for Access Control Information
+ - LDAP Update (Grant), Datastore Policy Update, LDAP
+ Query
+ The result of the Query is not defined.
- 10.1 LDIF Purpose
+ - LDAP Update (Deny), Datastore Policy Update, LDAP Query
- The intent of the LDIF is to design a common interchange
- format. Any given LDAP server should be able to translate
- the below defined LDIF into a meaningful request. Each
- server should be able to understand each part of the
- LDIF; there should not be any ambiguity into what any
- part of the syntax means.
+ The result of the Query is not defined.
- While the end goal is to have a common behavior model
- between different LDAP server implementations, the LDIF
- alone will not ensure identical ACL processing behavior
- between servers. The semantics of how a server
- interprets the aci syntax are not defined here. What
- 'deny' means on server1 might be different than on
- server2.
+ - LDAP Update (Replace), Datastore Policy Update, LDAP
+ Access Request
- The LDIF maintains an assumption that the receiving
- server supports 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 result of the Access Request is not defined.
+ - LDAP Update (Grant), Datastore Policy Update, LDAP
+ Access Request
+ The result of the Access Request is not defined.
+ - LDAP Update (Deny), Datastore Policy Update, LDAP
+ Access Request
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 30]
+Stokes, et al Expires 14 January 2001 [Page 34]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- 10.2 ACL Attributes
+ The result of the Access Request is not defined.
- There are three attributes which are allowed on all
- directory objects: aci, vendorAci and policyOwner. The
- syntax of these attributes is defined below. The aci,
- vendorAci and policyOwner attribute are all multivalued.
- In determining the order of the syntax, the DN was left
- until the end for parsing reasons. Examples follow the
- BNF
- 10.2.1 VendorACI_
+10. Access Control Parameters for LDAP Controls & Extended
+Operations
- The Vendor specific ACI information is listed in its own
- attribute. The assumption here is that if the vendor's
- need to provide information in an additional attribute,
- then the vendor specific information would not
- necessarily be of the same syntax as the ACI attribute
- which would have < acl syntax> .
+This section defines the parameters used in the access
+control LDAP controls and extended operations in this
+document.
+targetDN specifies the initial directory entry in DN syntax
+on which the control or extended operation is performed.
- 10.2.2 Policy Owner_
+whichObject specifies whether the access control information
+(in the get effective rights control) which is retrieved is
+for the target directory entry (ENTRY) or the target
+directory entry and its subtree (SUBTREE).
- The intent behind policy ownership is that it controls
- administrative subdomains. It can also control who has
- permission to set / change acls for implementations that
- do not have an acl controlling access to itself. If
- there are multiple policy owners it is implementation
- specific as to the behavior of whether policy owner #1
- can override policy owner # 2.
+rights in the get effective rights control or extended
+operation response is of the form specified in the BNF for
+<rights>.
- The syntax for policyOwner includes the 'scope' flag.
- Servers which do not support inheritance must expand the
- policyOwner inheritance similar to the expansion of the
- ACI. If the policy owner is not specified for any
- object in the tree, behavior is implementation defined.
- For instance, if no object anywhere in the tree has a
- policy owner, then the server could simply assert that
- the 'root DN' is considered the policy owner for all
- objects. An alternate approach might be that the
- implementation defines the entryDN to be the policy
- owner.
+subject is a LDAP string that defines the subject. Access
+control is get/set on a subject. The syntax of the subject
+is the same as the subject field in the BNF.
- The policyOwner and ACI are left as distinct attributes
- for several reasons. They syntax of the policy owner is
+
+
+11. Access Control Information (ACI) Controls
+
+The access control information controls provide a way to
+manipulate access control information in conjunction with a
+LDAP operation. One LDAP control is defined. This control
+allows access control information to be retrieved while
+manipulating other directory information for that entry.
+The control is:
+
+ - getEffectiveRights to obtain the effective rights for a
+ given directory entry(s) for a given subject during a
+ ldap_search operation
+
+11.1 getEffectiveRights Control
+
+
+11.1.1 Request Control
+
+This control may only be included in the ldap_search
+message as part of the controls field of the
+LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 31]
-\f
+Stokes, et al Expires 14 January 2001 [Page 35]
+\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- very similar to the syntax of the ACI. In parsing, it
- would be difficult to tell when one stops and the other
- begins (especially since there are no reserved characters
- in LDAP Dns ). Additionally, the inheritance models of
- the administrative subdomains may be different then the
- models guiding the ACI inheritance. Since there is no
- flag to tell if a given ACI is explicit vs inherited,
- combining the two sets of information ties the
- policyOwner inheritance to ACI inheritance. Additionally,
- keeping the information separate makes it easier for the
- applications to construct views of various models by only
- requesting the information they need.
+The controlType is set to <OID to be assigned>. The
+criticality MAY be either TRUE or FALSE (where absent is
+also equivalent to FALSE) at the client's option. The
+controlValue is an OCTET STRING, whose value is the BER
+encoding of a value of the following SEQUENCE:
- 10.2.3 ACI
+ getEffectiveRightsRequest ::= SEQUENCE {
+ effectiveRightsRequest SEQUENCE OF SEQUENCE {
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject <see <subject > in BNF> | "*"
+ }
+ }
- The aci attribute is defined using < acl syntax>. Within
- the acl syntax, the family OID describes the permissions,
- dnType, subhectDn and scope that will be found in the
- following string. The permissions for the IETF family
- are found below. The family OID is listed first in the
- syntax to be consistent with other LDAP LDIF definitions
- which list OIDs first. If the OID within the ACI
- attribute is listed as other than the IETF family oid,
- the syntax is the same as l isted below, but one or more
- of the scope, dnType, subjectDn or permissions may vary
- from the IETF defined syntax.
+The effectiveRightsRequest is a set of sequences that state
+the whichObject (entry or entry plus subtree) and specifics
+of the control request to be performed. A "*" in the subject
+field specifies that all DN types are to be used in
+returning the effective rights. This control is applied to
+the filter and scope set by the ldap_search operation, i.e.
+base, one-level, subtree. So the attributes/values returned
+are defined by the ldap_search operation.
- Within the acl syntax, there is a string which describes
- the rights. This is a composite of the permissions and
- resources to which the user is being granted or denied
- access. The set of permissions is fixed. Either of the
- actions "grant" | "deny" may be used when creating or
- updating an aci.
+11.1.2 Response Control
- Using the BNF defined below, it is possible for the
- permission string to be empty. The aci
+This control is included in the ldap_search_response message
+as part of the controls field of the LDAPMessage, as defined
+in Section 4.1.12 of [LDAPv3].
- aci:
- 1.2.3.4#subtree#grant;;attribute1$grant;r,s;[all]#group#cn=Dept
- XYZ, c=US
+The controlType is set to <OID to be assigned>. There is no
+need to set the criticality on the response. The
+controlValue is an OCTET STRING, whose value is the BER
+encoding of a value of the following SEQUENCE:
- mean that this group is granted permission to read and
- search all attributes except attribute1.
+ getEffectiveRightsResponse ::= {
+ result ENUMERATED {
+ success (0),
+ operationsError (1),
+ unavailableCriticalExtension (12),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ invalidAttributeSyntax (21),
+ insufficientRights (50),
+ unavailable (52),
+ unwillingToPerform (53),
+ other (80)
+ }
+ }
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 32]
+Stokes, et al Expires 14 January 2001 [Page 36]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
+
+
+The effective rights returned are returned with each entry
+returned by the search result. The control response for
+ldap_search is:
+ PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
+ rights <see <rights> in BNF>,
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject < see <subject> in BNF >
+ }
- Similarly, the aci
+Although this extends the search operation, there are no
+incompatibilities between versions. LDAPv2 cannot send a
+control, hence the above structure cannot be returned to a
+LDAPv2 client. A LDAPv3 client cannot send this request to
+a LDAPv2 server. A LDAPv3 server not supporting this
+control cannot return the additional data.
- aci: 1.2.3.4#subtree#group#cn=Dept XYZ, c=US simply
- means that no permissions have been defined for this
- group. It is up to the server implementation as to
- whether the group does or does not receive permission to
- attributes on an entry with an empty rights list.
+11.1.3 Client-Server Interaction
- The attributeString is an attribute Name (defined to be a
- printable string). If the string refers to an attribute
- not defined in the given server's schema, the server
- SHOULD report an error. Another option for the
- attributeString is "[entry]". This is provided to
- describe permissions which apply to an entire object.
- This could mean actions such as delete the object, or add
- a child object. The third option for attributeString is
- "[all]" which means the permission set should apply to
- all attributes.
+The getEffectiveRightsRequest control requests the rights
+that MUST be in effect for requested directory
+entry/attribute based on the subject DN. The server that
+consumes the search operation looks up the rights for the
+returned directory information based on the subject DN and
+returns that rights information.
- 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]". If two acis contain identical
- familyOID, scope, DnTypes and DNs, the permission given
- DN is specified in two distinct acis on any given entry,
- the rights lists can be combined into one list. For
- example:
+There are six possible scenarios that may occur as a result
+of the getEffectiveRights control being included on the
+search request:
- aci: 1.2.3.4#subtree#group#grant;r,w;[all]#cn=Dept XYZ
- aci: 1.2.3.4#subtree#group#grant;r;attribute1#cn=Dept
- XYZ
- is the equivalent of
+ 1. If the server does not support this control and the
+ client specified TRUE for the control's criticality
+ field, then the server MUST return
+ unavailableCriticalExtension as a return code in the
+ searchResponse message and not send back any other
+ results. This behavior is specified in section 4.1.12
+ of [LDAPv3].
- aci:
- 1.2.3.4#subtree#group#grant;r,w;[all];r,attribute1#cn=Dept
- XYZ
+ 2. If the server does not support this control and the
+ client specified FALSE for the control's criticality
+ field, then the server MUST ignore the control and
+ process the request as if it were not present. This
+ behavior is specified in section 4.1.12 of [LDAPv3].
- Multiple attributeStrings can be listed after any given
- permission set; for instance, "r,w ; attribute1,
- attribute2". This means that if the server supports a
- attribute aggregation mechanism, attribute1 and
- attribute2 should be considered to be part of the same
- group. If the server does not support a grouping
- mechanism, the permission set applies independently to
+ 3. If the server supports this control but for some
+ reason such as cannot process specified family and the
+ client specified TRUE for the control's criticality
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 33]
+Stokes, et al Expires 14 January 2001 [Page 37]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- attribute1 and attribute2. For servers that do not
- support attribute grouping, "r,w ; attribute1,
- attribute2" results in the same operations as " r,w;
- attribute1; r,w; attribute2 "
+ field, then the server SHOULD do the following: return
+ unavailableCriticalExtension as a return code in the
+ searchResult message.
- Within the vendorACI, the oid determines the format or
- the printable string to follow.
+ 4. If the server supports this control but for some
+ reason such as cannot process specified family and the
+ client specified FALSE for the control's criticality
+ field, then the server should process as 'no rights
+ returned for that family' and include the result
+ Unavailable in the getEffectiveRightsResponse control
+ in the searchResult message.
+ 5. If the server supports this control and can return the
+ rights per the family information, then it should
+ include the getEffectiveRightsResponse control in the
+ searchResult message with a result of success.
- 10.3 Modifying the ACI Values
+ 6. If the search request failed for any other reason,
+ then the server SHOULD omit the
+ getEffectiveRightsResponse control from the
+ searchResult message.
- The attribute: value pairs listed below would be possible
- inputs for normal LDAP operations such as ldapadd and
- ldapmodify. Within the ldapmodify command there are
- three changetypes: add, delete, replace.
+The client application is assured that the correct rights
+are returned for scope of the search operation if and only
+if the getEffectiveRightsResponse control returns the
+rights. If the server omits the getEffectiveRightsResponse
+control from the searchResult message, the client SHOULD
+assume that the control was ignored by the server.
- Replace works similarly to all other attributes. If the
- attribute value does not exist, create the value. If the
- attribute does exist, replace the value. If the aci
- value is replaced, all aci values are replaced. Given an
- aci for an entry:
+The getEffectiveRightsResponse control, if included by the
+server in the searchResponse message, should have the
+getEffectiveRightsResult set to either success if the rights
+are returned or set to the appropriate error code as to why
+the rights could not be returned.
- aci:
- 1.2.3.4#subtree#deny;r,w;[all];grant;rsc;attirbute2#group#cn=Dept
- ABC
- aci:
- 1.2.3.4#subtree#grant;r,;[all];grant;rsc;attirbute1#group#cn=Dept
- XYZ
+The server may not be able to return a right because it may
+not exist in that directory object's attribute; in this
+case, the rights request is ignored with success.
- perform the following change:
- dn: cn=someEntry
- changetype: replace
- add: aci
- aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
+12. Access Control Extended Operation
- The resulting acl is:
+An extended operation, get effective rights, is defined to
+obtain the effective rights for a given directory entry for
+a given subject. This operation may help with the
+management of access control information independent of
+manipulating other directory information.
- aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
- (aci 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 aci value(s). If the
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 34]
+
+Stokes, et al Expires 14 January 2001 [Page 38]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- aci does exist, then add the specified values to the
- given aci. For example a given aci:
+12.1 LDAP Get Effective Rights Operation
- aci: 1.2.3.4#subtree#group#grant;r,w;[all]#cn=Dept XYZ
+ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE
+{
+ requestName [0] <OID to be assigned>,
+ requestValue [1] OCTET STRING OPTIONAL }
- with a modification:
- dn: cn=someEntry
- changetype: add
- add: aci
- aci: 1.2.3.4#subtree#group#grant;r;attribute1#cn=Dept
- XYZ
+ where
- would yield an aci value of:
+ requestValue ::= SEQUENCE {
+ targetDN LDAPDN,
+ updates SEQUENCE OF SEQUENCE {
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ attr SEQUENCE {
+ attr <see <attr> in BNF >
+ },
+ subject < see <subject> in BNF > | "*"
+ }
+ }
- aci:
- 1.2.3.4#subtree#group#grant;r,w;[all];r,attribute1#cn=Dept
- XYZ
- To delete an entire acl, use ldapmodify - delete without
- specifying a value for the aci. The entry would then
- inherit its aci from some other node in the tree
- depending on the server inheritance model.
+The requestName is a dotted-decimal representation of the
+OBJECT IDENTIFIER corresponding to the request. The
+requestValue is information in a form defined by that
+request, encapsulated inside an OCTET STRING.
- dn: cn = some Entry
- changetype: delete
- delete: aci
+The server will respond to this with an LDAPMessage
+containing the ExtendedResponse which is a rights list.
- During an ldapmodify-delete, there are two possible
- interpretations of the delete.
+ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE
+{
+ COMPONENTS OF LDAPResult,
+ responseName [10] <OID to be assigned> OPTIONAL,
+ effectiveRights [11] OCTET STRING OPTIONAL }
- dn: cn = some Entry
- changetype: delete
- delete: aci
- aci: < > (see below)
+ where
- Interpretation 1.
+ effectiveRights ::= SEQUENCE OF SEQUENCE {
+ rights <see <rights> in BNF>,
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject < see <subject> in BNF >
+ }
- aci: 1.2.3.4#subtree#group#cn=Dept XYZ
- would delete the entire aci for the group cn=Dept XYZ
+If the server does not recognize the request name, it MUST
+return only the response fields from LDAPResult, containing
- Interpretation 2.
- aci:
- 1.2.3.4#subtree#grant;rsc;attribute1#group#cn=Dept XYZ
- would delete the 'grant;rsc;attribute1' portion of the
+Stokes, et al Expires 14 January 2001 [Page 39]
+\f
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 35]
-\f
+Internet-Draft Access Control Model 14 July 2000
- Internet-Draft Access Control Model 15 April 1999
+the protocolError result code.
- aci
- for the group cn=Dept XYZ
- before ldapmodify - delete:
- aci:
- 1.2.3.4#subtree#group#grant;r,w;[all];grant;rsc;attribute1#cn=Dept
- XYZ
+13. Security Considerations
- after ldapmodify - delete of attribute1
- aci: 1.2.3.4#subtree#group#grant;r,w;[all];#cn=Dept
- XYZ
+This document proposes protocol elements for transmission of
+security policy information. Security considerations are
+discussed throughout this draft. Because subject security
+attribute information is used to evaluate decision requests,
+it is security-sensitive information and must be protected
+against unauthorized modification whenever it is stored or
+transmitted.
- if the delete is for an attribute not existing within
- the aci, nothing
- is changed in the expected outcome. For example, if now
- attribute2
- is deleted,
+Interaction of access control with other directory functions
+(other than the ones defined in this document) are not
+defined in this document, but instead in the documents where
+those directory functions are defined. For example, the
+directory replication documents should address the
+interaction of access control with the replication function.
- aci: 1.2.3.4#subtree#grant;[attribute2]#group#cn=Dept
- XYZ
- the resulting aci would still be
- aci: 1.2.3.4#subtree#group#grant;r,w;[all];#cn=Dept
- XYZ
+14. References
+[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
+Access Protocol (v3)", RFC 2251, December 1997.
- 10.4 BNF
+[ECMA] ECMA, "Security in Open Systems: A Security
+Framework" ECMA TR/46, July 1988.
- <aci> ::= <acl syntax>
- <vendorAci > ::= <oid> + '#' + <printable string>
+[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements
+for LDAP", RFC 2820, May 2000.
- <acl syntax> ::= <familyOID> + '#' + <scope> + '#' +
- <rights> + '#' + <dnType> + '#' + <subjectDn>
+[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
+Directory Access Protocol (v3)": Attribute Syntax
+Definitions, RFC 2252, December 1997.
- <policyOwner> ::= <familyOid> + '#' + <scope> + '#' +
- <dnType> + '#' + <subjectDn>
+[UTF] M. Wahl, S. Kille, "Lightweight Directory Access
+Protocol (v3)": A UTF-8 String Representation of
+Distinguished Names", RFC 2253, December 1997.
- <subjectDn> ::= <printable string>
- <familyOid> ::= < oid >
+[Bradner97] Bradner, Scott, "Key Words for use in RFCs to
+Indicate Requirement Levels", RFC 2119.
- <scope> :: "entry" | "subtree"
+[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R.
+Morgan, "Authentication Methods for LDAP", RFC 2829, May
+2000.
- <dnType> :: "access-id" | "role" | "group"
- <rights> ::= [ ] | [ < right > + [ '$' + <right> ] * ]
+[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 36]
+Stokes, et al Expires 14 January 2001 [Page 40]
\f
- Internet-Draft Access Control Model 15 April 1999
+Internet-Draft Access Control Model 14 July 2000
- <right> ::= <action> + ';' + <permissions> +
- ';' + <attrs>
+ACKNOWLEDGEMENT
- <action> ::= "grant" | "deny"
+This is to acknowledge the numerous companies and individuals who have
+contributed their valuable help and insights to the development of this
+specification.
- <permissions> ::= [ ] | [ < permission > +
- [ ',' + <permission> ] * ]
- <attrs > ::= [ <attributeString> +
- [ ',' + <attributeString > ] * ]
- <attributeString> ::= "[all]" | "[entry]" |
- <printableString>
+AUTHOR(S) ADDRESS
- <permission> : "a" | "d" | "r" | "s" | "w" | "c"
- | "g" | "s" | "m" | "u"
- These are the permissions defined for
- the IETF family OID.
+ Ellen Stokes Bob Blakley
+ Tivoli Systems Tivoli Systems
+ 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway
+ Austin, TX 78731 Austin, TX 78731
+ USA USA
+ mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com
+ phone: +1 512 436 9098 phone: +1 512 436 1564
+ fax: +1 512 436 1199 fax: +1 512 436 1199
- 10.5 Examples
+ Debbie Rinkevich Robert Byrne
+ IBM Sun Microsystems
+ 11400 Burnet Rd 29 Chemin du Vieux Chene
+ Austin, TX 78758 Meylan ZIRST 38240
+ USA France
+ mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com
+ phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05
+ fax: +1 512 838 8597
- Suppose IETFFamilyOID = 1.2.3.4
- The following two examples show an administrative
- subdomain being established. The first example shows a
- single user being assigned the policyOwner for the entire
- domain. The second example shows a group of ids assigned
- to the policy Owner.
- policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt
- policyOwner: 1.2.3.4#subtree#group#cn=System Owners,
- o=Company
- The next example shows an aci attribute where a group
- "cn=Dept XYZ, c=US" is being given permissions to read,
- search and compare attribute1. The permission should
- apply to the entire subtree below the node containing
- this aci.
- aci: 1.2.3.4#subtree#group#grant;r,s,c;attribute1#cn=Dept
- XYZ, c=US
- The next example shows an ACI attribute where a role
- "cn=SysAdmins,o=Company" is being given permissions to
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 37]
-\f
- Internet-Draft Access Control Model 15 April 1999
- add objects below this node, and read, search and compare
- attributes2 and 3. The permission should apply to the
- entire subtree below the node containing this ACI.
- aci:
- 1.2.3.4#subtree#role#grant;a;[entry]$grant;r,s,c;attribute2,attribute3#cn=SysAdmins,o=Company
- 11. Security Considerations
- This draft proposes protocol elements for transmission of
- security policy information. Security considerations are
- discussed throughout this draft. Because subject
- security attribute information is used to evaluate
- decision requests, it is security-sensitive information
- and must be protected against unauthorized modification
- whenever it is stored or transmitted.
- 12. References
- [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight
- Directory Access Protocol (v3)", RFC 2251, December 1997.
- [ECMA] ECMA, "Security in Open Systems: A Security
- Framework" ECMA TR/46, July 1988
+Stokes, et al Expires 14 January 2001 [Page 41]
+\f
- [REQTS] Stokes, Byrne, Blakley, "Access Control
- Requirements for LDAP, INTERNET-DRAFT <draft-ietf-
- ldapext-acl-reqts-01.txt>, August 1998.
- [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille,
- "Lightweight Directory Access Protocol (v3)": Attribute
- Syntax Definitions, RFC 2252, December 1997.
- [UTF] M. Wahl, S. Kille, "Lightweight Directory Access
- Protocol (v3)": A UTF-8 String Representation of
- Distinguished Names", RFC 2253, December 1997.
- [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
- Indicate Requirement Levels", RFC 2119.
+Internet-Draft Access Control Model 14 July 2000
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 38]
-\f
- Internet-Draft Access Control Model 15 April 1999
- AUTHOR(S) ADDRESS
- Ellen Stokes Bob Blakley
- IBM Dascom
- 11400 Burnet Rd
- Austin, TX 78758 Austin, TX
- USA USA
- mail-to: stokes@austin.ibm.com mail-to: blakley@dascom.com
- phone: +1 512 838 3725
- fax: +1 512 838 8597
- Debbie Byrne
- IBM
- 11400 Burnet Rd
- Austin, TX 78758
- USA
- mail-to: djbyrne@us.ibm.com
- phone: +1 512 838 1960
- fax: +1 512 838 0156
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 39]
-\f
- Internet-Draft Access Control Model 15 April 1999
+Stokes, et al Expires 14 January 2001 [Page 42]
+\f
+ CONTENTS
+ 1. Introduction....................................... 2
+ 2. The LDAPv3 Access Control Model.................... 2
+ 3. Access Control Mechanism Attributes................ 5
+ 3.1 Root DSE Attribute for Access Control
+ Mechanism.................................... 5
+ 3.2 Root DSE Attribute for Control of Disclosing
+ Errors....................................... 5
+ 3.3 Subentry Class Access Control Mechanism...... 6
+ 4. The Access Control Information Attribute
+ (ldapACI).......................................... 7
+ 4.1 The BNF...................................... 8
+ 4.1.1 ACI String Representation 8
+ 4.1.2 ACI Binary Representation 10
+ 4.2 The Components of ldapACI Attribute.......... 11
+ 4.2.1 Scope 11
+ 4.2.2 Access Rights and Permissions 11
+ 4.2.3 Attributes 14
+ 4.2.4 Subjects and Associated
+ Authentication 15
+ 4.3 Grant/Deny Evaluation Rules.................. 15
+ 5. Required Permissions for each LDAP Operation....... 17
+ 5.1 Bind Operation............................... 18
+ 5.2 Search Operation............................. 18
+ 5.3 Modify Operation............................. 21
+ 5.4 Add Operation................................ 22
+ 5.5 Delete Operation............................. 23
+ 5.6 Modify DN Operation.......................... 23
+ 5.7 Compare Operation............................ 24
+ 5.8 Abandon Operation............................ 25
+ 5.9 Extended Operation........................... 25
+ 6. Required Permissions for Handling Aliases and
+ References......................................... 25
+ 6.1 ACI Distribution............................. 25
+ 6.2 Aliases...................................... 26
+ 6.3 Referrals.................................... 26
+ 7. Controlling Access to Access Control
+ Information........................................ 27
+ 8. ACI Examples....................................... 27
+ 8.1 Attribute Definition......................... 27
+ 8.2 Modifying the ldapACI Values................. 28
+ 8.3 Evaluation................................... 30
+ - i -
+ 9. Operational Semantics of Access Control
+ Operations......................................... 31
+ 9.1 Types of actions............................. 32
+ 9.2 Semantics of Histories....................... 32
+10. Access Control Parameters for LDAP Controls &
+ Extended Operations................................ 35
+11. Access Control Information (ACI) Controls.......... 35
+ 11.1 getEffectiveRights Control................... 35
+ 11.1.1 Request Control 35
+ 11.1.2 Response Control 36
+ 11.1.3 Client-Server Interaction 37
+12. Access Control Extended Operation.................. 38
+ 12.1 LDAP Get Effective Rights Operation.......... 39
+13. Security Considerations............................ 40
+14. References......................................... 40
- Stokes, Byrne, Blakley Expires 15 October 1999 [Page 40]
-\f
- CONTENTS
- 1. Introduction....................................... 2
- 2. Overview........................................... 2
- 3. Terminology........................................ 3
- 4. The Model.......................................... 6
- 4.1 Access Control Activity Lifecycle............ 6
- 4.2 Access Control Information Model............. 6
- 4.3 Bind and Credentials......................... 8
- 5. Access Control Information Schema.................. 8
- 5.1 Attributes................................... 8
- 5.1.1 Root DSE Attribute for Access
- Control Mechanism 8
- 5.1.2 Subschema Attribute for Access
- Control Mechanism 9
- 5.2 Other Defined Parameters/OIDs................ 9
- 5.2.1 Rights Families and Rights 9
- 5.2.2 DN Types 10
- 6. Access Control Parameters for LDAP Controls &
- Extended Operations................................ 10
- 7. Access Control Information (ACI) Controls.......... 12
- 7.1 getEffectiveRights Control................... 13
- 7.1.1 Request Control 13
- 7.1.2 Response Control 13
- 7.1.3 Client-Server Interaction 15
- 7.2 listSubjectRights Control.................... 16
- 7.2.1 Request Control 16
- 7.2.2 Response Control 17
- 7.2.3 Client-Server Interaction 18
- 7.3 specifyCredentials Control................... 20
- 7.3.1 Request Control 20
- 7.3.2 Response Control 21
- 7.3.3 Client-Server Interaction 22
- 8. Access Control Extended Operations................. 24
- 8.1 LDAP Get Effective Rights Operation.......... 24
- 8.2 LDAP List Subject Rights..................... 25
- - i -
+ - ii -
- 9. Operational Semantics of Access Control
- Operations......................................... 26
- 10. LDIF Syntax for Access Control Information......... 30
- 10.1 LDIF Purpose................................. 30
- 10.2 ACL Attributes............................... 31
- 10.2.1 VendorACI 31
- 10.2.2 Policy Owner 31
- 10.2.3 ACI 32
- 10.3 Modifying the ACI Values..................... 34
- 10.4 BNF.......................................... 36
- 10.5 Examples..................................... 37
- 11. Security Considerations............................ 38
- 12. References......................................... 38
+Full Copyright Statement
+Copyright (C) The Internet Society (2000).á All Rights
+Reserved.
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implementation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the
+above copyright notice and this paragraph are included on
+all such copies and derivative works.á However, this
+document itself may not be modified in any way, such as by
+removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed
+for the purpose of developing Internet standards in which
+case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to
+translate it into languages other than English.
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+This document and the information contained herein is
+provided on an "AS IS" basis and THE INTERNET SOCIETY AND
+THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
+WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
+ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
+INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- - ii -
+ - iii -
projects / openldap / blobdiff