From 1fdb11c817b6dc263201b1dd2b1a51f83f7f3c04 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Fri, 21 Jul 2000 22:51:21 +0000 Subject: [PATCH] Rev 06 --- .../draft-ietf-ldapext-acl-model-xx.txt | 3157 ++++++++++------- 1 file changed, 1958 insertions(+), 1199 deletions(-) diff --git a/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt b/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt index 9beb721f9f..7e159eb220 100644 --- a/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt +++ b/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt @@ -5,1891 +5,2631 @@ - Internet-Draft E. Stokes - LDAP Extensions WG D. Byrne - Intended Category: Standards Track IBM - Expires: 10 September 2000 B. Blakley - Dascom - 10 March 2000 +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 - + Access Control Model for LDAPv3 + - 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 - COPYRIGHT NOTICE - Copyright (C) The Internet Society (1997). All Rights - Reserved. +COPYRIGHT NOTICE - ABSTRACT +Copyright (C) The Internet Society (2000). All Rights +Reserved. - This document describes the access control model for the - Lightweight Directory Application Protocol (LDAP) +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 10 September 2000 [Page 1] +Stokes, et al Expires 14 January 2001 [Page 1] + +Internet-Draft Access Control Model 14 July 2000 - Internet-Draft Access Control Model 10 March 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. - 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 access control operations. An API (in a - separate document) is needed for the extended operation - getEffectiveAccess and specifyCredentials. - The keywords "MUST", "SHOULD", and "MAY" used in this - document are to be interpreted as described in - [Bradner97]. +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 one 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). +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. +2. The LDAPv3 Access Control Model +Access Control mechanisms evaluate requests for access to +protected resources and make decisions about whether those +requests should be granted or denied. In order to make a - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 2] +Stokes, et al Expires 14 January 2001 [Page 2] + +Internet-Draft Access Control Model 14 July 2000 - Internet-Draft Access Control Model 10 March 2000 +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. - The access control model defines +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. - - A wire protocol for interoperability: The existing - LDAP protocol flows for add, delete, modify, and - search are used to manipulate access control - information. There is an additional LDAP control - and extended protocol operation defined, - getEffectiveRights, to further help management of - access control information. +The access control mechanisms specified in this document are +neutral with respect to policy inheritance mechanisms, +explicit vs. implicit denial, and group nesting. - - A set of access control information (ACI) attributes - for application portability: These attributes are - used as input to the LDAP APIs so access control - information can be addressed uniformly independent - of how that information is addressed and stored at - the server. These same attributes appear in LDIF - output for interchange of access control - information. +The access control model defines - - A set of attributes to identity the access control - mechanisms supported by a server and in a given part - of the namespace. + - What flows on the wire for interoperability - Encoding of access control information on the wire is per - the LDAPv3 specifications. + 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. - The instantiation of an access control model at the - directory server is not defined in this document. + 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. - No mechanisms are defined in this document to control - access to access control information or for storage of - access control information at the server; this is vendor - dependent. + 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". - 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. + - 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] + - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 3] +Internet-Draft Access Control Model 14 July 2000 + 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. - Internet-Draft Access Control Model 10 March 2000 + - 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. - 3. Terminology +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). - 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. +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 - An "access control list entry" defines a single subject - security attribute's granted rights for the objects - governed by the access control list to which it belongs. - The "access control information" (aci) for an object or a - collection of objects defines which subject security - attributes entitle a subject to which granted rights. - The access control information for an object may be - 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?" +Stokes, et al Expires 14 January 2001 [Page 4] + - An "access decision function" is an algorithm which makes - an access decision based on subject security attributes, - access control information, an object identifier, and an - operation name (possibly augmented by additional - contextual information). - 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. - 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. +Internet-Draft Access Control Model 14 July 2000 - A "credential" is a collection of subject security - attributes. - "effective rights" are the complete set of rights a - subject is entitled to based on all access control lists +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. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 4] +3. Access Control Mechanism Attributes +Two attributes are defined to identify which access control +mechanisms are supported by a given server and by a given +subtree: supportedAccessControlSchemes and +accessControlSchemes. (We chose these names based on the +X.500 attribute, AccessControlScheme which is single-valued +and defined in X.501). +3.1 Root DSE Attribute for Access Control Mechanism +The server advertises which access control mechanisms it +supports by inclusion of the 'supportedAccessControlSchemes' +attribute in the root DSE. This attribute is a list of +OIDs, each of which identify an access control mechanism +supported by the server. By default, these are also the +mechanisms in effect in subtrees beneath the root in that +server unless overridden by a ldapACISubEntry (see section +"Subentry Class Access Control Mechanism"). - Internet-Draft Access Control Model 10 March 2000 + ( + NAME 'supportedAccessControlSchemes' + DESC list of access control mechanisms supported + by this directory server + SYNTAX LDAPOID + USAGE dSAOperation + ) +The access control mechanism defined is: + LDAPv3 +Other vendor access control mechanisms MAY be defined (by +OID) and are the responsibility of those vendors to provide +the definition and OID. - which apply to a specific object and based on all of the - subject's security attributes. - "granted rights" are the complete set of rights an access - control list entitles a subject to based on a specific - subject security attribute. +3.2 Root DSE Attribute for Control of Disclosing Errors - A "group" is a privilege attribute asserting a subject's - membership in the collection of subjects whose name is - that of the group. +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 - An "identity" is a subject security attribute which is - unique to a single subject. - 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. +Stokes, et al Expires 14 January 2001 [Page 5] + - A "right" is the basic unit of access control - 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. - A "role" is a privilege attribute asserting a subject's - organizational position and entitlement to perform the - operations appropriate to that organizational position. - A "subject' is an entity which initiate actions in an - information system. - A "subject security attribute" is a defined property - which is used by a security policy evaluation system to - make policy decisions. +Internet-Draft Access Control Model 14 July 2000 +in the rootDSE is interpreted as the default. + ( + 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 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 5] +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: + ( + 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. - Internet-Draft Access Control Model 10 March 2000 + ( + NAME 'accessControlSchemes' + DESC list of access control mechanisms supported + in this subtree - 4. The Model +Stokes, et al Expires 14 January 2001 [Page 6] + - The access control mechanism described in this draft - addresses these activities: - - Definition of subject security attributes - information - - Definition of access control policy - - Retrieval of subject security attributes +Internet-Draft Access Control Model 14 July 2000 - - Retrieval of effective access rights - - Externalization of access control policy information - 4.1 Access Control Information Model + SYNTAX LDAPOID + USAGE dSAOperation + ) - This document does not define formats for storage of - access control information; it does define the - operational semantics of access control operations. +4. The Access Control Information Attribute (ldapACI) +The access control information attribute, ldapACI, is +defined as: + ( + NAME 'ldapACI' + DESC 'ldap access control information' + EQUALITY caseIgnoreMatch + SYNTAX directoryString + USAGE directoryOperation + ) +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. +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, et al Expires 14 January 2001 [Page 7] + +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.1 The BNF +4.1.1 ACI String Representation + Values of this syntax are encoded according to the + following BNF which follows the BNF encoding + conventions described in [ABNF]: + ldapACI = scope "#" rights "#" attr "#" subject + scope = "entry" / "subtree" + rights = (("grant:" / "deny:") permissions) / + ("grant:" permissions ";deny:" permissions) - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 6] + permissions = [permission *("," permission)] + 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:" / - Internet-Draft Access Control Model 10 March 2000 +Stokes, et al Expires 14 January 2001 [Page 8] + - The diagram below illustrates the componentry of a LDAP - system and the placement of the function specified in - this draft. - +-------------+ - | Application |<--attrs to address ACI - +-------------+ - ldapACI - +--------+ - policyOwner - | LDAP | - | Client | - +--------+ - | - | <-- LDAP control - | - getEffectiveAccess - | - | <-- LDAP extended operation - | - getEffectiveAccess - v - +-----------------------------+ - | LDAP Server (e.g. SLAPD) | - +-----------------------------+ - . | - . | - . | - . | - v v - +----------+ +-----------+ - | Access | | |<-attrs to define - | Control |<--| Datastore | access control mechanisms - | Manager | | | - supportedACIMechanisms - +----------+ +-----------+ - aCIMechanisms - LDAP clients use the control and extended operation - 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 are compatible with that defined in the section - titled "Operational Semantics of Access Control - Operations". +Internet-Draft Access Control Model 14 July 2000 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 7] + "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 - Internet-Draft Access Control Model 10 March 2000 + ; 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 - The access control administration mechanisms specified in - this document are neutral with respect to policy - inheritance mechanisms, explicit vs. implicit denial, - and group nesting. + 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] - 5. Access Control Mechanism Attributes - There are several attributes defined associated with - access control. Two attributes are defined to identify - which access control mechanisms are supported by a given - server and by a given subtree: supportedACIMechanisms - and aCIMechanisms. +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. - 5.1 Root DSE Attribute for Access Control Mechanism +See section titled 'ACI Examples' for examples of the string +representation. - The server advertises which access control mechanisms it - supports by inclusion of the 'supportedACIMechanisms' - attribute in the root DSE. This attribute is a list of - OIDs, each of which identify an access control mechanism - supported by the server. - ( - NAME 'supportedACIMechanisms' - DESC list of access control mechanisms supported - by this directory server - SYNTAX LDAPOID - USAGE dSAOperation - ) - The access control mechanism defined is: - LDAPv3 - Other vendor access control mechanisms can be defined (by - OID) and are the responsibility of those vendors to - provide the definition and OID. - 5.2 Subschema Attribute for Access Control Mechanism - A given naming context must provide information about - which access control mechanisms are in effect for that - portion of the namespace. The following attribute must - be in each subschema entry associated with a naming +Stokes, et al Expires 14 January 2001 [Page 9] + - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 8] +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: - Internet-Draft Access Control Model 10 March 2000 + 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) } - context whose access control mechanism is different from - adjacent naming contexts supported by that directory - server. - aCIMechanisms lists the values (list of OIDs) that - defines the access control mechanism in effect for the - scope of that subschema entry. More than one mechanism - may be in effect for the scope of that subschema entry. - ( - NAME 'aCIMechanisms' - DESC list of access control mechanisms supported - in this subtree - SYNTAX LDAPOID - USAGE dSAOperation - ) +Stokes, et al Expires 14 January 2001 [Page 10] + - 6. Access Control Information Attributes +Internet-Draft Access Control Model 14 July 2000 - The intent of the following attribute definitions is to - design a common interchange format. Any given LDAP - server should be able to translate the below defined - attributes into a meaningful operation requests. Each - server should be able to understand the attributes; there - should not be any ambiguity into what any part of the - syntax means. - While the end goal is to have a common behavior model - between different LDAP server implementations, the - attribute 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 + Attribute ::= AttributeType -- from [LDAPv3] + IPAddress ::= PrintableString -- (e.g. 10.0.0.6) - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 9] +4.2 The Components of ldapACI Attribute +This section defines components that comprise the access +control information attribute, ldapACI. +4.2.1 Scope +Two scopes for access control information are defined: - Internet-Draft Access Control Model 10 March 2000 + - entry - the access control information in the ldapACI + attribute applies only to the entry in which it is + contained + - 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. - 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. - Two attributes are defined so access control information - (ACI) can be addressed in a server independent of server - implementation. These attributes are used in typical - LDAP APIs and in LDIF output of ACI. These two attributes - may be queried or set on all directory objects: ldapACI - and policyOwner. Their BNF and definitions are defined - below. +4.2.2 Access Rights and Permissions +Access rights can apply to an entire object or to attributes +of the object. Access can be granted or denied. Either or +both of the actions "grant" | "deny" may be used when +creating or updating ldapACI. - 6.1 The BNF +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. - < ldapACI > ::= < acl entry syntax > +Permissions which apply to attributes: - < acl entry syntax > ::= + '#' + + '#' - + < rights > + '#' + < dnType > - + '#' + < subjectDn > + 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 - < policyOwner > ::= < familyOid > + '#' + - + '#' +< dnType > + '#' + < subjectDn > - < subjectDn > ::= < printable string > | "public" | "this" - < familyOid > ::= < oid > - ::= "entry" | "subtree" +Stokes, et al Expires 14 January 2001 [Page 11] + - < dnType > ::= "access-id" | "role" | "group" | "subtree" - | "ipAddress" | "kerberosID" - | - < kerberosID > ::= < userID > + '@' + < realm > - < userID > ::= < printableString > - < realm > ::= < printableString > +Internet-Draft Access Control Model 14 July 2000 - < rights > ::= "grant" + ';' + + ';'+ - | "deny" + ';' + + ';'+ | - "grant"+';'++';'+"deny"+';'++';'+ - < permissions > ::= [ ] | [ + 1. r Read + If granted, permits attributes and values to be + returned in a read or search operation. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 10] + 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. - Internet-Draft Access Control Model 10 March 2000 + 5. c Compare + If granted, permites attributes and value to be used + in a compare operation. + 6. m Make - + [ ',' + ] ]* + The attribute permission "m" is required for all + attributes that are placed on an object when it is + created. Just as the "w" and "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. - < attr > ::= ["collection" + ':' + [ "[all]" | "[entry]" - | ] ] - | ["attribute" + ':' ] +Note: Modify-replace values of an attribute requires "w" +and "o" permission. - < permission > ::= "a" | "d" | "r" | "s" | "w" | - "c" | "e" | "b" +Permissions that apply to an entire entry: - These are the permissions defined for the IETF LDAP family - OID. - "a" corresponds to add - "d" corresponds to delete - "r" corresponds to read - "s" corresponds to search - "w" corresponds to write - "c" corresponds to compare - "e" corresponds to editDN - "b" corresponds to browseDN + a Add Add an entry below this entry - 6.2 Other Defined Parameters - This section defines additional parameters that are used - in the two attributes that address access control - information. +Stokes, et al Expires 14 January 2001 [Page 12] + - 6.2.1 Families and Rights - The familyOID tells what permission set etc. will follow - in the string. This allows a different permission set, - scope etc., but with the same syntax. - The following family is defined: - IETF-LDAPv3 - Other families can be defined (by OID). It is the - responsibility of those parties to provide the definition - and OID. +Internet-Draft Access Control Model 14 July 2000 - 6.2.1.1 IETF-LDAPv3 Family - Access rights can apply to an entire object or to + 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 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 11] + 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 + If granted, permits the entry to be removed from the + DIT regardless of controls on attributes within the + entry. + 3. e Export + If granted, permits an entry and its subordinates (if + any) to be exported; that is, removed from the current + location and placed in 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. + 4. i Import - Internet-Draft Access Control Model 10 March 2000 + 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. - attributes of the object. Each of the LDAP access rights - are discrete. One permission does not imply another - permission. The rights which apply to attributes and the - entry parallel the type of ldap operations that can be - performed. +Stokes, et al Expires 14 January 2001 [Page 13] + - Rights which apply to attributes: - r Read Read attribute values - w Write Write attribute values - s Search Search entries with specified attributes - c Compare Compare attributes - Rights that apply to an entire entry: - a Add Add an entry below this entry - d Delete Delete this entry - e EditDN Edit an entry's DN - b BrowseDN Browse an entry's DN +Internet-Draft Access Control Model 14 July 2000 - When searching, the ldap search filter specifies the - returned set of attributes. To do the search, browse (b) - must be set for the entry (you can search only entries - that you have permission to search so you can't discover - things you don't have permission to) and search (s) must - be set for all attributes used in the filter if you are - testing for existence, otherwise search (s) and read (r) - must be set for all attributes used in the filter because - the filter specifies a test for other than existence. - For a search to return attribute names only, search (s) - must be set for the attribute. For a search to return - attribute names and values, search (s) and read (r) must - be set for the attribute. Search (s) implies knowledge - of the attribute; read (r) implies knowledge of the - value. - 6.2.2 DN Types + 5. n RenameDN - The following DN Types strings are defined and MUST be - supported: + 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. - - access-id + 6. b BrowseDN + If granted, permits entries to be accessed using + directory operations which do not explicitly provide + the name of the entry. + 7. t ReturnDN + If granted, allows the distinguished name of the entry + to be disclosed in the operation result. +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) - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 12] + ldapACI: ...grant OID.attr1 subjectA + ldapACI: ...deny OID.attr1 subjectA +must be ldapACI: ...grant ... deny... OID.attr1 subjectA +Using the defined BNF it is possible for the permission +string to be empty. The ACI + ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US + ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US +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]". - Internet-Draft Access Control Model 10 March 2000 +4.2.3 Attributes +Attribute describes an attribute name in the form of a +dotted decimal OID for that . If the string (OID) +refers to an attribute not defined in the given server's +schema, the server SHOULD report an error. "[entry]" means - - group - - role - The following DN Types strings are defined and SHOULD be - supported: +Stokes, et al Expires 14 January 2001 [Page 14] + - - ipAddress - - kerberosID - An access-id is a non-collection (non-group and non-role - objects) DN that can be authenticated. - groupOfNames and groupOfUniqueNames (or subclasses from - those object classes) must be recognized as a collection - object. This aids in interoperability during - replication. +Internet-Draft Access Control Model 14 July 2000 - Other parties can (and will) define other DN Types. It - is the responsibility of those parties to provide the - definition. - 6.3 Basic ACI Attribute (ldapACI) +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. - ( - NAME 'ldapACI' - DESC 'ldap access control information' - EQUALITY caseIgnoreMatch - SYNTAX directoryString - USAGE directoryOperation - ) +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]". - Within the access control syntax, the family OID - describes the permissions, dnType, subjectDn and scope - that will be found in the following string. If the OID - within the ldapACI attribute is listed as other than the - IETF-LDAPv3 family OID, the syntax is the same, but one - or more of the scope, dnType, subjectDn or permissions - may vary from the defined syntax. - Within the access control syntax, there is a string which - describes the rights. This is a composite of the - permissions and resources to which the subject is being +4.2.4 Subjects and Associated Authentication +The following subjects are defined and MUST be supported: + - authzID, defined per [authmeth] - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 13] + - group, defined as the distinguished name of a + groupOfNames or groupOfUniqueNames entry + - role + - subtree, defined as the distinguished name of a non- + leaf node in the DIT + - ipAddress, + - public, defined as public access + - this, defined as the user whose name matches that of + the entry being accessed - Internet-Draft Access Control Model 10 March 2000 +Other parties MAY define other subjects. It is the +responsibility of those parties to provide the definition. +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. - granted or denied access. The set of permissions is - fixed. Either or both of the actions "grant" | "deny" - may be used when creating or updating ldapACI. +4.3 Grant/Deny Evaluation Rules - describes either an attribute name or an attribute - collection. The keyword attribute indicates that the - following printable string refers to an attribute name. - If the string refers to an attribute not defined in the - given server's schema, the server SHOULD report an error. - The keyword "collection" indicates that the string that - follows describes a group of attributes. The method for - grouping attributes is server specific. Another option - for the collection printable string 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 a - collection is "[all]" which means the permission set - should apply to all attributes. Even if the server does - not support attribute grouping, it MUST recognize the - "[all]" and "[entry]" keywords. If the server receives - an unrecognized attribute collection name, the server - SHOULD return an error. If the server supports grouping, - the grouping is server and implementation specific. +The decision whether to grant or deny a client access to a +particular piece of information is based on several pieces - 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]". - All permissions (for grant and deny) for an attribute and - a given DN MUST be contained within one ldapACI value, - i.e. (in abbreviated form) - ldapACI: ...grant attr1 DN1 - ldapACI: ...deny attr1 DN1 +Stokes, et al Expires 14 January 2001 [Page 15] + - must be ldapACI: ...grant ... deny... attr1 DN1 - Using the defined BNF it is possible for the permission - string to be empty. The ACI - ldapACI: 1.2.3.4#subtree#grant;; - attribute:attr1#group#cn=Dept XYZ,c=US - ldapACI: 1.2.3.4#subtree#grant;r,s; +Internet-Draft Access Control Model 14 July 2000 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 14] +of information found within the ldapaci value. Throughout +the decision making process, there are guiding principals. + - Specificity: More specific policies MUST override less + specific ones (e.g. individual user entry in ACI takes + precedence over group entry). + - Deny takes precedence over Grant. + - When there are conflicting ACI values, deny takes + precedence over grant. + - Deny is the default when there is no access control + information. +Precendence of Scope Types (highest to lowest) - Internet-Draft Access Control Model 10 March 2000 + - entry + - subtree +Precedence of Subjects within a Scope (highest to lowest): - collection:[all]#group#cn=Dept XYZ,c=US + - ipAddress - means that this group (Dept XYZ) is granted permission to - read and search all attributes except attr1 because attr1 - is more specific than "[all]". + - authzID, this + - group, role, this, public - 6.3.1 LDAP Operations + - subtree, public - The attributes which are defined for access control - interchange may be used in all LDAP operations. +Although other types MAY be defined given the BNF, use of +the well-known types aids in interoperability and +operational consistency. - Within the ldapmodify-delete operation, the entire acl - may be deleted by specifying +Access Decision algorithm: - dn: cn = some Entry - changetype: modify - delete: ldapACI + 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'. - In this case, the entry would then inherit its ACI from - some other node in the tree depending on the server - inheritance model. + 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 - Similarly, if all values of ldapACI are deleted, then the - access control information for that entry is defined by - that implementation's inheritance model. - 6.3.2 Grant/Deny Evaluation Rules +Stokes, et al Expires 14 January 2001 [Page 16] + - More specific policies must override less specific ones - (e.g. individual user entry in ACI takes precedence over - group entry). - Deny takes precedence over Grant. When there are - conflicting ACI values, deny takes precedence over grant. - Deny is the default when there is no access control - information. - Precendence of Scope Types (highest to lowest) - - entry +Internet-Draft Access Control Model 14 July 2000 - - subtree + 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. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 15] + 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. +5. Required Permissions for each LDAP Operation +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. +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. - Internet-Draft Access Control Model 10 March 2000 - Precedence of Privilege Attribute dnTypes within a scope - (highest to lowest): +Stokes, et al Expires 14 January 2001 [Page 17] + - - ipAddress - - access-id, kerberosID (both same precedence) - - group - - role +Internet-Draft Access Control Model 14 July 2000 - - subtree - Although other types can be defined given the BNF, use of - the well-known types aids in interoperability and - operational consistency. +Required permissions for LDAP extended operations and LDAP +controls are beyond the scope of this draft. - 6.4 Policy Owner Attribute (policyOwner) +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. - ( - NAME 'policyOwner' - DESC 'Policy Owner Access Control Information' - EQUALITY caseIgnoreMatch - SYNTAX directoryString - USAGE directoryOperation - ) +For the following, assume that the authorization identity of +the user doing the operation is authzID. - Policy ownership controls administrative subdomains. It - can also control who has permission to set / change acls - for implementations that do not have ACI 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. - 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. The scope and any inheritance hierarchy for policy - ownership is distinct from any inheritance hierarchy - defined for ACI values. +5.1 Bind Operation - 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 +This draft does not require any permissions to allow a bind +operation to proceed. +5.2 Search Operation - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 16] +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, et al Expires 14 January 2001 [Page 18] + - Internet-Draft Access Control Model 10 March 2000 - 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. +Internet-Draft Access Control Model 14 July 2000 - 6.5 ACI Examples - The examples use a family OID = 1.2.3.4 +Then the permissions required by authzID that need to be +evaluated are as follows: - 6.5.1 Attribute Definition + 1. permission "b" to the entry candidateDN - 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. + If this permission is not granted then the dn + candidateDN MUST not be returned nor any attribute + type nor attribute value from this entry. - policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt + If this permission is granted then the dn candidateDN + MAY be returned. - policyOwner: 1.2.3.4#subtree#group#cn=System - Owners,o=Company + 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. - 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. + 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. - ldapACI:1.2.3.4#subtree#grant;r,s,c; - attribute:attr1#group#cn=Dept XYZ,c=US + 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. - 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. + 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). - ldapACI: 1.2.3.4#subtree#grant;a; - collection:[entry]#role#cn=SysAdmins,o=Company + Note A: Although both "r" and "s" permissions will + typically be granted to attributes we keep both - ldapACI: 1.2.3.4#subtree#grant;r,s,c; - attribute:attr2#role#cn=SysAdmins,o=Company +Stokes, et al Expires 14 January 2001 [Page 19] + - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 17] +Internet-Draft Access Control Model 14 July 2000 + 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. - Internet-Draft Access Control Model 10 March 2000 + Note B: There is an unusual behaviour with respect to + naming attributes illustrated in the following + example: + 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. + 3. permission "r" to each attribute in the attribute list - ldapACI: 1.2.3.4#subtree#grant;r,s,c; - attribute:attr3#role#cn=SysAdmins,o=Company + AttributeDescriptionList (or all attributes in the + entry candidateDN if AttributeDescriptionList is *) + whose type and/or value will be returned. + 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. - 6.5.2 Modifying the ldapACI Values + 4. permission "t" to the entry candidateDN - Modify-Replace works as defined in the ldap oepration - 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. + 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. - A given ldapACI for an entry: - ldapACI: 1.2.3.4#subtree#deny;r,w; - collection:[all]#group#cn=Dept ABC + 5. Disclose on error for the Search operation - ldapACI: 1.2.3.4#subtree#grant;r; - attribute:attr1#group#cn=Dept XYZ + 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. - perform the following change: - dn: cn=someEntry - changetype: modify - replace: ldapACI - ldapACI: 1.2.3.4#subtree#grant;r,w; - collection:[all];#group#cn=Dept LMN - The resulting ACI is: +Stokes, et al Expires 14 January 2001 [Page 20] + - ldapACI: 1.2.3.4#subtree#grant;r,w; - collection:[all];#group#cn=Dept LMN - ( ldapACI 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 ldapACI value(s). If the - ACI does exist, then add the specified values to the given - ldapACI. For example a given ACI: - ldapACI: 1.2.3.4#subtree#grant;r,w; - collection:[all]#group#cn=Dept XYZ +Internet-Draft Access Control Model 14 July 2000 - with a modification: +5.3 Modify Operation - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 18] +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: - Internet-Draft Access Control Model 10 March 2000 + 1. permission "w" to each attribute being added to object + If this permission is not granted to such an + attribute, then the operation MUST fail. 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. + 2. permission "o" to each attribute for which a value is + being deleted from object - dn: cn=someEntry - changetype: modify - add: ldapACI - ldapACI: 1.2.3.4#subtree#grant;r; - attribute:attr1#group#cn=Dept XYZ + 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. - would yield an multi-valued aci of: - ldapACI: 1.2.3.4#subtree#grant;r,w; - collection:[all]#group#cn=Dept XYZ - ldapACI: 1.2.3.4#subtree#grant;r; - attribute:attr1#group#cn=Dept XYZ - To delete a particular ACI value, use the regular ldapmodify - - delete syntax - Given an ACI of: +Stokes, et al Expires 14 January 2001 [Page 21] + - ldapACI: 1.2.3.4#subtree#grant;r,w; - collection:[all]#group#cn=Dept XYZ - ldapACI: 1.2.3.4#subtree#grant;r; - attribute:attr1#group#cn=Dept XYZ - dn: cn = some Entry - changetype: modify - delete: ldapACI - ldapACI: 1.2.3.4#subtree#grant;r; - attribute:attr1#group#cn=Dept XYZ - would yield a remaining ACI on the server of - ldapACI: 1.2.3.4#subtree#grant;r,w; - collection:[all]#group#cn=Dept XYZ +Internet-Draft Access Control Model 14 July 2000 - 6.5.3 Evaluation - 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 7 for a discussion of the - semantics of ldapACI entries when backing-store ACI - administration is also used. + 3. permissions "o" and "w" to each attribute being + replaced in object + 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. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 19] +5.4 Add Operation +Recall that the parameters of the Add operation per RFC2251 +[LDAPv3] Section 4.7 are: + AddRequest ::= [APPLICATION 8] SEQUENCE { + entry LDAPDN, + attributes AttributeList } + AttributeList ::= SEQUENCE OF SEQUENCE { + type AttributeDescription, + vals SET OF AttributeValue } +Then the permissions required by authzID that need to be +evaluated are as follows: - Internet-Draft Access Control Model 10 March 2000 + 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 - Assume cn=jsmith is a member of group cn=G1. Assume - cn=jsmith is a member of group cn=G2. +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). - Example #1 - dn: o=XYZ, c=US - ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1; - #access-id#cn=jsmith,ou=ABC,o=XYZ,c=US - ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr1; - #group#cn=G1,ou=ABC,o=XYZ,c=US +If they are all granted then the operation MAY proceed. - What rights does cn=jsmith have to attr1 of o=XYZ,c=US? - Read (r) access; access-id is higher precedence than - group. +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 - Example #2 - dn: o=XYZ, c=US - ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr2; - #group#cn=G1,ou=ABC,o=XYZ,c=US - ldapACI: 1.2.3.4#subtree#grant;w;attribute: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 - dnTypes (group) have same precedence. +Stokes, et al Expires 14 January 2001 [Page 22] + - Example #3 - dn: o=XYZ, c=US - ldapACI: 1.2.3.4#subtree#grant;r,w;attribute:attr3; - #group#cn=G1,ou=ABC,o=XYZ,c=US - ldapACI: 1.2.3.4#subtree#deny;w;attribute:attr3; - #group#cn=G2,ou=ABC,o=XYZ,c=US - What rights does cn=jsmith have to attr3 of o=XYZ, c=US? - Read access; write is denied (deny has precedence over - grant). +Internet-Draft Access Control Model 14 July 2000 - Example #4 - dn: o=XYZ, c=US - ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr4; - #access-id#cn=jsmith,ou=ABC,o=XYZ,c=US - ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr4; - #subtree#ou=ABC,ou=XYZ,c=US +consistency with the MODIFY operation. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 20] +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 +Recall that the parameters of the Delete operation per +RFC2251 [LDAPv3] Section 4.10 are: + DelRequest ::= [APPLICATION 10] LDAPDN +Then the permissions required by authzID that need to be +evaluated are as follows: - Internet-Draft Access Control Model 10 March 2000 + 1. permission "d" to the entry in the Delete request +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). - What rights does cn=jsmith have to attr4 of o=XYZ, c=US? - Write (w); rights given to an access-id take precedence - over those given to a subtree. +If this permission is granted, then the operation MAY +proceed. +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 - 7. Operational Semantics of Access Control Operations +Recall that the parameters of the Modify DN operation per +RFC2251 [LDAPv3] Section 4.6 are: - 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). + 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: - 7.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. - - 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. +Stokes, et al Expires 14 January 2001 [Page 23] + - - 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. - - LDAP Access Request operations: invocations of LDAP - entry or attribute access operations (Read, Update, - Search, Compare, etc...). +Internet-Draft Access Control Model 14 July 2000 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 21] + 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. - Internet-Draft Access Control Model 10 March 2000 +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. - - Other operations: anything else, including Datastore - operations which do not change the access policy - enforced by the server. +5.7 Compare Operation +Recall that the parameters of the Compare operation per +RFC2251 [LDAPv3] Section 4.10 are: - 7.2 Semantics of Histories + CompareRequest ::= [APPLICATION 14] SEQUENCE { + entry LDAPDN, + ava AttributeValueAssertion } - The semantics of histories are defined as follows: +Then the permissions required by authzID that need to be +evaluated are as follows: - - 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. + 1. permission "c" to the attribute in entry on which the + comparison is being made. - - LDAP Update (Grant), LDAP Query +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. - 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. +If they are all granted then the operation MAY proceed. - - 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. - - 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 if it requires any - right not granted by the Update operation. - - 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 +Stokes, et al Expires 14 January 2001 [Page 24] + - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 22] +Internet-Draft Access Control Model 14 July 2000 +5.8 Abandon Operation - Internet-Draft Access Control Model 10 March 2000 +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. - operation. - - LDAP Update (Deny), LDAP Access Request +5.9 Extended 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. +Recall that the parameters of the Extended operation per +RFC2251 [LDA{v3] Section 4.12 are: - - LDAP Update (Replace), Other, LDAP Query + ExtendedRequest ::= [APPLICATION 23] SEQUENCE { + requestName [0] LDAPOID, + requestValue [1] OCTET STRING OPTIONAL } - 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 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. - - LDAP Update (Grant), Other, 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), Other, LDAP Query +6. Required Permissions for Handling Aliases and References - 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 +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. - 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 +6.1 ACI Distribution - 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 +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 10 September 2000 [Page 23] +Stokes, et al Expires 14 January 2001 [Page 25] + +Internet-Draft Access Control Model 14 July 2000 - Internet-Draft Access Control Model 10 March 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. - rights not granted by the Update operation, - depending on the policy in force before the Update - operation. +6.2 Aliases - - LDAP Update (Deny), Other, LDAP Access Request +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 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. +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. - - LDAP Update (Replace), Datastore Policy Update, LDAP - Query +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. - The result of the Query is not defined. - - LDAP Update (Grant), Datastore Policy Update, LDAP - Query +6.3 Referrals - The result of the Query is not defined. +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. - - LDAP Update (Deny), Datastore Policy Update, LDAP - Query - The result of the Query is not defined. - - LDAP Update (Replace), Datastore Policy Update, LDAP - Access Request - 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. +Stokes, et al Expires 14 January 2001 [Page 26] + - - LDAP Update (Deny), Datastore Policy Update, LDAP - Access Request - The result of the Access Request is not defined. +Internet-Draft Access Control Model 14 July 2000 +7. Controlling Access to Access Control Information - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 24] +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). +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. +8. ACI Examples +Note that in the examples, the form "OID." refers +to the OID in dotted decimal form for the attribute +. This shorthand notation is used only for the +examples. In implementation, the dotted decimal form of the +OID is used. - Internet-Draft Access Control Model 10 March 2000 +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. - 8. Access Control Parameters for LDAP Controls & Extended - Operations + ldapACI: entry#grant:r,w# + OID.ldapACI#authnLevel:any:role:cn=aciAdmin - This section defines the parameters used in the access - control LDAP controls and extended operations in this - document. + ldapACI: subtree#grant:r,w# + OID.ldapACI#authnLevel:any:role:cn=aciAdmin - targetDN specifies the initial directory entry in DN - syntax on which the control or extended operation is - performed. +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. - 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). + ldapACI:subtree#grant;r,s,c# + OID.attr1#group:cn=Dept XYZ,c=US - family specifies the family OID that will be retrieved - for the get effective rights control or extended - operation performed. A family has a defined set of - rights, among other things. - rights in the get effective rights control or extended - operation response is of the form specified in the BNF - for . - dnType speficies the type of subject security attribute. - Defined types are specified in the BNF. - 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. The well-known subjectDNs - strings are defined +Stokes, et al Expires 14 January 2001 [Page 27] + - - public - meaning public access for all users - - this - meaning the user whose name matches the entry - being accessed - - * - meaning everyone who has access to the entry +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 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 25] + ldapACI: subtree#grant:r,s,c# + OID.attr2#role:cn=SysAdmins,o=Company + ldapACI: subtree#grant:r,s,c# + OID.attr3#role:cn=SysAdmins,o=Company +8.2 Modifying the ldapACI Values +Modify-Replace works as defined in the ldap operation +modify. If the attribute value does not exist, create the +value. If the attribute does exist, replace the value. If +the ldapACI value is replaced, all ldapACI values are +replaced. +A given ldapACI for an entry: - Internet-Draft Access Control Model 10 March 2000 + ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC + ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ +perform the following change: - 9. Access Control Information (ACI) Controls + dn: cn=someEntry + changetype: modify + replace: ldapACI + ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN - 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 get/set - while manipulating other directory information for that - entry. The control is: +The resulting ACI is: - - getEffectiveRights to obtain the effective rights - for a given directory entry(s) for a given subject - during a ldap_search operation +ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN - 9.1 getEffectiveRights Control +( ldapACI 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 ldapACI value(s). If the +ACI does exist, then add the specified values to the given +ldapACI. For example a given ACI: - 9.1.1 Request Control +ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ - 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]. - The controlType is set to . 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 { - effectiveRightsRequest SEQUENCE OF SEQUENCE { - family LDAPOID | "*", - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - dnType "access-id"|"group"|"role"| - "ipAddress"|"kerberosID"| - | "*", - subjectDN LDAPString | "public" | - "this" | "*" - } - } - The effectiveRightsRequest is a set of sequences that - state the whichObject (entry or entry plus subtree) and +Stokes, et al Expires 14 January 2001 [Page 28] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + +with a modification: + + dn: cn=someEntry + changetype: modify + add: ldapACI + ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ + +would yield an multi-valued ACI of: + + ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ + + ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ + +To delete a particular ACI value, use the regular ldapmodify +- delete syntax + +Given an ACI of: + + ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ + ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ + + 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. + +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] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + +8.3 Evaluation + +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. + +Assume cn=jsmith is a member of group cn=G1. Assume +cn=jsmith is a member of group cn=G2. + + Example #1 + dn: o=XYZ, c=US + 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 + + What rights does cn=jsmith have to attr1 of o=XYZ,c=US? + Read (r) access; authzID is higher precedence than + group. + + + 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. + + + 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 + + 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, et al Expires 14 January 2001 [Page 30] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + + ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US + + 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. + + + 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 + + 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. + + 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 + + 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. + + + +9. Operational Semantics of Access Control Operations + +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). + + + + +Stokes, et al Expires 14 January 2001 [Page 31] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + +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. + + - 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. + + - 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. + + - LDAP Access Request operations: invocations of LDAP + entry or attribute access operations (Read, Update, + Search, Compare, etc...). + + - Other operations: anything else, including Datastore + operations which do not change the access policy + enforced by the server. + + +9.2 Semantics of Histories + +The semantics of histories are defined as follows: + + - 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. + + - 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. + + + +Stokes, et al Expires 14 January 2001 [Page 32] + + - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 26] +Internet-Draft Access Control Model 14 July 2000 + - 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. + - LDAP Update (Replace), LDAP Access Request - Internet-Draft Access Control Model 10 March 2000 + 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), 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. - specifics of the control request to be performed. One or - more family can be be obtained for a given subjectDN ad - dnType. A "*" in the family field indicates that the - rights for all families defined for the subjectDN / - dnType are to be returned. A "*" in the dnType 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. + - LDAP Update (Deny), LDAP Access Request - 9.1.2 Response Control + 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. - 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]. + - LDAP Update (Replace), Other, LDAP Query - The controlType is set to . 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: + The Query will show that the subject has all rights + granted by the Update operation, and no rights not + granted by the Update operation. - getEffectiveRightsResponse ::= { - result ENUMERATED { - success (0), - operationsError (1), - unavailableCriticalExtension (12), - noSuchAttribute (16), - undefinedAttributeType (17), - invalidAttributeSyntax (21), - insufficientRights (50), - unavailable (52), - unwillingToPerform (53), - other (80) - } - } + - LDAP Update (Grant), Other, LDAP Query - The effective rights returned are returned with each - entry returned by the search result. The control - response for ldap_search is: + 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. - PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE { - family LDAPOID, - rights in BNF>, - whichObject ENUMERATED { + - LDAP Update (Deny), Other, 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 - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 27] +Stokes, et al Expires 14 January 2001 [Page 33] + +Internet-Draft Access Control Model 14 July 2000 - Internet-Draft Access Control Model 10 March 2000 + before the Update operation. - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - dnType "access-id"|"group"| - "role"|"ipAddress"| - "kerberosID"| - | - "*", - subjectDN LDAPString | "public" | - "this" | "*" - } + - LDAP Update (Replace), Other, LDAP Access Request - 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. + 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. - 9.1.3 Client-Server Interaction + - LDAP Update (Grant), Other, LDAP Access Request - 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. + 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. - There are six possible scenarios that may occur as a - result of the getEffectiveRights control being included - on the search request: + - LDAP Update (Deny), Other, LDAP Access Request + 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. - 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]. + - LDAP Update (Replace), Datastore Policy Update, LDAP + Query - 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 + The result of the Query is not defined. + - LDAP Update (Grant), Datastore Policy Update, LDAP + Query + The result of the Query is not defined. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 28] + - LDAP Update (Deny), Datastore Policy Update, LDAP Query + The result of the Query is not defined. + - LDAP Update (Replace), Datastore Policy Update, LDAP + Access Request + 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. - Internet-Draft Access Control Model 10 March 2000 + - LDAP Update (Deny), Datastore Policy Update, LDAP + Access Request - control and process the request as if it were not - present. This behavior is specified in section - 4.1.12 of [LDAPv3]. +Stokes, et al Expires 14 January 2001 [Page 34] + - 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 field, then the server SHOULD do the - following: return unavailableCriticalExtension as a - return code in the searchResult message. - 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. - 6. If the search request failed for any other reason, - then the server SHOULD omit the - getEffectiveRightsResponse control from the - searchResult message. +Internet-Draft Access Control Model 14 July 2000 - 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. - 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. + The result of the Access Request is not defined. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 29] +10. Access Control Parameters for LDAP Controls & Extended +Operations +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. +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). +rights in the get effective rights control or extended +operation response is of the form specified in the BNF for +. +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. - Internet-Draft Access Control Model 10 March 2000 +11. Access Control Information (ACI) Controls - 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. +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 - 10. Access Control Extended Operation +11.1 getEffectiveRights Control - 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. +11.1.1 Request Control - 10.1 LDAP Get Effective Rights Operation +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]. - ldapGetEffectiveRightsRequest ::= [APPLICATION 23] - SEQUENCE { - requestName [0] , - requestValue [1] OCTET STRING OPTIONAL } - where - requestValue ::= SEQUENCE { - targetDN LDAPDN, - updates SEQUENCE OF SEQUENCE { - family LDAPOID | "*", - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - attr SEQUENCE { - attr in BNF > + +Stokes, et al Expires 14 January 2001 [Page 35] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + +The controlType is set to . 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 { + effectiveRightsRequest SEQUENCE OF SEQUENCE { + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + }, + subject in BNF> | "*" + } + } + +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. + +11.1.2 Response Control + +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]. + +The controlType is set to . 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: + + getEffectiveRightsResponse ::= { + result ENUMERATED { + success (0), + operationsError (1), + unavailableCriticalExtension (12), + noSuchAttribute (16), + undefinedAttributeType (17), + invalidAttributeSyntax (21), + insufficientRights (50), + unavailable (52), + unwillingToPerform (53), + other (80) + } + } + + + + +Stokes, et al Expires 14 January 2001 [Page 36] + + + + + +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 in BNF>, + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + }, + subject < see in BNF > + } + +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. + +11.1.3 Client-Server Interaction + +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. + +There are six possible scenarios that may occur as a result +of the getEffectiveRights control being included on the +search request: + + + 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]. + + 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, et al Expires 14 January 2001 [Page 37] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + + field, then the server SHOULD do the following: return + unavailableCriticalExtension as a return code in the + searchResult message. + + 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. + + 6. If the search request failed for any other reason, + then the server SHOULD omit the + getEffectiveRightsResponse control from the + searchResult message. + +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. + +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. + +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. + + +12. Access Control Extended Operation + +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. + + + + + + + +Stokes, et al Expires 14 January 2001 [Page 38] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + +12.1 LDAP Get Effective Rights Operation + +ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE +{ + requestName [0] , + requestValue [1] OCTET STRING OPTIONAL } + + where + + requestValue ::= SEQUENCE { + targetDN LDAPDN, + updates SEQUENCE OF SEQUENCE { + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) }, - dnType "access-id"|"group"| - "role"|"ipAddress"| - "kerberosID"| - | - "*", - subjectDN LDAPString | "public" | - "this" | "*" - } - } + attr SEQUENCE { + attr in BNF > + }, + subject < see in BNF > | "*" + } + } + + +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. + +The server will respond to this with an LDAPMessage +containing the ExtendedResponse which is a rights list. + +ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE +{ + COMPONENTS OF LDAPResult, + responseName [10] OPTIONAL, + effectiveRights [11] OCTET STRING OPTIONAL } + + where + + effectiveRights ::= SEQUENCE OF SEQUENCE { + rights in BNF>, + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + }, + subject < see in BNF > + } + +If the server does not recognize the request name, it MUST +return only the response fields from LDAPResult, containing + + + +Stokes, et al Expires 14 January 2001 [Page 39] + + + + + +Internet-Draft Access Control Model 14 July 2000 + + + +the protocolError result code. + + + +13. Security Considerations + +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. + +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. + + + +14. 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. +[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements +for LDAP", RFC 2820, May 2000. +[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. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 30] +[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. +Morgan, "Authentication Methods for LDAP", RFC 2829, May +2000. +[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax +Specifications: ABNF", RFC 2234, November 1997. +Stokes, et al Expires 14 January 2001 [Page 40] + - Internet-Draft Access Control Model 10 March 2000 +Internet-Draft Access Control Model 14 July 2000 - 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. - The server will respond to this with an LDAPMessage - containing the ExtendedResponse which is a rights list. - ldapGetEffectiveRightsResponse ::= [APPLICATION 24] - SEQUENCE { - COMPONENTS OF LDAPResult, - responseName [10] OPTIONAL, - effectiveRights [11] OCTET STRING OPTIONAL } +ACKNOWLEDGEMENT - where +This is to acknowledge the numerous companies and individuals who have +contributed their valuable help and insights to the development of this +specification. - effectiveRights ::= SEQUENCE OF SEQUENCE { - family LDAPOID, - rights in BNF>, - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - dnType "access-id"|"group"|"role"| - "ipAddress"|"kerberosID"| - , - subjectDN LDAPString | "public" | "this" - } - If the server does not recognize the request name, it - MUST return only the response fields from LDAPResult, - containing the protocolError result code. +AUTHOR(S) ADDRESS + 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 - 11. Security Considerations + 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 - 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. - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 31] - Internet-Draft Access Control Model 10 March 2000 - 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 - [REQTS] Stokes, Byrne, Blakley, "Access Control - Requirements for LDAP", INTERNET-DRAFT , February 2000. - [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. - AUTHOR(S) ADDRESS - Ellen Stokes Bob Blakley - IBM Dascom - 11400 Burnet Rd 5515 Balcones Drive - Austin, TX 78758 Austin, TX 78731 - USA USA - mail-to: stokes@austin.ibm.com mail-to: blakley@dascom.com - phone: +1 512 838 3725 phone: +1 512 458 4037 ext 5012 - fax: +1 512 838 8597 fax: +1 512 458 237 - 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 8597 +Stokes, et al Expires 14 January 2001 [Page 41] + - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 32] +Internet-Draft Access Control Model 14 July 2000 - Internet-Draft Access Control Model 10 March 2000 @@ -1941,9 +2681,10 @@ - Stokes, Byrne, Blakley Expires 10 September 2000 [Page 33] +Stokes, et al Expires 14 January 2001 [Page 42] + @@ -1952,55 +2693,62 @@ - CONTENTS + CONTENTS - 1. Introduction....................................... 2 + 1. Introduction....................................... 2 - 2. Overview........................................... 2 + 2. The LDAPv3 Access Control Model.................... 2 - 3. Terminology........................................ 4 + 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 Model.......................................... 6 - 4.1 Access Control Information Model............. 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. Access Control Mechanism Attributes................ 8 - 5.1 Root DSE Attribute for Access Control - Mechanism.................................... 8 - 5.2 Subschema Attribute for Access Control - Mechanism.................................... 8 + 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. Access Control Information Attributes.............. 9 - 6.1 The BNF...................................... 10 - 6.2 Other Defined Parameters..................... 11 - 6.2.1 Families and Rights 11 - 6.2.2 DN Types 12 - 6.3 Basic ACI Attribute (ldapACI)................ 13 - 6.3.1 LDAP Operations 15 - 6.3.2 Grant/Deny Evaluation Rules 15 - 6.4 Policy Owner Attribute (policyOwner)......... 16 - 6.5 ACI Examples................................. 17 - 6.5.1 Attribute Definition 17 - 6.5.2 Modifying the ldapACI Values 18 - 6.5.3 Evaluation 19 + 6. Required Permissions for Handling Aliases and + References......................................... 25 + 6.1 ACI Distribution............................. 25 + 6.2 Aliases...................................... 26 + 6.3 Referrals.................................... 26 - 7. Operational Semantics of Access Control - Operations......................................... 21 - 7.1 Types of actions............................. 21 - 7.2 Semantics of Histories....................... 22 + 7. Controlling Access to Access Control + Information........................................ 27 - 8. Access Control Parameters for LDAP Controls & - Extended Operations................................ 25 + 8. ACI Examples....................................... 27 + 8.1 Attribute Definition......................... 27 + 8.2 Modifying the ldapACI Values................. 28 + 8.3 Evaluation................................... 30 - 9. Access Control Information (ACI) Controls.......... 26 - 9.1 getEffectiveRights Control................... 26 - 9.1.1 Request Control 26 - 9.1.2 Response Control 27 - 9.1.3 Client-Server Interaction 28 + - i - - - i - @@ -2011,15 +2759,26 @@ + 9. Operational Semantics of Access Control + Operations......................................... 31 + 9.1 Types of actions............................. 32 + 9.2 Semantics of Histories....................... 32 - 10. Access Control Extended Operation.................. 30 - 10.1 LDAP Get Effective Rights Operation.......... 30 +10. Access Control Parameters for LDAP Controls & + Extended Operations................................ 35 - 11. Security Considerations............................ 31 +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. References......................................... 32 +12. Access Control Extended Operation.................. 38 + 12.1 LDAP Get Effective Rights Operation.......... 39 +13. Security Considerations............................ 40 +14. References......................................... 40 @@ -2054,55 +2813,55 @@ + - ii - - - ii - +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. - Full Copyright Statement - Copyright (C) The Internet Society (1999).á 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. @@ -2120,7 +2879,7 @@ - - iii - + - iii - -- 2.39.5