From: Kurt Zeilenga Date: Wed, 6 Oct 1999 17:23:54 +0000 (+0000) Subject: draft-ietf-ldapext-acl-model-04.txt X-Git-Tag: UCDATA_2_4~350 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=76705ae89538edc1468f3aa8b91c9519bffef759;p=openldap draft-ietf-ldapext-acl-model-04.txt --- diff --git a/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt b/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt index ecdb41cd81..4e247f2f7f 100644 --- a/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt +++ b/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt @@ -1,11 +1,12 @@ Internet-Draft E. Stokes LDAP Extensions WG D. Byrne - Intended Category: Standards Track B. Blakley - Expires: 25 December 1999 IBM - 25 June 1999 + Intended Category: Standards Track IBM + Expires: 5 April 2000 B. Blakley + Dascom + 5 October 1999 Access Control Model for LDAP - + STATUS OF THIS MEMO @@ -18,7 +19,7 @@ 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 + any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." @@ -42,25 +43,27 @@ This document describes the access control model for the Lightweight Directory Application Protocol (LDAP) - directory service. It includes a description of the - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 1] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 1] - Internet-Draft Access Control Model 25 June 1999 + Internet-Draft Access Control Model 5 October 1999 + directory service. It includes a description of the model, the LDAP controls, and the extended operations to - the LDAP protocol. A separate document defines the - corresponding application programming interfaces (APIs). - RFC2219 [Bradner97] terminology is used. + 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. RFC2219 + [Bradner97] terminology is used. @@ -73,16 +76,15 @@ need to provide an access control model definition for LDAP directory content among servers within an enterprise and the Internet. Currently LDAP does not define an - access control model, but is needed to ensure consistent - secure access across heterogeneous LDAP implementations. - The major objective is to provide a simple, but secure, - highly efficient access control model for LDAP while also - providing the appropriate flexibility to meet the needs - of both the Internet and enterprise environments and - policies. This document defines the model and the - protocol extensions (controls and extended operations). - A separate document defines the corresponding application - programming interfaces (APIs). + 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). 2. Overview @@ -97,49 +99,28 @@ subject and the rules which govern the use of the target object. - This proposal defines the protocol elements for - transmission of this access control policy data in an - LDAP environment and an attribute that defines the access - control mechanism in effect for a given part of the LDAP - namespace. The instantiation of an access control model - - + The access control model defines - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 2] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 2] - Internet-Draft Access Control Model 25 June 1999 - at the directory server is not defined in this document. - By defining only what flows on the wire allows existing - access control mechanisms to be used at the directory - server. - 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. + Internet-Draft Access Control Model 5 October 1999 - 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. - The access control model defines - A wire protocol for interoperability: The existing - LDAP protocol flows for add, delete, modify, etc are - used to manipulate access control information. - There are additional LDAP controls and extended - protocol operations defined to further help + LDAP protocol flows for add, delete, modify, and + search are used to manipulate access control + information. There are additional LDAP controls and + extended protocol operations defined to further help management of access control information: getEffectiveRights and specifyCredentials. @@ -153,32 +134,47 @@ information. - A set of attributes to identity the access control - mechanisms supported by a server. + mechanisms supported by a server and a given part of + the namespace. 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. + 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. + 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. + 3. Terminology - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 3] + An "access control list" contains the access control + policy information controlling access to an object or + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 3] - Internet-Draft Access Control Model 25 June 1999 - 3. Terminology + Internet-Draft Access Control Model 5 October 1999 + + - 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. @@ -186,11 +182,11 @@ security attribute's granted rights for the objects governed by the access control list to which it belongs. - The "access control policy information" (acpi) for an - object or a collection of objects defines which subject - security attributes entitle a subject to which granted - rights. The access control policy information for an - object is stored in an access control list. + 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 @@ -199,8 +195,8 @@ An "access decision function" is an algorithm which makes an access decision based on subject security attributes, - access control policy information, an object identifier, - and an operation name (possibly augmented by additional + access control information, an object identifier, and an + operation name (possibly augmented by additional contextual information). An "access decision function interface" is a programmatic @@ -220,24 +216,24 @@ "effective rights" are the complete set of rights a subject is entitled to based on all access control lists + which apply to a specific object and based on all of the + subject's security attributes. + "granted rights" are the complete set of rights an access - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 4] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 4] - Internet-Draft Access Control Model 25 June 1999 + Internet-Draft Access Control Model 5 October 1999 - 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. @@ -248,17 +244,6 @@ An "identity" is a subject security attribute which is unique to a single subject. - An "object" is the target of operations in an information - system. - - An "operation" is the result of executing the code - accessed through a named entry point in an information - system. - - An "operation name" is the name of the entry point - through which an operation is invoked in an information - system. - A "privilege attribute" is a subject security attribute which may be shared by several subjects. @@ -266,7 +251,7 @@ to authorize a requester to perform a specific operation on an object of a specific type. - A "right" is the basic unit of access control policy + 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 @@ -279,52 +264,49 @@ 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. - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 5] + 4. The Model + The access control mechanism described in this draft - Internet-Draft Access Control Model 25 June 1999 + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 5] - organizational position and entitlement to perform the - operations appropriate to that organizational position. - A "subject" is an entity which intiates 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 5 October 1999 - 4. The Model - 4.1 Access Control Activity Lifecycle + addresses these activities: - The access control proposal described in this draft - addresses four activities: + - Definition of subject security attributes + information - - Creation of subject security attribute information - and access control policy information + - Definition of access control policy - - Retrieval of subject security attribute information - at the time an access request is made + - Retrieval of subject security attributes - - Evaluation of access requests against policy, - resulting in an access decision + - Retrieval of effective access rights - - Replication of access control policy information - from one server to another + - Externalization of access control policy information - 4.2 Access Control Information Model + 4.1 Access Control Information Model This document does not define formats for storage of access control information; it does define the @@ -341,48 +323,66 @@ - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 6] - Internet-Draft Access Control Model 25 June 1999 - The diagram below illustrates the componentry of an LDAP + + + + + + + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 6] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + The diagram below illustrates the componentry of a LDAP system and the placement of the function specified in this draft. - +-------------+ - | Application | - +-------------+ - +--------+ - | LDAP | - | Client | - +--------+ - | - | - | <-- LDAP Extended Access Control - Controls - | or Extended Access Control - Operations - v - +-----------------------------+ - | LDAP Server (e.g. SLAPD) | - +-----------------------------+ - . | - . | - . | - . | - v v - +----------+ +-----------+ - | Access | | | - | Control |<.....| Datastore | - | Manager | | | - +----------+ +-----------+ + +-------------+ + | Application |<--attrs to address ACI + +-------------+ - aCI + +--------+ - vendorACI + | LDAP | - policyOwner + | Client | + +--------+ + | + | <-- LDAP controls + | - getEffectiveAccess + | - specifyCredentials + | <-- LDAP extended operations + | - getEffectiveAccess + v + +-----------------------------+ + | LDAP Server (e.g. SLAPD) | + +-----------------------------+ + . | + . | + . | + . | + v v + +----------+ +-----------+ + | Access | | |<-attrs to define + | Control |<--| Datastore | access control mechanisms + | Manager | | | - supportedACIMechanisms + +----------+ +-----------+ - aCIMechanism LDAP clients use the controls and extended operations specified in this document to administer access control @@ -394,87 +394,97 @@ external to their datastores. Datastores and external access control managers may implement any access control rule syntax and semantics they choose, as long as the - semantics is compatible with that defined in the section + semantics are compatible with that defined in the section titled "Operational Semantics of Access Control - Operations" (found after the control and extended + Operations". - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 7] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 7] - Internet-Draft Access Control Model 25 June 1999 + Internet-Draft Access Control Model 5 October 1999 - operation definition). - The access control administration mechanisms specified in this document are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting. - 4.3 Bind and Credentials + 4.2 Bind and Credentials A bind authenticates a principal to the directory. A principal is represented by a DN. A principal has a set - of credentials that are used for determining whether - access to resources specified in ldap operations. These - credentials may be pushed to the server by the client or - may be pulled by the server from the directory data. - Credentials may be local with respect to the server. If - not local (owned by another server or administrative - scope), then the server may decide to define a trust - model that states how to evaluate the trust of a - credential at bind time. The definition of such a trust - model is outside the scope of this document. + of credentials that are used to determine access to + resources specified in ldap operations. These + credentials may be pushed to the server by the client by + using the specifyCredentials control (see section on the + specifyCredentials control) or may be pulled by the + server from the directory data, i.e. access control + information associated with a directory entry using + normal LDAP operations. Credentials may be local with + respect to the server. If the credentials are not local + to the server, i.e. owned by another server or + administrative scope, then the server may decide to + define a trust model that states how to evaluate the + trust of a credential at bind time. The definition of + such a trust model is outside the scope of this document. - 5. Access Control Information Schema + 5. Access Control Mechanism Attributes - 5.1 Attributes + There are several attributes defined associated with + access control. Two attributes are defined to identity + which access control mechanisms are supported by a given + server and by a given subtree: supportedACIMechanisms + and aCIMechanism. - 5.1.1 Root DSE Attribute for Access Control Mechanism + 5.1 Root DSE Attribute for Access Control Mechanism - The following attribute may be included in the Root DSE. + 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 - ) - Two access control mechanisms are defined by this - document: - LDAPv3 - X500 + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 8] - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 8] + Internet-Draft Access Control Model 5 October 1999 - Internet-Draft Access Control Model 25 June 1999 + 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.1.2 Subschema Attribute for Access Control Mechanism + + 5.2 Subschema Attribute for Access Control Mechanism A given naming context must provide information about which access control mechanism is in effect for that @@ -484,1246 +494,1581 @@ adjacent naming contexts supported by that directory server. - - aCIMechanism lists the value (an OID) that defines - the access control mechanism in effect for the scope - of that subschema entry + aCIMechanism lists the value (an OID) that defines the + access control mechanism in effect for the scope of that + subschema entry. - 5.2 Other Defined Parameters/OIDs + ( + NAME 'aCIMechanism' + DESC list of access control mechanism supported + in this subtree + SYNTAX LDAPOID + USAGE dSAOperation + ) - 5.2.1 Rights Families and Rights - The following rights families are defined: - LDAPv3 - X500 + 6. Access Control Information Attributes - Other parties can (and will) define other rights - families. It is the responsibility of those parties to - provide the definition and OID. - 5.2.1.1 LDAPv3 Rights Family + 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 - Access rights can apply to an entire object or to - attributes of the object. Each of the LDAP access rights - are discrete. One permission does not imply another - permission. The rights may be ORed together to provide - the desired rights list. - Rights which apply to attributes are: - 1 Read Read attribute values - 2 Write Write attribute values - 4 Search Search entries with specified attributes - 8 Compare Compare attributes + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 9] - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 9] + Internet-Draft Access Control Model 5 October 1999 - Internet-Draft Access Control Model 25 June 1999 + 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 + based on the scope flag. - Rights that apply to an entire object are: + Three 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. + There are three attributes which may be queried or set on + all directory objects: aci, vendorAci and policyOwner. + Their BNF and definitions are defined below. - 16 Add Add an object below this object - 32 Delete Delete this object - 64 EditDN Edit an object's DN - Rights that apply to the object to which the directory - object points are: + 6.1 The BNF - 128 Manage Perform a privileged operation; used to - restrict access to operations which - read or write especially sensitive data - 256 Use Execute; useful in controlling access to - the objects referred to by directory - entries than in controlling access to - the directory entries themselves - 512 Get Get retrieves the attribute values - 1024 Set Set writes the attribute values + < aci > ::= < acl entry syntax > + + [ '#' ]* - 5.2.1.2 The X.500 Rights Family + < vendorAci > ::= + '#' + < printable string > - + < acl entry syntax > ::= + '#' + + '#' + + < rights > + '#' + < dnType > + + '#' + < subjectDn > - 5.2.2 DN Types + < policyOwner > ::= < familyOid > + '#' + + + '#' +< dnType > + '#' + < subjectDn > - The following DN Types are defined: + < subjectDn > ::= < printable string > | "public" | "this" - - access-id, OID= - - group, OID= - - role, OID= + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 10] - access-id, group, and role MUST be supported. An acess- - id is a non-collection (non-group and non-role objects) - DN that can be authenticated. - Other parties can (and will) define other DN Types. It - is the responsibility of those parties to provide the - definition and OID. + Internet-Draft Access Control Model 5 October 1999 + < familyOid > ::= < oid > - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 10] + ::= "entry" | "subtree" | + < level > ::= numericstring + < dnType > ::= "access-id" | "role" | "group" + < rights > ::= [ ] | [ < right > + [ '$' + + ] * ] + < rightsList > ::= + ';' + + < right > ::= + ';' + - Internet-Draft Access Control Model 25 June 1999 + < action > ::= "grant" | "deny" + < permissions > ::= [ ] | [ < permission > + + [ ',' + ] ] * + < attrs > ::= [ < attributeString> + + [ ',' + < attributeString > ] * ] - 6. Access Control Parameters for LDAP Controls & Extended - Operations + < attributeString > ::= "[all]" | "[entry]" + | - This section defines the parameters used in the access - control LDAP controls and extended operations in this - document. + < permission > ::= "a" | "d" | "r" | "s" | "w" | + "c" | "g" | "s" | "m" | "u" | "e" - targetDN specifies the initial directory entry in DN - syntax on which the control or extended operation is - performed. + These are the permissions defined for the IETF family OID. + "a" corresponds to add + "d" corresponds to delete + "r" corresponds to read + "w" corresponds to write + "c" corresponds to compare + "g" corresponds to get + "s" corresponds to set + "m" corresponds to manage + "u" corresponds to use + "e" corresponds to editDn - whichObject specifies whether the access control - information which is get/set is for the target directory - entry (ENTRY) or the target directory entry and its - subtree (SUBTREE). - rightsFamily specifies the family of rights that will be - get/set for the control or extended operation performed. - A rights family has a defined set of rights. + 6.2 Other Defined Parameters - rightsList in the SearchResultEntry is of the form - specified in the LDIF BNF for . + This section defines additional parameters that are used - dnType speficies the type of subject security attribute. - Defined types are access-id, group, and role. - subjectDN is a LDAP string that defines the subject or - value of the dnType. The subjectDN may be a DN or - another string such as IPAddress (dotted-decimal string - representation) on which access control is get/set. If - the subject is an entry in the directory, then the syntax - of the LDAP string is DN. We define two well-known - subjectDNs, the strings - - public - meaning public access for all users + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 11] - - this - meaning the user whose name matches the entry - being accessed - Four operations are defined: - - ACI_GRANT grants the rights specified in the - rightsList for the given subject. If an access - control list does not exist for the specified - entry/attribute, then the access control list is - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 11] + Internet-Draft Access Control Model 5 October 1999 + in the three (3) attributes that address access control + information. + 6.2.1 Rights Families and Rights - Internet-Draft Access Control Model 25 June 1999 + The rightsFamilyOID tells what permission set etc. will + follow in the string. The idea was to allow a different + permission set, scope etc. but with the same syntax. + So, for a single aCIMechanism ( the IETF one ) there + could be multiple rights families; one which IETF + defines, and MUST be recognized by servers claiming + support for this ACI mechanism, and other rights families + for models which can use the defined syntax, but need a + different permission set etc. + The following rights families are defined: + LDAPv3 + Other rights families can be defined (by OID). It is the + responsibility of those parties to provide the definition + and OID. - created with the granted rights for the given - subject. If the access control list already exists - for the specified entry/attribute, then the access - control list is modified to grant the rights for the - given subject. - - ACI_DENY denies the rights specified in the - rightsList for the given subject. No implementation - is implied for this operation. For example, denial - of rights may be implemented as explicit denial - (negative rights) on the access control list or - removal of rights from the access control list. + 6.2.1.1 LDAPv3 Rights Family - - ACI_REPLACE replaces the entire access control list - for the specified entry/attribute. If an access - control list does not exist for the specified - entry/attribute, then the access control list is - created with the granted rights for the given - subject. + Access rights can apply to an entire object or to + attributes of the object. Each of the LDAP access rights + are discrete. One permission does not imply another + permission. The rights may be ORed together to provide + the desired rights list. The rights which apply to + attributes and the entry parallel the type of ldap + operations that can be performed. - - ACI_DELETE deletes the entire access control list - for the specified entry/attribute. + Rights which apply to attributes: - attrs specifies the list of attributes against which the - operation is performed. attrs can be defined using a - LDAP filter expression. + 1 Read Read attribute values + 2 Write Write attribute values + 4 Search Search entries with specified attributes + 8 Compare Compare attributes + Rights that apply to an entire entry: - 7. Access Control Information (ACI) Controls + 16 Add Add an entry below this entry + 32 Delete Delete this entry - The access control information controls provide a way to - manipulate access control information in conjunction with - an LDAP operation such as ldap_add, ldap_modify, or - ldap_search. Three LDAP controls are defined for - transmission of access control information. These - controls allow access control information to be get/set - while manipulating other directory information. The - controls are: - - getEffectiveRights to obtain the effective rights - for a given directory entry(s) for a given subject - during a ldap_search operation - - specifyCredentials to specify a set of credentials - for the bind identity (DN) during a ldap_bind + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 12] - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 12] + Internet-Draft Access Control Model 5 October 1999 - Internet-Draft Access Control Model 25 June 1999 + 64 EditDN Edit an entry's DN + Rights that apply to the object to which the directory + entry points: + 128 Manage Perform a privileged operation; used to + restrict access to operations which + read or write especially sensitive data + 256 Use Execute; useful in controlling access to + the objects referred to by directory + entries rather than in controlling + access + to the directory entries themselves + 512 Get Get retrieves the attribute values + 1024 Set Set writes the attribute values - operation + The rights that apply to the object to which the + directory entry points (manage/use/get/set) are best + described by example. Suppose the object to which the + directory entry points is a pointer. - 7.1 getEffectiveRights Control + Manage addresses the right to perform a privileged + operation such as administrative operations on the + printer. It can be used to restrict access to operations + which read/write especially sensitive data. Examples of + these operations are start queue, stop queue, and flush + queue. + Use addresses the right to execute and is useful to + control access to the objects referred to by the + directory entry. This right is not applicable to the + printer example; however, some objects support access to + user functions as well as data and administrative + functions to which this right could apply. - 7.1.1 Request Control + Get in this printer example addresses the right to send + data access commands to the print that retrieve data. An + example is list jobs in the queue. - This control is included in the ldap_search message as - part of the controls field of the LDAPMessage, as - defined in Section 4.1.12 of [LDAPv3]. + Set in this printer example addresses the right to send + data modification commands to the printer that affect + printer operations. Examples are send job to print queue + and flush job from queue. - 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 { - targetDN LDAPDN, - effectiveRightsRequest SEQUENCE OF SEQUENCE { - rightsFamily LDAPOID | "*", - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - dnType LDAPOID | "*", - subjectDN LDAPString, - } - } - The targetDN specifies the initial directory entry in DN - syntax on which the getEffectiveRights control is - performed. request is a set of sequences that state the - whichObject (entry or entry plus subtree) and specifics - of the control request to be performed. One or more - rightsFamily can be be obtained for a given subjectDN ad - dnType. A "*" in the rightsFamily field indicates that - the rights for all rights families defined for the - subjectDN / dnType are to be returned. This control is - applied to the scope set by the ldap_search operation, - i.e. base, one-level, subtree. - 7.1.2 Response Control - This control is included in the ldap_search_response + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 13] - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 13] + Internet-Draft Access Control Model 5 October 1999 - Internet-Draft Access Control Model 25 June 1999 + 6.2.2 DN Types + The following DN Types strings are defined and MUST be + supported: + - access-id - message as part of the controls field of the LDAPMessage, - as defined in Section 4.1.12 of [LDAPv3]. + - group - The controlType is set to . The - criticality MAY be either TRUE or FALSE (where absent is - also equivalent to FALSE). The controlValue is an OCTET - STRING, whose value is the BER encoding of a value of the - following SEQUENCE: + - role - getEffectiveRightsResponse ::= { - result ENUMERATED { - success (0), - operationsError (1), - unavailableCriticalExtension (12), - noSuchAttribute (16), - undefinedAttributeType (17), - invalidAttributeSyntax (21), - unavailable (52), - unwillingToPerform (53), - other (80) - } - } + An access-id is a non-collection (non-group and non-role + objects) DN that can be authenticated. - The effective rights returned are returned with each - entry returned by the search result. The control - response for ldap_search is: + Other parties can (and will) define other DN Types. It + is the responsibility of those parties to provide the + definition and OID. - PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE { - rightFamily LDAPOID, - rightsList ENUMERATED, - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - } - } + 6.3 Basic ACI Attribute (aCI) - Although this extends the search operation, there are no - incompatibilities between versions. LDAPv2 cannot send a - control, hence the above structure cannot be returned to - a LDAPv2 client. A LDAPv3 client cannot send this - request to a LDAPv2 server. A LDAPv3 server not - supporting this control cannot return the additional - data. + ( aciOID NAME 'aCI' DESC 'Access control information' + EQUALITY caseIgnoreMatch SYNTAX directoryString ) + 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 ACI attribute is listed as other than the IETF + family oid, the syntax is the same as listed below, but + one or more of the scope, dnType, subjectDn or + permissions may vary from the IETF 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 + granted or denied access. The set of permissions is + fixed. Either of the actions "grant" | "deny" may be + used when creating or updating ACI. + The attributeString is an attribute Name (defined to be a + printable string). If the string refers to an attribute + not defined in the given server's schema, the server + SHOULD report an error. Another option for the + attributeString is "[entry]". This is provided to + describe permissions which apply to an entire object. + This could mean actions such as delete the object, or add - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 14] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 14] - Internet-Draft Access Control Model 25 June 1999 + Internet-Draft Access Control Model 5 October 1999 - 7.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. + a child object. The third option for attributeString is + "[all]" which means the permission set should apply to + all attributes. - There are six possible scenarios that may occur as a - result of the getEffectiveRights control being included - on the search request: + If the keyword "[all]" and another attribute are both + specified within an aci, the more specific permission set + for the attribute overrides the less specific permission + set for "[all]". + If two ACIs contain identical familyOID, scope, DnTypes + and DNs, the permission given DN is specified in two + distinct acis on any given entry, the rights lists can be + combined into one list. For example, - 1. If the server does not support this control and the - client specified TRUE for the control's criticality - field, then the server MUST return - unavailableCriticalExtension as a return code in - the searchResponse message and not send back any - other results. This behavior is specified in - section 4.1.12 of [LDAPv3]. + aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ + aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept + XYZ - 2. If the server does not support this control and the - client specified FALSE for the control's - criticality field, then the server MUST ignore the - control and process the request as if it were not - present. This behavior is specified in section - 4.1.12 of [LDAPv3]. + is the equivalent of - 3. If the server supports this control but for some - reason such as cannot process specified - rightsFamily and the client specified TRUE for the - control's criticality field, then the server SHOULD - do the following: return - unavailableCriticalExtension as a return code in - the searchResult message. + aci: 1.2.3.4#subtree#grant;r,w;[all]; + r,attribute1#group#cn=Dept XYZ - 4. If the server supports this control but for some - reason such as cannot process specified - rightsFamily and the client specified FALSE for the - control's criticality field, then the server should - process as 'no rights returned for that family' and - include the result Unavailable in the - getEffectiveRightsResponse control in the - searchResult message. + Using the defined BNF it is possible for the permission + string to be empty. The ACI + aci: 1.2.3.4#subtree#grant;;attribute1$grant;r,s; + [all]#group#cn=Dept XYZ,c=US + means that this group is granted permission to read and + search all attributes except attribute1. - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 15] + Similarly, the ACI + aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US + simply means that no permissions have been defined for + this group. It is up to the server implementation as to + whether the group does or does not receive permission to + attributes on an entry with an empty rights list. + Multiple attributeStrings can be listed after any given + permission set; for instance, "r,w ; attribute1, + attribute2". This means that if the server supports a + attribute aggregation mechanism, attribute1 and - Internet-Draft Access Control Model 25 June 1999 + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 15] - 5. If the server supports this control and can return - the rights per the rightsFamily information, then - it should include the getEffectiveRightsResponse - control in the searchResult message with a result - of success. - 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. + Internet-Draft Access Control Model 5 October 1999 - 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. - 7.2 specifyCredentials Control + attribute2 should be considered to be part of the same + group. If the server does not support a grouping + mechanism, the permission set applies independently to + attribute1 and attribute2. For servers that do not + support attribute grouping, "grant ; r,w ; attribute1, + attribute2" results in the same operations as "grant ; + r,w; attribute1$grant; r,w; attribute2" - 7.2.1 Request Control - This control is included in the ldap_bind message as - part of the controls field of the LDAPMessage, as - defined in Section 4.1.12 of [LDAPv3]. + 6.3.1 LDAP Operations - 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: + The attributes which are defined for access control + interchange may be used in all LDAP operations. - specifyCredentialRequest ::= SEQUENCE { + Within the ldapmodify-delete operation, the entire acl may + be deleted by specifying + dn: cn = some Entry + changetype: modify + delete: aci + In this case, the entry would then inherit its ACI from some + other node in the tree depending on the server inheritance + model. - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 16] + Deleting the last ACI value from an entry is not the same as + deleting the ACI from the entry. It is possible for an entry + to contain an ACI with no values. In this case, nothing is + returned to the client when querying the aci. It is server + dependent whether access is granted or denied in the absence + of any ACI information. Deleting an ACI value which does + not exist will result in an unchanged ACI and a return code + specifying that the attribute value does not exist. + 6.4 ACI Examples + 6.4.1 Attribute Definition + Pretend IETFFamilyOID = 1.2.3.4 - Internet-Draft Access Control Model 25 June 1999 + The following two examples show an administrative + subdomain being established. The first example shows a + single user being assigned the policyOwner for the entire - credential LDAPString - } - } + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 16] - The credential specifies the credential (e.g. groups, - roles, etc) that the client is requesting be associated - with the bind DN for access control determination in - subsequent ldap operations. This provides a 'push' model - for credentials where the client attempts to 'push' the - credential to the server. The server may process at bind - time as follows: - - server may unconditionally ignore - - server may unconditionally accept - - server may define trust model and evaluate of the - trust of each credential - If this control is not used, it is assumed that the - server determines (pulls) the credentials associated with - the bind DN when needed in subsequent ldap operations to - provide access control. - 7.2.2 Response Control + Internet-Draft Access Control Model 5 October 1999 - This control is included in the ldap_bind message as part - of the controls field of the LDAPMessage, as defined in - Section 4.1.12 of [LDAPv3]. - The controlType is set to . The - criticality MAY be either TRUE or FALSE (where absent is - also equivalent to FALSE). The controlValue is an OCTET - STRING, whose value is the BER encoding of a value of the - following SEQUENCE: - specifyCredentialsResponse ::= { - result ENUMERATED { - success (0), - operationsError (1), - unavailableCriticalExtension (12), - unavailable (52), - unwillingToPerform (53), - other (80) - } + domain. The second example shows a group of ids assigned + to the policy Owner. + policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt + policyOwner: 1.2.3.4#subtree#group#cn=System Owners, + o=Company - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 17] + The next example shows an aci attribute where a group + "cn=Dept XYZ, c=US" is being given permissions to read, + search and compare attribute1. The permission should + apply to the entire subtree below the node containing + this ACI. + aci:1.2.3.4#subtree#grant;r,s,c; + attribute1#group#cn=Dept XYZ,c=US + The next example shows an ACI attribute where a role + "cn=SysAdmins,o=Company" is being given permissions to + add objects below this node, and read, search and compare + attributes 2 and 3. The permission should apply to the + entire subtree below the node containing this ACI. + aci: 1.2.3.4#subtree#grant;a;[entry]$grant; + r,s,c;attribute2, attribute3#role# + cn=SysAdmins,o=Company + 6.4.2 Modifying the ACI Values - Internet-Draft Access Control Model 25 June 1999 + Replace works similarly to all other attributes. If the + attribute value does not exist, create the value. If the + attribute does exist, replace the value. If the ACI value + is replaced, all ACI values are replaced. + A given aci for an entry: + aci: 1.2.3.4#subtree#deny;r,w;[all]$grant;r,s,c; + attribute2#group#cn=Dept ABC - } + aci: 1.2.3.4#subtree#grant;r;[all]$grant;r,s,c; + attribute1#group#cn=Dept XYZ - No data is returned; just the result is returned. + perform the following change: - Although this extends the bind operation, there are no - incompatibilities between versions. LDAPv2 cannot send a - control. A LDAPv3 client cannot send this request to a - LDAPv2 server. A LDAPv3 server not supporting this - control cannot return the additional data. - 7.2.3 Client-Server Interaction - The specifyCredentialsRequest control specifies the - credentials that the client wants the server to use for - access control in subsequent ldap operations. The server - that consumes the bind operation may unconditionally - accept, ignore, or evaluate the trust of the specified - credentials at bind time and returns only a success or - failure response (no data returned). - There are six possible scenarios that may occur as a - result of the specifyCredential control being included on - the bind request: + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 17] - 1. If the server does not support this control and the - client specified TRUE for the control's criticality - field, then the server MUST return - unavailableCriticalExtension as a return code in - the bindResponse message. This behavior is - specified in section 4.1.12 of [LDAPv3]. - 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 credential - (e.g. server decided to evaluate the trust of that - credential and the result is the server not - trusting all the credentials or unconditionally - ignores the credential) and the client specified + Internet-Draft Access Control Model 5 October 1999 - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 18] + dn: cn=someEntry + changetype: modify + replace: aci + aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN + The resulting acl is: + aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN + ( aci values for Dept XYZ and ABC are lost through the + replace ) - Internet-Draft Access Control Model 25 June 1999 + During an ldapmodify-add, if the ACI does not exist, the + create the ACI with the specific aci value(s). If the ACI + does exist, then add the specified values to the given ACI. + For example a given ACI: + aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ + with a modification: - TRUE for the control's criticality field, then the - server SHOULD do the following: return - unavailableCriticalExtension as a return code in - the bindResult message and omit the - specifyCredentialResponse control in the bindResult - message. + dn: cn=someEntry + changetype: modify + add: aci + aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - 4. If the server supports this control but for some - reason such as cannot process specified credential - (e.g. server decided to evaluate the trust of that - credential and the result is the server not - trusting all the credentials or unconditionally - ignores the credential) and the client specified - FALSE for the control's criticality field, then the - server should process as 'credential ignored' and - include the result Unavailable in the - specifyCredentialResponse control in the bindResult - message. + would yield an multi-valued aci of: - 5. If the server supports this control and evaulates - the trust of that credential and the result is the - server trusting all the credentials, then it should - include the specifyCredentialResponse control in - the bindResult message with a result of success. + aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ + aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ + To delete a particular aci value, use the regular ldapmodify + - delete syntax - 6. If the bind request failed for any other reason, - then the server SHOULD omit the - specifyCredentialResponse control from the - bindResult message. + Given an ACI of: - The client application is assured that the correct - credentials are used by the server when specified by the - client for subsequent ldap operations if and only if the - specifyCredentialResponse is successful. If the server - omits the specifyCredentialResponse control from the - bindResponse message, the client SHOULD assume that the - control was ignored by the server. + aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ + aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - The specifyCredentialResponse control, if included by the - server in the bindResponse message, should have the - bindResult set to either success if the credentials were - accepted by the server or set to the appropriate error - code as to why the credentials were not accepted. + dn: cn = some Entry + changetype: modify + delete: aci + aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ + + would yield a remaining ACI on the server of + + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 18] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ + + + 6.5 Vendor ACI Attribute (vendorAci) + + ( vendorAciOID NAME 'vendorACI' DESC 'Vendor specific + Access control information' EQUALITY caseIgnoreMatch SYNTAX + directoryString ) + + The Vendor specific ACI information is listed in its own + attribute. This may be used by vendors to provide vendor + specific access control related information which can not be + expressed in defined ACISyntax. Within the vendorACI, the + oid determines the format or the printable string to follow. + + + 6.6 Policy Owner Attribute (policyOwner) + + ( policyOwnerOID NAME 'policyOwner' DESC 'Policy Owner + Access Control Information' EQUALITY caseIgnoreMatch + SYNTAX directoryString ) + + 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. + + If the policy owner is not specified for any object in + the tree, behavior is implementation defined. For + instance, if no object anywhere in the tree has a + policy owner, then the server could simply assert that + the 'root DN' is considered the policy owner for all + objects. An alternate approach might be that the + implementation defines the entryDN to be the policy + owner. + + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 19] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + 7. 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). + + + 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. + + - 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. + + + + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 20] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + 7.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. + + - 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 with an access- + denied exception 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. + + - LDAP Update (Deny), LDAP Access Request + + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 21] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + The Request will fail with an access-denied + exception if it requires any right denied to the + requesting subject by the Update operation. If the + Request requires only rights which were not denied + by the Update operation, it may succeed, depending + on the policy in force before the Update operation. + + - LDAP Update (Replace), Other, 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), 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 + + 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 + + The Request will succeed if it requires only rights + granted to the requesting subject by the Update + operation. The Request will fail with an access- + denied exception if it requires any right not + granted by the Update operation. + + - LDAP Update (Grant), Other, 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. + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 22] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + - LDAP Update (Deny), Other, LDAP Access Request + + The Request will fail with an access-denied + exception if it requires any right denied to the + requesting subject by the Update operation. If the + Request requires only rights which were not denied + by the Update operation, it may succeed, depending + on the policy in force before the Update operation. + + - LDAP Update (Replace), Datastore Policy Update, LDAP + Query + + The result of the Query is not defined. + + - LDAP Update (Grant), Datastore Policy Update, LDAP + Query + + The result of the Query is not defined. + + - 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. + + - LDAP Update (Deny), Datastore Policy Update, LDAP + Access Request + + The result of the Access Request is not defined. + + + + 8. Access Control Parameters for LDAP Controls & Extended + Operations + + This section defines the parameters used in the access + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 23] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + 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). + + rightsFamily specifies the family of rights that will be + retrieved for the get effective rights control or + extended operation performed. A rights family has a + defined set of rights. + + rightsList in the get effective rights control or + extended operations response is of the form specified in + the BNF for . + + dnType speficies the type of subject security attribute. + Defined types are access-id, group, and role. + + 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. Two well-known subjectDNs + strings are defined + + - public - meaning public access for all users + + - this - meaning the user whose name matches the entry + being accessed + + + + 9. Access Control Information (ACI) Controls + + The access control information controls provide a way to + manipulate access control information in conjunction with + a LDAP operation. Two LDAP controls are defined. These + controls allow access control information to be get/set + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 24] + + + + + + + Internet-Draft Access Control Model 5 October 1999 + + + + while manipulating other directory information for that + entry. The controls are: + + - getEffectiveRights to obtain the effective rights + for a given directory entry(s) for a given subject + during a ldap_search operation + + - specifyCredentials to specify a set of credentials + for the bind identity (DN) during a ldap_bind + operation + + 9.1 getEffectiveRights Control + + + 9.1.1 Request Control + This control may only be included in the ldap_search + message as part of the controls field of the + LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. + 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 { + rightsFamily LDAPOID | "*", + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + }, + dnType "access-id"|"group"|"role"|"*", + subjectDN LDAPString, + } + } + 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. One or + more rightsFamily can be be obtained for a given + subjectDN ad dnType. A "*" in the rightsFamily field + indicates that the rights for all rights families defined + for the subjectDN / dnType are to be returned. A "*" in - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 19] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 25] - Internet-Draft Access Control Model 25 June 1999 + Internet-Draft Access Control Model 5 October 1999 - 8. Access Control Extended Operations - Two extended operations (analogous to the controls) are - defined for transmission of access control information. - These operations help with the management of access - control information independent of manipulating other - directory information. The extended operations are: - - LDAP Get Effective Rights to obtain the effective - rights for a given directory entry for a given - subject + 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. - 8.1 LDAP Get Effective Rights Operation + 9.1.2 Response Control - ldapGetEffectiveRightsRequest ::= [APPLICATION 23] - SEQUENCE { - requestName [0] , - requestValue [1] OCTET STRING OPTIONAL } + 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]. - where + The controlType is set to . The + criticality MAY be either TRUE or FALSE (where absent is + also equivalent to FALSE). The controlValue is an OCTET + STRING, whose value is the BER encoding of a value of the + following SEQUENCE: - requestValue ::= SEQUENCE { - targetDN LDAPDN, - updates SEQUENCE OF SEQUENCE { - rightsFamily LDAPOID | "*", - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - dnType LDAPOID | "*", - subjectDN LDAPString, - } + getEffectiveRightsResponse ::= { + result ENUMERATED { + success (0), + operationsError (1), + unavailableCriticalExtension (12), + noSuchAttribute (16), + undefinedAttributeType (17), + invalidAttributeSyntax (21), + insufficientRights (50), + unavailable (52), + unwillingToPerform (53), + other (80) } + } + + 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 { + rightFamily LDAPOID, + rightsList LDAPString, + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + } + dnType LDAPString + subjectDN LDAPString + + + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 26] - 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. - ldpGetEffectiveRightsResponse ::= [APPLICATION 24] - SEQUENCE { + Internet-Draft Access Control Model 5 October 1999 - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 20] + } + 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. + 9.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. - Internet-Draft Access Control Model 25 June 1999 + 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]. - COMPONENTS OF LDAPResult, - responseName [10] OPTIONAL, - effectiveRights [11] OCTET STRING OPTIONAL } + 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]. - where + 3. If the server supports this control but for some + reason such as cannot process specified + rightsFamily and the client specified TRUE for the + control's criticality field, then the server SHOULD + do the following: return + unavailableCriticalExtension as a return code in - effectiveRights ::= SEQUENCE OF SEQUENCE { - rightFamily LDAPOID, - rightsList ENUMERATED, - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - subjectDnType LDAPOID, - subjectDN LDAPSTRING - } - If the server does not recognize the request name, it - MUST return only the response fields from LDAPResult, - containing the protocolError result code. + + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 27] - 9. Access Control Information Attributes/LDIF - 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 not defined here. What 'deny' - means on server1 might be different than on server2. - Additionally, while the server must recognize and act on the - attribute when received over the wire, there are no - requirements for the server to actually implement this - attribute. - The attribute definition maintains an assumption that the - receiving server supports inheritance within the security + Internet-Draft Access Control Model 5 October 1999 - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 21] + the searchResult message. + 4. If the server supports this control but for some + reason such as cannot process specified + rightsFamily and the client specified FALSE for the + control's criticality field, then the server should + process as 'no rights returned for that family' and + include the result Unavailable in the + getEffectiveRightsResponse control in the + searchResult message. + 5. If the server supports this control and can return + the rights per the rightsFamily information, then + it should include the getEffectiveRightsResponse + control in the searchResult message with a result + of success. + 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. - Internet-Draft Access Control Model 25 June 1999 + 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. + 9.2 specifyCredentials Control + This control is used with the ldap_bind() operation to + push credentials from the client to the server. A + privilege attribute certificate is an example of a - model. If the server does not support inheritance, the - receiving server must expand any inherited information based - on the scope flag. - 9.1 ACI Attributes + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 28] - There are three attributes which may be queried or set on - all directory objects: aci, vendorAci and policyOwner. The - syntax of these attributes is defined below. - 9.1.1 The BNF - < aci > ::= < acl syntax > - < vendorAci > ::= + '#' + < printable string > - < acl syntax > ::= + '#' + + '#' - + < rights > + '#' + < dnType > - + '#' + < subjectDn > + Internet-Draft Access Control Model 5 October 1999 - < policyOwner > ::= < familyOid > + '#' + - + '#' +< dnType > + '#' + < subjectDn > - < subjectDn > ::= < printable string > - < familyOid > ::= < oid > + credential that could be pushed from the client to the + server. - ::= "entry" | "subtree" | - < level > ::= numericstring + 9.2.1 Request Control - < dnType > ::= "access-id" | "role" | "group" + This control is included in the ldap_bind message as + part of the controls field of the LDAPMessage, as + defined in Section 4.1.12 of [LDAPv3]. - < rights > ::= [ ] | [ < right > + [ '$' - + ] * ] + 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: - < right > ::= + ';' + - + ';' + + specifyCredentialRequest ::= SEQUENCE { + credential LDAPString + } + } - < action > ::= "grant" | "deny" + The credential specifies the credential (e.g. groups, + roles, etc) that the client is requesting be associated + with the bind DN for access control determination in + subsequent ldap operations. This provides a 'push' model + for credentials where the client attempts to 'push' the + credential to the server. The server may process at bind + time as follows: - < permissions > ::= [ ] | [ < permission > - + [ ',' + ] * ] + - server may unconditionally ignore + - server may unconditionally accept + - server may define trust model and evaluate of the + trust of each credential - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 22] + If this control is not used, it is assumed that the + server determines (pulls) the credentials associated with + the bind DN when needed in subsequent ldap operations to + provide access control. + 9.2.2 Response Control + This control is included in the ldap_bind message as part + of the controls field of the LDAPMessage, as defined in + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 29] - Internet-Draft Access Control Model 25 June 1999 - < attrs > ::= [ < attributeString> - + [ ',' + < attributeString > ] * ] - < attributeString > ::= "[all]" | "[entry]" - | - < permission > ::= "a" | "d" | "r" | "s" | "w" | - "c" | "g" | "s" | "m" | "u" | "e" + Internet-Draft Access Control Model 5 October 1999 - These are the permissions defined for the IETF family OID. - "a" corresponds to add - "d" corresponds to delete - "r" corresponds to read - "w" corresponds to write - "c" corresponds to compare - "g" corresponds to get - "s" corresponds to set - "m" corresponds to manage - "u" corresponds to use - "e" corresponds to editDn - 9.1.2 VendorACI + Section 4.1.12 of [LDAPv3]. - ( vendorAciOID NAME 'vendorACI' DESC 'Vendor specific - Access control information' EQUALITY caseIgnoreMatch SYNTAX - directoryString ) + The controlType is set to . The + criticality MAY be either TRUE or FALSE (where absent is + also equivalent to FALSE). The controlValue is an OCTET + STRING, whose value is the BER encoding of a value of the + following SEQUENCE: - The Vendor specific ACI information is listed in its own - attribute. This may be used by vendors to provide vendor - specific access control related information which can not be - expressed in defined ACISyntax. Within the vendorACI, the - oid determines the format or the printable string to follow. + specifyCredentialsResponse ::= { + result ENUMERATED { + success (0), + operationsError (1), + unavailableCriticalExtension (12), + unavailable (52), + unwillingToPerform (53), + other (80) + } + } + No data is returned; just the result is returned. - 9.1.3 Policy Owner + Although this extends the bind operation, there are no + incompatibilities between versions. LDAPv2 cannot send a + control. A LDAPv3 client cannot send this request to a + LDAPv2 server. A LDAPv3 server not supporting this + control cannot return the additional data. - ( policySyntaxOID DESC 'PolicyOwner Syntax' ) ( - policyOwnerOID NAME 'policyOwner' DESC 'Policy Owner Access - Control Information' EQUALITY caseIgnoreMatch SYNTAX - policySyntaxOID ) + 9.2.3 Client-Server Interaction - 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 + The specifyCredentialsRequest control specifies the + credentials that the client wants the server to use for + access control in subsequent ldap operations. The server + that consumes the bind operation may unconditionally + accept, ignore, or evaluate the trust of the specified + credentials at bind time and returns only a success or + failure response (no data returned). + There are six possible scenarios that may occur as a + result of the specifyCredential control being included on + the bind request: - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 23] + 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 + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 30] - Internet-Draft Access Control Model 25 June 1999 - 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. + Internet-Draft Access Control Model 5 October 1999 - 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. - If the policy owner is not specified for any object in the - tree, behavior is implementation defined. For instance, if - no object anywhere in the tree has a policy owner, then the - server could simply assert that the 'root DN' is considered - the policy owner for all objects. An alternate approach - might be that the implementation defines the entryDN to be - the policy owner. + unavailableCriticalExtension as a return code in + the bindResponse message. This behavior is + specified in section 4.1.12 of [LDAPv3]. - 9.1.4 ACI + 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]. - ( aciSyntaxOID DESC 'ACI Syntax' ) - ( aciOID NAME 'aci' DESC 'Access control information' - EQUALITY caseIgnoreMatch SYNTAX aciSyntaxOID ) + 3. If the server supports this control but for some + reason such as cannot process specified credential + (e.g. server decided to evaluate the trust of that + credential and the result is the server not + trusting all the credentials or unconditionally + ignores the credential) and the client specified + TRUE for the control's criticality field, then the + server SHOULD do the following: return + unavailableCriticalExtension as a return code in + the bindResult message and omit the + specifyCredentialResponse control in the bindResult + message. - 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 ACI - attribute is listed as other than the IETF family oid, the - syntax is the same as listed below, but one or more of the - scope, dnType, subjectDn or permissions may vary from the - IETF defined syntax. + 4. If the server supports this control but for some + reason such as cannot process specified credential + (e.g. server decided to evaluate the trust of that + credential and the result is the server not + trusting all the credentials or unconditionally + ignores the credential) and the client specified + FALSE for the control's criticality field, then the + server should process as 'credential ignored' and + include the result Unavailable in the + specifyCredentialResponse control in the bindResult + message. - 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 user is being granted or denied - access. The set of permissions is fixed. Either of the - actions "grant" | "deny" may be used when creating or - updating ACI. + 5. If the server supports this control and evaulates + the trust of that credential and the result is the + server trusting all the credentials, then it should + include the specifyCredentialResponse control in + the bindResult message with a result of success. - The attributeString is an attribute Name (defined to be a - printable string). If the string refers to an attribute not - defined in the given server's schema, the server SHOULD - report an error. Another option for the attributeString is + 6. If the bind request failed for any other reason, + then the server SHOULD omit the + specifyCredentialResponse control from the - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 24] + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 31] - Internet-Draft Access Control Model 25 June 1999 + Internet-Draft Access Control Model 5 October 1999 - "[entry]". This is provided to describe permissions which - apply to an entire object. This could mean actions such as - delete the object, or add a child object. The third option - for attributeString is "[all]" which means the permission - set should apply to all attributes. + bindResult message. - 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]". + The client application is assured that the correct + credentials are used by the server when specified by the + client for subsequent ldap operations if and only if the + specifyCredentialResponse is successful. If the server + omits the specifyCredentialResponse control from the + bindResponse message, the client SHOULD assume that the + control was ignored by the server. - If two ACIs contain identical familyOID, scope, DnTypes and - DNs, the permission given DN is specified in two distinct - acis on any given entry, the rights lists can be combined - into one list. For example, + The specifyCredentialResponse control, if included by the + server in the bindResponse message, should have the + bindResult set to either success if the credentials were + accepted by the server or set to the appropriate error + code as to why the credentials were not accepted. - aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ - aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - is the equivalent of + 10. Access Control Extended Operation - aci: 1.2.3.4#subtree#grant;r,w;[all]; - r,attribute1#group#cn=Dept XYZ + 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. - Using the defined BNF it is possible for the permission - string to be empty. The ACI - aci: 1.2.3.4#subtree#grant;;attribute1$grant;r,s; - [all]#group#cn=Dept XYZ,c=US + 10.1 LDAP Get Effective Rights Operation - means that this group is granted permission to read and - search all attributes except attribute1. + ldapGetEffectiveRightsRequest ::= [APPLICATION 23] + SEQUENCE { + requestName [0] , + requestValue [1] OCTET STRING OPTIONAL } - Similarly, the ACI + where - aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US + requestValue ::= SEQUENCE { + targetDN LDAPDN, + updates SEQUENCE OF SEQUENCE { + rightsFamily LDAPOID | "*", + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + }, + dnType LDAPOID | "*", + subjectDN LDAPString, - simply means that no permissions have been defined for this - group. It is up to the server implementation as to whether - the group does or does not receive permission to attributes - on an entry with an empty rights list. - Multiple attributeStrings can be listed after any given - permission set; for instance, "r,w ; attribute1, - attribute2". This means that if the server supports a + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 32] - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 25] + Internet-Draft Access Control Model 5 October 1999 - Internet-Draft Access Control Model 25 June 1999 + } + } - attribute aggregation mechanism, attribute1 and attribute2 - should be considered to be part of the same group. If the - server does not support a grouping mechanism, the permission - set applies independently to attribute1 and attribute2. For - servers that do not support attribute grouping, "grant ; r,w - ; attribute1, attribute2" results in the same operations as - "grant ; r,w; attribute1$grant; r,w; attribute2" + 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. - 9.1.5 LDAP Operations + ldapGetEffectiveRightsResponse ::= [APPLICATION 24] + SEQUENCE { + COMPONENTS OF LDAPResult, + responseName [10] OPTIONAL, + effectiveRights [11] OCTET STRING OPTIONAL } - The attributes which are defined for access control - interchange may be used in all LDAP operations. + where - Within the ldapmodify-delete operation, the entire acl may - be deleted by specifying + effectiveRights ::= SEQUENCE OF SEQUENCE { + rightFamily LDAPOID, + rightsList ENUMERATED, + whichObject ENUMERATED { + LDAP_ENTRY (1), + LDAP_SUBTREE (2) + }, + subjectDnType LDAPOID, + subjectDN LDAPSTRING + } - dn: cn = some Entry - changetype: modify - delete: aci + If the server does not recognize the request name, it + MUST return only the response fields from LDAPResult, + containing the protocolError result code. - In this case, the entry would then inherit its ACI from some - other node in the tree depending on the server inheritance - model. - Deleting the last ACI value from an entry is not the same as - deleting the ACI from the entry. It is possible for an entry - to contain an ACI with no values. In this case, nothing is - returned to the client when querying the aci. It is server - dependent whether access is granted or denied in the absence - of any ACI information. Deleting an ACI value which does - not exist will result in an unchanged ACI and a return code - specifying that the attribute value does not exist. + 11. Security Considerations - 9.2 Examples + 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 - 9.2.1 Attribute Definition - Pretend IETFFamilyOID = 1.2.3.4 + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 33] - The following two examples show an administrative - subdomain being established. The first example shows a - single user being assigned the policyOwner for the entire - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 26] + Internet-Draft Access Control Model 5 October 1999 + whenever it is stored or transmitted. - Internet-Draft Access Control Model 25 June 1999 + 12. References - domain. The second example shows a group of ids assigned - to the policy Owner. + [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight + Directory Access Protocol (v3)", RFC 2251, December 1997. - policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt + [ECMA] ECMA, "Security in Open Systems: A Security + Framework" ECMA TR/46, July 1988 - policyOwner: 1.2.3.4#subtree#group#cn=System Owners, - o=Company + [REQTS] Stokes, Byrne, Blakley, "Access Control + Requirements for LDAP, INTERNET-DRAFT , August 1998. - The next example shows an aci attribute where a group - "cn=Dept XYZ, c=US" is being given permissions to read, - search and compare attribute1. The permission should - apply to the entire subtree below the node containing - this ACI. + [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, + "Lightweight Directory Access Protocol (v3)": Attribute + Syntax Definitions, RFC 2252, December 1997. - aci:1.2.3.4#subtree#grant;r,s,c; - attribute1#group#cn=Dept XYZ,c=US + [UTF] M. Wahl, S. Kille, "Lightweight Directory Access + Protocol (v3)": A UTF-8 String Representation of + Distinguished Names", RFC 2253, December 1997. - 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 2 and 3. The permission should apply to the - entire subtree below the node containing this ACI. + [Bradner97] Bradner, Scott, "Key Words for use in RFCs to + Indicate Requirement Levels", RFC 2119. - aci: 1.2.3.4#subtree#grant;a;[entry]$grant; - r,s,c;attribute2, attribute3#role# - cn=SysAdmins,o=Company + AUTHOR(S) ADDRESS - 9.2.2 Modifying the ACI Values + 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 - Replace works similarly to all other attributes. If the - attribute value does not exist, create the value. If the - attribute does exist, replace the value. If the ACI value - is replaced, all ACI values are replaced. - A given aci for an entry: + Debbie Byrne + IBM + 11400 Burnet Rd + Austin, TX 78758 + USA - aci: 1.2.3.4#subtree#deny;r,w;[all]$grant;r,s,c; - attribute2#group#cn=Dept ABC - aci: 1.2.3.4#subtree#grant;r;[all]$grant;r,s,c; - attribute1#group#cn=Dept XYZ - perform the following change: + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 34] - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 27] + Internet-Draft Access Control Model 5 October 1999 + mail-to: djbyrne@us.ibm.com + phone: +1 512 838 1960 + fax: +1 512 838 8597 - Internet-Draft Access Control Model 25 June 1999 - dn: cn=someEntry - changetype: modify - replace: aci - aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN - The resulting acl is: - aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN - ( aci values for Dept XYZ and ABC are lost through the - replace ) - During an ldapmodify-add, if the ACI does not exist, the - create the ACI with the specific aci value(s). If the ACI - does exist, then add the specified values to the given ACI. - For example a given ACI: - aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ - with a modification: - dn: cn=someEntry - changetype: modify - add: aci - aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - would yield an multi-valued aci of: - aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ - aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - To delete a particular aci value, use the regular ldapmodify - - delete syntax - Given an ACI of: - aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ - aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - dn: cn = some Entry - changetype: modify - delete: aci - aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ - would yield a remaining ACI on the server of - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 28] - Internet-Draft Access Control Model 25 June 1999 - aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ - 10. Security Considerations - This draft proposes protocol elements for transmission of - security policy information. Security considerations are - discussed throughout this draft. Because subject - security attribute information is used to evaluate - decision requests, it is security-sensitive information - and must be protected against unauthorized modification - whenever it is stored or transmitted. - 11. 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 , August 1998. - [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, - "Lightweight Directory Access Protocol (v3)": Attribute - Syntax Definitions, RFC 2252, December 1997. - [UTF] M. Wahl, S. Kille, "Lightweight Directory Access - Protocol (v3)": A UTF-8 String Representation of - Distinguished Names", RFC 2253, December 1997. - [Bradner97] Bradner, Scott, "Key Words for use in RFCs to - Indicate Requirement Levels", RFC 2119. - AUTHOR(S) ADDRESS + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 35] - Ellen Stokes Bob Blakley - IBM Dascom - 11400 Burnet Rd 5515 Balcones Drive - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 29] + Internet-Draft Access Control Model 5 October 1999 - Internet-Draft Access Control Model 25 June 1999 - 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 @@ -1757,17 +2102,16 @@ - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 30] - Internet-Draft Access Control Model 25 June 1999 + Stokes, Byrne, Blakley Expires 5 April 2000 [Page 36] @@ -1778,19 +2122,55 @@ + CONTENTS + 1. Introduction....................................... 2 + 2. Overview........................................... 2 + 3. Terminology........................................ 3 + 4. The Model.......................................... 5 + 4.1 Access Control Information Model............. 6 + 4.2 Bind and Credentials......................... 8 + 5. Access Control Mechanism Attributes................ 8 + 5.1 Root DSE Attribute for Access Control + Mechanism.................................... 8 + 5.2 Subschema Attribute for Access Control + Mechanism.................................... 9 + 6. Access Control Information Attributes.............. 9 + 6.1 The BNF...................................... 10 + 6.2 Other Defined Parameters..................... 11 + 6.2.1 Rights Families and Rights 12 + 6.2.2 DN Types 14 + 6.3 Basic ACI Attribute (aCI).................... 14 + 6.3.1 LDAP Operations 16 + 6.4 ACI Examples................................. 16 + 6.4.1 Attribute Definition 16 + 6.4.2 Modifying the ACI Values 17 + 6.5 Vendor ACI Attribute (vendorAci)............. 19 + 6.6 Policy Owner Attribute (policyOwner)......... 19 + 7. Operational Semantics of Access Control + Operations......................................... 20 + 7.1 Types of actions............................. 20 + 7.2 Semantics of Histories....................... 21 + 8. Access Control Parameters for LDAP Controls & + Extended Operations................................ 23 + 9. Access Control Information (ACI) Controls.......... 24 + 9.1 getEffectiveRights Control................... 25 + 9.1.1 Request Control 25 + 9.1.2 Response Control 26 + 9.1.3 Client-Server Interaction 27 + - i - @@ -1802,9 +2182,17 @@ + 9.2 specifyCredentials Control................... 28 + 9.2.1 Request Control 29 + 9.2.2 Response Control 29 + 9.2.3 Client-Server Interaction 30 + 10. Access Control Extended Operation.................. 32 + 10.1 LDAP Get Effective Rights Operation.......... 32 + 11. Security Considerations............................ 33 + 12. References......................................... 34 @@ -1816,7 +2204,6 @@ - Stokes, Byrne, Blakley Expires 25 December 1999 [Page 31] @@ -1827,55 +2214,23 @@ - CONTENTS - 1. Introduction....................................... 2 - 2. Overview........................................... 2 - 3. Terminology........................................ 4 - 4. The Model.......................................... 6 - 4.1 Access Control Activity Lifecycle............. 6 - 4.2 Access Control Information Model.............. 6 - 4.3 Bind and Credentials.......................... 8 - 5. Access Control Information Schema.................. 8 - 5.1 Attributes.................................... 8 - 5.1.1 Root DSE Attribute for Access Control - Mechanism 8 - 5.1.2 Subschema Attribute for Access Control - Mechanism 9 - 5.2 Other Defined Parameters/OIDs................. 9 - 5.2.1 Rights Families and Rights 9 - 5.2.2 DN Types 10 - 6. Access Control Parameters for LDAP Controls & - Extended Operations................................ 11 - 7. Access Control Information (ACI) Controls.......... 12 - 7.1 getEffectiveRights Control.................... 13 - 7.1.1 Request Control 13 - 7.1.2 Response Control 13 - 7.1.3 Client-Server Interaction 15 - 7.2 specifyCredentials Control.................... 16 - 7.2.1 Request Control 16 - 7.2.2 Response Control 17 - 7.2.3 Client-Server Interaction 18 - 8. Access Control Extended Operations................. 20 - 8.1 LDAP Get Effective Rights Operation........... 20 - 10. Security Considerations............................ 29 - 11. References......................................... 29 - - i - + - ii - @@ -1935,7 +2290,7 @@ - - ii - + - iii -