1 Internet-Draft E. Stokes
2 LDAP Extensions WG D. Byrne
3 Intended Category: Standards Track B. Blakley
4 Expires: 25 December 1999 IBM
7 Access Control Model for LDAP
8 <draft-ietf-ldapext-acl-model-03.txt>
12 This document is an Internet-Draft and is in full
13 conformance with all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet
16 Engineering Task Force (IETF), its areas, and its working
17 groups. Note that other groups may also distribute
18 working documents as Internet-Drafts. Internet-Drafts are
19 draft documents valid for a maximum of six months and may
20 be updated, replaced, or obsoleted by other documents at
21 any time. It is inappropriate to use Internet- Drafts as
22 reference material or to cite them other than as "work in
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt
28 The list of Internet-Draft Shadow Directories can be
29 accessed at http://www.ietf.org/shadow.html.
31 Comments and suggestions on this document are encouraged.
32 Comments on this document should be sent to the LDAPEXT
33 working group discussion list:
35 ietf-ldapext@netscape.com
38 Copyright (C) The Internet Society (1997). All Rights
43 This document describes the access control model for the
44 Lightweight Directory Application Protocol (LDAP)
45 directory service. It includes a description of the
49 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 1]
56 Internet-Draft Access Control Model 25 June 1999
60 model, the LDAP controls, and the extended operations to
61 the LDAP protocol. A separate document defines the
62 corresponding application programming interfaces (APIs).
63 RFC2219 [Bradner97] terminology is used.
69 The ability to securely access (replicate and distribute)
70 directory information throughout the network is necessary
71 for successful deployment. LDAP's acceptance as an
72 access protocol for directory information is driving the
73 need to provide an access control model definition for
74 LDAP directory content among servers within an enterprise
75 and the Internet. Currently LDAP does not define an
76 access control model, but is needed to ensure consistent
77 secure access across heterogeneous LDAP implementations.
78 The major objective is to provide a simple, but secure,
79 highly efficient access control model for LDAP while also
80 providing the appropriate flexibility to meet the needs
81 of both the Internet and enterprise environments and
82 policies. This document defines the model and the
83 protocol extensions (controls and extended operations).
84 A separate document defines the corresponding application
85 programming interfaces (APIs).
90 Access Control mechanisms evaluate requests for access to
91 protected resources and make decisions about whether
92 those requests should be granted or denied. In order to
93 make a grant/deny decision about a request for access to
94 a protected resource, an access control mechanism needs
95 to evaluate policy data. This policy data describes
96 security-relevant characteristics of the requesting
97 subject and the rules which govern the use of the target
100 This proposal defines the protocol elements for
101 transmission of this access control policy data in an
102 LDAP environment and an attribute that defines the access
103 control mechanism in effect for a given part of the LDAP
104 namespace. The instantiation of an access control model
108 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 2]
115 Internet-Draft Access Control Model 25 June 1999
119 at the directory server is not defined in this document.
120 By defining only what flows on the wire allows existing
121 access control mechanisms to be used at the directory
124 No mechanisms are defined in this document to control
125 access to access control information or for storage of
126 access control information at the server; this is vendor
129 A separate requirements document for access control
130 exists. The access control model used the requirements
131 documents as a guideline for the development of this
132 specification and are reflected in this specification to
133 the extent that the working group could agree on an
134 access control model.
136 The access control model defines
138 - A wire protocol for interoperability: The existing
139 LDAP protocol flows for add, delete, modify, etc are
140 used to manipulate access control information.
141 There are additional LDAP controls and extended
142 protocol operations defined to further help
143 management of access control information:
144 getEffectiveRights and specifyCredentials.
146 - A set of access control information (ACI) attributes
147 for application portability: These attributes are
148 used as input to the LDAP APIs so access control
149 information can be addressed uniformly independent
150 of how that information is addressed and stored at
151 the server. These same attributes appear in LDIF
152 output for interchange of access control
155 - A set of attributes to identity the access control
156 mechanisms supported by a server.
158 Encoding of access control information on the wire is per
159 the LDAPv3 specifications.
167 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 3]
174 Internet-Draft Access Control Model 25 June 1999
180 An "access control list" contains the access control
181 policy information controlling access to an object or
182 collection of objects. An access control list consists
183 of a set of access control list entries.
185 An "access control list entry" defines a single subject
186 security attribute's granted rights for the objects
187 governed by the access control list to which it belongs.
189 The "access control policy information" (acpi) for an
190 object or a collection of objects defines which subject
191 security attributes entitle a subject to which granted
192 rights. The access control policy information for an
193 object is stored in an access control list.
195 An "access decision" is a boolean-valued function which
196 answers the question: "can the subject with these subject
197 security attributes perform this operation on this
200 An "access decision function" is an algorithm which makes
201 an access decision based on subject security attributes,
202 access control policy information, an object identifier,
203 and an operation name (possibly augmented by additional
204 contextual information).
206 An "access decision function interface" is a programmatic
207 interface through which applications can request an
210 An "access identity" is an identity which is used by an
211 access decision function to make an access decision.
213 An "audit identity" is an identity which does not, in the
214 absence of additional information, enable a party
215 receiving and examining it to determine which subject it
218 A "credential" is a collection of subject security
221 "effective rights" are the complete set of rights a
222 subject is entitled to based on all access control lists
226 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 4]
233 Internet-Draft Access Control Model 25 June 1999
237 which apply to a specific object and based on all of the
238 subject's security attributes.
240 "granted rights" are the complete set of rights an access
241 control list entitles a subject to based on a specific
242 subject security attribute.
244 A "group" is a privilege attribute asserting a subject's
245 membership in the collection of subjects whose name is
248 An "identity" is a subject security attribute which is
249 unique to a single subject.
251 An "object" is the target of operations in an information
254 An "operation" is the result of executing the code
255 accessed through a named entry point in an information
258 An "operation name" is the name of the entry point
259 through which an operation is invoked in an information
262 A "privilege attribute" is a subject security attribute
263 which may be shared by several subjects.
265 "required rights" are the complete set of rights needed
266 to authorize a requester to perform a specific operation
267 on an object of a specific type.
269 A "right" is the basic unit of access control policy
270 administration. For each object type in an information
271 system, a security administrator defines a set of
272 required rights for each operation. For each object in
273 the system, a security administrator defines a set of
274 granted rights for each subject security attribute. When
275 an access decision is required, an access decision
276 function checks to make sure that the requester's subject
277 security attributes have been granted all required rights
278 needed to perform the requested operation on the
279 specified target object.
281 A "role" is a privilege attribute asserting a subject's
285 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 5]
292 Internet-Draft Access Control Model 25 June 1999
296 organizational position and entitlement to perform the
297 operations appropriate to that organizational position.
299 A "subject" is an entity which intiates actions in an
302 A "subject security attribute" is a defined property
303 which is used by a security policy evaluation system to
304 make policy decisions.
310 4.1 Access Control Activity Lifecycle
312 The access control proposal described in this draft
313 addresses four activities:
315 - Creation of subject security attribute information
316 and access control policy information
318 - Retrieval of subject security attribute information
319 at the time an access request is made
321 - Evaluation of access requests against policy,
322 resulting in an access decision
324 - Replication of access control policy information
325 from one server to another
327 4.2 Access Control Information Model
329 This document does not define formats for storage of
330 access control information; it does define the
331 operational semantics of access control operations.
344 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 6]
351 Internet-Draft Access Control Model 25 June 1999
355 The diagram below illustrates the componentry of an LDAP
356 system and the placement of the function specified in
368 | <-- LDAP Extended Access Control
370 | or Extended Access Control
373 +-----------------------------+
374 | LDAP Server (e.g. SLAPD) |
375 +-----------------------------+
381 +----------+ +-----------+
383 | Control |<.....| Datastore |
385 +----------+ +-----------+
387 LDAP clients use the controls and extended operations
388 specified in this document to administer access control
389 policy enforced by LDAP servers. Servers may store
390 access control information in any way they choose. In
391 particular, servers may use the access control mechanisms
392 of their datastores to store and enforce LDAP access
393 control, or they may implement access control managers
394 external to their datastores. Datastores and external
395 access control managers may implement any access control
396 rule syntax and semantics they choose, as long as the
397 semantics is compatible with that defined in the section
398 titled "Operational Semantics of Access Control
399 Operations" (found after the control and extended
403 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 7]
410 Internet-Draft Access Control Model 25 June 1999
414 operation definition).
416 The access control administration mechanisms specified in
417 this document are neutral with respect to policy
418 inheritance mechanisms, explicit vs. implicit denial,
421 4.3 Bind and Credentials
423 A bind authenticates a principal to the directory. A
424 principal is represented by a DN. A principal has a set
425 of credentials that are used for determining whether
426 access to resources specified in ldap operations. These
427 credentials may be pushed to the server by the client or
428 may be pulled by the server from the directory data.
429 Credentials may be local with respect to the server. If
430 not local (owned by another server or administrative
431 scope), then the server may decide to define a trust
432 model that states how to evaluate the trust of a
433 credential at bind time. The definition of such a trust
434 model is outside the scope of this document.
437 5. Access Control Information Schema
443 5.1.1 Root DSE Attribute for Access Control Mechanism
445 The following attribute may be included in the Root DSE.
447 (<OID to be assigned>
448 NAME 'supportedACIMechanisms'
449 DESC list of access control mechanisms supported
450 by this directory server
454 Two access control mechanisms are defined by this
456 LDAPv3 <OID to be assigned>
457 X500 <OID to be assigned>
462 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 8]
469 Internet-Draft Access Control Model 25 June 1999
473 Other vendor access control mechanisms can be defined (by
474 OID) and are the responsibility of those vendors to
475 provide the definition and OID.
477 5.1.2 Subschema Attribute for Access Control Mechanism
479 A given naming context must provide information about
480 which access control mechanism is in effect for that
481 portion of the namespace. The following attribute must
482 be in each subschema entry associated with a naming
483 context whose access control mechanism is different from
484 adjacent naming contexts supported by that directory
487 - aCIMechanism lists the value (an OID) that defines
488 the access control mechanism in effect for the scope
489 of that subschema entry
491 5.2 Other Defined Parameters/OIDs
494 5.2.1 Rights Families and Rights
496 The following rights families are defined:
497 LDAPv3 <OID to be assigned>
498 X500 <OID to be assigned>
500 Other parties can (and will) define other rights
501 families. It is the responsibility of those parties to
502 provide the definition and OID.
504 5.2.1.1 LDAPv3 Rights Family
506 Access rights can apply to an entire object or to
507 attributes of the object. Each of the LDAP access rights
508 are discrete. One permission does not imply another
509 permission. The rights may be ORed together to provide
510 the desired rights list.
512 Rights which apply to attributes are:
514 1 Read Read attribute values
515 2 Write Write attribute values
516 4 Search Search entries with specified attributes
517 8 Compare Compare attributes
521 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 9]
528 Internet-Draft Access Control Model 25 June 1999
532 Rights that apply to an entire object are:
534 16 Add Add an object below this object
535 32 Delete Delete this object
536 64 EditDN Edit an object's DN
538 Rights that apply to the object to which the directory
541 128 Manage Perform a privileged operation; used to
542 restrict access to operations which
543 read or write especially sensitive data
544 256 Use Execute; useful in controlling access to
545 the objects referred to by directory
546 entries than in controlling access to
547 the directory entries themselves
548 512 Get Get retrieves the attribute values
549 1024 Set Set writes the attribute values
551 5.2.1.2 The X.500 Rights Family
553 <define the rights for X.500>
557 The following DN Types are defined:
559 - access-id, OID=<OID to be assigned>
561 - group, OID=<OID to be assigned>
563 - role, OID=<OID to be assigned>
565 access-id, group, and role MUST be supported. An acess-
566 id is a non-collection (non-group and non-role objects)
567 DN that can be authenticated.
569 Other parties can (and will) define other DN Types. It
570 is the responsibility of those parties to provide the
580 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 10]
587 Internet-Draft Access Control Model 25 June 1999
591 6. Access Control Parameters for LDAP Controls & Extended
594 This section defines the parameters used in the access
595 control LDAP controls and extended operations in this
598 targetDN specifies the initial directory entry in DN
599 syntax on which the control or extended operation is
602 whichObject specifies whether the access control
603 information which is get/set is for the target directory
604 entry (ENTRY) or the target directory entry and its
607 rightsFamily specifies the family of rights that will be
608 get/set for the control or extended operation performed.
609 A rights family has a defined set of rights.
611 rightsList in the SearchResultEntry is of the form
612 specified in the LDIF BNF for <right>.
614 dnType speficies the type of subject security attribute.
615 Defined types are access-id, group, and role.
617 subjectDN is a LDAP string that defines the subject or
618 value of the dnType. The subjectDN may be a DN or
619 another string such as IPAddress (dotted-decimal string
620 representation) on which access control is get/set. If
621 the subject is an entry in the directory, then the syntax
622 of the LDAP string is DN. We define two well-known
623 subjectDNs, the strings
625 - public - meaning public access for all users
627 - this - meaning the user whose name matches the entry
630 Four operations are defined:
632 - ACI_GRANT grants the rights specified in the
633 rightsList for the given subject. If an access
634 control list does not exist for the specified
635 entry/attribute, then the access control list is
639 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 11]
646 Internet-Draft Access Control Model 25 June 1999
650 created with the granted rights for the given
651 subject. If the access control list already exists
652 for the specified entry/attribute, then the access
653 control list is modified to grant the rights for the
656 - ACI_DENY denies the rights specified in the
657 rightsList for the given subject. No implementation
658 is implied for this operation. For example, denial
659 of rights may be implemented as explicit denial
660 (negative rights) on the access control list or
661 removal of rights from the access control list.
663 - ACI_REPLACE replaces the entire access control list
664 for the specified entry/attribute. If an access
665 control list does not exist for the specified
666 entry/attribute, then the access control list is
667 created with the granted rights for the given
670 - ACI_DELETE deletes the entire access control list
671 for the specified entry/attribute.
673 attrs specifies the list of attributes against which the
674 operation is performed. attrs can be defined using a
675 LDAP filter expression.
678 7. Access Control Information (ACI) Controls
680 The access control information controls provide a way to
681 manipulate access control information in conjunction with
682 an LDAP operation such as ldap_add, ldap_modify, or
683 ldap_search. Three LDAP controls are defined for
684 transmission of access control information. These
685 controls allow access control information to be get/set
686 while manipulating other directory information. The
689 - getEffectiveRights to obtain the effective rights
690 for a given directory entry(s) for a given subject
691 during a ldap_search operation
693 - specifyCredentials to specify a set of credentials
694 for the bind identity (DN) during a ldap_bind
698 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 12]
705 Internet-Draft Access Control Model 25 June 1999
711 7.1 getEffectiveRights Control
714 7.1.1 Request Control
716 This control is included in the ldap_search message as
717 part of the controls field of the LDAPMessage, as
718 defined in Section 4.1.12 of [LDAPv3].
720 The controlType is set to <OID to be assigned>. The
721 criticality MAY be either TRUE or FALSE (where absent is
722 also equivalent to FALSE) at the client's option. The
723 controlValue is an OCTET STRING, whose value is the BER
724 encoding of a value of the following SEQUENCE:
726 getEffectiveRightsRequest ::= SEQUENCE {
728 effectiveRightsRequest SEQUENCE OF SEQUENCE {
729 rightsFamily LDAPOID | "*",
730 whichObject ENUMERATED {
734 dnType LDAPOID | "*",
735 subjectDN LDAPString,
739 The targetDN specifies the initial directory entry in DN
740 syntax on which the getEffectiveRights control is
741 performed. request is a set of sequences that state the
742 whichObject (entry or entry plus subtree) and specifics
743 of the control request to be performed. One or more
744 rightsFamily can be be obtained for a given subjectDN ad
745 dnType. A "*" in the rightsFamily field indicates that
746 the rights for all rights families defined for the
747 subjectDN / dnType are to be returned. This control is
748 applied to the scope set by the ldap_search operation,
749 i.e. base, one-level, subtree.
751 7.1.2 Response Control
753 This control is included in the ldap_search_response
757 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 13]
764 Internet-Draft Access Control Model 25 June 1999
768 message as part of the controls field of the LDAPMessage,
769 as defined in Section 4.1.12 of [LDAPv3].
771 The controlType is set to <OID to be assigned>. The
772 criticality MAY be either TRUE or FALSE (where absent is
773 also equivalent to FALSE). The controlValue is an OCTET
774 STRING, whose value is the BER encoding of a value of the
777 getEffectiveRightsResponse ::= {
781 unavailableCriticalExtension (12),
782 noSuchAttribute (16),
783 undefinedAttributeType (17),
784 invalidAttributeSyntax (21),
786 unwillingToPerform (53),
791 The effective rights returned are returned with each
792 entry returned by the search result. The control
793 response for ldap_search is:
795 PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
797 rightsList ENUMERATED,
798 whichObject ENUMERATED {
804 Although this extends the search operation, there are no
805 incompatibilities between versions. LDAPv2 cannot send a
806 control, hence the above structure cannot be returned to
807 a LDAPv2 client. A LDAPv3 client cannot send this
808 request to a LDAPv2 server. A LDAPv3 server not
809 supporting this control cannot return the additional
816 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 14]
823 Internet-Draft Access Control Model 25 June 1999
827 7.1.3 Client-Server Interaction
829 The getEffectiveRightsRequest control requests the rights
830 that MUST be in effect for requested directory
831 entry/attribute based on the subject DN. The server that
832 consumes the search operation looks up the rights for the
833 returned directory information based on the subject DN
834 and returns that rights information.
836 There are six possible scenarios that may occur as a
837 result of the getEffectiveRights control being included
838 on the search request:
841 1. If the server does not support this control and the
842 client specified TRUE for the control's criticality
843 field, then the server MUST return
844 unavailableCriticalExtension as a return code in
845 the searchResponse message and not send back any
846 other results. This behavior is specified in
847 section 4.1.12 of [LDAPv3].
849 2. If the server does not support this control and the
850 client specified FALSE for the control's
851 criticality field, then the server MUST ignore the
852 control and process the request as if it were not
853 present. This behavior is specified in section
856 3. If the server supports this control but for some
857 reason such as cannot process specified
858 rightsFamily and the client specified TRUE for the
859 control's criticality field, then the server SHOULD
860 do the following: return
861 unavailableCriticalExtension as a return code in
862 the searchResult message.
864 4. If the server supports this control but for some
865 reason such as cannot process specified
866 rightsFamily and the client specified FALSE for the
867 control's criticality field, then the server should
868 process as 'no rights returned for that family' and
869 include the result Unavailable in the
870 getEffectiveRightsResponse control in the
871 searchResult message.
875 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 15]
882 Internet-Draft Access Control Model 25 June 1999
886 5. If the server supports this control and can return
887 the rights per the rightsFamily information, then
888 it should include the getEffectiveRightsResponse
889 control in the searchResult message with a result
892 6. If the search request failed for any other reason,
893 then the server SHOULD omit the
894 getEffectiveRightsResponse control from the
895 searchResult message.
897 The client application is assured that the correct rights
898 are returned for scope of the search operation if and
899 only if the getEffectiveRightsResponse control returns
900 the rights. If the server omits the
901 getEffectiveRightsResponse control from the searchResult
902 message, the client SHOULD assume that the control was
903 ignored by the server.
905 The getEffectiveRightsResponse control, if included by
906 the server in the searchResponse message, should have the
907 getEffectiveRightsResult set to either success if the
908 rights are returned or set to the appropriate error code
909 as to why the rights could not be returned.
911 The server may not be able to return a right because it
912 may not exist in that directory object's attribute; in
913 this case, the rights request is ignored with success.
915 7.2 specifyCredentials Control
918 7.2.1 Request Control
920 This control is included in the ldap_bind message as
921 part of the controls field of the LDAPMessage, as
922 defined in Section 4.1.12 of [LDAPv3].
924 The controlType is set to <OID to be assigned>. The
925 criticality MAY be either TRUE or FALSE (where absent is
926 also equivalent to FALSE) at the client's option. The
927 controlValue is an OCTET STRING, whose value is the BER
928 encoding of a value of the following SEQUENCE:
930 specifyCredentialRequest ::= SEQUENCE {
934 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 16]
941 Internet-Draft Access Control Model 25 June 1999
945 credential LDAPString
949 The credential specifies the credential (e.g. groups,
950 roles, etc) that the client is requesting be associated
951 with the bind DN for access control determination in
952 subsequent ldap operations. This provides a 'push' model
953 for credentials where the client attempts to 'push' the
954 credential to the server. The server may process at bind
957 - server may unconditionally ignore
959 - server may unconditionally accept
961 - server may define trust model and evaluate of the
962 trust of each credential
964 If this control is not used, it is assumed that the
965 server determines (pulls) the credentials associated with
966 the bind DN when needed in subsequent ldap operations to
967 provide access control.
969 7.2.2 Response Control
971 This control is included in the ldap_bind message as part
972 of the controls field of the LDAPMessage, as defined in
973 Section 4.1.12 of [LDAPv3].
975 The controlType is set to <OID to be assigned>. The
976 criticality MAY be either TRUE or FALSE (where absent is
977 also equivalent to FALSE). The controlValue is an OCTET
978 STRING, whose value is the BER encoding of a value of the
981 specifyCredentialsResponse ::= {
985 unavailableCriticalExtension (12),
987 unwillingToPerform (53),
993 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 17]
1000 Internet-Draft Access Control Model 25 June 1999
1006 No data is returned; just the result is returned.
1008 Although this extends the bind operation, there are no
1009 incompatibilities between versions. LDAPv2 cannot send a
1010 control. A LDAPv3 client cannot send this request to a
1011 LDAPv2 server. A LDAPv3 server not supporting this
1012 control cannot return the additional data.
1014 7.2.3 Client-Server Interaction
1016 The specifyCredentialsRequest control specifies the
1017 credentials that the client wants the server to use for
1018 access control in subsequent ldap operations. The server
1019 that consumes the bind operation may unconditionally
1020 accept, ignore, or evaluate the trust of the specified
1021 credentials at bind time and returns only a success or
1022 failure response (no data returned).
1024 There are six possible scenarios that may occur as a
1025 result of the specifyCredential control being included on
1029 1. If the server does not support this control and the
1030 client specified TRUE for the control's criticality
1031 field, then the server MUST return
1032 unavailableCriticalExtension as a return code in
1033 the bindResponse message. This behavior is
1034 specified in section 4.1.12 of [LDAPv3].
1036 2. If the server does not support this control and the
1037 client specified FALSE for the control's
1038 criticality field, then the server MUST ignore the
1039 control and process the request as if it were not
1040 present. This behavior is specified in section
1043 3. If the server supports this control but for some
1044 reason such as cannot process specified credential
1045 (e.g. server decided to evaluate the trust of that
1046 credential and the result is the server not
1047 trusting all the credentials or unconditionally
1048 ignores the credential) and the client specified
1052 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 18]
1059 Internet-Draft Access Control Model 25 June 1999
1063 TRUE for the control's criticality field, then the
1064 server SHOULD do the following: return
1065 unavailableCriticalExtension as a return code in
1066 the bindResult message and omit the
1067 specifyCredentialResponse control in the bindResult
1070 4. If the server supports this control but for some
1071 reason such as cannot process specified credential
1072 (e.g. server decided to evaluate the trust of that
1073 credential and the result is the server not
1074 trusting all the credentials or unconditionally
1075 ignores the credential) and the client specified
1076 FALSE for the control's criticality field, then the
1077 server should process as 'credential ignored' and
1078 include the result Unavailable in the
1079 specifyCredentialResponse control in the bindResult
1082 5. If the server supports this control and evaulates
1083 the trust of that credential and the result is the
1084 server trusting all the credentials, then it should
1085 include the specifyCredentialResponse control in
1086 the bindResult message with a result of success.
1088 6. If the bind request failed for any other reason,
1089 then the server SHOULD omit the
1090 specifyCredentialResponse control from the
1093 The client application is assured that the correct
1094 credentials are used by the server when specified by the
1095 client for subsequent ldap operations if and only if the
1096 specifyCredentialResponse is successful. If the server
1097 omits the specifyCredentialResponse control from the
1098 bindResponse message, the client SHOULD assume that the
1099 control was ignored by the server.
1101 The specifyCredentialResponse control, if included by the
1102 server in the bindResponse message, should have the
1103 bindResult set to either success if the credentials were
1104 accepted by the server or set to the appropriate error
1105 code as to why the credentials were not accepted.
1111 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 19]
1118 Internet-Draft Access Control Model 25 June 1999
1122 8. Access Control Extended Operations
1124 Two extended operations (analogous to the controls) are
1125 defined for transmission of access control information.
1126 These operations help with the management of access
1127 control information independent of manipulating other
1128 directory information. The extended operations are:
1130 - LDAP Get Effective Rights to obtain the effective
1131 rights for a given directory entry for a given
1134 8.1 LDAP Get Effective Rights Operation
1136 ldapGetEffectiveRightsRequest ::= [APPLICATION 23]
1138 requestName [0] <OID to be assigned>,
1139 requestValue [1] OCTET STRING OPTIONAL }
1143 requestValue ::= SEQUENCE {
1145 updates SEQUENCE OF SEQUENCE {
1146 rightsFamily LDAPOID | "*",
1147 whichObject ENUMERATED {
1151 dnType LDAPOID | "*",
1152 subjectDN LDAPString,
1157 The requestName is a dotted-decimal representation of the
1158 OBJECT IDENTIFIER corresponding to the request. The
1159 requestValue is information in a form defined by that
1160 request, encapsulated inside an OCTET STRING.
1162 The server will respond to this with an LDAPMessage
1163 containing the ExtendedResponse which is a rights list.
1165 ldpGetEffectiveRightsResponse ::= [APPLICATION 24]
1170 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 20]
1177 Internet-Draft Access Control Model 25 June 1999
1181 COMPONENTS OF LDAPResult,
1182 responseName [10] <OID to be assigned> OPTIONAL,
1183 effectiveRights [11] OCTET STRING OPTIONAL }
1187 effectiveRights ::= SEQUENCE OF SEQUENCE {
1188 rightFamily LDAPOID,
1189 rightsList ENUMERATED,
1190 whichObject ENUMERATED {
1194 subjectDnType LDAPOID,
1195 subjectDN LDAPSTRING
1198 If the server does not recognize the request name, it
1199 MUST return only the response fields from LDAPResult,
1200 containing the protocolError result code.
1204 9. Access Control Information Attributes/LDIF
1206 The intent of the following attribute definitions is to
1207 design a common interchange format. Any given LDAP server
1208 should be able to translate the below defined attributes
1209 into a meaningful operation requests. Each server should be
1210 able to understand the attributes; there should not be any
1211 ambiguity into what any part of the syntax means.
1213 While the end goal is to have a common behavior model
1214 between different LDAP server implementations, the attribute
1215 definition alone will not ensure identical ACL processing
1216 behavior between servers. The semantics of how a server
1217 interprets the ACI syntax are not defined here. What 'deny'
1218 means on server1 might be different than on server2.
1219 Additionally, while the server must recognize and act on the
1220 attribute when received over the wire, there are no
1221 requirements for the server to actually implement this
1224 The attribute definition maintains an assumption that the
1225 receiving server supports inheritance within the security
1229 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 21]
1236 Internet-Draft Access Control Model 25 June 1999
1240 model. If the server does not support inheritance, the
1241 receiving server must expand any inherited information based
1247 There are three attributes which may be queried or set on
1248 all directory objects: aci, vendorAci and policyOwner. The
1249 syntax of these attributes is defined below.
1254 < aci > ::= < acl syntax >
1256 < vendorAci > ::= <oid> + '#' + < printable string >
1258 < acl syntax > ::= <familyOID> + '#' + <scope > + '#'
1259 + < rights > + '#' + < dnType >
1260 + '#' + < subjectDn >
1262 < policyOwner > ::= < familyOid > + '#' + <scope >
1263 + '#' +< dnType > + '#' + < subjectDn >
1265 < subjectDn > ::= < printable string >
1267 < familyOid > ::= < oid >
1269 <scope > ::= "entry" | "subtree" | <level>
1271 < level > ::= numericstring
1273 < dnType > ::= "access-id" | "role" | "group"
1275 < rights > ::= [ ] | [ < right > + [ '$'
1278 < right > ::= <action > + ';' + <permissions>
1281 < action > ::= "grant" | "deny"
1283 < permissions > ::= [ ] | [ < permission >
1284 + [ ',' + <permission> ] * ]
1288 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 22]
1295 Internet-Draft Access Control Model 25 June 1999
1299 < attrs > ::= [ < attributeString>
1300 + [ ',' + < attributeString > ] * ]
1302 < attributeString > ::= "[all]" | "[entry]"
1303 | <printableString >
1305 < permission > ::= "a" | "d" | "r" | "s" | "w" |
1306 "c" | "g" | "s" | "m" | "u" | "e"
1308 These are the permissions defined for the IETF family OID.
1309 "a" corresponds to add
1310 "d" corresponds to delete
1311 "r" corresponds to read
1312 "w" corresponds to write
1313 "c" corresponds to compare
1314 "g" corresponds to get
1315 "s" corresponds to set
1316 "m" corresponds to manage
1317 "u" corresponds to use
1318 "e" corresponds to editDn
1323 ( vendorAciOID NAME 'vendorACI' DESC 'Vendor specific
1324 Access control information' EQUALITY caseIgnoreMatch SYNTAX
1327 The Vendor specific ACI information is listed in its own
1328 attribute. This may be used by vendors to provide vendor
1329 specific access control related information which can not be
1330 expressed in defined ACISyntax. Within the vendorACI, the
1331 oid determines the format or the printable string to follow.
1336 ( policySyntaxOID DESC 'PolicyOwner Syntax' ) (
1337 policyOwnerOID NAME 'policyOwner' DESC 'Policy Owner Access
1338 Control Information' EQUALITY caseIgnoreMatch SYNTAX
1341 Policy ownership controls administrative subdomains. It can
1342 also control who has permission to set / change acls for
1343 implementations that do not have ACI controlling access to
1347 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 23]
1354 Internet-Draft Access Control Model 25 June 1999
1358 itself. If there are multiple policy owners it is
1359 implementation specific as to the behavior of whether policy
1360 owner #1 can override policy owner # 2.
1362 The syntax for policyOwner includes the 'scope' flag.
1363 Servers which do not support inheritance must expand the
1364 policyOwner inheritance similar to the expansion of the ACI.
1365 The scope and any inheritance hierarchy for policy ownership
1366 is distinct from any inheritance hierarchy defined for ACI
1369 If the policy owner is not specified for any object in the
1370 tree, behavior is implementation defined. For instance, if
1371 no object anywhere in the tree has a policy owner, then the
1372 server could simply assert that the 'root DN' is considered
1373 the policy owner for all objects. An alternate approach
1374 might be that the implementation defines the entryDN to be
1380 ( aciSyntaxOID DESC 'ACI Syntax' )
1381 ( aciOID NAME 'aci' DESC 'Access control information'
1382 EQUALITY caseIgnoreMatch SYNTAX aciSyntaxOID )
1384 Within the access control syntax, the family OID describes
1385 the permissions, dnType, subjectDn and scope that will be
1386 found in the following string. If the OID within the ACI
1387 attribute is listed as other than the IETF family oid, the
1388 syntax is the same as listed below, but one or more of the
1389 scope, dnType, subjectDn or permissions may vary from the
1390 IETF defined syntax.
1392 Within the access control syntax, there is a string which
1393 describes the rights. This is a composite of the permissions
1394 and resources to which the user is being granted or denied
1395 access. The set of permissions is fixed. Either of the
1396 actions "grant" | "deny" may be used when creating or
1399 The attributeString is an attribute Name (defined to be a
1400 printable string). If the string refers to an attribute not
1401 defined in the given server's schema, the server SHOULD
1402 report an error. Another option for the attributeString is
1406 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 24]
1413 Internet-Draft Access Control Model 25 June 1999
1417 "[entry]". This is provided to describe permissions which
1418 apply to an entire object. This could mean actions such as
1419 delete the object, or add a child object. The third option
1420 for attributeString is "[all]" which means the permission
1421 set should apply to all attributes.
1423 If the keyword "[all]" and another attribute are both
1424 specified within an aci, the more specific permission set
1425 for the attribute overrides the less specific permission set
1428 If two ACIs contain identical familyOID, scope, DnTypes and
1429 DNs, the permission given DN is specified in two distinct
1430 acis on any given entry, the rights lists can be combined
1431 into one list. For example,
1433 aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1434 aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1436 is the equivalent of
1438 aci: 1.2.3.4#subtree#grant;r,w;[all];
1439 r,attribute1#group#cn=Dept XYZ
1441 Using the defined BNF it is possible for the permission
1442 string to be empty. The ACI
1444 aci: 1.2.3.4#subtree#grant;;attribute1$grant;r,s;
1445 [all]#group#cn=Dept XYZ,c=US
1447 means that this group is granted permission to read and
1448 search all attributes except attribute1.
1452 aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US
1454 simply means that no permissions have been defined for this
1455 group. It is up to the server implementation as to whether
1456 the group does or does not receive permission to attributes
1457 on an entry with an empty rights list.
1459 Multiple attributeStrings can be listed after any given
1460 permission set; for instance, "r,w ; attribute1,
1461 attribute2". This means that if the server supports a
1465 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 25]
1472 Internet-Draft Access Control Model 25 June 1999
1476 attribute aggregation mechanism, attribute1 and attribute2
1477 should be considered to be part of the same group. If the
1478 server does not support a grouping mechanism, the permission
1479 set applies independently to attribute1 and attribute2. For
1480 servers that do not support attribute grouping, "grant ; r,w
1481 ; attribute1, attribute2" results in the same operations as
1482 "grant ; r,w; attribute1$grant; r,w; attribute2"
1485 9.1.5 LDAP Operations
1487 The attributes which are defined for access control
1488 interchange may be used in all LDAP operations.
1490 Within the ldapmodify-delete operation, the entire acl may
1491 be deleted by specifying
1497 In this case, the entry would then inherit its ACI from some
1498 other node in the tree depending on the server inheritance
1501 Deleting the last ACI value from an entry is not the same as
1502 deleting the ACI from the entry. It is possible for an entry
1503 to contain an ACI with no values. In this case, nothing is
1504 returned to the client when querying the aci. It is server
1505 dependent whether access is granted or denied in the absence
1506 of any ACI information. Deleting an ACI value which does
1507 not exist will result in an unchanged ACI and a return code
1508 specifying that the attribute value does not exist.
1514 9.2.1 Attribute Definition
1516 Pretend IETFFamilyOID = 1.2.3.4
1518 The following two examples show an administrative
1519 subdomain being established. The first example shows a
1520 single user being assigned the policyOwner for the entire
1524 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 26]
1531 Internet-Draft Access Control Model 25 June 1999
1535 domain. The second example shows a group of ids assigned
1536 to the policy Owner.
1538 policyOwner: 1.2.3.4#subtree#access-id#cn=Hoyt
1540 policyOwner: 1.2.3.4#subtree#group#cn=System Owners,
1543 The next example shows an aci attribute where a group
1544 "cn=Dept XYZ, c=US" is being given permissions to read,
1545 search and compare attribute1. The permission should
1546 apply to the entire subtree below the node containing
1549 aci:1.2.3.4#subtree#grant;r,s,c;
1550 attribute1#group#cn=Dept XYZ,c=US
1552 The next example shows an ACI attribute where a role
1553 "cn=SysAdmins,o=Company" is being given permissions to
1554 add objects below this node, and read, search and compare
1555 attributes 2 and 3. The permission should apply to the
1556 entire subtree below the node containing this ACI.
1558 aci: 1.2.3.4#subtree#grant;a;[entry]$grant;
1559 r,s,c;attribute2, attribute3#role#
1560 cn=SysAdmins,o=Company
1563 9.2.2 Modifying the ACI Values
1565 Replace works similarly to all other attributes. If the
1566 attribute value does not exist, create the value. If the
1567 attribute does exist, replace the value. If the ACI value
1568 is replaced, all ACI values are replaced.
1570 A given aci for an entry:
1572 aci: 1.2.3.4#subtree#deny;r,w;[all]$grant;r,s,c;
1573 attribute2#group#cn=Dept ABC
1575 aci: 1.2.3.4#subtree#grant;r;[all]$grant;r,s,c;
1576 attribute1#group#cn=Dept XYZ
1578 perform the following change:
1583 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 27]
1590 Internet-Draft Access Control Model 25 June 1999
1597 aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
1599 The resulting acl is:
1601 aci: 1.2.3.4#subtree#grant;r,w;[all];#group#cn=Dept LMN
1603 ( aci values for Dept XYZ and ABC are lost through the
1606 During an ldapmodify-add, if the ACI does not exist, the
1607 create the ACI with the specific aci value(s). If the ACI
1608 does exist, then add the specified values to the given ACI.
1609 For example a given ACI:
1611 aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1613 with a modification:
1618 aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1620 would yield an multi-valued aci of:
1622 aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1623 aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1624 To delete a particular aci value, use the regular ldapmodify
1629 aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1630 aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1635 aci: 1.2.3.4#subtree#grant;r;attribute1#group#cn=Dept XYZ
1637 would yield a remaining ACI on the server of
1642 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 28]
1649 Internet-Draft Access Control Model 25 June 1999
1653 aci: 1.2.3.4#subtree#grant;r,w;[all]#group#cn=Dept XYZ
1657 10. Security Considerations
1659 This draft proposes protocol elements for transmission of
1660 security policy information. Security considerations are
1661 discussed throughout this draft. Because subject
1662 security attribute information is used to evaluate
1663 decision requests, it is security-sensitive information
1664 and must be protected against unauthorized modification
1665 whenever it is stored or transmitted.
1671 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight
1672 Directory Access Protocol (v3)", RFC 2251, December 1997.
1674 [ECMA] ECMA, "Security in Open Systems: A Security
1675 Framework" ECMA TR/46, July 1988
1677 [REQTS] Stokes, Byrne, Blakley, "Access Control
1678 Requirements for LDAP, INTERNET-DRAFT <draft-ietf-
1679 ldapext-acl-reqts-01.txt>, August 1998.
1681 [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille,
1682 "Lightweight Directory Access Protocol (v3)": Attribute
1683 Syntax Definitions, RFC 2252, December 1997.
1685 [UTF] M. Wahl, S. Kille, "Lightweight Directory Access
1686 Protocol (v3)": A UTF-8 String Representation of
1687 Distinguished Names", RFC 2253, December 1997.
1689 [Bradner97] Bradner, Scott, "Key Words for use in RFCs to
1690 Indicate Requirement Levels", RFC 2119.
1695 Ellen Stokes Bob Blakley
1697 11400 Burnet Rd 5515 Balcones Drive
1701 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 29]
1708 Internet-Draft Access Control Model 25 June 1999
1712 Austin, TX 78758 Austin, TX 78731
1714 mail-to: stokes@austin.ibm.com mail-to: blakley@dascom.com
1715 phone: +1 512 838 3725 phone: +1 512 458 4037 ext 5012
1716 fax: +1 512 838 8597 fax: +1 512 458 237
1724 mail-to: djbyrne@us.ibm.com
1725 phone: +1 512 838 1960
1726 fax: +1 512 838 8597
1760 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 30]
1767 Internet-Draft Access Control Model 25 June 1999
1819 Stokes, Byrne, Blakley Expires 25 December 1999 [Page 31]
1833 1. Introduction....................................... 2
1835 2. Overview........................................... 2
1837 3. Terminology........................................ 4
1839 4. The Model.......................................... 6
1840 4.1 Access Control Activity Lifecycle............. 6
1841 4.2 Access Control Information Model.............. 6
1842 4.3 Bind and Credentials.......................... 8
1844 5. Access Control Information Schema.................. 8
1845 5.1 Attributes.................................... 8
1846 5.1.1 Root DSE Attribute for Access Control
1848 5.1.2 Subschema Attribute for Access Control
1850 5.2 Other Defined Parameters/OIDs................. 9
1851 5.2.1 Rights Families and Rights 9
1854 6. Access Control Parameters for LDAP Controls &
1855 Extended Operations................................ 11
1857 7. Access Control Information (ACI) Controls.......... 12
1858 7.1 getEffectiveRights Control.................... 13
1859 7.1.1 Request Control 13
1860 7.1.2 Response Control 13
1861 7.1.3 Client-Server Interaction 15
1862 7.2 specifyCredentials Control.................... 16
1863 7.2.1 Request Control 16
1864 7.2.2 Response Control 17
1865 7.2.3 Client-Server Interaction 18
1867 8. Access Control Extended Operations................. 20
1868 8.1 LDAP Get Effective Rights Operation........... 20
1870 10. Security Considerations............................ 29
1872 11. References......................................... 29
1890 Full Copyright Statement
1892 Copyright (C) The Internet Society (1999).á All Rights
1895 This document and translations of it may be copied and
1896 furnished to others, and derivative works that comment on or
1897 otherwise explain it or assist in its implementation may be
1898 prepared, copied, published and distributed, in whole or in
1899 part, without restriction of any kind, provided that the
1900 above copyright notice and this paragraph are included on
1901 all such copies and derivative works.á However, this
1902 document itself may not be modified in any way, such as by
1903 removing the copyright notice or references to the Internet
1904 Society or other Internet organizations, except as needed
1905 for the purpose of developing Internet standards in which
1906 case the procedures for copyrights defined in the Internet
1907 Standards process must be followed, or as required to
1908 translate it into languages other than English.
1910 The limited permissions granted above are perpetual and will
1911 not be revoked by the Internet Society or its successors or
1914 This document and the information contained herein is
1915 provided on an "AS IS" basis and THE INTERNET SOCIETY AND
1916 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
1917 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
1918 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1919 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1920 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.