1 2 3 4Network Working Group S. Haripriya 5Internet-Draft Jaimon. Jose, Ed. 6Updates: 02 (if approved) Jim. Sermersheim 7Intended status: Standards Track Novell, Inc. 8Expires: July 9, 2007 January 5, 2007 9 10 11 LDAP: Dynamic Groups for LDAPv3 12 draft-haripriya-dynamicgroup-02 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on July 9, 2007. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2007). 42 43 44 45 46 47 48 49 50 51 52 53 54 55Haripriya, et al. Expires July 9, 2007 [Page 1] 56 57Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 58 59 60Abstract 61 62 This document describes the requirements, semantics, schema elements, 63 and operations needed for a dynamic group feature in LDAP. A dynamic 64 group is defined here as a group object with a membership list of 65 distinguished names that is dynamically generated using LDAP search 66 criteria. The dynamic membership list may then be interrogated by 67 LDAP search and compare operations, and may also be used to find the 68 groups that an object is a member of. This feature eliminates a huge 69 amount of the administrative effort required today for maintaining 70 group memberships and role-based operations in large enterprises. 71 72 73Table of Contents 74 75 1. Conventions used in this document . . . . . . . . . . . . . . 4 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. Requirements of a dynamic group feature . . . . . . . . . . . 6 78 4. Schema and Semantic Definitions for Dynamic Groups . . . . . . 7 79 4.1. Object Classes . . . . . . . . . . . . . . . . . . . . . . 7 80 4.1.1. dynamicGroup . . . . . . . . . . . . . . . . . . . . . 7 81 4.1.2. dynamicGroupOfUniqueNames . . . . . . . . . . . . . . 7 82 4.1.3. dynamicGroupAux . . . . . . . . . . . . . . . . . . . 7 83 4.1.4. dynamicGroupOfUniqueNamesAux . . . . . . . . . . . . . 7 84 4.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.2.1. memberQueryURL . . . . . . . . . . . . . . . . . . . . 8 86 4.2.2. excludedMember . . . . . . . . . . . . . . . . . . . . 11 87 4.3. member . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.4. uniqueMember . . . . . . . . . . . . . . . . . . . . . . . 11 89 4.5. dgIdentity . . . . . . . . . . . . . . . . . . . . . . . . 11 90 4.5.1. dgIdentity - Security implications . . . . . . . . . . 12 91 5. Advertisement of support for dynamic groups . . . . . . . . . 13 92 6. Dynamic Group Operations . . . . . . . . . . . . . . . . . . . 14 93 6.1. Existing Operations . . . . . . . . . . . . . . . . . . . 14 94 6.1.1. Access to resources in the directory . . . . . . . . . 14 95 6.1.2. Reading a dynamic group object . . . . . . . . . . . . 14 96 6.1.3. 'Is Member Of' functionality . . . . . . . . . . . . . 15 97 6.2. New Extensions . . . . . . . . . . . . . . . . . . . . . . 16 98 6.2.1. Managing the static members of a dynamic group . . . . 16 99 7. Performance Considerations . . . . . . . . . . . . . . . . . . 17 100 7.1. Caching of Dynamic Members . . . . . . . . . . . . . . . . 17 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 103 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21 105 Appendix A. Example Values for memberQueryURL . . . . . . . . . . 22 106 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 108 109 110 111Haripriya, et al. Expires July 9, 2007 [Page 2] 112 113Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 114 115 116 Intellectual Property and Copyright Statements . . . . . . . . . . 25 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Haripriya, et al. Expires July 9, 2007 [Page 3] 168 169Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 170 171 1721. Conventions used in this document 173 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [1]. 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Haripriya, et al. Expires July 9, 2007 [Page 4] 224 225Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 226 227 2282. Introduction 229 230 The LDAP schema described in [4] defines two object classes: 231 'groupOfNames', and 'groupOfUniqueNames', that hold a static list of 232 distinguished names in their 'member' or 'uniqueMember' attributes 233 respectively, and are typically used to describe a group of objects 234 for various functions. These grouping functions range from simple 235 group membership applications such as email distribution lists to 236 describing common authorization for a set of users The administration 237 and updating of these membership lists must be done by specifically 238 modifying the DN values in the member or uniqueMember attributes. 239 Thus, each time a change in membership happens, a process must exist 240 which adds or removes the particular entry's DN from the member 241 attribute. For example, consider an organization, where the access 242 to its facilities is controlled by membership in a directory group. 243 Assume that all employees in a department have been added to the 244 group that provides access to the required department facility. If 245 an employee moves from one department to another, the administrator 246 must remove the employee from one group and add him to another. 247 Similarly consider an organization that wants to provide access to 248 its facility, to both interns and employees on weekdays, but only to 249 employees on weekends. It would be effort-consuming to achieve this 250 with static groups. 251 252 "Dynamic groups" are like normal groups, but they let one specify 253 criteria to be used for evaluating membership to a group; the 254 membership of the group is determined dynamically by the directory 255 servers involved. This lets the group administrator define the 256 membership in terms of attributes, and let the DSAs worry about who 257 are the actual members. This solution is more scalable and reduces 258 administrative costs. This can also supplement static groups in LDAP 259 to provide flexibility to the user. 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Haripriya, et al. Expires July 9, 2007 [Page 5] 280 281Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 282 283 2843. Requirements of a dynamic group feature 285 286 The following requirements SHOULD be met by a proposal for the 287 dynamic groups feature: 288 289 1. Creation and administration of dynamic groups should be done 290 using normal LDAP operations. 291 292 2. Applications must be able to use dynamic groups in the same way 293 that they are able to use static groups for listing members and 294 for membership evaluation. 295 296 3. Interrogation of a dynamic group's membership should be done 297 using normal LDAP operations, and should be consistent. This 298 means that all authorization identities with the same permission 299 to the membership attribute of a dynamic group (such as 'read') 300 should be presented with the same membership list. 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Haripriya, et al. Expires July 9, 2007 [Page 6] 336 337Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 338 339 3404. Schema and Semantic Definitions for Dynamic Groups 341 342 The dynamic group classes are defined by the following schema 343 3444.1. Object Classes 345 346 The following object classes MUST be supported, and their semantics 347 understood by the server, for it to support the dynamic groups 348 feature. 349 3504.1.1. dynamicGroup 351 352 ( <OID.TBD> NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY 353 (memberQueryURL $ excludedMember $ dgIdentity )) 354 355 This structural object class is used to create a dynamic group 356 object. It is derived from groupOfNames, which is defined in [4]. 357 3584.1.2. dynamicGroupOfUniqueNames 359 360 ( <OID.TBD> NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames 361 STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity )) 362 363 This structural object class is used to create a dynamic group object 364 whose membership list is held in a uniqueMember attribute. It is 365 derived from groupOfUniqueNames, which is defined in [4]. 366 3674.1.3. dynamicGroupAux 368 369 ( <OID.TBD> NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY 370 (memberQueryURL $ excludedMember $ dgIdentity )) 371 372 This auxiliary object class is used to convert an existing object to 373 a dynamic group or to create an object of another object class but 374 with dynamic group capabilities. This is derived from groupOfNames 375 which is defined in [4]. 376 3774.1.4. dynamicGroupOfUniqueNamesAux 378 379 ( <OID.TBD> NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames 380 AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity )) 381 382 This auxiliary object class is used to convert an existing object to 383 a dynamic group of unique names or to create an object of another 384 object class but with dynamic group capabilities. This is derived 385 from groupOfUniqueNames which is defined in [4]. 386 387 388 389 390 391Haripriya, et al. Expires July 9, 2007 [Page 7] 392 393Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 394 395 3964.2. Attributes 397 398 The following attribute names MUST be supported by the server. 399 4004.2.1. memberQueryURL 401 402 This attribute describes the membership of the list using an LDAPURL 403 [3]. 404 405 (<OID.TBD> NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 406 407 The value of memberQueryURL is encoded as an LDAPURL [3] 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Haripriya, et al. Expires July 9, 2007 [Page 8] 448 449Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 450 451 452 The BNF from [3] is listed here for reference. 453ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn 454 [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION 455 extensions]]]]] 456 ; <host> and <port> are defined 457 ; in Sections 3.2.2 and 3.2.3 458 ; of [RFC3986]. 459 ; <filter> is from Section 3 of 460 ; [RFC4515], subject to the 461 ; provisions of the 462 ; "Percent-Encoding" section 463 ; below. 464scheme = "ldap" 465dn = distinguishedName ; From Section 3 of [RFC4514], 466 ; subject to the provisions of 467 ; the "Percent-Encoding" 468 ; section below. 469attributes = attrdesc *(COMMA attrdesc) 470attrdesc = selector *(COMMA selector) 471selector = attributeSelector ; From Section 4.5.1 of 472 ; [RFC4511], subject to the 473 ; provisions of the 474 ; "Percent-Encoding" section 475 ; below. 476scope = "base" / "one" / "sub" 477extensions = extension *(COMMA extension) 478extension = [EXCLAMATION] extype [EQUALS exvalue] 479extype = oid ; From section 1.4 of [RFC4512]. 480exvalue = LDAPString ; From section 4.1.2 of 481 ; [RFC4511], subject to the 482 ; provisions of the 483 ; "Percent-Encoding" section 484 ; below. 485EXCLAMATION = %x21 ; exclamation mark ("!") 486SLASH = %x2F ; forward slash ("/") 487COLON = %x3A ; colon (":") 488QUESTION = %x3F ; question mark ("?") 489 490 491 For the purpose of evaluating dynamic members, the directory server 492 uses only the dn, scope, filter and extensions fields. All remaining 493 fields are ignored if specified. If other fields are specified, the 494 server SHALL ignore them and MAY omit them when presenting the value 495 to a client. The dn is used to specify the base dn from which to 496 start the search for dynamic members. The scope specifies the scope 497 with respect to the dn in which to search for dynamic members. The 498 filter specifies the criteria with which to select objects for 499 dynamic membership. 500 501 502 503Haripriya, et al. Expires July 9, 2007 [Page 9] 504 505Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 506 507 5084.2.1.1. The x-chain extension 509 510 A new extension is defined for use of the memberQueryURL in dynamic 511 groups, named 'x-chain'. x-chain does not take a value. When x-chain 512 is present, the server must follow any search continuation references 513 to other servers while searching for dynamic members. When x-chain 514 is absent, the dynamic members computed will be only those that are 515 present on the server from which the search is made. A directory 516 server supporting the memberQueryURL MAY support the x-chain 517 extension, thus the x-chain extension could be critical or non- 518 critical as specified by the '!' prefix to the extension type. 519 5204.2.1.2. Semantics of multiple values for memberQueryURL 521 522 The memberQueryURL MAY have multiple values, and in that case, the 523 members of the dynamic group will be the union of the members 524 computed using each individual URL value. This is useful in 525 specifying a group membership that is made up from subtrees rooted at 526 different base DNs, and possibly using different filters. 527 5284.2.1.3. Condition of membership 529 530 An object O is a member of a dynamic group G if and only if 531 532 (( O is a value of the 'member' or 'uniqueMember' attribute of G) 533 534 OR 535 536 (( O is selected by the membership criteria specified in the 537 'memberQueryURL' attribute values of G) 538 539 AND 540 541 ( O is not listed in the 'excludedMember' attribute of G) )) 542 543 If a member M of a dynamic group G happens to be a dynamic or a 544 static group, the static or dynamic members of M SHALL NOT be 545 considered as members of G. M is a member of G though. 546 547 The last condition is imposed because 548 549 o Recursively evaluating members of members may degrade the 550 performance of the server drastically. 551 552 o Looping may occur particularly in situations where the search 553 chains across multiple-servers. 554 555 556 557 558 559Haripriya, et al. Expires July 9, 2007 [Page 10] 560 561Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 562 563 564 o Dynamic membership assertions (compare operation) cannot be 565 optimized if recursive memberships are allowed. Without 566 recursion, comparisons can be made light-weight. 567 5684.2.2. excludedMember 569 570 ( <OID.TBD> NAME 'excludedMember' SUP distinguishedName ) 571 572 This attribute is used to exclude entries from being a dynamic member 573 of a dynamic group. Thus an entry is a dynamic member of a dynamic 574 group if and only if it is selected by the member criteria specified 575 by the 'memberQueryURL' attribute or explicitly added to the member 576 or uniqueMember attribute, and it is not listed in the 577 'excludedMember' attribute. 578 5794.3. member 580 581 ( 2.5.4.31 NAME 'member' SUP distinguishedName ) 582 583 Defined in [4], this attribute is overloaded when used in the context 584 of a dynamic group. It is used to explicitly specify static members 585 of a dynamic group. If the same entry is listed in both the 'member' 586 and 'excludedMember' attributes, the 'member' overrides the 587 'excludedMember', and the entry is considered to be a member of the 588 group. This attribute is also used to interrogate both the static 589 and dynamic member values of a dynamic group object. Subclasses of 590 this attribute are NOT considered in this manner. 591 5924.4. uniqueMember 593 594 ( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName ) 595 596 Defined in [4], this attribute is overloaded when used in the context 597 of a dynamic group. It is used to specify the static members of a 598 dynamic group. If the same entry is listed in both the 599 'uniqueMember' and 'excludedMember' attributes, the 'uniqueMember' 600 overrides the 'excludedMember', and the entry is considered to be a 601 member of the group. This attribute is also used to interrogate both 602 the static and dynamic member values of a dynamic group object. 603 Subclasses of this attribute are NOT considered in this manner. 604 6054.5. dgIdentity 606 607 ( <OID.TBD> NAME 'identity' SUP distinguishedName SINGLE-VALUE ) 608 609 In order to provide consistent results when processing the search 610 criteria, the server must use a single authorization identity. If 611 the authorization of the bound identity is used, the membership list 612 613 614 615Haripriya, et al. Expires July 9, 2007 [Page 11] 616 617Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 618 619 620 will vary, from identity to identity due to differing access 621 controls. This may either be done by the server authenticating as 622 the dgIdentity prior to performing a search or compare operation, or 623 may be done by simply assuming the authorization of the dgIdentity 624 when performing those operations. As server implementations vary, so 625 may the mechanisms to achieve consistent results through the use of 626 the dgIdentity. In the case that the server authenticates as the 627 dgIdentity, it may be required by the server that this identity have 628 proper authentication credentials, and it may be required that this 629 identity reside in the DIB of the local server. 630 631 In the absence of an identity value, or in case the identity value 632 cannot be used, the server will process the memberQueryURL as the 633 anonymous identity. This attribute MAY be supported, and represents 634 the identity the server will use for processing the memberQueryURL. 635 6364.5.1. dgIdentity - Security implications 637 638 Because this attribute indirectly but effectively grants anyone with 639 read or compare access to the member or uniqueMember attribute 640 sufficient permission to gain a DN result set from the 641 memberQueryURL, server implementations SHOULD NOT allow this 642 attribute to be populated with the DN of any object that is not 643 administered by the identity making the change to this attribute. 644 For purposes of this document, to "administer an object" indicates 645 that the administrative identity has the ability to fully update the 646 access control mechanism in place the object in question. As of this 647 writing, there is no way to describe further what it means to be 648 fully able to administer the access control mechanism for an object, 649 so this definition is left as implementation-specific. 650 651 This requirement will allow an entity that has privileges to 652 administer a particular subtree (meaning that entity can add, delete, 653 and update objects in that subtree), to place in the dgIdentity DNs 654 of only those objects it administers. 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Haripriya, et al. Expires July 9, 2007 [Page 12] 672 673Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 674 675 6765. Advertisement of support for dynamic groups 677 678 If the dynamic groups schema is not present on an LDAP server, it 679 MUST be assumed that the dynamic groups feature is not supported. 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727Haripriya, et al. Expires July 9, 2007 [Page 13] 728 729Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 730 731 7326. Dynamic Group Operations 733 7346.1. Existing Operations 735 736 The following operations SHOULD expose the dynamic groups 737 functionality. These operations do not require any change in the 738 LDAP protocol to be exchanged between the client and server. 739 7406.1.1. Access to resources in the directory 741 742 If access control items are set on a target resource object in the 743 directory, with the subject being a dynamic group object, then all 744 the members of the group object, including the dynamic members, will 745 get the same permissions on the target entry. This would be the most 746 useful application of dynamic groups as seen by an administrator 747 because it lets the server control access to resources based on 748 dynamic membership to a trustee (subject of ACI) of the resource. 749 The way to specify a dynamic ACL is currently implementation 750 specific, as there is no common ACL definition for LDAP, and hence 751 will be dealt with in a separate document or later (TO BE DONE). 752 7536.1.2. Reading a dynamic group object 754 755 When the member attributes of a dynamic group object is listed by the 756 client using an LDAP search operation, the member values returned 757 SHOULD contain both the static and dynamic members of the group 758 object. This functionality will not require a change to the 759 protocol, and the clients need not be aware of dynamic groups to 760 exploit this functionality. This feature is useful for clients that 761 determine access privileges to a resource by themselves, by reading 762 the members of a group object. It will also be useful to 763 administrators who want to see the result of the query URL that they 764 set on the dynamic group entry. Note that this overloads the 765 semantics of the 'member' and 'uniqueMember' attributes. This could 766 lead to some surprises for the client . 767 768 for example: Clients that read the member attribute of a dynamic 769 group object and then attempt to remove values (which were dynamic) 770 could get an error specifying such a value was not there. 771 772 Example: 773 774 Let cn=dg1,o=myorg be a dynamic group object with the following 775 attributes stored in the directory. 776 777 778 779 780 781 782 783Haripriya, et al. Expires July 9, 2007 [Page 14] 784 785Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 786 787 788 member: cn=admin,o=myorg 789 790 excludedMember: cn=guest,ou=finance,o=myorg 791 792 excludedMember: cn=robin,ou=finance,o=myorg 793 794 memberQueryURL: 795 ldap:///ou=finance,o=myorg??sub?(objectclass=organizationalPerson) 796 797 If there are 5 organizationalPerson objects under ou=finance,o=myorg 798 with common names bob, alice, john, robin, and guest, then the output 799 of a base-scope LDAP search at cn=dg1,o=myorg, with the attribute 800 list containing 'member' will be as follows: 801 802 dn: cn=dg1,o=myorg 803 804 member: cn=admin,o=myorg 805 806 member: cn=bob,ou=finance,o=myorg 807 808 member: cn=alice,ou=finance,o=myorg 809 810 member: cn=john,ou=finance,o=myorg 811 8126.1.3. 'Is Member Of' functionality 813 814 The LDAP compare operation allows one to discover whether a given DN 815 is in the membership list of a dynamic group. Again, the server 816 SHOULD produce consistent results among different authorization 817 identities when processing this request, as long as those identities 818 have the same access to the member or uniqueMember attribute. Using 819 the data from the example in Section 6.1.2, a compare on 820 cn=dg1,o=myorg, for the AVA member=cn=bob,ou=finance,o=myorg would 821 result in a response of compareTrue (assuming the bound identity was 822 authorized to compare the member attribute of cn=dg1,o=myorg). 823 824 Likewise, a search operation that contains an equalityMatch or 825 presence filter, naming the member or uniqueMember attribute as the 826 attribute (such as (member= cn=bob,ou=finance,o=myorg), or 827 (member=*)), will cause the server to evaluate this filter against 828 the rules given in Section 4.2.1.3 in the event that the search is 829 performed on a dynamic group object. As of this writing, no other 830 matching rules exist for the distinguished name syntax, thus no 831 requirements beyond equalityMatch are given here. 832 833 834 835 836 837 838 839Haripriya, et al. Expires July 9, 2007 [Page 15] 840 841Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 842 843 8446.2. New Extensions 845 846 The following new extensions are added for dynamic group support. 847 8486.2.1. Managing the static members of a dynamic group 849 850 Because a dynamic group overloads the semantics of the member and 851 uniqueMember attributes, a mechanism is needed to retrieve the static 852 values found in these attributes for management purposes. To serve 853 this need, a new attribute option is defined here called 'x-static'. 854 Attribute options are discussed in Section 2.5 of [2]. This option 855 SHALL only be specified with the 'member' or 'uniqueMember' 856 attribute. When the LDAP server does not understand the semantics of 857 this option on a given attribute, the option SHOULD be ignored. This 858 attribute option is only used to affect the transmitted values, and 859 does not impose sub-typing semantics on the attribute. 860 861 This option MAY be specified by a client during a search request in 862 the list of attributes to be returned, i.e. member;x-static. In this 863 case, the server SHALL only return those members of the dynamic group 864 that are statically listed as values of the member or uniqueMember 865 attribute. The evaluation process listed in Section 9 SHALL NOT be 866 used to populate the values to be returned. 867 868 This option MAY be specified is either an equalityMatch or presence 869 search filter. In this case, the server evaluates only the values 870 statically listed in the member or uniqueMember attribute, and does 871 not apply the evaluation process listed in Section 9. 872 873 This option MAY be specified in update operations such as add and 874 modify, but SHOULD be ignored, as its presence is semantically the 875 same as its non-presence. 876 877 Note to user: Performing a search to read a dynamic group, with a 878 filter item such as (member=*), and specifying member;x-static, may 879 result in a search result entry that has no member attribute. This 880 may seem counter-intuitive. 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895Haripriya, et al. Expires July 9, 2007 [Page 16] 896 897Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 898 899 9007. Performance Considerations 901 902 When the x-chain extension is present on the memberQueryURL, the 903 server MUST follow any search continuation references to other 904 servers while searching for dynamic members. This may be expensive 905 and slow in a true distributed environment. The dynamicGroup 906 implementation can consider a distributed caching feature to improve 907 the performance. An outline of such a distributed caching is given 908 below. 909 9107.1. Caching of Dynamic Members 911 912 Since the dynamic members of a group are computed every time the 913 group is accessed, the performance could be affected. An 914 implementation of dynamic groups can get around this problem by 915 caching the computed members of a dynamic group locally and using the 916 cached data subsequently. One way to do this is to create pseudo- 917 objects for each dynamic group on every server that holds an object 918 that is a dynamic member of the group. With this, the computation of 919 the dynamic members of a group reduces to the task of reading the 920 pseudo-objects from each server. These pseudo-objects need to be 921 linked from the original dynamic group to speed up the member 922 computation. Also, since these are cached objects, appropriate 923 timeouts need to be associated with the cache after which the cache 924 should be invalidated or refreshed 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951Haripriya, et al. Expires July 9, 2007 [Page 17] 952 953Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 954 955 9568. Security Considerations 957 958 This document discusses the use of one object as the identity 959 (Section 4.5) with which to read information for another object. If 960 the creation of the dgIdentity attribute is uncontrolled, an intruder 961 could potentially create a dynamic group with the identity of, say, 962 the administrator, to be able to read the directory as the 963 administrator, and see information which would be otherwise 964 unavailable to him. Thus, a person adding an object as identity of a 965 dynamic group should have appropriate permissions on the object being 966 added as identity. 967 968 This document also discusses using dynamic memberships to provide 969 access for resources in a directory. As the dynamic members are not 970 created by the administrator, there could be surprises for the 971 administrator in the form of certain objects getting access to 972 certain resources through dynamic membership, which the administrator 973 never intended. So the administrator should be wary of such 974 problems. The administrator could view the memberships and make sure 975 that anybody who is not supposed to be a member of a group is added 976 to the excludedMember list. 977 978 Denial of service attacks can be launched on an LDAP server, by 979 repeatedly searching for a dynamic group with a large membership list 980 and listing the member attribute. A more effective form of denial of 981 service attack could be launched by making searches of the form 982 (member="somedn") at the top of tree and closing the client 983 connection as soon as the search starts. Some administrative limits 984 be imposed to avoid such situations. 985 986 The dynamic groups feature could be potentially misused by a user to 987 circumvent any administrative size-limit restriction placed on the 988 server. In order to search an LDAP server and obtain the names of 989 all the objects on the server irrespective of admin size-limit 990 restriction on the server, the LDAP user could create a dynamic group 991 with a memberQueryURL which matches all objects in the tree, and list 992 just that one object. 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007Haripriya, et al. Expires July 9, 2007 [Page 18] 1008 1009Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1010 1011 10129. IANA Considerations 1013 1014 There are no IANA considerations. 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063Haripriya, et al. Expires July 9, 2007 [Page 19] 1064 1065Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1066 1067 106810. Conclusions 1069 1070 This document discusses the syntax, semantics and usage of dynamic 1071 groups in LDAPv3. 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119Haripriya, et al. Expires July 9, 2007 [Page 20] 1120 1121Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1122 1123 112411. Normative References 1125 1126 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1127 Levels", BCP 14, RFC 2119, March 1997. 1128 1129 [2] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): 1130 Directory Information Models", RFC 4512, June 2006. 1131 1132 [3] Smith, M. and T. Howes, "Lightweight Directory Access Protocol 1133 (LDAP): Uniform Resource Locator", RFC 4516, June 2006. 1134 1135 [4] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): 1136 Schema for User Applications", RFC 4519, June 2006. 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175Haripriya, et al. Expires July 9, 2007 [Page 21] 1176 1177Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1178 1179 1180Appendix A. Example Values for memberQueryURL 1181 1182 1. This memberQueryURL value specifies the membership criteria for a 1183 dynamic group entry as "all inetorgperson entries that also have 1184 their title attribute set to 'manager', and are in the DIT-wide 1185 subtree under ou=hr,o=myorg ". 1186 1187 memberQueryURL: ldap:/// 1188 ou=hr,o=myorg??sub?(& 1189 (objectclass=inetorgperson)(title=manager))? x-chain 1190 1191 2. This value lets the user specify the membership criteria for a 1192 dynamic group entry as "all entries on the local server, that 1193 either have unix accounts or belong to the unix department, and 1194 are under the engineering container ". 1195 1196 memberQueryURL: ldap:///ou=eng,o=myorg??sub? 1197 (|(objectclass=posixaccount)(department=unix)) 1198 1199 3. These values let the user specify the membership criteria as "all 1200 inetorgperson entries on the local server, in either the 1201 ou=eng,o=myorg or ou=support,o=myorg" subtrees. 1202 1203 memberQueryURL: 1204 ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson) 1205 1206 memberQueryURL: 1207 ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson) 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231Haripriya, et al. Expires July 9, 2007 [Page 22] 1232 1233Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1234 1235 1236Appendix B. Acknowledgments 1237 1238 Funding for the RFC Editor function is currently provided by the 1239 Internet Society. 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287Haripriya, et al. Expires July 9, 2007 [Page 23] 1288 1289Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1290 1291 1292Authors' Addresses 1293 1294 Haripriya S 1295 Novell, Inc. 1296 49/1 & 49/3 Garvebhavi Palya, 1297 7th Mile, Hosur Road 1298 Bangalore, Karnataka 560068 1299 India 1300 1301 Email: sharipriya@novell.com 1302 1303 1304 Jaimon Jose (editor) 1305 Novell, Inc. 1306 49/1 & 49/3 Garvebhavi Palya, 1307 7th Mile, Hosur Road 1308 Bangalore, Karnataka 560068 1309 India 1310 1311 Email: jjaimon@novell.com 1312 1313 1314 Jim Sermersheim 1315 Novell, Inc. 1316 1800 South Novell Place 1317 Provo, Utah 84606 1318 US 1319 1320 Email: jimse@novell.com 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343Haripriya, et al. Expires July 9, 2007 [Page 24] 1344 1345Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007 1346 1347 1348Full Copyright Statement 1349 1350 Copyright (C) The Internet Society (2007). 1351 1352 This document is subject to the rights, licenses and restrictions 1353 contained in BCP 78, and except as set forth therein, the authors 1354 retain all their rights. 1355 1356 This document and the information contained herein are provided on an 1357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1359 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1360 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1361 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1363 1364 1365Intellectual Property 1366 1367 The IETF takes no position regarding the validity or scope of any 1368 Intellectual Property Rights or other rights that might be claimed to 1369 pertain to the implementation or use of the technology described in 1370 this document or the extent to which any license under such rights 1371 might or might not be available; nor does it represent that it has 1372 made any independent effort to identify any such rights. Information 1373 on the procedures with respect to rights in RFC documents can be 1374 found in BCP 78 and BCP 79. 1375 1376 Copies of IPR disclosures made to the IETF Secretariat and any 1377 assurances of licenses to be made available, or the result of an 1378 attempt made to obtain a general license or permission for the use of 1379 such proprietary rights by implementers or users of this 1380 specification can be obtained from the IETF on-line IPR repository at 1381 http://www.ietf.org/ipr. 1382 1383 The IETF invites any interested party to bring to its attention any 1384 copyrights, patents or patent applications, or other proprietary 1385 rights that may cover technology that may be required to implement 1386 this standard. Please address the information to the IETF at 1387 ietf-ipr@ietf.org. 1388 1389 1390Acknowledgment 1391 1392 Funding for the RFC Editor function is provided by the IETF 1393 Administrative Support Activity (IASA). 1394 1395 1396 1397 1398 1399Haripriya, et al. Expires July 9, 2007 [Page 25] 1400 1401