Internet-Draft B. Blakley LDAP Extensions WG D. Byrne Intended Category: Standards Track E. Stokes Expires: 18 May 1999 IBM 18 November 1998 Access Control Model for LDAP STATUS OF THIS MEMO This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or munnari.oz.au. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com ABSTRACT This document describes the access control list (ACL) model for the Lightweight Directory Application Protocol (LDAP) directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. A separate document defines the corresponding application programming interfaces (APIs). RFC2219 [Bradner97] terminology is used. Blakley, Byrne, Stokes [Page 1] Internet-Draft ACL Model 18 November 1998 1. Introduction The ability to securely access (replicate and distribute) directory information throughout the network is necessary for successful deployment. LDAP's acceptance as an access protocol for directory information is driving the need to provide an access control model definition for LDAP directory content among servers within an enterprise and the Internet. Currently LDAP does not define an access control model, but is needed to ensure consistent secure access across heterogeneous LDAP implementations. The major objective is to provide a simple, but secure, highly efficient access control model for LDAP while also providing the appropriate flexibility to meet the needs of both the Internet and enterprise environments and policies. This document defines the model and the protocol extensions (controls and extended operations). A separate document defines the corresponding application programming interfaces (APIs). 2. Overview Access Control mechanisms evaluate requests for access to protected resources and make decisions about whether those requests should be granted or denied. In order to make a grant/deny decision about a request for access to a protected resource, an access control mechanism needs to evaluate policy data. This policy data describes security-relevant characteristics of the requesting subject and the rules which govern the use of the target object. This proposal defines the protocol elements for transmission of this access control policy data in an LDAP environment and an attribute that defines the ACL mechanism in effect for a given part of the LDAP namespace. The instantiation of an ACL model at the directory server is not defined in this document. By defining only what flows on the wire allows existing ACL mechanisms to be used at the directory server. No mechanism is defined in this document to control access to access control information; this is vendor dependent. Blakley, Byrne, Stokes [Page 2] Internet-Draft ACL Model 18 November 1998 Encoding of access control information on the wire is per the LDAPv3 specifications. 2.1 Access Control Activity Lifecycle The access control proposal described in this draft addresses four activities: - Creation of subject security attribute information and access control policy information - Retrieval of subject security attribute information at the time an access request is made - Evaluation of access requests against policy, resulting in an access decision - Replication of access control policy information from one server to another 2.2 Access Control Information Model This document does not define formats for storage of access control information; it does define the operational semantics of access control operations. Blakley, Byrne, Stokes [Page 3] Internet-Draft ACL Model 18 November 1998 The diagram below illustrates the componentry of an LDAP system and the placement of the function specified in this draft. +-------------+ | Application | +-------------+ +--------+ | LDAP | | Client | +--------+ | | | <-- LDAP Extended ACL Controls | or Extended ACL Operations v +-----------------------------+ | LDAP Server (e.g. SLAPD) | +-----------------------------+ . | . | . | . | v v +----------+ +-----------+ | | | | | ACL Mgr. |<.....| Datastore | | | | | +----------+ +-----------+ LDAP clients use the controls and extended operations specified in this document to administer access control policy enforced by LDAP servers. Servers may store access control information in any way they choose. In particular, servers may use the access control mechanisms of their datastores to store and enforce LDAP access control, or they may implement ACL managers external to their datastores. Datastores and external ACL managers may implement any access control rule syntax and semantics they choose, as long as the semantics is compatible with that defined in the section titled "Operational Semantics of Access Control Operations" (found after the control and extended operation definition). Blakley, Byrne, Stokes [Page 4] Internet-Draft ACL Model 18 November 1998 The access control administration mechanisms specified in this document are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting. 2.3 Terminology An "access control list" contains the access control policy information controlling access to an object or collection of objects. An access control list consists of a set of access control list entries. An "access control list entry" defines a single subject security attribute's granted rights for the objects governed by the access control list to which it belongs. The "access control policy information" (acpi) for an object or a collection of objects defines which subject security attributes entitle a subject to which granted rights. The access control policy information for an object is stored in an access control list. An "access decision" is a boolean-valued function which answers the question: "can the subject with these subject security attributes perform this operation on this object?" An "access decision function" is an algorithm which makes an access decision based on subject security attributes, access control policy information, an object identifier, and an operation name (possibly augmented by additional contextual information). An "access decision function interface" is a programmatic interface through which applications can request an access decision. An "access identity" is an identity which is used by an access decision function to make an access decision. An "audit identity" is an identity which does not, in the absence of additional information, enable a party receiving and examining it to determine which subject it belongs to. Blakley, Byrne, Stokes [Page 5] Internet-Draft ACL Model 18 November 1998 A "credential" is a collection of subject security attributes. "effective rights" are the complete set of rights a subject is entitled to based on all access control lists 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. A "group" is a privilege attribute asserting a subject's membership in the collection of subjects whose name is that of the group. 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. "required rights" are the complete set of rights needed to authorize a requester to perform a specific operation on an object of a specific type. A "right" is the basic unit of access control policy administration. For each object type in an information system, a security administrator defines a set of required rights for each operation. For each object in the system, a security administrator defines a set of granted rights for each subject security attribute. When an access decision is required, an access decision function checks to make sure that the requester's subject Blakley, Byrne, Stokes [Page 6] Internet-Draft ACL Model 18 November 1998 security attributes have been granted all required rights needed to perform the requested operation on the specified target object. A "role" is a privilege attribute asserting a subject's organizational position and entitlement to perform the operations appropriate to that organizational position. A "subject" is an entity which 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. 3. LDIF Syntax for Access Control Information To be supplied. 4. ACL Schema 4.1 Attributes 4.1.1 Root DSE Attribute for ACL Mechanism The following attribute may be included in the Root DSE. ( NAME 'supportedACLMechanisms' DESC list of ACL mechanisms supported by this directory server SYNTAX LDAPOID ) Two ACL mechanisms are defined by this document: LDAPv3 X500 Other vendor ACL mechanisms can be defined (by OID) and are the responsibility of those vendors to provide the definition and OID. Blakley, Byrne, Stokes [Page 7] Internet-Draft ACL Model 18 November 1998 4.1.2 Subschema Attribute for ACL Mechanism A given naming context must provide information about which ACL mechanism is in effect for that portion of the namespace. The following attribute must be in each subschema entry associated with a naming context whose ACL mechanism is different from adjacent naming contexts supported by that directory server. - aclMechanism lists the value (an OID) that defines the ACL mechanism in effect for the scope of that subschema entry 4.2 Other Defined Parameters/OIDs 4.2.1 Rights Families and Rights The following rights families are defined: LDAPv3 X500 Other parties can (and will) define other rights families. It is the responsibility of those parties to provide the definition and OID. 4.2.1.1 LDAPv3 Rights Family 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 Rights that apply to an entire object are: 16 Add Add an object below this object 32 Delete Delete this object Blakley, Byrne, Stokes [Page 8] Internet-Draft ACL Model 18 November 1998 Rights that apply to the object to which the directory object points are: 64 Manage Perform a privileged operation; used to restrict access to operations which read or write especially sensitive data 128 Use Execute; useful in controlling access to the objects referred to by directory entries than in controlling access to the directory entries themselves 256 Get Get retrieves the attribute values 512 Set Set writes the attribute values 4.2.1.2 The X.500 Rights Family 4.2.2 DN Types The following DN Types are defined: - access-id, OID= - group, OID= - role, OID= access-id and group MUST be supported; role SHOULD be supported. Other parties can (and will) define other DN Types. It is the responsibility of those parties to provide the definition and OID. 5. Access Control Parameters for LDAP Controls & Extended Operations This section defines the parameters used in the access control LDAP controls and extended operations in this document. targetDN specifies the initial direcctory entry in DN syntax on which the control or extended operation is performed. Blakley, Byrne, Stokes [Page 9] Internet-Draft ACL Model 18 November 1998 whichObject specifies whether the ACL which is get/set is for the directory entry (ENTRY) or the 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. 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. Four operations are defined: - ACL_GRANT grants the rights specified in the rightsList for the given subject. If an access control list does not exist for the specified entry/attribute, then the access control list is created with the granted rights for the given subject. If the access control list already exists for the specified entry/attribute, then the access control list is modified to grant the rights for the given subject. - ACL_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. - ACL_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. Blakley, Byrne, Stokes [Page 10] Internet-Draft ACL Model 18 November 1998 - ACL_DELETE deletes the entire access control list for the specified entry/attribute. attrs specifies the list of attributes against which the operation is performed. attrs can be defined using a LDAP filter expression. 6. ACL Controls The ACL 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: - updateAccessControl to manipulate access control information during ldap_add and ldap_modify operations - getEffectiveAccess to obtain the effective rights for a given directory entry(s) for a given subject during a ldap_search operation - listSubjectRights to get the access control information for a given directory entry(s) during a ldap_search operation 6.1 updateAccessControl 6.1.1 Request Control This control is included in the ldap_add and ldap_modify 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: Blakley, Byrne, Stokes [Page 11] Internet-Draft ACL Model 18 November 1998 updateAccessControlRequest ::= SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { rightsFamily LDAPOID, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID, subjectDN LDAPString, perms SEQUENCE OF SEQUENCE { operation ENUMERATED { ACCESS_GRANT (1), ACCESS_DENY (2), ACCESS_REPLACE (4), ACCESS_DELETE (8) }, rightsList ENUMERATED, attrs LDAPSTRING } } } The targetDN specifies the initial directory entry in DN syntax on which the updateAccessControl control is performed. updates 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 updated. The rightsList can be set (per the specified operation) on one or more attributes (defined by a LDAPString using LDAP filters to define which attributes) for a given rightsFamily, dnType, and subjectDN. 6.1.2 Response Control This control is included in the ldap_add and ldap_modify 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: Blakley, Byrne, Stokes [Page 12] Internet-Draft ACL Model 18 November 1998 updateAccessControlResponse ::= { result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), unavailable (52), unwillingToPerform (53), other (80) } } 6.1.3 Client-Server Interaction The updateAccessControlRequest control specifies that for the given target, a scope and a set of rights are updated. The server that consumes the add or modify operation can also set the ACL information for those directory entry(s). There are six possible scenarios that may occur as a result of the updateAccessControl control being included on the add or modify 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 addResponse or modifyResponse message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified rightsFamily and the client specified TRUE for the Blakley, Byrne, Stokes [Page 13] Internet-Draft ACL Model 18 November 1998 control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the addResult or modifyResult message and include the updateAccessControlResponse control in the addResult or modifyResult 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 updated for that family' and include the result Unavilable in the updateAccessControlResponse control in the addResult or modifyResult message. 5. If the server supports this control and can set the rights per the rightsFamily information, then it should include the updateAccessControlResponse control in the addResult or modifyResult message with a result of success. 6. If the add/modify request failed for any other reason, then the server SHOULD omit the updateAccessControlResponse control from the addResult or modifyResult message. The client application is assured that the correct rights are set if and only if the result code in the updateAccessControlResponse control is success. If the server omits the updateAccessControlResponse control from the addResult or modifyResult message, the client SHOULD assume that the control was ignored by the server. The updateAccessControlResponse control, if included by the server in the addResponse or modifyResponse message, should have the result set to either success if the rights were updated or set to the appropriate error code as to why the rights could not be updated. The server may not be able to remove a right because it may not exist in that target object's attribute; in this case, the remove request for that right is ignored with success. Blakley, Byrne, Stokes [Page 14] Internet-Draft ACL Model 18 November 1998 6.2 getEffectiveRights Control 6.2.1 Request Control This control is included in the ldap_search message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. 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, request 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. The scope of the operation is controlled by the scope set in the ldap_search operation. 6.2.2 Response Control This control is included in the ldap_search message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. Blakley, Byrne, Stokes [Page 15] Internet-Draft ACL Model 18 November 1998 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: getEffectiveRightsResponse ::= { result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), unavailable (52), unwillingToPerform (53), other (80) } } The effective rights returned are returned with each attribute returned by the search result. So, the result for ldap_search is: SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } PartialAttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue, rightFamily LDAPOID, rightsList ENUMERATED, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) } } 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 Blakley, Byrne, Stokes [Page 16] Internet-Draft ACL Model 18 November 1998 data. 6.2.3 Client-Server Interaction The getEffectiveRightsRequest control requests the rights that MUST be in effect for requested directory entry/attribute based on the subject DN. The server that consumes the search operation looks up the rights for the returned directory information based on the subject DN and returns that rights information. There are six possible scenarios that may occur as a result of the getEffectiveRights control being included on the bind request: 1. If the server does not support this control and the client specified TRUE for the control's criticality field, then the server MUST return unavailableCriticalExtension as a return code in the searchResponse message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified 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. 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 Blakley, Byrne, Stokes [Page 17] Internet-Draft ACL Model 18 November 1998 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. 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. 6.3 listSubjectRights Control 6.3.1 Request Control This control is included in the ldap_search message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. 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 Blakley, Byrne, Stokes [Page 18] Internet-Draft ACL Model 18 November 1998 encoding of a value of the following SEQUENCE: listSubjectRightsRequest ::= SEQUENCE { targetDN LDAPDN, request 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. A "*" in the dnType field indicates that all dnTypes are processed by this request. A "*" in the subjectDN field indicates that all subjectDNs are processed by this request. The scope of the operation is controlled by the scope set in the ldap_search operation. 6.3.2 Response Control This control is included in the ldap_search message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. 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: listSubjectRightsResponse ::= { result ENUMERATED { success (0), Blakley, Byrne, Stokes [Page 19] Internet-Draft ACL Model 18 November 1998 operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), unavailable (52), unwillingToPerform (53), other (80) } } The subjects' rights returned are returned with each attribute returned by the search result. So, the result for ldap_search is: SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } PartialAttributeList ::= SEQUENCE OF SEQUENCE { type AttributeDescription, vals SET OF AttributeValue, rightsFamily LDAPOID, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID, subjectDN LDAPString, rightsList ENUMERATED } 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. 6.3.3 Client-Server Interaction The listSubjectRightsRequest control specifies the rights that MUST be returned for the scope of the search. The server that consumes the search operation looks up the Blakley, Byrne, Stokes [Page 20] Internet-Draft ACL Model 18 November 1998 rights for the returned directory information and returns the result as search information associated with the scope of that search. There are six possible scenarios that may occur as a result of the listSubjectRights control being included on the bind request: 1. If the server does not support this control and the client specified TRUE for the control's criticality field, then the server MUST return unavailableCriticalExtension as a return code in the searchResponse message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified rightsFamily and the client specified TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the searchResult message and omit the listSubjectRightsResponse control in the searchResult message. 4. If the server supports this control but for some reason such as cannot process specified rightsFamily and the client specified FALSE for the control's criticality field, then the server should process as 'no rights returned for that family' and include the result Unavailable in the listSubjectRightsResponse control in the searchResult message. Blakley, Byrne, Stokes [Page 21] Internet-Draft ACL Model 18 November 1998 5. If the server supports this control and can return the rights per the rightsFamily information, then it should include the listSubjectRightsResponse control in the searchResult message with a result of success. 6. If the search request failed for any other reason, then the server SHOULD omit the listSubjectRightsResponse control from the searchResult message. The client application is assured that the correct rights are returned for the scope of the search operation if and only if the listSubjectRightsResponse control returns the rights. If the server omits the listSubjectRightsResponse control from the searchResponse message, the client SHOULD assume that the control was ignored by the server. The listSubjectRightsResponse control, if included by the server in the searchResponse message, should have the searchResult set to either success if the rights were returned or set to the appropriate error code as to why the rights could not be returned. 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. ACL Extended Operations Three 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 Update Access Operation to manipulate access control information - LDAP Get Effective Access to obtain the effective rights for a given directory entry for a given subject Blakley, Byrne, Stokes [Page 22] Internet-Draft ACL Model 18 November 1998 - LDAP List Subject Rights to get the access control information for a given directory entry 7.1 LDAP Update Access Operation ldapUpdateAccessRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] , requestValue [1] OCTET STRING } where requestValue ::= SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { rightsFamily LDAPOID, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID, subjectDN LDAPString, perms SEQUENCE OF SEQUENCE { operation ENUMERATED { ACCESS_GRANT (1), ACCESS_DENY (2), ACCESS_REPLACE (4), ACCESS_DELETE (8) }, rightsList ENUMERATED, attrs LDAPSTRING } } } 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 result code. ldapUpdateAccessResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] OPTIONAL, Blakley, Byrne, Stokes [Page 23] Internet-Draft ACL Model 18 November 1998 result [11] OCTET STRING OPTIONAL } where result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), unavailable (52), unwillingToPerform (53), other (80) } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 7.2 LDAP Get Effective Rights Operation ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] , requestValue [1] OCTET STRING OPTIONAL } where requestValue ::= SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { rightsFamily LDAPOID, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID, subjectDN LDAPString, } } The requestName is a dotted-decimal representation of the Blakley, Byrne, Stokes [Page 24] Internet-Draft ACL Model 18 November 1998 OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING. The server will respond to this with an LDAPMessage containing the ExtendedResponse which is a rights list. LDAPgetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] OPTIONAL, effectiveRights [11] OCTET STRING OPTIONAL } where effectiveRights ::= SEQUENCE OF SEQUENCE { rightsFamily LDAPOID, rightsList ENUMERATED, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, attrs LDAPSTRING } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 7.3 LDAP List Subject Rights ldapListSubjectRightsRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] , requestValue [1] OCTET STRING } where requestValue ::= SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { rightsFamily LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) Blakley, Byrne, Stokes [Page 25] Internet-Draft ACL Model 18 November 1998 }, dnType LDAPOID | "*", subjectDN LDAPString | "*", } } 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 result code. ldapListSubjectRightsResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] OPTIONAL, subjectRightsList [11] OCTET STRING OPTIONAL } where subjectRightsList ::= SEQUENCE OF SEQUENCE { rightsFamily LDAPOID, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType LDAPOID, subjectDN LDAPString, perms SEQUENCE OF SEQUENCE { rightsList ENUMERATED, attrs LDAPSTRING } } } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. Blakley, Byrne, Stokes [Page 26] Internet-Draft ACL Model 18 November 1998 8. 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). We consider five types of actions: - LDAP Access Control Policy Update actions: invocations of the LDAP Update Access Extended Operation or LDAP Update Access Control. - LDAP Access Control Policy Query operations: invocations of the LDAP Get Effective Access Extended Operation, LDAP Get Effective Access Control, LDAP List Subject Rights Extended Operation, or LDAP List Subject Rights Control. - 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. 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 Blakley, Byrne, Stokes [Page 27] Internet-Draft ACL Model 18 November 1998 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 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. Blakley, Byrne, Stokes [Page 28] Internet-Draft ACL Model 18 November 1998 - 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. - 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 Update, LDAP Query The result of the Query is not defined. Blakley, Byrne, Stokes [Page 29] Internet-Draft ACL Model 18 November 1998 - LDAP Update (Grant), Datastore Update, LDAP Query The result of the Query is not defined. - LDAP Update (Deny), Datastore Update, LDAP Query The result of the Query is not defined. - LDAP Update (Replace), Datastore Update, LDAP Access Request The result of the Access Request is not defined. - LDAP Update (Grant), Datastore Update, LDAP Access Request The result of the Access Request is not defined. - LDAP Update (Deny), Datastore Update, LDAP Access Request The result of the Access Request is not defined. 9. 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. 10. 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 Blakley, Byrne, Stokes [Page 30] Internet-Draft ACL Model 18 November 1998 [REQTS] Stokes, Byrne, Blakley, "Access Control Requirements for LDAP, INTERNET-DRAFT , February 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 Bob Blakley Ellen Stokes IBM IBM 11400 Burnet Rd 11400 Burnet Rd Austin, TX 78758 Austin, TX 78758 USA USA mail-to: blakley@us.ibm.com mail-to: stokes@austin.ibm.com phone: +1 512 838 8133 phone: +1 512 838 3725 fax: +1 512 838 8597 fax: +1 512 838 8597 Debbie Byrne IBM 11400 Burnet Rd Austin, TX 78758 USA mail-to: djbyrne@us.ibm.com phone: +1 512 838 1960 fax: +1 512 838 0156 Blakley, Byrne, Stokes [Page 31] Internet-Draft ACL Model 18 November 1998 Blakley, Byrne, Stokes [Page 32] CONTENTS 1. Introduction....................................... 2 2. Overview........................................... 2 2.1 Access Control Activity Lifecycle............. 3 2.2 Access Control Information Model.............. 3 2.3 Terminology................................... 5 3. LDIF Syntax for Access Control Information......... 7 4. ACL Schema......................................... 7 4.1 Attributes.................................... 7 4.1.1 Root DSE Attribute for ACL Mechanism 7 4.1.2 Subschema Attribute for ACL Mechanism 8 4.2 Other Defined Parameters/OIDs................. 8 4.2.1 Rights Families and Rights 8 4.2.2 DN Types 9 5. Access Control Parameters for LDAP Controls & Extended Operations................................ 9 6. ACL Controls....................................... 11 6.1 updateAccessControl........................... 11 6.1.1 Request Control 11 6.1.2 Response Control 12 6.1.3 Client-Server Interaction 13 6.2 getEffectiveRights Control.................... 15 6.2.1 Request Control 15 6.2.2 Response Control 15 6.2.3 Client-Server Interaction 17 6.3 listSubjectRights Control..................... 18 6.3.1 Request Control 18 6.3.2 Response Control 19 6.3.3 Client-Server Interaction 20 7. ACL Extended Operations............................ 22 7.1 LDAP Update Access Operation.................. 23 7.2 LDAP Get Effective Rights Operation........... 24 7.3 LDAP List Subject Rights...................... 25 - i - 8. Operational Semantics of Access Control Operations......................................... 27 9. Security Considerations............................ 30 10. References......................................... 30 - ii -