Haripriya S. Internet Draft Jaimon C. Jose Jim Sermersheim draft-haripriya-dynamicgroup-01.txt Novell, Inc Expires: August 2003 March 2003 LDAP: Dynamic Groups for LDAPV3 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract This draft describes the requirements, semantics, schema elements, and operations needed for a dynamic group feature in LDAP. A dynamic group is defined here as a group object with a membership list of distinguished names that is dynamically generated using LDAP search criteria. The dynamic membership list may then be interrogated by LDAP search and compare operations, and be used to identify a group of access control subjects. This feature eliminates a huge amount of the administrative effort required today for maintaining group memberships and role-based operations in large enterprises. 3. Table of Contents 1. Status of this Memo.............................................1 2. Abstract........................................................1 3. Table of Contents...............................................1 4. Overview........................................................2 5. Conventions used in this document...............................2 6. Requirements of a dynamic group feature.........................2 7. Schema definitions for dynamic groups...........................2 8. Semantics of membership.........................................6 9. Operations exposing dynamic groups functionality................7 10. Security Considerations........................................9 11. References.....................................................9 12. Author's Addresses............................................10 Internet Draft - Expires August 2003 1 Dynamic Groups for LDAP March 2003 4. Overview The LDAP schema described in [RFC2256] defines two object classes: ægroupOfNamesÆ, and ægroupOfUniqueNamesÆ, that hold a static list of distinguished names in their 'member' or 'uniqueMember' attributes respectively, and are typically used to describe a group of objects for various functions. These grouping functions range from simple group membership applications such as email distribution lists to describing common authorization for a set of users The administration and updating of these membership lists must be done by specifically modifying the DN values in the member or uniqueMember attributes. Thus, each time a change in membership happens, a process must exist which adds or removes the particular entryÆs DN from the member attribute. For example, consider an organization, where the access to its facilities is controlled by membership in a directory group. Assume that all employees in a department have been added to the group that provides access to the required department facility. If an employee moves from one department to another, the administrator must remove the employee from one group and add him to another. Similarly consider an organization that wants to provide access to its facility, to both interns and employees on weekdays, but only to employees on weekends. It would be effort-consuming to achieve this with static groups. "Dynamic groups" are like normal groups, but they let one specify criteria to be used for evaluating membership to a group; the membership of the group is determined dynamically by the directory servers involved. This lets the group administrator define the membership in terms of attributes, and let the DSA worry about what is an actual member. This solution is more scalable and reduces administrative costs. This can also supplement static groups in LDAP to provide flexibility to the user. 5. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [1]. 6. Requirements of a dynamic group feature The following requirements SHOULD be met by a proposal for the dynamic groups feature: 1. Creation and administration of dynamic groups should be done using normal LDAP operations. 2. Interrogation of a dynamic group's membership should be done using normal LDAP operations, and should be consistent. This means that all authorization identities with the same permission to the membership attribute of a dynamic group (such as 'read') should be presented with the same membership list. 3. The membership list of a dynamic group should be allowed to represent an access control subject. 7. Schema and Semantic definitions for dynamic groups The dynamic group class of objects are described by the following schema. 7.1 Object Classes Internet-Draft - Expires August 2003 2 Dynamic Groups for LDAP March 2003 The following object classes MUST be supported, and their semantics understood by the server, for it to support the dynamic groups feature. 7.1.1 dynamicGroup ( NAME 'dynamicGroup' SUP groupOfNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity )) This structural object class is used to create a dynamic group object. It is derived from groupOfNames, which is defined in [RFC2256]. 7.1.2 dynamicGroupOfUniqueNames ( NAME 'dynamicGroupOfUniqueNames' SUP groupOfUniqueNames STRUCTURAL MAY (memberQueryURL $ excludedMember $ dgIdentity )) This structural object class is used to create a dynamic group object whose membership list is held in a uniqueMember attribute. It is derived from groupOfUniqueNames, which is defined in [RFC2256]. 7.1.3 dynamicGroupAux ( NAME 'dynamicGroupAux' SUP groupOfNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity )) This auxiliary object class is used to convert an existing object to a dynamic group or to create an object of another object class but with dynamic group capabilities. This is derived from groupOfNames which is defined in [RFC2256]. 7.1.4 dynamicGroupOfUniqueNamesAux ( OID.TBD NAME 'dynamicGroupOfUniqueNamesAux' SUP groupOfUniqueNames AUXILIARY MAY (memberQueryURL $ excludedMember $ dgIdentity )) This auxiliary object class is used to convert an existing object to a dynamic group of unique names or to create an object of another object class but with dynamic group capabilities. This is derived from groupOfUniqueNames which is defined in [RFC2256]. 7.2 Attributes The following attribute types MUST be supported by the server. 7.2.1 memberQueryURL This attribute describes the membership of the list using an LDAPURL [RFC2255].. ( NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) The value of memberQueryURL is encoded as an 'ldapurl'. The BNF from [RFC2255] is listed here for reference. ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes] ["?" [scope] ["?" [filter] ["?" extensions]]]]]] Internet-Draft - Expires August 2003 3 Dynamic Groups for LDAP March 2003 scheme = "ldap" attributes = attrdesc *("," attrdesc) scope = "base" / "one" / "sub" dn = distinguishedName from Section 3 of [RFC2256] hostport = hostport from Section 5 of [RFC1738] attrdesc = AttributeDescription from Section 4.1.5 of [RFC2252] filter = filter from Section 4 of [RFC2254] extensions = extension *("," extension) extension = ["!"] extype ["=" exvalue] extype = token / xtoken exvalue = LDAPString from section 4.1.2 of [RFC2252] token = oid from section 4.1 of [3] xtoken = ("X-" / "x-") token For the purpose of evaluating dynamic members, the directory server uses only the dn, scope, filter and extensions fields. All remaining fields are ignored if specified. If other fields are specified, the server SHALL ignore them and MAY omit them when presenting the value to a client. The dn is used to specify the base dn from which to start the search for dynamic members. The scope specifies the scope with respect to the dn in which to search for dynamic members. The filter specifies the criteria with which to select objects for dynamic membership. 7.2.1.1 The x-chain extension A new extension is defined for use of the memberQueryURL in dynamic groups, named 'x-chain'. x-chain does not take a value. When x-chain is present, the server must follow any search continuation references to other servers while searching for dynamic members. When x-chain is absent, the dynamic members computed will be only those that are present on the server from which the search is made. A directory server supporting the memberQueryURL MAY support the x-chain extension, thus the x-chain extension could be critical or non-critical as specified by the '!' prefix to the extension type. 7.2.1.2 Semantics of multiple values for memberQueryURL The memberQueryURL MAY have multiple values, and in that case, the members of the dynamic group will be the union of the members computed using each individual URL value. This is useful in specifying a group membership that is made up from subtrees rooted at different base DNs, and possibly using different filters.. 7.2.1.3 Condition of membership An object O is a member of a dynamic group G if and only if (( O is a value of the 'member' or 'uniqueMember' attribute of G) OR (( O is selected by the membership criteria specified in the 'memberQueryURL' attribute values of G) AND ( O is not listed in the 'excludedMember' attribute of G) )) If a member M of a dynamic group G happens to be dynamic or static group, the static or dynamic members of M SHALL NOT be considered as members of G. M is a member of G though. Internet-Draft - Expires August 2003 4 Dynamic Groups for LDAP March 2003 The last condition is imposed because a. Recursively evaluating members of members may degrade the performance of the server drastically. b. Looping may occur particularly in situations where the search chains across multiple-servers. c. Dynamic membership assertions (compare operation) cannot be optimized if recursive memberships are allowed. Without recursion, comparisons can be made light-weight. 7.2.1.4 Examples of memberQueryURL values memberQueryURL: ldap:///ou=hr,o=myorg??sub? (&(objectclass=inetorgperson)(title=manager))? x-chain This memberQueryURL value specifies the membership criteria for a dynamic group entry as "all inetorgperson entries that also have their title attribute set to 'manager', and are in the DIT-wide subtree under ou=hr,o=myorg ". memberQueryURL: ldap:///ou=eng,o=myorg??sub? (|(objectclass=posixaccount)(department=unix)) This value lets the user specify the membership criteria for a dynamic group entry as "all entries on the local server, that either have unix accounts or belong to the unix department, and are under the engineering container ". memberQueryURL: ldap:///ou=eng,o=myorg??sub? (objectclass=inetorgperson) memberQueryURL: ldap:///ou=support,o=myorg??sub? (objectclass=inetorgperson) These values let the user specify the membership criteria as "all inetorgperson entries on the local server, in either the ou=eng,o=myorg or ou=support,o=myorg" subtrees. 7.2.2 excludedMember ( NAME 'excludedMember' SUP distinguishedName ) This attribute is used to exclude entries from being a dynamic member of a dynamic group. Thus an entry is a dynamic member of a dynamic group if and only if it is selected by the member criteria specified by the 'memberQueryURL' attribute or explicitly added to the member or uniqueMember attribute, and it is not listed in the 'excludedMember' attribute. 7.2.3 member ( 2.5.4.31 NAME 'member' SUP distinguishedName ) Defined in [RFC2256], this attribute is overloaded when used in the context of a dynamic group. It is used to explicitly specify static members of a dynamic group. If the same entry is listed in both the 'member' and 'excludedMember' attributes, the 'member' overrides the 'excludedMember', and the entry is considered to be a member of the group. This attribute is also used to interrogate both the static and dynamic member values of a dynamic group object. Subclasses of this attribute are NOT considered in this manner. Internet-Draft - Expires August 2003 5 Dynamic Groups for LDAP March 2003 7.2.4 uniqueMember ( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName ) Defined in [RFC2256], this attribute is overloaded when used in the context of a dynamic group. It is used to specify the static members of a dynamic group. If the same entry is listed in both the 'uniqueMember' and 'excludedMember' attributes, the 'uniqueMember' overrides the 'excludedMember', and the entry is considered to be a member of the group. This attribute is also used to interrogate both the static and dynamic member values of a dynamic group object. Subclasses of this attribute are NOT considered in this manner. 7.2.5 dgIdentity ( NAME 'identity' SUP distinguishedName SINGLE-VALUE ) In order to provide consistent results when processing the search criteria, the server must use a single authorization identity. If the authorization of the bound identity is used, the membership list will vary, from identity to identity due to differing access controls. This may either be done by the server authenticating as the dgIdentity prior to performing a search or compare operation, or may be done by simply assuming the authorization of the dgIdentity when performing those operations. As server implementations vary, so may the mechanisms to achieve consistent results through the use of the dgIdentity. In the case that the server authenticates as the dgIdentity, it may be required by the server that this identity have proper authentication credentials, and it may be required that this identity reside in the DIB of the local server. In the absence of an identity value, or in case the identity value cannot be used, the server will process the memberQueryURL as the anonymous identity. This attribute MAY be supported, and represents the identity the server will use for processing the memberQueryURL. 7.2.5.1 dgIdentity security considerations Because this attribute indirectly but effectively grants anyone with read or compare access to the member or uniqueMember attribute sufficient permission to gain a DN result set from the memberQueryURL, server implementations SHOULD NOT allow this attribute to be populated with the DN of any object that is not administered by the identity making the change to this attribute. For purposes of this document, to "administer an object" indicates that the administrative identity has the ability to fully update the access control mechanism in place for the object in question. As of this writing, there is no way to describe further what it means to be fully able to administer the access control mechanism for an object, so this definition is left as implementation- specific. This requirement will allow an entity that has privileges to administer a particular subtree (meaning that entity can add, delete, and update objects in that subtree), to place in the dgIdentity DNs of only those objects it administers. 8. Advertisement of support for dynamic groups If the dynamic groups schema is not present on an LDAP server, it MUST be assumed that the dynamic groups feature is not supported. Internet-Draft - Expires August 2003 6 Dynamic Groups for LDAP March 2003 9. Operations exposing dynamic groups functionality 9.1 Existing operations The following operations SHOULD expose the dynamic groups functionality. These operations do not require any change in the LDAP protocol to be exchanged between the client and server. 9.1.1 Access to resources in the directory If access control items are set on a target resource object in the directory, with the subject being a dynamic group object, then all the members of the group object, including the dynamic members, will get the same permissions on the target entry. This would be the most useful application of dynamic groups as seen by an administrator because it lets the server control access to resources based on dynamic membership to a trustee (subject of ACI) of the resource. The way to specify a dynamic ACL is currently implementation specific, as there is no common ACL definition for LDAP, and hence will be dealt with in a separate document or later (TO BE DONE). 9.1.2 Reading a dynamic group object When the member attributes of a dynamic group object is listed by the client using an LDAP search operation, the member values returned SHOULD contain both the static and dynamic members of the group object. This functionality will not require a change to the protocol, and the clients need not be aware of dynamic groups to exploit this functionality. This feature is useful for clients that determine access privileges to a resource by themselves, by reading the members of a group object. It will also be useful to administrators who want to see the result of the query URL that they set on the dynamic group entry. Note that this overloads the semantics of the 'member' and 'uniqueMember' attributes. This could lead to some surprises for the client û for example: Clients that read the member attribute of a dynamic group object and then attempt to remove values (which were dynamic) could get an error specifying such a value was not there. Example: Let cn=dg1,o=myorg be a dynamic group object with the following attributes stored in the directory. member: cn=admin,o=myorg excludedMember: cn=guest,ou=finance,o=myorg excludedMember: cn=robin,ou=finance,o=myorg memberQueryURL: ldap:///ou=finance,o=myorg??sub? (objectclass=organizationalPerson) If there are 5 organizationalPerson objects under ou=finance,o=myorg with common names bob, alice, john, robin, and guest, then the output of a base-scope LDAP search at cn=dg1,o=myorg, with the attribute list containing 'member' will be as follows: dn: cn=dg1,o=myorg Internet-Draft - Expires August 2003 7 Dynamic Groups for LDAP March 2003 member: cn=admin,o=myorg member: cn=bob,ou=finance,o=myorg member: cn=alice,ou=finance,o=myorg member: cn=john,ou=finance,o=myorg 9.1.3 'Is Member Of' functionality The LDAP compare operation allows one to discover whether a given DN is in the membership list of a dynamic group. Again, the server SHOULD produce consistent results among different authorization identities when processing this request, as long as those identities have the same access to the member or uniqueMember attribute. Using the data from the example in Section 10.1.2, a compare on cn=dg1,o=myorg, for the AVA member=cn=bob,ou=finance,o=myorg would result in a response of compareTrue (assuming the bound identity was authorized to compare the member attribute of cn=dg1,o=myorg). Likewise, a search operation that contains an equalityMatch or presence filter, naming the member or uniqueMember attribute as the attribute (such as (member= cn=bob,ou=finance,o=myorg), or (member=*)), will cause the server to evaluate this filter against the rules given in Section 9 in the event that the search is performed on a dynamic group object. As of this writing, no other matching rules exist for the distinguished name syntax, thus no requirements beyond equalityMatch are given here. 9.2 New extensions 9.2.1 Managing the static members of a dynamic group Because a dynamic group overloads the semantics of the member or uniqueMember attribute, a mechanism is needed to interrogate the static values found in these attributes for management purposes. To serve this need, a new attribute option is defined here called 'x- static'. Attribute options are discussed in Section 4.1.5 of [RFC2251]. This option SHALL only be specified with the 'member' or 'uniqueMember' attribute. When the LDAP server does not understand the semantics of this option on a given attribute, the option SHOULD be ignored. This attribute option is only used to affect the transmitted values, and does not impose sub-typing semantics on the attribute. This option MAY be specified by a client during a search request in the list of attributes to be returned, i.e. member;x-static. In this case, the server SHALL only return those members of the dynamic group that are statically listed as values of the member or uniqueMember attribute. The evaluation process listed in Section 9 SHALL NOT be used to populate the values to be returned. This option MAY be specified is either an equalityMatch or presence search filter. In this case, the server evaluates only the values statically listed in the member or uniqueMember attribute, and does not apply the evaluation process listed in Section 9. This option MAY be specified in update operations such as add and modify, but is ignored, as its presence is semantically the same as its non-presence. Note to user: Performing a search to read a dynamic group, with a filter item such as (member=*), and specifying member;x-static, may Internet-Draft - Expires August 2003 8 Dynamic Groups for LDAP March 2003 result in a search result entry that has no member attribute. This may seem counter-intuitive. 10. Security Considerations This document discusses the use of one object as the identity (see 7.2.5.1) with which to read information for another object. If the creation of the dgIdentity attribute is uncontrolled, an intruder could potentially create a dynamic group with the identity of, say, the administrator, to be able to read the directory as the administrator, and see information which would be otherwise unavailable to him. Thus, a person adding an object as identity of a dynamic group should have appropriate permissions on the object being added as identity. This document also discusses using dynamic memberships to provide access for resources in a directory. As the dynamic members are not created by the administrator, there could be surprises for the administrator in the form of certain objects getting access to certain resources through dynamic membership, which the administrator never intended. So the administrator should be wary of such problems. The administrator could view the memberships and make sure that anybody who is not supposed to be a member of a group is added to the excludedMember list. Denial of service attacks can be launched on an LDAP server, by repeatedly searching for a dynamic group with a large membership list and listing the member attribute. A more effective form of denial of service attack could be launched by making searches of the form ômember=ö at the top of tree and closing the client connection as soon as the search starts. Some administrative limits can be imposed to avoid such situations. The dynamic groups feature could be potentially misused by a user to circumvent any administrative size-limit restriction placed on the server. In order to search an LDAP server and obtain the names of all the objects on the server irrespective of admin size-limit restriction on the server, the LDAP user could create a dynamic group with a memberQueryURL which matches all objects in the tree, and list just that one object. 11. References [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [RFC2254] Howes, T., "A String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC2255] Howes, T., Smith, M., "The LDAP URL Format", RFC 2255, December 1997. [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use Internet-Draft - Expires August 2003 9 Dynamic Groups for LDAP March 2003 with LDAPv3", RFC 2256, December 1997. [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels," RFC 2119, March 1997. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. 12. AuthorsÆ Addresses Haripriya S. Novell Inc. 49/1 & 49/3 Garvebhavi Palya 7th Mile Hosur Rd. Phone: +91-80-5731858 extn: 2121 Bangalore India Email: sharipriya@novell.com Jaimon C. Jose Novell Inc. 49/1 & 49/3 Garvebhavi Palya 7th Mile Hosur Rd. Phone: +91-80-5731858 extn: 2020 Bangalore India Email: jjaimon@novell.com Jim Sermersheim Novell Inc. 1800 South Novell Place Phone: +1 801 861-3088 Provo, Utah 84606, USA Email: jimse@novell.com Internet-Draft - Expires August 2003 10