Internet DRAFT - draft-haripriya-ldapext-dynamicgroup
draft-haripriya-ldapext-dynamicgroup
Haripriya S.
Internet Draft Jaimon C. Jose
Jim Sermersheim
draft-haripriya-ldapext-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
( <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 [RFC2256].
7.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 [RFC2256].
7.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 [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]..
(<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'. 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
( <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.
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
( <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 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=<somedn>÷ 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
