1 2 3 4 5 6 7 8Internet-Draft E. Stokes 9LDAP Extensions WG B. Blakley 10Intended Category: Standards Track Tivoli Systems 11Expires: 14 January 2001 D. Rinkevich 12 IBM 13 R. Byrne 14 Sun Microsystems 15 14 July 2000 16 17 Access Control Model for LDAPv3 18 <draft-ietf-ldapext-acl-model-06.txt> 19 20STATUS OF THIS MEMO 21 22This document is an Internet-Draft and is in full 23conformance with all provisions of Section 10 of RFC2026. 24 25Internet-Drafts are working documents of the Internet 26Engineering Task Force (IETF), its areas, and its working 27groups. Note that other groups may also distribute working 28documents as Internet-Drafts. Internet-Drafts are draft 29documents valid for a maximum of six months and may be 30updated, replaced, or obsoleted by other documents at any 31time. It is inappropriate to use Internet-Drafts as 32reference material or to cite them other than as "work in 33progress." 34 35The list of current Internet-Drafts can be accessed at 36http://www.ietf.org/ietf/1id-abstracts.txt 37 38The list of Internet-Draft Shadow Directories can be 39accessed at http://www.ietf.org/shadow.html. 40 41Comments and suggestions on this document are encouraged. 42Comments on this document should be sent to the LDAPEXT 43working group discussion list: 44 45 ietf-ldapext@netscape.com 46 47COPYRIGHT NOTICE 48 49Copyright (C) The Internet Society (2000). All Rights 50Reserved. 51 52ABSTRACT 53 54This document describes the access control model for the 55Lightweight Directory Application Protocol V3 (LDAPv3) 56directory service. It includes a description of the model, 57the LDAP controls, and the extended operations to the LDAP 58protocol. The current LDAP APIs are sufficient for most 59 60 61 62Stokes, et al Expires 14 January 2001 [Page 1] 63 64 65 66 67 68Internet-Draft Access Control Model 14 July 2000 69 70 71 72access control operations. An API (in a separate document) 73is needed for the extended operation getEffectiveAccess. A 74separate requirements document for access control exists 75[REQTS]. The access control model used the requirements 76documents as a guideline for the development of this 77specification and are reflected in this specification to the 78extent that the working group could agree on an access 79control model. 80 81 82The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 83"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and 84"MAY" used in this document are to be interpreted as 85described in [Bradner97]. 86 87 88 891. Introduction 90 91The ability to securely access (replicate and distribute) 92directory information throughout the network is necessary 93for successful deployment. LDAP's acceptance as an access 94protocol for directory information is driving the need to 95provide an access control model definition for LDAP 96directory content among servers within an enterprise and the 97Internet. Currently LDAP does not define an access control 98model, but one is needed to ensure consistent secure access, 99replication, and management across heterogeneous LDAP 100implementations. The major objective is to provide a simple, 101usable, and implementable, but secure and efficient access 102control model for LDAP while also providing the appropriate 103flexibility to meet the needs of both the Internet and 104enterprise environments and policies. This document defines 105the model and the protocol extensions (controls and extended 106operations). 107 108This draft does not (and cannot) fully specify the behavior 109of the Access Control Model in a distributed environment 110(e.g. propagating access control information across servers 111and ACI administration) because there is no LDAP standard 112defining how to distribute directory data between LDAP 113servers. The behavior of the Access Control Model in 114distributed environments is beyond the scope of this draft. 115 116 117 1182. The LDAPv3 Access Control Model 119 120Access Control mechanisms evaluate requests for access to 121protected resources and make decisions about whether those 122requests should be granted or denied. In order to make a 123 124 125 126Stokes, et al Expires 14 January 2001 [Page 2] 127 128 129 130 131 132Internet-Draft Access Control Model 14 July 2000 133 134 135 136grant/deny decision about a request for access to a 137protected resource, an access control mechanism needs to 138evaluate policy data. This policy data describes security- 139relevant characteristics of the requesting subject and the 140rules which govern the use of the target object. 141 142No mechanism is defined in this document for storage of 143access control information at the server beyond indicating 144that the attribute holding access control information is an 145operational attribute. 146 147The access control mechanisms specified in this document are 148neutral with respect to policy inheritance mechanisms, 149explicit vs. implicit denial, and group nesting. 150 151The access control model defines 152 153 - What flows on the wire for interoperability 154 155 The existing LDAP protocol flows for ldap operations 156 are used to manipulate access control information. A 157 set of permissions and their semantics with respect to 158 ldap operations is defined. The permissions parallel 159 the types of ldap operations defined. What is 160 transmitted is exactly what is read back. Encoding of 161 access control information on the wire is per the 162 LDAPv3 specifications. 163 164 There is an additional LDAP control and extended 165 protocol operation defined, getEffectiveRights. LDAP 166 clients use the control and extended operation to 167 manage and administer access control policy enforced by 168 LDAP servers. 169 170 Servers may store access control information in any way 171 they choose. In particular, servers may use the access 172 control mechanisms of their datastores to store and 173 enforce LDAP access control, or they may implement 174 access control managers external to their datastores. 175 Datastores and external access control managers MAY 176 implement any access control rule syntax and semantics 177 they choose, but the semantics MUST be compatible with 178 those defined in the section titled "Operational 179 Semantics of Access Control Operations". 180 181 - Attributes and classes for application portability of 182 access control information 183 184 An access control information attribute (ldapACI) for 185 application portability: This attribute is used as 186 input to the LDAP APIs so access control information 187 188 189 190Stokes, et al Expires 14 January 2001 [Page 3] 191 192 193 194 195 196Internet-Draft Access Control Model 14 July 2000 197 198 199 200 can be addressed uniformly independent of how that 201 information is addressed and stored at the server. 202 This same attribute appears in LDIF output for 203 interchange of access control information. 204 205 An access control information subentry class 206 (ldapACISubEntry) and a set of attributes 207 (supportedAccessControlSchemes which is used in the 208 rootDSE and accessControlSchemes which is used in the 209 subentry ldapACISubEntry) to identity the access 210 control mechanisms supported by a server and in a given 211 part of the namespace, respectively. 212 213 - An attribute in the rootDSE, discloseOnError, to 214 control whether it is permissible for the server to 215 return the name of an entry or attribute in an error 216 (or empty set) operation result. This closes a hole on 217 the ability to discover information you are not 218 authorized to discover. 219 220 - A mechanism to control access to access control 221 information: The access control information attribute, 222 ldapACI, is used to control access to access control 223 information (controls access to itself). How to get an 224 initial ldapACI in the directory is server specific and 225 beyond the scope of this model. 226 227Servers can support multiple access control mechanisms, but 228MUST be capable of supporting the LDAP Mechanism in the DIT 229scoped by the rootDSE (entire server's DIT) for that server 230and SHOULD be capable of supporting the LDAP mechanism in an 231arbitrary part (subtree) of the DIT. 232 233The accessControlSchemes attribute in the ldapACISubEntry 234indicates which access control mechanism is in effect for 235the scope of that ldapACISubEntry. The 236supportedAccessControlSchemes attribute in the rootDSE 237indicates which acess control mechanisms are supported by 238the server; those mechanisms are in effect in that server's 239DIT unless overridden by a mechanism defined in a 240ldapACISubEntry elsewhere in that DIT. 241 242Changing the value(s) of either the 243supportedAccessControlSchemes or accessControlSchemes 244attributes changes the mechanism(s) in effect for the scope 245of those attributes (where scope is either that of the 246rootDSE or ldapACISubEntry). 247 248Through the use of the mechanism rootDSE attribute and 249ldapACI subentry, it is possible to run multiple mechanisms 250in either the same subtree or separate subtrees. If two 251 252 253 254Stokes, et al Expires 14 January 2001 [Page 4] 255 256 257 258 259 260Internet-Draft Access Control Model 14 July 2000 261 262 263 264mechanisms are run in the same subtree, it is desirable that 265the result be the same independent of mechanism, but 266definition and discussion of this is beyond the scope of 267this model. 268 269 270 2713. Access Control Mechanism Attributes 272 273Two attributes are defined to identify which access control 274mechanisms are supported by a given server and by a given 275subtree: supportedAccessControlSchemes and 276accessControlSchemes. (We chose these names based on the 277X.500 attribute, AccessControlScheme which is single-valued 278and defined in X.501). 279 280 2813.1 Root DSE Attribute for Access Control Mechanism 282 283The server advertises which access control mechanisms it 284supports by inclusion of the 'supportedAccessControlSchemes' 285attribute in the root DSE. This attribute is a list of 286OIDs, each of which identify an access control mechanism 287supported by the server. By default, these are also the 288mechanisms in effect in subtrees beneath the root in that 289server unless overridden by a ldapACISubEntry (see section 290"Subentry Class Access Control Mechanism"). 291 292 (<OID to be assigned> 293 NAME 'supportedAccessControlSchemes' 294 DESC list of access control mechanisms supported 295 by this directory server 296 SYNTAX LDAPOID 297 USAGE dSAOperation 298 ) 299 300The access control mechanism defined is: 301 LDAPv3 <OID to be assigned> 302 303Other vendor access control mechanisms MAY be defined (by 304OID) and are the responsibility of those vendors to provide 305the definition and OID. 306 307 3083.2 Root DSE Attribute for Control of Disclosing Errors 309 310The server specifies whether it is permissible for the name 311of an entry or attribute to be disclosed in an error (or 312empty) operation result. This rootDSE attribute is 313discloseOnError. The default for discloseOnError is false 314(0) or not to disclose on error. The lack of this attribute 315 316 317 318Stokes, et al Expires 14 January 2001 [Page 5] 319 320 321 322 323 324Internet-Draft Access Control Model 14 July 2000 325 326 327 328in the rootDSE is interpreted as the default. 329 330 (<OID to be assigned> 331 NAME 'discloseOnError' 332 DESC specify whether to return the name of an 333 entry or attribute in an error (or 334 empty) operation result; 0=do not 335 disclose (default); 1=disclose 336 SYNTAX LDAPString 337 USAGE dSAOperation 338 339 3403.3 Subentry Class Access Control Mechanism 341 342A given naming context MUST provide information about which 343access control mechanisms are in effect for that portion of 344the namespace. This information is contained in a subentry 345(ldapACISubEntry class), derived from [SUBENTRY]. 346ldapACISubEntry MAY be used to define the scope of an access 347control mechanism. The value(s) held in the rootDSE 348attribute, supportedAccessControlSchemes, are the mechanisms 349in effect in subtrees beneath the root in that server unless 350overridden in a ldapACISubEntry further down the tree held 351by that server. The scope of that ldapACISubEntry is to the 352end of the subtree held by that server or until another 353ldapACISubEntry is encountered in that subtree held by that 354server. The ldapACISubEntry class is defined as: 355 356 357 ( <OID to be assigned> 358 NAME 'ldapACISubEntry' 359 DESC 'LDAP ACI Subentry class' 360 SUP ldapSubEntry STRUCTURAL 361 MUST ( accessControlSchemes ) 362 ) 363 364The accessControlSchemes attribute MUST be in each ldap 365access control subentry entry associated with a naming 366context whose access control mechanism is different from 367adjacent naming contexts supported by that directory server. 368accessControlSchemes lists the values (list of OIDs) that 369define the access control mechanisms in effect for the scope 370of that ldap access control subentry. Although, in general, 371this attribute will define only a single mechanism (single 372value), more than one mechanism MAY be in effect for the 373scope of that subentry. 374 375 (<OID to be assigned> 376 NAME 'accessControlSchemes' 377 DESC list of access control mechanisms supported 378 in this subtree 379 380 381 382Stokes, et al Expires 14 January 2001 [Page 6] 383 384 385 386 387 388Internet-Draft Access Control Model 14 July 2000 389 390 391 392 SYNTAX LDAPOID 393 USAGE dSAOperation 394 ) 395 396 397 3984. The Access Control Information Attribute (ldapACI) 399 400The access control information attribute, ldapACI, is 401defined as: 402 403 (<OID to be assigned> 404 NAME 'ldapACI' 405 DESC 'ldap access control information' 406 EQUALITY caseIgnoreMatch 407 SYNTAX directoryString 408 USAGE directoryOperation 409 ) 410 411The intent of the attribute definition is to design a common 412interchange format. Any given LDAP server should be able to 413translate the below defined attribute into meaningful 414operation requests. Each server should be able to understand 415the attribute; there should not be any ambiguity into what 416any part of the syntax means. 417 418While the end goal is to have a common behavior model 419between different LDAP server implementations, the attribute 420definition alone will not ensure identical ACL processing 421behavior between servers. The semantics of how a server 422interprets the ACI syntax are defined in the "Operational 423Semantics of Access Control" section of this document. 424Additionally, while the server must recognize and act on the 425attribute when received over the wire, there are no 426requirements for the server to physically store this 427attribute. 428 429The attribute definition maintains an assumption that the 430receiving server supports inheritance within the security 431model. If the server does not support inheritance, the 432receiving server must expand any inherited information based 433on the scope flag. If the server does not support partial 434inheritance and both the entry and subtree scope are used, 435then entry is the prevailing scope. (It is possible for two 436values in the ldapACI attribute to have different scopes 437given the syntax of ldapACI; one might contain 'entry' and 438another might contain 'subtree'. This implies that some 439ldapACI values inherit down the DIT and othersdo not - hence 440partial inheritance of the ldapACI attribute.) 441 442The attribute is defined so access control information (ACI) 443 444 445 446Stokes, et al Expires 14 January 2001 [Page 7] 447 448 449 450 451 452Internet-Draft Access Control Model 14 July 2000 453 454 455 456can be addressed in a server independent of server 457implementation. This attribute is used in typical LDAP APIs 458and in LDIF output of ACI. This attribute may be queried or 459set on all directory objects. The BNF and definitions are 460given below. 461 462 4634.1 The BNF 464 465 4664.1.1 ACI String Representation 467 468 Values of this syntax are encoded according to the 469 following BNF which follows the BNF encoding 470 conventions described in [ABNF]: 471 472 ldapACI = scope "#" rights "#" attr "#" subject 473 474 scope = "entry" / "subtree" 475 476 rights = (("grant:" / "deny:") permissions) / 477 ("grant:" permissions ";deny:" permissions) 478 479 permissions = [permission *("," permission)] 480 481 permission = "a" / ; add 482 "d" / ; delete 483 "e" / ; export 484 "i" / ; import 485 "n" / ; renameDN 486 "b" / ; browseDN 487 "t" / ; returnDN 488 "r" / ; read 489 "s" / ; search 490 "w" / ; write (mod-add) 491 "o" / ; obliterate (mod-del) 492 "c" / ; compare 493 "m" / ; make 494 495 attr = "[all]" / "[entry]" / (attribute *("," attribute)) 496 497 attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38) 498 ; from [ATTR] 499 500 subject = ["authnLevel:" authnLevel ":"] 501 (("authzID-" authzID) / 502 ("role:" dn) / 503 ("group:" dn) / 504 ("subtree:" dn) / 505 ("ipAddress:" ipAddress) / 506 "public:" / 507 508 509 510Stokes, et al Expires 14 January 2001 [Page 8] 511 512 513 514 515 516Internet-Draft Access Control Model 14 July 2000 517 518 519 520 "this:") 521 522 authnLevel = "any" / 523 "simple" / 524 sasl 525 526 sasl = "sasl:" 527 ("any" / 528 mechanism) 529 530 mechanism = ; sasl mechanism from 4.2 of [LDAPv3] 531 532 authzID = ; authzID from [AuthMeth] repeated below 533 ; for convenience 534 535 authzId = dnAuthzId / uAuthzId 536 537 ; distinguished-name-based authz id. 538 dnAuthzId = "dn:" dn 539 540 dn = utf8string ; with syntax defined in [UTF] 541 542 ; unspecified userid, UTF-8 encoded. 543 uAuthzId = "u:" userid 544 userid = utf8string ; syntax unspecified 545 546 ipAddress = printableString 547 ; dotted decimal form (e.g. 10.0.0.6) 548 ; or use wildcards such as 12.3.45.* to 549 ; specify a specific subnetwork 550 ; or 123.45.6.*+255.255.255.115 to 551 ; specify a subnetmask 552 ; or use a wildcard domain name such as 553 ; *.airius.com to specify a specific 554 ; DNS domain 555 556 printableString ; printableString syntax from [ATTR] 557 558 559Note that the colon following the "public" and "this" 560subject options exist only to simplify string parsing. 561 562Note also that per [AuthMeth], authzID may be expanded in 563the future. 564 565See section titled 'ACI Examples' for examples of the string 566representation. 567 568 569 570 571 572 573 574Stokes, et al Expires 14 January 2001 [Page 9] 575 576 577 578 579 580Internet-Draft Access Control Model 14 July 2000 581 582 583 5844.1.2 ACI Binary Representation 585 586 The following ASN.1 data type is used to represent this 587 syntax when transferred in binary form: 588 589 ldapACI ::= SEQUENCE { 590 scope ENUMERATED { 591 entry (0), 592 subtree (1) }, 593 rights SEQUENCE OF CHOICE { 594 grant [0] Permissions, 595 deny [1] Permissions }, 596 attr CHOICE { 597 all [0] NULL, 598 entry [1] NULL, 599 attributes [2] SEQUENCE OF Attribute }, 600 subject SEQUENCE { 601 authnLevel CHOICE { 602 any [0] NULL, 603 simple [1] NULL, 604 sasl [2] CHOICE { 605 any [0] NULL, 606 mechanism [1] LDAPString -- from [LDAPv3] 607 } 608 }, 609 subject CHOICE { 610 dn [0] DN, 611 user [1] utf8String 612 role [1] DN, 613 group [2] DN, 614 subtree [3] DN, 615 ipAddress [4] IPAddress, 616 public [6] NULL, 617 this [7] NULL }, } -- may be expanded 618 per [AuthMeth] 619 620 Permissions ::= SEQUENCE OF ENUMERATED { 621 add (0), 622 delete (1), 623 export (2), 624 import (3), 625 renameDN (4), 626 browseDN (5), 627 returnDN (6), 628 read (7), 629 search (8), 630 write (9), 631 obliterate (10), 632 compare (11), 633 make (12) } 634 635 636 637 638Stokes, et al Expires 14 January 2001 [Page 10] 639 640 641 642 643 644Internet-Draft Access Control Model 14 July 2000 645 646 647 648 Attribute ::= AttributeType -- from [LDAPv3] 649 650 IPAddress ::= PrintableString -- (e.g. 10.0.0.6) 651 652 653 6544.2 The Components of ldapACI Attribute 655 656This section defines components that comprise the access 657control information attribute, ldapACI. 658 659 6604.2.1 Scope 661 662Two scopes for access control information are defined: 663 664 - entry - the access control information in the ldapACI 665 attribute applies only to the entry in which it is 666 contained 667 668 - subtree - the access control information in the ldapACI 669 attribute applies to each entry down the subtree unless 670 it is overridden by an entry-specific ldapACI whose 671 values are more specific. 672 673Use of prescriptive ACIs and scoping via use of a 674ldapACISubEntry is outside the scope of this document. 675 676 6774.2.2 Access Rights and Permissions 678 679Access rights can apply to an entire object or to attributes 680of the object. Access can be granted or denied. Either or 681both of the actions "grant" | "deny" may be used when 682creating or updating ldapACI. 683 684Each of the LDAP access permissions are discrete. One 685permission does not imply another permission. The 686permissions which apply to attributes and the entry parallel 687the type of ldap operations that can be performed. 688 689Permissions which apply to attributes: 690 691 r Read Read attribute values 692 w Write Modify-add values 693 o Obliterate Modify-delete values 694 s Search Search entries with specified attributes 695 c Compare Compare attributes 696 m Make Make attributes on a new entry below 697 this entry 698 699 700 701 702Stokes, et al Expires 14 January 2001 [Page 11] 703 704 705 706 707 708Internet-Draft Access Control Model 14 July 2000 709 710 711 712 1. r Read 713 714 If granted, permits attributes and values to be 715 returned in a read or search operation. 716 717 2. w Write 718 719 If granted, permits attributes and values to be added 720 in a modify operation. 721 722 3. o Obliterate 723 724 If granted, permits attributes and values to be 725 deleted in a modify operation. 726 727 4. s Search 728 729 If granted, permits attributes and values to be 730 included in a search operation. 731 732 5. c Compare 733 734 If granted, permites attributes and value to be used 735 in a compare operation. 736 737 6. m Make 738 739 The attribute permission "m" is required for all 740 attributes that are placed on an object when it is 741 created. Just as the "w" and "o" permissions are used 742 in the Modify operation, the "m" permission is used in 743 the Add operation. Additionally, note that "w" and "o" 744 have no bearing on the Add operation and "m" has no 745 bearing on the Modify operation. Since a new object 746 does not yet exist, the "a" and "m" permissions needed 747 to create it must be granted on the new object's 748 parent. This differs from "w" and "o" which must be 749 granted on the object being modified. The "m" 750 permission is distinct and separate from the "w" and 751 "o" permissions so that there is no conflict between 752 the permissions needed to add new children to an entry 753 and the permissions needed to modify existing children 754 of the same entry. 755 756Note: Modify-replace values of an attribute requires "w" 757and "o" permission. 758 759Permissions that apply to an entire entry: 760 761 762 a Add Add an entry below this entry 763 764 765 766Stokes, et al Expires 14 January 2001 [Page 12] 767 768 769 770 771 772Internet-Draft Access Control Model 14 July 2000 773 774 775 776 d Delete Delete this entry 777 e Export Export entry & subordinates to new 778 location 779 i Import Import entry & subordinates from some 780 location 781 n RenameDN Rename an entry's DN 782 b BrowseDN Browse an entry's DN 783 t ReturnDN Allows DN of entry to be disclosed in 784 an operation result 785 786 787 1. a Add 788 789 If granted, permits creation of an entry in the DIT 790 subject to control on all attributes and values to be 791 placed in the new entry at time of creation. In order 792 to add an entry, permission must also be granted to 793 add at least the mandatory attributes. 794 795 2. d Delete 796 797 If granted, permits the entry to be removed from the 798 DIT regardless of controls on attributes within the 799 entry. 800 801 3. e Export 802 803 If granted, permits an entry and its subordinates (if 804 any) to be exported; that is, removed from the current 805 location and placed in a new location subject to the 806 granting of suitable permission at the destination. 807 If the last RDN is changed, Rename is also required at 808 the current location. In order to export an entry or 809 its subordinates, there are no prerequisite 810 permissions to contained attributed, including the RDN 811 attributes; this is true even when the operation 812 causes new attribute values to be added or removed as 813 the result of the changes of RDN. 814 815 4. i Import 816 817 If granted, permits an entry and its suordinates (if 818 any) to be imported; that is, removed from some other 819 location and placed a t the location to which the 820 permission applies subject to the granting of suitable 821 permissions at the source location. In order to 822 import an entry or its subordinates, there are no 823 prerequisite permissions to contained attributed, 824 including the RDN attributes; this is true even when 825 the operation causes new attribute values to be added 826 or removed as the result of the changes of RDN. 827 828 829 830Stokes, et al Expires 14 January 2001 [Page 13] 831 832 833 834 835 836Internet-Draft Access Control Model 14 July 2000 837 838 839 840 5. n RenameDN 841 842 Granting Rename is necessary for an entry to be 843 renamed with a new RDN, taking into account 844 consequential changes to the distinguished names of 845 subordinate entries, if any; if the name of the 846 superior is unchanged, the grant is sufficient. In 847 order to rename an entry, there are no prerequisite 848 permissions to contained attributed, including the RDN 849 attributes; this is true even when the operation 850 causes new attribute values to be added or removed as 851 the result of the changes of RDN. 852 853 6. b BrowseDN 854 855 If granted, permits entries to be accessed using 856 directory operations which do not explicitly provide 857 the name of the entry. 858 859 7. t ReturnDN 860 861 If granted, allows the distinguished name of the entry 862 to be disclosed in the operation result. 863 864All permissions (for grant and deny) for an attribute/entry 865and a given subject MUST be contained within one ldapACI 866value, i.e. (in abbreviated form) 867 868 ldapACI: ...grant OID.attr1 subjectA 869 ldapACI: ...deny OID.attr1 subjectA 870 871must be ldapACI: ...grant ... deny... OID.attr1 subjectA 872 873Using the defined BNF it is possible for the permission 874string to be empty. The ACI 875 876 ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US 877 878 ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US 879 880means that this group (Dept XYZ) is granted permission to 881read and search all attributes except OID.attr1 because 882OID.attr1 is more specific than "[all]". 883 884 8854.2.3 Attributes 886 887Attribute describes an attribute name in the form of a 888dotted decimal OID for that <attr>. If the string (OID) 889refers to an attribute not defined in the given server's 890schema, the server SHOULD report an error. "[entry]" means 891 892 893 894Stokes, et al Expires 14 January 2001 [Page 14] 895 896 897 898 899 900Internet-Draft Access Control Model 14 July 2000 901 902 903 904the permissions apply to the entire object. This could mean 905actions such as delete the object, or add a child object. 906"[all]" means the permission set apply to all attributes of 907the entry. 908 909If the keyword "[all]" and another attribute are both 910specified within an ACI, the more specific permission set 911for the attribute overrides the less specific permission set 912for "[all]". 913 914 9154.2.4 Subjects and Associated Authentication 916 917The following subjects are defined and MUST be supported: 918 919 - authzID, defined per [authmeth] 920 921 - group, defined as the distinguished name of a 922 groupOfNames or groupOfUniqueNames entry 923 924 - role 925 926 - subtree, defined as the distinguished name of a non- 927 leaf node in the DIT 928 929 - ipAddress, 930 931 - public, defined as public access 932 933 - this, defined as the user whose name matches that of 934 the entry being accessed 935 936Other parties MAY define other subjects. It is the 937responsibility of those parties to provide the definition. 938 939A subject may be qualified by the type of authentication 940required for access to a given attribute(s) or entry. If no 941authnLevel is present, then no specific type of 942authentication is additionally required for access. If 943authnLevel is specified, then that type of authentication is 944additionally required for access. The authnLevels parallel 945the authentication mechanisms specified for LDAPv3: simple, 946SASL (any type of SASL mechanism), and a SASL-specific 947mechanism. The authnLevel of is not an acceptable mechanism 948for this case) as part of obtaining access. 949 950 9514.3 Grant/Deny Evaluation Rules 952 953The decision whether to grant or deny a client access to a 954particular piece of information is based on several pieces 955 956 957 958Stokes, et al Expires 14 January 2001 [Page 15] 959 960 961 962 963 964Internet-Draft Access Control Model 14 July 2000 965 966 967 968of information found within the ldapaci value. Throughout 969the decision making process, there are guiding principals. 970 971 - Specificity: More specific policies MUST override less 972 specific ones (e.g. individual user entry in ACI takes 973 precedence over group entry). 974 975 - Deny takes precedence over Grant. 976 977 - When there are conflicting ACI values, deny takes 978 precedence over grant. 979 980 - Deny is the default when there is no access control 981 information. 982 983Precendence of Scope Types (highest to lowest) 984 985 - entry 986 987 - subtree 988 989Precedence of Subjects within a Scope (highest to lowest): 990 991 - ipAddress 992 993 - authzID, this 994 995 - group, role, this, public 996 997 - subtree, public 998 999Although other types MAY be defined given the BNF, use of 1000the well-known types aids in interoperability and 1001operational consistency. 1002 1003Access Decision algorithm: 1004 1005 1. Determine all the ldapACI values which could apply to 1006 the target DN which is being accessed. This is the DN 1007 of the entry which is being queried in a search, 1008 modified, deleted, etc. When determining all the 1009 ldapACI values, the scope field should be used. All 1010 ldapACI values with a scope of 'entry' take precedence 1011 over ldapACI values with a scope of 'subtree'. 1012 1013 2. Determine which ldapACI (of the set determined in step 1014 1) apply to the bound DN. This is determined by 1015 looking at the subject (combination of subject type 1016 and subject value) and bind type. If no bind is in 1017 effect (this is possible in ldapv3), then treat this 1018 lack of bind as if bound as anonymous. Start with the 1019 1020 1021 1022Stokes, et al Expires 14 January 2001 [Page 16] 1023 1024 1025 1026 1027 1028Internet-Draft Access Control Model 14 July 2000 1029 1030 1031 1032 most specific subject type. If at any time, at least 1033 one ldapACI value exists for a specificity level, then 1034 processing stops; the exception here is 'this' because 1035 this may also be combined with group to use power of 1036 'this'. Evaluation should take place on set of 1037 ldapACI values which are all of the same specificity 1038 level. Subjects of the same precedence are combined 1039 using union semantics. 1040 1041 3. Evaluate the remaining ldapACI values and determine a 1042 grant/deny decision. If conflicting ldapACI value 1043 exists for the same attribute, or attributes (i.e. one 1044 ldapACI grants permission and another denies 1045 permission), then deny takes precedence over grant. 1046 For example, if one is granted permission to 1047 "objectclass" in one ldapACI value by being a member 1048 of group cn=Admin, and denied permission by being a 1049 member of cn = NontrustedAdmins, then the bound user 1050 would not receive permission to objectclass. 1051 1052 The rule of specificity also applies to the 1053 attributes. If one is denied permission to "[ all ]" 1054 attributes, but granted permission to "objectclass" 1055 then the more specific value of "objectclass" takes 1056 precedence over the less specific value of "[ all ] ". 1057 In this case the user would be granted permission to 1058 "objectclass" but denied permission to all other 1059 attributes. 1060 1061 1062 10635. Required Permissions for each LDAP Operation 1064 1065This section defines the required permissions for each LDAP 1066operation but even if these requirements are satisfied the 1067server MAY refuse to carry out the operation due to other 1068implementation specific security considerations. For 1069example, a server may refuse to modify an entry because the 1070database where that entry resides is in read only mode. 1071Another example might be that although the access control is 1072available to the userPassword attribute a server may refuse 1073modifications due to some server specific policy governing 1074access to passwords. 1075 1076Here, we specify the rights required by a user when 1077performing an LDAP operation in terms of the LDAP 1078permissions specified in section 6.1. Recall that "a, d, 1079e, i, n, b,t" are permissions that apply to entries as a 1080whole while permissions "r, s, w, o, c, m" apply to 1081attributes within entries. 1082 1083 1084 1085 1086Stokes, et al Expires 14 January 2001 [Page 17] 1087 1088 1089 1090 1091 1092Internet-Draft Access Control Model 14 July 2000 1093 1094 1095 1096Required permissions for LDAP extended operations and LDAP 1097controls are beyond the scope of this draft. 1098 1099There is a requirement that a user should not be able to 1100infer the existence of data in the Directory, if the user 1101does not have the required access rights to that data. An 1102example of this requirement would be in a hosting 1103environment where you would not want any users from the coke 1104subtree to be able to even discover that the pepsi tree was 1105hosted on the same server. This "discloseOnError" feature 1106will be set once for server in the rootDSE advertised by the 1107attribute discloseOnError. The default for discloseOnError 1108is false (0). The lack of this attribute in the rootDSE is 1109interpreted as the default. The details of its effects are 1110addressed below, operation by operation. 1111 1112For the following, assume that the authorization identity of 1113the user doing the operation is authzID. 1114 1115 11165.1 Bind Operation 1117 1118This draft does not require any permissions to allow a bind 1119operation to proceed. 1120 1121 11225.2 Search Operation 1123 1124Recall that the parameters of the Search operation per RFC 11252251 [LDAPv3] Section 4.5 are: 1126 1127 SearchRequest ::= [APPLICATION 3] SEQUENCE { 1128 baseObject LDAPDN, 1129 scope ENUMERATED { 1130 baseObject (0), 1131 singleLevel (1), 1132 wholeSubtree (2) }, 1133 derefAliases ENUMERATED { 1134 neverDerefAliases (0), 1135 derefInSearching (1), 1136 derefFindingBaseObj (2), 1137 derefAlways (3) }, 1138 sizeLimit INTEGER (0 .. maxInt), 1139 timeLimit INTEGER (0 .. maxInt), 1140 typesOnly BOOLEAN, 1141 filter Filter, 1142 attributes AttributeDescriptionList } 1143 1144Suppose a server is processing a search request from user 1145authzID with parameters as above and is processing the entry 1146with dn candidateDN to decide if it may be returned or not. 1147 1148 1149 1150Stokes, et al Expires 14 January 2001 [Page 18] 1151 1152 1153 1154 1155 1156Internet-Draft Access Control Model 14 July 2000 1157 1158 1159 1160Then the permissions required by authzID that need to be 1161evaluated are as follows: 1162 1163 1164 1. permission "b" to the entry candidateDN 1165 1166 If this permission is not granted then the dn 1167 candidateDN MUST not be returned nor any attribute 1168 type nor attribute value from this entry. 1169 1170 If this permission is granted then the dn candidateDN 1171 MAY be returned. 1172 1173 Note: The idea of the "b" permission is to say "a user 1174 has discovery rights" at a certain entry in the 1175 directory. Assuming that the further required 1176 permissions below are satisfied then having "b" right 1177 is enough to allow the server to return candidateDN. 1178 Of course candidateDN contains in it's components, 1179 attributes and attribute values for all the ancestors 1180 of candidateDN. This can lead to the slightly odd 1181 situation that we can discover the naming attribute of 1182 an entry and that attribute's value by virtue of 1183 having the required searching permissions to it's 1184 child but not by searching the entry directly. 1185 1186 2. permission "s" to each attribute appearing in a 1187 presence test during the evaluation of the search 1188 filter. permission "r" to each attribute appearing in 1189 non-presence tests (see rfc1960, section 3: 1190 equalityMatch, substrings, greaterOrEquial, 1191 lessOrEqual, present, approxMatch, extensibleMatch) 1192 during the evaluation of the search filter. 1193 1194 The above statement covers the case where the 1195 attributes are being evaluated as part of an 1196 extensibleMatch (RFC 2251 section 4.5.1) which appears 1197 in the filter. In the case where the dnAttributes 1198 field of the extensibleMatch is true then we do not 1199 require any access checks to the attributes of the dn 1200 candidateDN as access to these is taken to be granted 1201 by the "b" permission, which has already been required 1202 above. 1203 1204 If there is an attribute in a filter element to which 1205 the required permission is not granted then that 1206 filter element evaluates to "Undefined" of the three- 1207 valued-logic of X.511(93). 1208 1209 Note A: Although both "r" and "s" permissions will 1210 typically be granted to attributes we keep both 1211 1212 1213 1214Stokes, et al Expires 14 January 2001 [Page 19] 1215 1216 1217 1218 1219 1220Internet-Draft Access Control Model 14 July 2000 1221 1222 1223 1224 permissions as there are cases where the distinction 1225 is useful. For example, the ability to grant the 1226 right to discover that a user entry contains a 1227 userPassword attribute, but not to read it's value 1228 ("s" but not "r"). The converse, granting "r" but not 1229 "s" permission is less easy to motivate. 1230 1231 Note B: There is an unusual behaviour with respect to 1232 naming attributes illustrated in the following 1233 example: 1234 1235 Suppose I have "b" rights to cn=fred,o=sun.com and "r" 1236 rights to attribute objectclass but not "r" rights to 1237 cn then with search filter (objectclass=*) I get back 1238 the dn and objectclass (and so can see the value of 1239 cn), but with a search filter of (cn=fred) I do not 1240 get anything. 1241 1242 3. permission "r" to each attribute in the attribute list 1243 1244 AttributeDescriptionList (or all attributes in the 1245 entry candidateDN if AttributeDescriptionList is *) 1246 whose type and/or value will be returned. 1247 1248 Note: The presence of an attribute in an entry is only 1249 ever volunteered by the server if "r" permission is 1250 granted to it, though a user may infer the presence of 1251 an attribute with "s" permission by using a presence 1252 test on that attribute in the search filter. 1253 1254 4. permission "t" to the entry candidateDN 1255 1256 If this permission is not granted then the dn 1257 candidateDN MUST NOT be returned. If the server knows 1258 of an alias for the entry, this alias may be returned 1259 instead. If no alias name is available then the entry 1260 candidateDN MUST be omitted from the search results. 1261 1262 1263 5. Disclose on error for the Search operation 1264 1265 If every entry in the scope of the search fails to 1266 satisfy item 1 (browse right on the candidate entry) 1267 or item 2 (right to use the filter on that entry) and 1268 if discloseOnError is not granted to the baseObject 1269 entry then the operation MUST fail with a "no such 1270 object error" and the matchedDN of the LDAPResult MUST 1271 be set to "". If every entry in the scope of the 1272 search fails to satisfy items 1 or 2 above and 1273 discloseOnError is granted to the baseObject then the 1274 empty set of results is returned. 1275 1276 1277 1278Stokes, et al Expires 14 January 2001 [Page 20] 1279 1280 1281 1282 1283 1284Internet-Draft Access Control Model 14 July 2000 1285 1286 1287 12885.3 Modify Operation 1289 1290Recall that the parameters of the Modify operation per 1291RFC2251 [LDAPv3] Section 4.6 are: 1292 1293 ModifyRequest ::= [APPLICATION 6] SEQUENCE { 1294 object LDAPDN, 1295 modification SEQUENCE OF SEQUENCE { 1296 operation ENUMERATED { 1297 add (0), 1298 delete (1), 1299 replace (2) }, 1300 modification AttributeTypeAndValues } } 1301 1302 1303 AttributeTypeAndValues ::= SEQUENCE { 1304 type AttributeDescription, 1305 vals SET OF AttributeValue } 1306 1307Then the permissions required by authzID that need to be 1308evaluated are as follows: 1309 1310 1311 1. permission "w" to each attribute being added to object 1312 1313 If this permission is not granted to such an 1314 attribute, then the operation MUST fail. In this 1315 case, if discloseOnError is not granted to the entry 1316 then "no such object" error is returned; if 1317 discloseOnError is granted to the entry and a 1318 duplicate attribute value is being added then 1319 "attribute value already exists" error is returned; if 1320 discloseOnError is granted to the entry and no 1321 duplicate value is being added then an "insufficient 1322 access" error is returned. 1323 1324 2. permission "o" to each attribute for which a value is 1325 being deleted from object 1326 1327 If this permission is not granted to such an attribute 1328 then the operation MUST fail. In this case, if 1329 discloseOnError is not granted to the entry then "no 1330 such object" error is returned; if discloseOnError is 1331 granted to the entry and the attribute or one of the 1332 values to be deleted does not exist then a "no such 1333 attribute or value" error is returned; if 1334 discloseOnError is granted to the entry and the 1335 attribute and all values specified to be deleted exist 1336 then an "insufficient access" error is returned. 1337 1338 1339 1340 1341 1342Stokes, et al Expires 14 January 2001 [Page 21] 1343 1344 1345 1346 1347 1348Internet-Draft Access Control Model 14 July 2000 1349 1350 1351 1352 3. permissions "o" and "w" to each attribute being 1353 replaced in object 1354 1355 If one of these these permissions is not granted to 1356 such an attribute then the operation MUST fail. In 1357 this case, if discloseOnError is not granted to the 1358 entry then a "no such object" error is returned; if 1359 discloseOnError is granted to the entry then 1360 "insufficient access" error is returned. 1361 1362 13635.4 Add Operation 1364 1365Recall that the parameters of the Add operation per RFC2251 1366[LDAPv3] Section 4.7 are: 1367 1368 AddRequest ::= [APPLICATION 8] SEQUENCE { 1369 entry LDAPDN, 1370 attributes AttributeList } 1371 1372 1373 AttributeList ::= SEQUENCE OF SEQUENCE { 1374 type AttributeDescription, 1375 vals SET OF AttributeValue } 1376 1377Then the permissions required by authzID that need to be 1378evaluated are as follows: 1379 1380 permission "a" to the parent of entry 1381 1382 The access rights required for the creation of a root 1383 entry in the Directory are beyond the scope of this 1384 document. They will be vendor specific. 1385 1386 1. permission "m" to the parent of entry for each 1387 attribute being added to entry 1388 1389If any of these permissions are not granted then the 1390operation MUST fail. In this case if discloseOnError is on 1391and the entry to be added does not already exist then 1392"insufficient access" is returned. If it does exist then 1393"Entry already exists" is returned. If discloseOnError is 1394off then "No such object" is returned (meaning the parent 1395object). 1396 1397If they are all granted then the operation MAY proceed. 1398 1399Note: We require "m" permission to each attribute to prevent 1400an entry from aquiring "unintended" rights (via group or 1401role membership), to stop a "rogue" ACI being added that 1402would prevent even admins deleting the entry and general 1403 1404 1405 1406Stokes, et al Expires 14 January 2001 [Page 22] 1407 1408 1409 1410 1411 1412Internet-Draft Access Control Model 14 July 2000 1413 1414 1415 1416consistency with the MODIFY operation. 1417 1418Note: The access rights required for the creation of the 1419first entry in the directory are beyond the scope of this 1420document. 1421 1422 14235.5 Delete Operation 1424 1425Recall that the parameters of the Delete operation per 1426RFC2251 [LDAPv3] Section 4.10 are: 1427 1428 DelRequest ::= [APPLICATION 10] LDAPDN 1429 1430Then the permissions required by authzID that need to be 1431evaluated are as follows: 1432 1433 1434 1. permission "d" to the entry in the Delete request 1435 1436If this permission is not granted, then the operation MUST 1437fail. In this case if discloseOnError is on and the entry 1438to be deleted exists then "insufficient access" is returned. 1439If it does not exist then "No such Object" is returned. If 1440discloseOnError is off then "No such object" is returned 1441(meaning the parent object). 1442 1443If this permission is granted, then the operation MAY 1444proceed. 1445 1446Note: One could also require the "o" permission to be 1447granted to allow the operation to proceed, but customer 1448experience has shown that the requirement of the additional 1449permission is not useful nor expected, and X.500 requires 1450only the "d" permission. 1451 1452 14535.6 Modify DN Operation 1454 1455Recall that the parameters of the Modify DN operation per 1456RFC2251 [LDAPv3] Section 4.6 are: 1457 1458 ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { 1459 entry LDAPDN, 1460 newrdn RelativeLDAPDN, 1461 deleteoldrdn BOOLEAN, 1462 newSuperior [0] LDAPDN OPTIONAL } 1463 1464Then the permissions required by authzID that need to be 1465evaluated are as follows: 1466 1467 1468 1469 1470Stokes, et al Expires 14 January 2001 [Page 23] 1471 1472 1473 1474 1475 1476Internet-Draft Access Control Model 14 July 2000 1477 1478 1479 1480 1. If newSuperior is not present (ie. only the RDN is 1481 being renamed) then permission "n" to entry is 1482 required. 1483 1484 2. If newSuperior is present then permission "e" to entry 1485 and permission "i" to newSuperior are required. 1486 1487If any of these permissions are not granted then the 1488operation MUST fail. In this case, if discloseOnError is on 1489then an "insufficient access error" is returned. Otherwise, 1490"No such object" is returned. 1491 1492If they are all granted then the operation MAY proceed. 1493 1494Note A: We do not require any additional permissions in the 1495case where deleteoldrdn is TRUE. 1496 1497Note B: These permissions allow the naming attribute of an 1498entry (or entries) to be changed even though "o" and "w" 1499permissions are not available on the entry. Distinguishing 1500the permissions like this allows us to grant permissions for 1501the ModifyDN operation, but not the Modify operation and 1502vice versa. 1503 1504 15055.7 Compare Operation 1506 1507Recall that the parameters of the Compare operation per 1508RFC2251 [LDAPv3] Section 4.10 are: 1509 1510 CompareRequest ::= [APPLICATION 14] SEQUENCE { 1511 entry LDAPDN, 1512 ava AttributeValueAssertion } 1513 1514Then the permissions required by authzID that need to be 1515evaluated are as follows: 1516 1517 1518 1. permission "c" to the attribute in entry on which the 1519 comparison is being made. 1520 1521If any of these permissions are not granted then the 1522operation MUST fail. In this case, if discloseOnError is on 1523then an "insufficient access error" is returned. Otherwise, 1524"No such object" is returned. 1525 1526If they are all granted then the operation MAY proceed. 1527 1528 1529 1530 1531 1532 1533 1534Stokes, et al Expires 14 January 2001 [Page 24] 1535 1536 1537 1538 1539 1540Internet-Draft Access Control Model 14 July 2000 1541 1542 1543 15445.8 Abandon Operation 1545 1546Recall that the parameters of the Abandon operation per 1547RFC2251 [LDAPv3] Section 4.6 are: 1548 1549 AbandonRequest ::= [APPLICATION 16] MessageID 1550 1551authzID always has the right to send an Abandon Operation 1552for an operation he previously initiated. 1553 1554 15555.9 Extended Operation 1556 1557Recall that the parameters of the Extended operation per 1558RFC2251 [LDA{v3] Section 4.12 are: 1559 1560 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 1561 requestName [0] LDAPOID, 1562 requestValue [1] OCTET STRING OPTIONAL } 1563 1564The access required for an Extended Operation is beyond the 1565scope of this document. The required access will normally 1566be defined by the implementor of the extended request. 1567 1568 1569 15706. Required Permissions for Handling Aliases and References 1571 1572 1573Use of aliases and referrals are part of LDAPv3. However, 1574neither is particularly well-defined. Alias 1575objects/attributes are defined in RFC 2256 as derived from 1576X.500, but LDAPv3 does not explicitly define its semantics 1577or behavior. X.500 does define alias semantics and behavior 1578with respect to access control; we define its behavior in 1579LDAPv3 based on the X.511, section 7.11.1. Referrals and 1580knowledge information are still under design in LDAPv3; they 1581are defined in X.500, however, X.500 punts on their 1582semantics and behavior with respect to access control. We 1583define their semantics and behavior in LDAPv3 in terms that 1584should be independent of the future LDAPv3 definition of 1585referrals and knowledge information. 1586 1587 15886.1 ACI Distribution 1589 1590Currently there is no LDAP standard defining how to 1591distribute directory data between LDAP servers. Consequently 1592this draft cannot fully specify the behavior of the Access 1593Control Model in a distributed environment. The case of 1594distribution via referrals is treated in the "Referrals" 1595 1596 1597 1598Stokes, et al Expires 14 January 2001 [Page 25] 1599 1600 1601 1602 1603 1604Internet-Draft Access Control Model 14 July 2000 1605 1606 1607 1608section below. In the case of chaining (where one LDAP 1609server forwards a request to another on behalf of a client) 1610then it is server specific how the access control model 1611behaves in this environment. Similarly it is server specific 1612how the server determines whether the chaining of an 1613operation is permitted in the first place. For example, the 1614implementation may choose to regard the local naming context 1615and the remote subordinate naming context as seperate Access 1616Control Specific Areas, or it may regard the DIT as one 1617Access Control Specific Area and implement mechanisms to 1618propagate access control information between the two 1619servers. The behavior of the Access Control Model in 1620distributed environments such as these is beyond the scope 1621of this draft. 1622 1623 16246.2 Aliases 1625 1626There are two things to protect with respect to aliases: 1627the real name of the aliased object and the location of the 1628server holding it. 1629 1630If alias de-referencing is required in the process of 1631locating a target entry, no specifc permissions are 1632necessary for alias de-referencing to take place. Access 1633control is enforced at the object pointed to by the alias. 1634 1635If alias de-referencing would result in a 1636continuationReference (e.g. from a search operation), then 1637browse permission is required to the alias entry and read 1638permission is required to the 'aliasedObjectName' attribute. 1639Requiring these permission closes the hole of discovery. 1640 1641 16426.3 Referrals 1643 1644If a referral is to be followed, no specifc permissions are 1645necessary for the ldap client to follow the referral. Access 1646control is enforced at the referenced object. If a referral 1647is returned, then browse is required on the entry and read 1648permission is required to the attribute containing the 1649referral (we cannot name this attribute exactly today 1650because there are no RFCs on this - only drafts). If the 1651server implements a default referral, then no special 1652permissions are required to read and return that referral. 1653Requiring these permissions closes the hole of discovery. 1654In the default case, it is assumed that a default referral 1655is public. 1656 1657 1658 1659 1660 1661 1662Stokes, et al Expires 14 January 2001 [Page 26] 1663 1664 1665 1666 1667 1668Internet-Draft Access Control Model 14 July 2000 1669 1670 1671 16727. Controlling Access to Access Control Information 1673 1674The ldapACI attribute is used to specify control for who has 1675permission to set/change access control information 1676(ldapACI). The ldapACI attribute/OID is just another 1677attribute described with a scope, set of rights and 1678permissions, and subject as a value of the ldapACI 1679attribute. (See the example in the "ACI Examples" section). 1680 1681If the policy for controlling the ldapACI attribute is not 1682specified for any object in the tree, behavior is 1683implementation defined. For instance, if no object anywhere 1684in the tree defines the access for ldapACI within the 1685ldapACI attribute, then the server could simply assert that 1686the 'root DN' is considered the policy owner (controller for 1687controlling access control) for all objects. 1688 1689 1690 16918. ACI Examples 1692 1693Note that in the examples, the form "OID.<attrname>" refers 1694to the OID in dotted decimal form for the attribute 1695<attrname>. This shorthand notation is used only for the 1696examples. In implementation, the dotted decimal form of the 1697OID is used. 1698 1699 17008.1 Attribute Definition 1701 1702The following examples show the access required to control 1703access to the ldapACI attribute. The first example shows 1704controlling the access control on an individual entry and 1705its attributes. The second example shows controlling the 1706access control on a subtree. 1707 1708 ldapACI: entry#grant:r,w# 1709 OID.ldapACI#authnLevel:any:role:cn=aciAdmin 1710 1711 ldapACI: subtree#grant:r,w# 1712 OID.ldapACI#authnLevel:any:role:cn=aciAdmin 1713 1714The next example shows a ldapACI attribute where a group 1715"cn=Dept XYZ, c=US" is being given permissions to read, 1716search, and compare attribute attr1. The permission applies 1717to the entire subtree below the node containing this ACI. 1718Authentication of a specified type is not required. 1719 1720 ldapACI:subtree#grant;r,s,c# 1721 OID.attr1#group:cn=Dept XYZ,c=US 1722 1723 1724 1725 1726Stokes, et al Expires 14 January 2001 [Page 27] 1727 1728 1729 1730 1731 1732Internet-Draft Access Control Model 14 July 2000 1733 1734 1735 1736The next example shows an ACI attribute where a role 1737"cn=SysAdmins,o=Company" is being given permissions to add 1738objects below this node and read, search, and compare 1739attributes attr2 and attr3. The permission applies to the 1740entire subtree below the node containing this ACI. 1741 1742 ldapACI: subtree#grant:a# 1743 [entry]#role:cn=SysAdmins,o=Company 1744 1745 ldapACI: subtree#grant:r,s,c# 1746 OID.attr2#role:cn=SysAdmins,o=Company 1747 1748 ldapACI: subtree#grant:r,s,c# 1749 OID.attr3#role:cn=SysAdmins,o=Company 1750 1751 17528.2 Modifying the ldapACI Values 1753 1754Modify-Replace works as defined in the ldap operation 1755modify. If the attribute value does not exist, create the 1756value. If the attribute does exist, replace the value. If 1757the ldapACI value is replaced, all ldapACI values are 1758replaced. 1759 1760A given ldapACI for an entry: 1761 1762 ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC 1763 1764 ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ 1765 1766perform the following change: 1767 1768 dn: cn=someEntry 1769 changetype: modify 1770 replace: ldapACI 1771 ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN 1772 1773The resulting ACI is: 1774 1775ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN 1776 1777( ldapACI values for Dept XYZ and ABC are lost through the 1778replace ) 1779 1780During an ldapmodify-add, if the ACI does not exist, the 1781create the ACI with the specific ldapACI value(s). If the 1782ACI does exist, then add the specified values to the given 1783ldapACI. For example a given ACI: 1784 1785ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ 1786 1787 1788 1789 1790Stokes, et al Expires 14 January 2001 [Page 28] 1791 1792 1793 1794 1795 1796Internet-Draft Access Control Model 14 July 2000 1797 1798 1799 1800with a modification: 1801 1802 dn: cn=someEntry 1803 changetype: modify 1804 add: ldapACI 1805 ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ 1806 1807would yield an multi-valued ACI of: 1808 1809 ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ 1810 1811 ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ 1812 1813To delete a particular ACI value, use the regular ldapmodify 1814- delete syntax 1815 1816Given an ACI of: 1817 1818 ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ 1819 ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ 1820 1821 dn: cn = some Entry 1822 changetype: modify 1823 delete: ldapACI 1824 ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ 1825 1826would yield a remaining ACI on the server of 1827 1828ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ 1829 1830The attributes which are defined for access control 1831interchange may be used in all LDAP operations. 1832 1833Within the ldapmodify-delete operation, the entire acl may 1834be deleted by specifying 1835 1836 dn: cn = some Entry 1837 changetype: modify 1838 delete: ldapACI 1839 1840In this case, the entry would then inherit its ACI from some 1841other node in the tree depending on the server inheritance 1842model. 1843 1844Similarly, if all values of ldapACI are deleted, then the 1845access control information for that entry is defined by that 1846implementation's inheritance model. 1847 1848 1849 1850 1851 1852 1853 1854Stokes, et al Expires 14 January 2001 [Page 29] 1855 1856 1857 1858 1859 1860Internet-Draft Access Control Model 14 July 2000 1861 1862 1863 18648.3 Evaluation 1865 1866These examples assume that the ldapACI entries listed in 1867each example are the only ACI which applies to the entry in 1868question; if backing-store ACI also exists, the effective 1869policy may be different from that listed in each example. 1870See section 10 for a discussion of the semantics of ldapACI 1871entries when backing-store ACI administration is also used. 1872 1873Assume cn=jsmith is a member of group cn=G1. Assume 1874cn=jsmith is a member of group cn=G2. 1875 1876 Example #1 1877 dn: o=XYZ, c=US 1878 ldapACI: subtree#grant:r#attr1 1879 #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US 1880 ldapACI: subtree#grant:w#attr1 1881 #group:cn=G1,ou=ABC,o=XYZ,c=US 1882 1883 What rights does cn=jsmith have to attr1 of o=XYZ,c=US? 1884 Read (r) access; authzID is higher precedence than 1885 group. 1886 1887 1888 Example #2 1889 dn: o=XYZ, c=US 1890 ldapACI: subtree#grant:r#attr2 1891 #group:cn=G1,ou=ABC,o=XYZ,c=US 1892 ldapACI: subtree#grant:w#attr2 1893 #group:cn=G2,ou=ABC,o=XYZ,c=US 1894 1895 What rights does cn=jsmith have to attr2 of o=XYZ,c=US? 1896 Read-write (r,w) access; ACI is combined because both 1897 subjects (group) have same precedence. 1898 1899 1900 Example #3 1901 dn: o=XYZ, c=US 1902 ldapACI: subtree#grant:r,w#attr3 1903 #group:cn=G1,ou=ABC,o=XYZ,c=US 1904 ldapACI: subtree#deny:w#attr3#group:cn=G2,ou=ABC,o=XYZ,c=US 1905 1906 What rights does cn=jsmith have to attr3 of o=XYZ, c=US? 1907 Read access; write is denied (deny has precedence over 1908 grant). 1909 1910 1911 Example #4 1912 dn: o=XYZ, c=US 1913 ldapACI: subtree#grant:w#attr4 1914 #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US 1915 1916 1917 1918Stokes, et al Expires 14 January 2001 [Page 30] 1919 1920 1921 1922 1923 1924Internet-Draft Access Control Model 14 July 2000 1925 1926 1927 1928 ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US 1929 1930 What rights does cn=jsmith have to attr4 of o=XYZ, c=US? 1931 Write (w); rights given to an authzID take precedence 1932 over those given to a subtree. 1933 1934 1935 Example #5 1936 dn: o=XYZ, c=US 1937 ldapACI: subtree#grant:m#OID.attr5 1938 #authzID-dn:cn=jsmith,o=ABC,c=US 1939 ldapACI: subtree#grant:m#OID.cn 1940 #authzID-dn:cn=jsmith,o=ABC,c=US 1941 ldapACI: subtree#grant:m#OID.sn 1942 #authzID-dn:cn=jsmith,o=ABC,c=US 1943 ldapACI: subtree#grant:a#[entry] 1944 #authzID-dn:#cn=jsmith,o=ABC,c=US 1945 1946 What rights does cn=jsmith have to o=XYZ, c=US? 1947 Make(m) on attributes attr5, cn, and sn and Add(a) 1948 on the entry. These are the minimal yet sufficient 1949 permissions to create a new object, 1950 cn=New, o=XYZ, c=US with values for the attr5, cn, 1951 and sn attributes. This example illustrates how the 1952 "m" permission can be used to limit the attributes 1953 that can be created on a new entry. 1954 1955 Example #6 1956 dn: c=US 1957 ldapACI: subtree#grant:m#[all]#subtree:c=US 1958 dn: o=XYZ, c=US 1959 ldapACI: subtree#grant:a#[entry]# 1960 authzID-dn:cn=jsmith,o=ABC,c=US 1961 1962 What rights does cn=jsmith have to o=XYZ, c=US? 1963 Make(m) on attributes all attributes and Add(a) on the 1964 entry. These are sufficient permissions to create a new 1965 object, cn=New, o=XYZ, c=US with values any desired 1966 attributes. For administrators who do not wish to limit 1967 the attributes that can be created on new entries, this 1968 example shows how a single ldapACI at the top of the 1969 domain solves the problem. 1970 1971 1972 19739. Operational Semantics of Access Control Operations 1974 1975The semantics of access control operations described in this 1976document are defined operationally in terms of "histories". 1977A history is a sequence of actions (x1, x2, ..., xN). 1978 1979 1980 1981 1982Stokes, et al Expires 14 January 2001 [Page 31] 1983 1984 1985 1986 1987 1988Internet-Draft Access Control Model 14 July 2000 1989 1990 1991 19929.1 Types of actions 1993 1994We consider five types of actions: 1995 1996 - LDAP Access Control Policy Update actions: invocations 1997 of ldap modify when used to add, delete, or replace the 1998 aci attribute; invocations of ldap add when used to add 1999 an entry with an aci attribute. A LDAP Access Control 2000 Policy Update action may replace the policy (by 2001 completely replacing the aci attribute with new policy 2002 information) or it may grant or deny specific rights 2003 while leaving others unaffected. 2004 2005 - LDAP Access Control Policy Query operations: 2006 invocations of ldap search when used to retrieve the 2007 aci attribute; invocations of ldap search with the 2008 getEffectiveRightsRequest control; invocations of the 2009 ldapGetEffectiveRightsRequest extended operation. 2010 2011 - Datastore Access Control Policy Update Actions: any 2012 operation implemented by the server which LDAP is using 2013 as its datastore which changes the access policy 2014 enforced with respect to attempts to access LDAP 2015 directory entries and their attributes. 2016 2017 - LDAP Access Request operations: invocations of LDAP 2018 entry or attribute access operations (Read, Update, 2019 Search, Compare, etc...). 2020 2021 - Other operations: anything else, including Datastore 2022 operations which do not change the access policy 2023 enforced by the server. 2024 2025 20269.2 Semantics of Histories 2027 2028The semantics of histories are defined as follows: 2029 2030 - LDAP Update (Replace), LDAP Query 2031 2032 The Query will show that the subject has all rights 2033 granted by the Update operation, and no rights not 2034 granted by the Update operation. 2035 2036 - LDAP Update (Grant), LDAP Query 2037 2038 The Query will show that the subject has all rights 2039 granted by the Update operation. The Query may show 2040 that the subject also has other rights not granted by 2041 the Update operation, depending on the policy in force 2042 before the Update operation. 2043 2044 2045 2046Stokes, et al Expires 14 January 2001 [Page 32] 2047 2048 2049 2050 2051 2052Internet-Draft Access Control Model 14 July 2000 2053 2054 2055 2056 - LDAP Update (Deny), LDAP Query 2057 2058 The Query will show that the subject does not have any 2059 right denied by the Update operation. The Query may 2060 show that the subject has rights not denied by the 2061 Update operation, depending on the policy in force 2062 before the Update operation. 2063 2064 - LDAP Update (Replace), LDAP Access Request 2065 2066 The Request will succeed if it requires only rights 2067 granted to the requesting subject by the Update 2068 operation. The Request will fail if it requires any 2069 right not granted by the Update operation. 2070 2071 - LDAP Update (Grant), LDAP Access Request 2072 2073 The Request will succeed if it requires only rights 2074 granted to the requesting subject by the Update 2075 operation. The Request may succeed if it requires 2076 rights not granted by the Update operation, depending 2077 on the policy in force before the Update operation. 2078 2079 - LDAP Update (Deny), LDAP Access Request 2080 2081 The Request will fail if it requires any right denied 2082 to the requesting subject by the Update operation. If 2083 the Request requires only rights which were not denied 2084 by the Update operation, it may succeed, depending on 2085 the policy in force before the Update operation. 2086 2087 - LDAP Update (Replace), Other, LDAP Query 2088 2089 The Query will show that the subject has all rights 2090 granted by the Update operation, and no rights not 2091 granted by the Update operation. 2092 2093 - LDAP Update (Grant), Other, LDAP Query 2094 2095 The Query will show that the subject has all rights 2096 granted by the Update operation. The Query may show 2097 that the subject also has other rights not granted by 2098 the Update operation, depending on the policy in force 2099 before the Update operation. 2100 2101 - LDAP Update (Deny), Other, LDAP Query 2102 2103 The Query will show that the subject does not have any 2104 right denied by the Update operation. The Query may 2105 show that the subject has rights not denied by the 2106 Update operation, depending on the policy in force 2107 2108 2109 2110Stokes, et al Expires 14 January 2001 [Page 33] 2111 2112 2113 2114 2115 2116Internet-Draft Access Control Model 14 July 2000 2117 2118 2119 2120 before the Update operation. 2121 2122 - LDAP Update (Replace), Other, LDAP Access Request 2123 2124 The Request will succeed if it requires only rights 2125 granted to the requesting subject by the Update 2126 operation. The Request will fail if it requires any 2127 right not granted by the Update operation. 2128 2129 - LDAP Update (Grant), Other, LDAP Access Request 2130 2131 The Request will succeed if it requires only rights 2132 granted to the requesting subject by the Update 2133 operation. The Request may succeed if it requires 2134 rights not granted by the Update operation, depending 2135 on the policy in force before the Update operation. 2136 2137 - LDAP Update (Deny), Other, LDAP Access Request 2138 2139 The Request will fail if it requires any right denied 2140 to the requesting subject by the Update operation. If 2141 the Request requires only rights which were not denied 2142 by the Update operation, it may succeed, depending on 2143 the policy in force before the Update operation. 2144 2145 - LDAP Update (Replace), Datastore Policy Update, LDAP 2146 Query 2147 2148 The result of the Query is not defined. 2149 2150 - LDAP Update (Grant), Datastore Policy Update, LDAP 2151 Query 2152 2153 The result of the Query is not defined. 2154 2155 - LDAP Update (Deny), Datastore Policy Update, LDAP Query 2156 2157 The result of the Query is not defined. 2158 2159 - LDAP Update (Replace), Datastore Policy Update, LDAP 2160 Access Request 2161 2162 The result of the Access Request is not defined. 2163 2164 - LDAP Update (Grant), Datastore Policy Update, LDAP 2165 Access Request 2166 2167 The result of the Access Request is not defined. 2168 2169 - LDAP Update (Deny), Datastore Policy Update, LDAP 2170 Access Request 2171 2172 2173 2174Stokes, et al Expires 14 January 2001 [Page 34] 2175 2176 2177 2178 2179 2180Internet-Draft Access Control Model 14 July 2000 2181 2182 2183 2184 The result of the Access Request is not defined. 2185 2186 2187 218810. Access Control Parameters for LDAP Controls & Extended 2189Operations 2190 2191This section defines the parameters used in the access 2192control LDAP controls and extended operations in this 2193document. 2194 2195targetDN specifies the initial directory entry in DN syntax 2196on which the control or extended operation is performed. 2197 2198whichObject specifies whether the access control information 2199(in the get effective rights control) which is retrieved is 2200for the target directory entry (ENTRY) or the target 2201directory entry and its subtree (SUBTREE). 2202 2203rights in the get effective rights control or extended 2204operation response is of the form specified in the BNF for 2205<rights>. 2206 2207subject is a LDAP string that defines the subject. Access 2208control is get/set on a subject. The syntax of the subject 2209is the same as the subject field in the BNF. 2210 2211 2212 221311. Access Control Information (ACI) Controls 2214 2215The access control information controls provide a way to 2216manipulate access control information in conjunction with a 2217LDAP operation. One LDAP control is defined. This control 2218allows access control information to be retrieved while 2219manipulating other directory information for that entry. 2220The control is: 2221 2222 - getEffectiveRights to obtain the effective rights for a 2223 given directory entry(s) for a given subject during a 2224 ldap_search operation 2225 222611.1 getEffectiveRights Control 2227 2228 222911.1.1 Request Control 2230 2231This control may only be included in the ldap_search 2232message as part of the controls field of the 2233LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. 2234 2235 2236 2237 2238Stokes, et al Expires 14 January 2001 [Page 35] 2239 2240 2241 2242 2243 2244Internet-Draft Access Control Model 14 July 2000 2245 2246 2247 2248The controlType is set to <OID to be assigned>. The 2249criticality MAY be either TRUE or FALSE (where absent is 2250also equivalent to FALSE) at the client's option. The 2251controlValue is an OCTET STRING, whose value is the BER 2252encoding of a value of the following SEQUENCE: 2253 2254 getEffectiveRightsRequest ::= SEQUENCE { 2255 effectiveRightsRequest SEQUENCE OF SEQUENCE { 2256 whichObject ENUMERATED { 2257 LDAP_ENTRY (1), 2258 LDAP_SUBTREE (2) 2259 }, 2260 subject <see <subject > in BNF> | "*" 2261 } 2262 } 2263 2264The effectiveRightsRequest is a set of sequences that state 2265the whichObject (entry or entry plus subtree) and specifics 2266of the control request to be performed. A "*" in the subject 2267field specifies that all DN types are to be used in 2268returning the effective rights. This control is applied to 2269the filter and scope set by the ldap_search operation, i.e. 2270base, one-level, subtree. So the attributes/values returned 2271are defined by the ldap_search operation. 2272 227311.1.2 Response Control 2274 2275This control is included in the ldap_search_response message 2276as part of the controls field of the LDAPMessage, as defined 2277in Section 4.1.12 of [LDAPv3]. 2278 2279The controlType is set to <OID to be assigned>. There is no 2280need to set the criticality on the response. The 2281controlValue is an OCTET STRING, whose value is the BER 2282encoding of a value of the following SEQUENCE: 2283 2284 getEffectiveRightsResponse ::= { 2285 result ENUMERATED { 2286 success (0), 2287 operationsError (1), 2288 unavailableCriticalExtension (12), 2289 noSuchAttribute (16), 2290 undefinedAttributeType (17), 2291 invalidAttributeSyntax (21), 2292 insufficientRights (50), 2293 unavailable (52), 2294 unwillingToPerform (53), 2295 other (80) 2296 } 2297 } 2298 2299 2300 2301 2302Stokes, et al Expires 14 January 2001 [Page 36] 2303 2304 2305 2306 2307 2308Internet-Draft Access Control Model 14 July 2000 2309 2310 2311 2312The effective rights returned are returned with each entry 2313returned by the search result. The control response for 2314ldap_search is: 2315 2316 PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE { 2317 rights <see <rights> in BNF>, 2318 whichObject ENUMERATED { 2319 LDAP_ENTRY (1), 2320 LDAP_SUBTREE (2) 2321 }, 2322 subject < see <subject> in BNF > 2323 } 2324 2325Although this extends the search operation, there are no 2326incompatibilities between versions. LDAPv2 cannot send a 2327control, hence the above structure cannot be returned to a 2328LDAPv2 client. A LDAPv3 client cannot send this request to 2329a LDAPv2 server. A LDAPv3 server not supporting this 2330control cannot return the additional data. 2331 233211.1.3 Client-Server Interaction 2333 2334The getEffectiveRightsRequest control requests the rights 2335that MUST be in effect for requested directory 2336entry/attribute based on the subject DN. The server that 2337consumes the search operation looks up the rights for the 2338returned directory information based on the subject DN and 2339returns that rights information. 2340 2341There are six possible scenarios that may occur as a result 2342of the getEffectiveRights control being included on the 2343search request: 2344 2345 2346 1. If the server does not support this control and the 2347 client specified TRUE for the control's criticality 2348 field, then the server MUST return 2349 unavailableCriticalExtension as a return code in the 2350 searchResponse message and not send back any other 2351 results. This behavior is specified in section 4.1.12 2352 of [LDAPv3]. 2353 2354 2. If the server does not support this control and the 2355 client specified FALSE for the control's criticality 2356 field, then the server MUST ignore the control and 2357 process the request as if it were not present. This 2358 behavior is specified in section 4.1.12 of [LDAPv3]. 2359 2360 3. If the server supports this control but for some 2361 reason such as cannot process specified family and the 2362 client specified TRUE for the control's criticality 2363 2364 2365 2366Stokes, et al Expires 14 January 2001 [Page 37] 2367 2368 2369 2370 2371 2372Internet-Draft Access Control Model 14 July 2000 2373 2374 2375 2376 field, then the server SHOULD do the following: return 2377 unavailableCriticalExtension as a return code in the 2378 searchResult message. 2379 2380 4. If the server supports this control but for some 2381 reason such as cannot process specified family and the 2382 client specified FALSE for the control's criticality 2383 field, then the server should process as 'no rights 2384 returned for that family' and include the result 2385 Unavailable in the getEffectiveRightsResponse control 2386 in the searchResult message. 2387 2388 5. If the server supports this control and can return the 2389 rights per the family information, then it should 2390 include the getEffectiveRightsResponse control in the 2391 searchResult message with a result of success. 2392 2393 6. If the search request failed for any other reason, 2394 then the server SHOULD omit the 2395 getEffectiveRightsResponse control from the 2396 searchResult message. 2397 2398The client application is assured that the correct rights 2399are returned for scope of the search operation if and only 2400if the getEffectiveRightsResponse control returns the 2401rights. If the server omits the getEffectiveRightsResponse 2402control from the searchResult message, the client SHOULD 2403assume that the control was ignored by the server. 2404 2405The getEffectiveRightsResponse control, if included by the 2406server in the searchResponse message, should have the 2407getEffectiveRightsResult set to either success if the rights 2408are returned or set to the appropriate error code as to why 2409the rights could not be returned. 2410 2411The server may not be able to return a right because it may 2412not exist in that directory object's attribute; in this 2413case, the rights request is ignored with success. 2414 2415 241612. Access Control Extended Operation 2417 2418An extended operation, get effective rights, is defined to 2419obtain the effective rights for a given directory entry for 2420a given subject. This operation may help with the 2421management of access control information independent of 2422manipulating other directory information. 2423 2424 2425 2426 2427 2428 2429 2430Stokes, et al Expires 14 January 2001 [Page 38] 2431 2432 2433 2434 2435 2436Internet-Draft Access Control Model 14 July 2000 2437 2438 2439 244012.1 LDAP Get Effective Rights Operation 2441 2442ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE 2443{ 2444 requestName [0] <OID to be assigned>, 2445 requestValue [1] OCTET STRING OPTIONAL } 2446 2447 where 2448 2449 requestValue ::= SEQUENCE { 2450 targetDN LDAPDN, 2451 updates SEQUENCE OF SEQUENCE { 2452 whichObject ENUMERATED { 2453 LDAP_ENTRY (1), 2454 LDAP_SUBTREE (2) 2455 }, 2456 attr SEQUENCE { 2457 attr <see <attr> in BNF > 2458 }, 2459 subject < see <subject> in BNF > | "*" 2460 } 2461 } 2462 2463 2464The requestName is a dotted-decimal representation of the 2465OBJECT IDENTIFIER corresponding to the request. The 2466requestValue is information in a form defined by that 2467request, encapsulated inside an OCTET STRING. 2468 2469The server will respond to this with an LDAPMessage 2470containing the ExtendedResponse which is a rights list. 2471 2472ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE 2473{ 2474 COMPONENTS OF LDAPResult, 2475 responseName [10] <OID to be assigned> OPTIONAL, 2476 effectiveRights [11] OCTET STRING OPTIONAL } 2477 2478 where 2479 2480 effectiveRights ::= SEQUENCE OF SEQUENCE { 2481 rights <see <rights> in BNF>, 2482 whichObject ENUMERATED { 2483 LDAP_ENTRY (1), 2484 LDAP_SUBTREE (2) 2485 }, 2486 subject < see <subject> in BNF > 2487 } 2488 2489If the server does not recognize the request name, it MUST 2490return only the response fields from LDAPResult, containing 2491 2492 2493 2494Stokes, et al Expires 14 January 2001 [Page 39] 2495 2496 2497 2498 2499 2500Internet-Draft Access Control Model 14 July 2000 2501 2502 2503 2504the protocolError result code. 2505 2506 2507 250813. Security Considerations 2509 2510This document proposes protocol elements for transmission of 2511security policy information. Security considerations are 2512discussed throughout this draft. Because subject security 2513attribute information is used to evaluate decision requests, 2514it is security-sensitive information and must be protected 2515against unauthorized modification whenever it is stored or 2516transmitted. 2517 2518Interaction of access control with other directory functions 2519(other than the ones defined in this document) are not 2520defined in this document, but instead in the documents where 2521those directory functions are defined. For example, the 2522directory replication documents should address the 2523interaction of access control with the replication function. 2524 2525 2526 252714. References 2528 2529[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory 2530Access Protocol (v3)", RFC 2251, December 1997. 2531 2532[ECMA] ECMA, "Security in Open Systems: A Security 2533Framework" ECMA TR/46, July 1988. 2534 2535[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements 2536for LDAP", RFC 2820, May 2000. 2537 2538[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight 2539Directory Access Protocol (v3)": Attribute Syntax 2540Definitions, RFC 2252, December 1997. 2541 2542[UTF] M. Wahl, S. Kille, "Lightweight Directory Access 2543Protocol (v3)": A UTF-8 String Representation of 2544Distinguished Names", RFC 2253, December 1997. 2545 2546[Bradner97] Bradner, Scott, "Key Words for use in RFCs to 2547Indicate Requirement Levels", RFC 2119. 2548 2549[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. 2550Morgan, "Authentication Methods for LDAP", RFC 2829, May 25512000. 2552 2553[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax 2554Specifications: ABNF", RFC 2234, November 1997. 2555 2556 2557 2558Stokes, et al Expires 14 January 2001 [Page 40] 2559 2560 2561 2562 2563 2564Internet-Draft Access Control Model 14 July 2000 2565 2566 2567 2568ACKNOWLEDGEMENT 2569 2570This is to acknowledge the numerous companies and individuals who have 2571contributed their valuable help and insights to the development of this 2572specification. 2573 2574 2575AUTHOR(S) ADDRESS 2576 2577 Ellen Stokes Bob Blakley 2578 Tivoli Systems Tivoli Systems 2579 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway 2580 Austin, TX 78731 Austin, TX 78731 2581 USA USA 2582 mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com 2583 phone: +1 512 436 9098 phone: +1 512 436 1564 2584 fax: +1 512 436 1199 fax: +1 512 436 1199 2585 2586 2587 Debbie Rinkevich Robert Byrne 2588 IBM Sun Microsystems 2589 11400 Burnet Rd 29 Chemin du Vieux Chene 2590 Austin, TX 78758 Meylan ZIRST 38240 2591 USA France 2592 mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com 2593 phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05 2594 fax: +1 512 838 8597 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622Stokes, et al Expires 14 January 2001 [Page 41] 2623 2624 2625 2626 2627 2628Internet-Draft Access Control Model 14 July 2000 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686Stokes, et al Expires 14 January 2001 [Page 42] 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 CONTENTS 2697 2698 2699 1. Introduction....................................... 2 2700 2701 2. The LDAPv3 Access Control Model.................... 2 2702 2703 3. Access Control Mechanism Attributes................ 5 2704 3.1 Root DSE Attribute for Access Control 2705 Mechanism.................................... 5 2706 3.2 Root DSE Attribute for Control of Disclosing 2707 Errors....................................... 5 2708 3.3 Subentry Class Access Control Mechanism...... 6 2709 2710 4. The Access Control Information Attribute 2711 (ldapACI).......................................... 7 2712 4.1 The BNF...................................... 8 2713 4.1.1 ACI String Representation 8 2714 4.1.2 ACI Binary Representation 10 2715 4.2 The Components of ldapACI Attribute.......... 11 2716 4.2.1 Scope 11 2717 4.2.2 Access Rights and Permissions 11 2718 4.2.3 Attributes 14 2719 4.2.4 Subjects and Associated 2720 Authentication 15 2721 4.3 Grant/Deny Evaluation Rules.................. 15 2722 2723 5. Required Permissions for each LDAP Operation....... 17 2724 5.1 Bind Operation............................... 18 2725 5.2 Search Operation............................. 18 2726 5.3 Modify Operation............................. 21 2727 5.4 Add Operation................................ 22 2728 5.5 Delete Operation............................. 23 2729 5.6 Modify DN Operation.......................... 23 2730 5.7 Compare Operation............................ 24 2731 5.8 Abandon Operation............................ 25 2732 5.9 Extended Operation........................... 25 2733 2734 6. Required Permissions for Handling Aliases and 2735 References......................................... 25 2736 6.1 ACI Distribution............................. 25 2737 6.2 Aliases...................................... 26 2738 6.3 Referrals.................................... 26 2739 2740 7. Controlling Access to Access Control 2741 Information........................................ 27 2742 2743 8. ACI Examples....................................... 27 2744 8.1 Attribute Definition......................... 27 2745 8.2 Modifying the ldapACI Values................. 28 2746 8.3 Evaluation................................... 30 2747 2748 2749 2750 - i - 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 9. Operational Semantics of Access Control 2763 Operations......................................... 31 2764 9.1 Types of actions............................. 32 2765 9.2 Semantics of Histories....................... 32 2766 276710. Access Control Parameters for LDAP Controls & 2768 Extended Operations................................ 35 2769 277011. Access Control Information (ACI) Controls.......... 35 2771 11.1 getEffectiveRights Control................... 35 2772 11.1.1 Request Control 35 2773 11.1.2 Response Control 36 2774 11.1.3 Client-Server Interaction 37 2775 277612. Access Control Extended Operation.................. 38 2777 12.1 LDAP Get Effective Rights Operation.......... 39 2778 277913. Security Considerations............................ 40 2780 278114. References......................................... 40 2782 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 - ii - 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828Full Copyright Statement 2829 2830Copyright (C) The Internet Society (2000).� All Rights 2831Reserved. 2832 2833This document and translations of it may be copied and 2834furnished to others, and derivative works that comment on or 2835otherwise explain it or assist in its implementation may be 2836prepared, copied, published and distributed, in whole or in 2837part, without restriction of any kind, provided that the 2838above copyright notice and this paragraph are included on 2839all such copies and derivative works.� However, this 2840document itself may not be modified in any way, such as by 2841removing the copyright notice or references to the Internet 2842Society or other Internet organizations, except as needed 2843for the purpose of developing Internet standards in which 2844case the procedures for copyrights defined in the Internet 2845Standards process must be followed, or as required to 2846translate it into languages other than English. 2847 2848The limited permissions granted above are perpetual and will 2849not be revoked by the Internet Society or its successors or 2850assigns. 2851 2852This document and the information contained herein is 2853provided on an "AS IS" basis and THE INTERNET SOCIETY AND 2854THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 2855WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2856ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2857INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2858MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2859 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 - iii - 2883 2884 2885 2886 2887