--- /dev/null
+
+
+
+Network Working Group S. Haripriya
+Internet-Draft Jaimon. Jose, Ed.
+Updates: 02 (if approved) Jim. Sermersheim
+Intended status: Standards Track Novell, Inc.
+Expires: July 9, 2007 January 5, 2007
+
+
+ LDAP: Dynamic Groups for LDAPv3
+ draft-haripriya-dynamicgroup-02
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ 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.
+
+ This Internet-Draft will expire on July 9, 2007.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 1]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+Abstract
+
+ This document 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 may also be used to find the
+ groups that an object is a member of. This feature eliminates a huge
+ amount of the administrative effort required today for maintaining
+ group memberships and role-based operations in large enterprises.
+
+
+Table of Contents
+
+ 1. Conventions used in this document . . . . . . . . . . . . . . 4
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Requirements of a dynamic group feature . . . . . . . . . . . 6
+ 4. Schema and Semantic Definitions for Dynamic Groups . . . . . . 7
+ 4.1. Object Classes . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1.1. dynamicGroup . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1.2. dynamicGroupOfUniqueNames . . . . . . . . . . . . . . 7
+ 4.1.3. dynamicGroupAux . . . . . . . . . . . . . . . . . . . 7
+ 4.1.4. dynamicGroupOfUniqueNamesAux . . . . . . . . . . . . . 7
+ 4.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.2.1. memberQueryURL . . . . . . . . . . . . . . . . . . . . 8
+ 4.2.2. excludedMember . . . . . . . . . . . . . . . . . . . . 11
+ 4.3. member . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.4. uniqueMember . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.5. dgIdentity . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.5.1. dgIdentity - Security implications . . . . . . . . . . 12
+ 5. Advertisement of support for dynamic groups . . . . . . . . . 13
+ 6. Dynamic Group Operations . . . . . . . . . . . . . . . . . . . 14
+ 6.1. Existing Operations . . . . . . . . . . . . . . . . . . . 14
+ 6.1.1. Access to resources in the directory . . . . . . . . . 14
+ 6.1.2. Reading a dynamic group object . . . . . . . . . . . . 14
+ 6.1.3. 'Is Member Of' functionality . . . . . . . . . . . . . 15
+ 6.2. New Extensions . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.2.1. Managing the static members of a dynamic group . . . . 16
+ 7. Performance Considerations . . . . . . . . . . . . . . . . . . 17
+ 7.1. Caching of Dynamic Members . . . . . . . . . . . . . . . . 17
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . . 21
+ Appendix A. Example Values for memberQueryURL . . . . . . . . . . 22
+ Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 2]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+ Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 3]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+1. 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 [1].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 4]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+2. Introduction
+
+ The LDAP schema described in [4] 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 DSAs worry about who
+ are the actual members. This solution is more scalable and reduces
+ administrative costs. This can also supplement static groups in LDAP
+ to provide flexibility to the user.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 5]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+3. 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. Applications must be able to use dynamic groups in the same way
+ that they are able to use static groups for listing members and
+ for membership evaluation.
+
+ 3. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 6]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+4. Schema and Semantic Definitions for Dynamic Groups
+
+ The dynamic group classes are defined by the following schema
+
+4.1. Object Classes
+
+ The following object classes MUST be supported, and their semantics
+ understood by the server, for it to support the dynamic groups
+ feature.
+
+4.1.1. dynamicGroup
+
+ ( <OID.TBD> 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 [4].
+
+4.1.2. dynamicGroupOfUniqueNames
+
+ ( <OID.TBD> 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 [4].
+
+4.1.3. dynamicGroupAux
+
+ ( <OID.TBD> 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 [4].
+
+4.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 [4].
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 7]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+4.2. Attributes
+
+ The following attribute names MUST be supported by the server.
+
+4.2.1. memberQueryURL
+
+ This attribute describes the membership of the list using an LDAPURL
+ [3].
+
+ (<OID.TBD> NAME 'memberQueryURL' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The value of memberQueryURL is encoded as an LDAPURL [3]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 8]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+ The BNF from [3] is listed here for reference.
+ldapurl = scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn
+ [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION
+ extensions]]]]]
+ ; <host> and <port> are defined
+ ; in Sections 3.2.2 and 3.2.3
+ ; of [RFC3986].
+ ; <filter> is from Section 3 of
+ ; [RFC4515], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+scheme = "ldap"
+dn = distinguishedName ; From Section 3 of [RFC4514],
+ ; subject to the provisions of
+ ; the "Percent-Encoding"
+ ; section below.
+attributes = attrdesc *(COMMA attrdesc)
+attrdesc = selector *(COMMA selector)
+selector = attributeSelector ; From Section 4.5.1 of
+ ; [RFC4511], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+scope = "base" / "one" / "sub"
+extensions = extension *(COMMA extension)
+extension = [EXCLAMATION] extype [EQUALS exvalue]
+extype = oid ; From section 1.4 of [RFC4512].
+exvalue = LDAPString ; From section 4.1.2 of
+ ; [RFC4511], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+EXCLAMATION = %x21 ; exclamation mark ("!")
+SLASH = %x2F ; forward slash ("/")
+COLON = %x3A ; colon (":")
+QUESTION = %x3F ; question mark ("?")
+
+
+ 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.
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 9]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+4.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.
+
+4.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.
+
+4.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 a dynamic or a
+ static group, the static or dynamic members of M SHALL NOT be
+ considered as members of G. M is a member of G though.
+
+ The last condition is imposed because
+
+ o Recursively evaluating members of members may degrade the
+ performance of the server drastically.
+
+ o Looping may occur particularly in situations where the search
+ chains across multiple-servers.
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 10]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+ o Dynamic membership assertions (compare operation) cannot be
+ optimized if recursive memberships are allowed. Without
+ recursion, comparisons can be made light-weight.
+
+4.2.2. excludedMember
+
+ ( <OID.TBD> 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.
+
+4.3. member
+
+ ( 2.5.4.31 NAME 'member' SUP distinguishedName )
+
+ Defined in [4], 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.
+
+4.4. uniqueMember
+
+ ( 2.5.4.32 NAME 'uniqueMember' SUP distinguishedName )
+
+ Defined in [4], 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.
+
+4.5. dgIdentity
+
+ ( <OID.TBD> 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
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 11]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+ 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.
+
+4.5.1. dgIdentity - Security implications
+
+ 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 12]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+5. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 13]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+6. Dynamic Group Operations
+
+6.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.
+
+6.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).
+
+6.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.
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 14]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+ 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
+
+ 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
+
+6.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 6.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 4.2.1.3 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.
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 15]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+6.2. New Extensions
+
+ The following new extensions are added for dynamic group support.
+
+6.2.1. Managing the static members of a dynamic group
+
+ Because a dynamic group overloads the semantics of the member and
+ uniqueMember attributes, a mechanism is needed to retrieve 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 2.5 of [2]. 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 SHOULD be 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
+ result in a search result entry that has no member attribute. This
+ may seem counter-intuitive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 16]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+7. Performance Considerations
+
+ When the x-chain extension is present on the memberQueryURL, the
+ server MUST follow any search continuation references to other
+ servers while searching for dynamic members. This may be expensive
+ and slow in a true distributed environment. The dynamicGroup
+ implementation can consider a distributed caching feature to improve
+ the performance. An outline of such a distributed caching is given
+ below.
+
+7.1. Caching of Dynamic Members
+
+ Since the dynamic members of a group are computed every time the
+ group is accessed, the performance could be affected. An
+ implementation of dynamic groups can get around this problem by
+ caching the computed members of a dynamic group locally and using the
+ cached data subsequently. One way to do this is to create pseudo-
+ objects for each dynamic group on every server that holds an object
+ that is a dynamic member of the group. With this, the computation of
+ the dynamic members of a group reduces to the task of reading the
+ pseudo-objects from each server. These pseudo-objects need to be
+ linked from the original dynamic group to speed up the member
+ computation. Also, since these are cached objects, appropriate
+ timeouts need to be associated with the cache after which the cache
+ should be invalidated or refreshed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 17]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+8. Security Considerations
+
+ This document discusses the use of one object as the identity
+ (Section 4.5) 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="somedn") at the top of tree and closing the client
+ connection as soon as the search starts. Some administrative limits
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 18]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+9. IANA Considerations
+
+ There are no IANA considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 19]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+10. Conclusions
+
+ This document discusses the syntax, semantics and usage of dynamic
+ groups in LDAPv3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 20]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+11. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP):
+ Directory Information Models", RFC 4512, June 2006.
+
+ [3] Smith, M. and T. Howes, "Lightweight Directory Access Protocol
+ (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
+
+ [4] Sciberras, A., "Lightweight Directory Access Protocol (LDAP):
+ Schema for User Applications", RFC 4519, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 21]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+Appendix A. Example Values for memberQueryURL
+
+ 1. 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=hr,o=myorg??sub?(&
+ (objectclass=inetorgperson)(title=manager))? x-chain
+
+ 2. 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=posixaccount)(department=unix))
+
+ 3. 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.
+
+ memberQueryURL:
+ ldap:///ou=eng,o=myorg??sub?(objectclass=inetorgperson)
+
+ memberQueryURL:
+ ldap:///ou=support,o=myorg??sub?(objectclass=inetorgperson)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 22]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+Appendix B. Acknowledgments
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 23]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+Authors' Addresses
+
+ Haripriya S
+ Novell, Inc.
+ 49/1 & 49/3 Garvebhavi Palya,
+ 7th Mile, Hosur Road
+ Bangalore, Karnataka 560068
+ India
+
+ Email: sharipriya@novell.com
+
+
+ Jaimon Jose (editor)
+ Novell, Inc.
+ 49/1 & 49/3 Garvebhavi Palya,
+ 7th Mile, Hosur Road
+ Bangalore, Karnataka 560068
+ India
+
+ Email: jjaimon@novell.com
+
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606
+ US
+
+ Email: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 24]
+\f
+Internet-Draft LDAP: Dynamic Groups for LDAPv3 January 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Haripriya, et al. Expires July 9, 2007 [Page 25]
+\f
projects / openldap / commitdiff