Internet Draft C. Brooks draft-brooks-ldap-sets-00.txt Individual Category: Standards Track Delaware, USA Expires April 2013 October 25, 2012 LDAP schema for pragmatic representation of sets draft-brooks-ldap-sets-00.txt Abstract In the absence of a generically useful standard for the organization of groups or lists of objects within an LDAP compatible directory server, standards driven software is incapable of achieving functional parity with proprietary software that uses sane object grouping methods. This document defines an immediately useful mechanism based on real world practices and problems as commonly encountered by users of LDAPv3 and requests discussion and suggestions for improvements. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents primarily intended to lead to the creation of standards and documentation facilitating system interoperability and intersystem communications within the global Internet community. Distribution of this document is unlimited. Internet-Drafts are 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 "works in progress." By submitting this Internet-Draft to the IESG, the author represents that any applicable patent or other IPR claims of which he is aware have been disclosed, and any of which he becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 30th, 2013. Copyright Notice Copyright (c) 2012 Charles T. Brooks. Some or all rights may be Brooks Expires April 2013 [Page 1] Internet Draft LDAP psets October 25, 2012 reassigned to the appropriate agent, whenever I figure out who that is, in conformance with the provisions of BCP 78 and BCP 79. Table of Contents 1. Introduction ....................................................2 2. Nomenclature ....................................................2 3. Required Capabilities ...........................................3 3.1 A memberOf attribute that can be applied to any object ......3 3.2 Support for frequently required queries as a single search ..3 3.3 Represent Sets Containing a Single Object ...................4 3.4 Represent the Empty Set .....................................4 3.5 Directly Include Objects Outside the Directory (ur-objects) .4 3.6 Indirectly Refer to Objects Within the Directory ............4 4. ObjectClasses and Attributes ...................................5 4.1 The pset auxiliary objectClass ..............................5 4.2 The psetMember auxiliary objectClass ........................5 4.3 The memberOfPset Attribute Type .............................6 4.4 The psetScope Attribute Type ................................7 4.5 The psetMembership Attribute Type ...........................7 5. Security Considerations .......................................10 5.1 Catholic Security Practices for LDAP Accessible Directories 10 5.2 Expansion of URIs by Directory Services ....................10 5.3 Denial of Service through Pset Recursion ...................10 5.4 PsetScope is not inherently an Access Control Mechanism ....10 5.5 Difficulties of defining Default Security Settings .........10 6. IANA Considerations ............................................11 7. References ....................................................11 7.1. Normative References ......................................11 7.2. Informative References ....................................14 Appendix A: A Brief Discussion of Set Attribute Applicability ....14 A.1 Attributes may Apply to All Members but not to the Set .....15 A.2 Attributes may Apply to the Set but not to All Members .....15 A.3 Attributes applying equally to sets and their members ......15 A.4 Attributes that do not apply to either .....................15 Appendix B: Psets and Zermelo-Fraenkel Axioms ....................16 Appendix C: Examples of Using Psets to Solve Common Problems .....16 C.1 A Very Simple Mailing List .................................17 C.2 A Very Useful Polymorphic Set ..............................17 Appendix D: Other Efforts and their Shortcomings .................17 D.1 RFC3671 Collective LDAP Attributes .........................17 D.2 RFC4519 groupOfNames .......................................17 D.3 RFC4519 groupOfUniqueNames .................................17 D.4 groupOfEntries (draft-findlay-ldap-groupofentries-00) ......17 D.5 RFC2307 posixGroup .........................................18 D.6 RFC2307bis posixGroup ......................................18 D.7 inetMailGroup (draft-srivastava-ldap-mail-00) ..............18 D.8 Dynamic Groups (draft-haripriya-dynamicgroup-02) ...........19 Brooks Expires April 2013 [Page 2] Internet Draft LDAP psets October 25, 2012 1. Introduction The primary purpose of a central Directory is administrative and audit simplification. Without a central Directory, system administrators must create and maintain user access and authentication details on each separate system or class of systems. Since modern networks can contain millions of nodes, this is impractical and inevitably creates security and audit issues if attempted. Standards based LDAP accessible Directories can only realize a small portion of the administrative simplification possible. This is because there is no standard schema for a generic set object that is actually useful in the field. Existing standard schema provide only special use cases (such as mailing lists for specific mailers, operating system specific user groups, and 19th century business hierarchies) or are fundamentally flawed due to lack of essential features (like the ability to contain the empty set, ur-objects, and/or subsets). Generally, existing solutions are best described as "abandoning all pretense of schema standarization". Most Directories implement private schema, modify standardized schema, or implement various expired internet-drafts. Many large Directories do all three, and abuse the extensibleObject Objectclass mercilessly as well. Since LDAP exists as an integration, standarization, and unification enabling technology, the lack of a generic set object has fundamentally compromised the usability of LDAP by undermining compatibility. To remediate this problem an object must be defined that has the ability to represent any sort of set, without catering to the peculiar needs of specific vendors yet allowing all implementations to work transparently. 2. Nomenclature This document describes the implementation of a grouping object called a "pset". Psets are pragmatic, practical, and polymorphic. The pronunciation shall be as English "Pea Set". Capitalization shall follow normal english rules as demonstrated in this document. A pset is defined to be a finite collection of objects capable of being retrieved using the Lightweight Directory Access Protocol. This definition is both vendor-neutral and compatible with existing usages in mathematics and computer science. Pset is not currently in use as a generic computer science term, and thus avoids the lexical confusion seen in such overloaded computer Brooks Expires April 2013 [Page 3] Internet Draft LDAP psets October 25, 2012 terms as "domain" and "gateway". This will increase the ability of users to locate pertinent information with search engines; the author considers this a high value objective. The reality of empty sets shall be both axiomatic and explicit in this document, and while empty sets MAY be considered equivalent in some applications, objects containing or describing empty sets SHALL NOT be considered identical unless such objects have identical distinguished names. Because vendors have conflicting definitions of "group" and "list", those terms will be avoided here whenever possible. When used, they will have additional qualifying adjectives such as POSIX group or mailing list. 3. Required Capabilities Any means of representing sets MUST conform to the following criteria, determined empirically, in order to be generically useful. 3.1 A memberOf Attribute that can be Applied to Any Object Fundamentally, the concept of set members being attributes of sets (as for example in RFC2307 groups) is broken. In reality, a boy scout is not an attribute of a scout troop; membership in the troop is an attribute of the boy. Members are not attributes, but membership is. Reversing this relationship in order to preserve existing POSIX semantics and paradigms is unnecessary and has led directly to the situation that psets are intended to remediate. Since memberOf has already been defined multiple times in various (possibly conflicting) ways by different Directories, the less desirable type name memberOfPset will be used. Other attribute types may be used rather than memberOfPset within a psetMembership attribute; this will be discussed further on. 3.2 Support for frequently required queries as a single search An optimal set representation mechanism will allow DUAs (Directory User Agents) to satisfy the following queries in a single search request: Is set X empty? How many members does set X have? Who are all the members of set X? Is object Y a member of set X? Does set X have attribute Z? Brooks Expires April 2013 [Page 4] Internet Draft LDAP psets October 25, 2012 Queries concerning number of members MAY be satisfied by enumeration of returned objects if the LDAP service API does not provide explicit object counts in any other way. 3.3 Represent Sets Containing a Single Object Organizations using directories need the ability to define controls and properties so that unexpected employee terminations do not require deletion of large complex data sets that will have to be recreated when a replacement is hired. For example, if a corporate officer is specified by personal DN in hundreds of access controls and configurations across an global enterprise, and that officer is convicted of some malfeasance, the directory owner will have no choice but to either preserve the named account or embark on an expensive reconfiguration process, and either way reconfiguration will be again required later when a new officer is designated. However, if all configuration objects are defined in terms of a pset composed only of this exemplary officer, she can be replaced within the pset trivially, and the new officer will thus immediately be granted all necessary capabilities without undue expenditure of effort. This strategy reduces normal human errors dramatically. 3.4 Represent the Empty Set Quite frequently, human endeavors require the responsibilities and prerogatives of some position to be temporarily unassigned. In the example given above [section 3.1] optimal procedure may well be to immediately delete the terminated officer's account, leaving the pset empty until a suitable replacement can be found. 3.5 Directly Include Objects Outside the Directory (ur-objects) Many extant set representation mechanisms can only contain pointers to objects within the Directory. For example, the GroupOfNames objectClass requires that each member attribute contain the distinguished name of another object; therefore systems which use GroupOfNames for mailing list purposes cannot include the mail addresses of non-local users without creating "dummy objects", which usually require fabrication of spurious data and often present security risks. A pragmatically useful set mechanism WILL support ur-objects, although LDAP administrators and users are not required to make use of this feature. 3.6 Indirectly Refer to Objects Within the Directory It should not be necessary to check the content of every set in a directory due to a change in a single local object's attributes in order to maintain data integrity (unless such a change rewrites the Brooks Expires April 2013 [Page 5] Internet Draft LDAP psets October 25, 2012 DN itself). Psets MUST be able to reference other attributes, rather than forcing use of duplicate entries that must be maintained by administrators or application logic. 4. ObjectClasses and Attributes 4.1 The pset auxiliary objectClass objectclass pragmaticSet (alias pSet) MAY (psetMembership, displayName, owner, psetScope) MUST (cn, description) objectclass = ( 1.3.6.1.4.1.39438.1.1 NAME ( 'pset' 'pragmaticSet' ) DESC 'a collection of objects, considered as itself an object' SUP top AUXILIARY MUST ( cn $ description ) MAY ( psetMembership $ displayName $ owner $ psetScope ) ) In use, sets will correspond to some physical or logical structure such as a mailing list, access group, corporate department, or academic discipline. Because structural objectClasses have already been defined for many of these, it is pragmatically necessary for the pset objectClass to be defined as auxilary. This prevents conflict with the LDAP requirement that each Directory entry have a single structural objectClass. 4.2 The psetMember auxiliary objectClass objectclass psetMember (alias pMember) MAY (psetScope) MUST (memberOfPset) objectclass = ( 1.3.6.1.4.1.39438.1.2 NAME ( 'psetMember' 'pragmaticSetMember' 'pMember' ) DESC 'denotes membership in a pragmatic set' SUP top AUXILIARY MUST ( memberOfPset ) MAY ( psetScope ) ) Each member of a set that is included in a pset object by reference (viz. by resolution of a URI contained by a psetMembership attribute) Brooks Expires April 2013 [Page 6] Internet Draft LDAP psets October 25, 2012 SHOULD be marked by a memberOfPset attribute, regardless of the actual memberOfPset URIs used to describe the set. The psetMember auxilary objectclass provides this attribute type without disrupting the structural requirements of objects within sets. 4.3 The memberOfPset Attribute Type Name: memberOfPset ShortName: None Description: Denotes membership in one or more pragmatic sets OID: brooksType.2.1 SizeRestriction: None SingleValued: False attributetype ( 1.3.6.1.4.1.39438.2.1 NAME 'memberOfPset' DESC 'Distinguished Name of a Pset of which this object is an element' EQUALITY distinguishedNameMatch ORDERING distinguishedNameMatch SUBSTR distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE userApplication ) In a normalized directory running on strong hardware, all types of sets (including POSIX groups, mailing lists, etc.) SHOULD be represented by the use of psets, and membership in various psets SHOULD be denoted by the use of memberOfPset attributes applied to objects. However, it is recognized that a transition will need to be made from current methods, and that hardware capabilities may limit the ability of LDAP administrators to normalize large databases. The definition of the psetMembership and memberOfPset attributes therefore makes no requirement that URIs used as pset-attribute-references be specified only in terms of memberOfPset attribute values. (The appendices show an example of POSIX group semantics implemented without memberOfPset and without duplication of primary group definitions in secondary group objects). Psets are intended to provide flexibility, without imposing undue implementation challenges for LDAP server programmers. 4.4 The psetScope Attribute Type Name: psetScope ShortName: None Description: Application defined string describing usage of pset OID: brooksType.2.2 SizeRestriction: None Brooks Expires April 2013 [Page 7] Internet Draft LDAP psets October 25, 2012 SingleValued: True attributetype ( 1.3.6.1.4.1.39438.2.2 NAME 'psetScope' DESC 'Application defined string advising uses of pset' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 USAGE userApplication ) The psetScope Attribute Type has the PrintableString syntax and is single valued. LDAP administrators and others will define scope syntactica to meet user-specific needs for signalling the intended use case of sets. For example, a psetScope used to control access to corporate mailing lists might have possible values of INTERNAL, EXTERNAL, and PRIVATE. PsetScope values MAY be used in Access Control Lists or MAY contain Access Control lists, which MAY be enforced by LDAP server configuration and/or by LDAP enabled applications. LDAP administrators may choose to use psetScope values to apply to specific attributes of a pset, or to the pset as a whole, as required. (See Appendix C for examples.) 4.5 The psetMembership Attribute Type Name: psetMembership ShortName: None Description: attribute content descriptor optionally containing URI OID: brooksType.5 (1.3.6.1.4.1.39438.2.5) Syntax: DirectoryString SizeRestriction: None SingleValued: False attributetype ( 1.3.6.1.4.1.39438.2.5 NAME 'psetMembership' DESC 'Object that resolves to a polymorphic list of set members' EQUALITY caseExactMatch ORDERING caseExactOrderingMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplication ) The psetMembership attribute type has the directoryString syntax, is Brooks Expires April 2013 [Page 8] Internet Draft LDAP psets October 25, 2012 multivalued, and is case sensitive. Values placed in the attribute SHALL consist of a pset-attribute-name, optionally followed by one or more spaces and a pset-attribute-reference. The pset-attribute-name is used to label a resource or set of resources that will be returned when a query operation is performed against the set an attribute of the named type. Pset-attribute-names SHOULD be valid LDAP attribute types already defined by schema. Pset-attribute-references SHOULD either be ur-objects (see section 3.3 above) capable of being stored by the attribute type referenced in the pset-attribute-name, or a URI containing a valid query component [RFC3986, section 3.4] that when dereferenced will provide zero or more attribute values capable of being stored in the attribute type referenced by the pset-attribute-name. Note that although the pset-attribute-name may include any characters allowed by the directoryString syntax, in practice LDAP attribute types, (including private attribute types) SHOULD NOT use esoteric characters and SHOULD use camelcased alphanumeric ASCII. If more than one psetMembership value exists with the same pset-attribute-name, search operations on that attribute SHALL contain results concatenated from all such psetMembership in the form of a normal multi-valued attribute. If a psetMembership attribute contains no pset-attribute-reference at all, searches for that pset-attribute-name SHALL succeed and return the empty set. If a pset-attribute-reference contains a URI that resolves to the empty set, a search for the pset attribute SHALL return the empty set. If a pset-attribute-reference contains a URI that generates errors, a search requesting the corresponding pset attribute name SHALL NOT complete succesfully, and the error(s) SHALL be passed through to the searcher, optionally with additional errors designating the issue to be related to improper pset specification. No special handling will be required for URIs that resolve to TRUE or FALSE [RFC4526] if the server supports such results. Because psetMembership attributes can contain URIs which in turn can be case sensitive, the attribute type MUST preserve case. However, psetmembers may also contain absolute values, such as email addresses, that are not case sensitive. Client applications SHOULD take care to perform tests and comparisons appropriately. Brooks Expires April 2013 [Page 9] Internet Draft LDAP psets October 25, 2012 Any results from URI resolution that do not conform to the format requirements of the attribute type named by pset-attribute-name MAY be discarded by the server if a schema violation error is returned to the client by the search. Resemblances to the RFC2079 labeledURIObject are intentional; note, however, that the order of operands is reversed. 5. Security Considerations 5.1 Catholic Security Practices for LDAP Accessible Directories General purpose Directories always contain information that SHOULD be restricted and/or controlled for security reasons. This may include the content of psets, particularly when such psets describe access control lists, mailing lists, or security groups. The pset objectClass and its related attributes are designed to be fully compatible with the existing methods used to assure the security of LDAP accessible data within existing directory servers. Users are cautioned to carefully consider and maintain proper security on all directory objects, not just psets, and advised to periodically audit LDAP access controls. 5.2 Expansion of URIs by Directory Services Whenever psetMembership URIs are expanded by a Directory service to a list of individual attribute values, security controls MUST be evaluated twice. Primus, if the requesting entity does not have access to the requested psetMembership attribute itself, the filter SHALL NOT be evaluated. Secundus, if the primary requirement has been satisfied, the filter MUST be evaluated in the security context of the requesting entity. 5.3 Denial of Service through Pset Recursion By design, the pset definition allows nested sets and therefore embodies potential for infinite recursion. Although a properly designed and administrated Directory will not contain such errors, user-writable areas (such as personal address books) may be exploited by malicious users as a form of Denial-of-Service attack. Appropriate timeout settings for query resolution will ameliorate the effects of such actions, but Directory administrators SHOULD consider restricting or disallowing the creation of psets by unskilled users. 5.4 PsetScope is not inherently an Access Control Mechanism The psetScope attribute DOES NOT restrict how applications can apply pset attributes to psets or pset members; psetScope MAY Brooks Expires April 2013 [Page 10] Internet Draft LDAP psets October 25, 2012 be used in application logic or even in LDAP server access controls but it is essentially a "hint" that delivers information about how a pset is intended to be used, and does not serve any additional function within the Directory by default. Do not place security sensitive information within a psetScope attribute without carefully considering implications; do not ever place passwords or the equivalent in psetScope. 5.5 Difficulties of defining Default Security Settings It should be noted that the existing hodgepodge of LDAP schema used in the field to represent various kinds of sets has prevented the creation of a globally useful set of default security settings controlling access to sensitive access control group and mailing list data. In practice, LDAP admins using standards-based directory services have a more difficult and tedious configuration task than admins of proprietary, single-vendor directory servers. If psets become the dominant method of representing all forms of LDAP sets, including mailing lists, user groups, etc., this problem may then be resolved for all Directory servers. 6. IANA Considerations The author has been granted an OID of 39438 for the explicit purpose of representing psets and associated objects in globally useful LDAP schema. Any such objects will be in perpetuity restricted to the uses described and will not be reissued or reused in any incompatible fashion by the author in any work, public or private. They are a gift. All such objects will be registered with and curated by the IANA in accordance with RFC4520, BCP64. No other actions are required from IANA as result of this document. The author wishes thank the IANA for their assistance. 7. References 7.1. Normative References [OSIDIR] "Information Processing Systems - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. [RFC4510] Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map. K. Zeilenga, Ed.. June 2006. (Format: TXT=12354 bytes) (Obsoletes RFC2251, RFC2252, RFC2253, RFC2254, RFC2255, RFC2256, RFC2829, RFC2830, RFC3377, RFC3771) (Status: PROPOSED STANDARD) Brooks Expires April 2013 [Page 11] Internet Draft LDAP psets October 25, 2012 [RFC4511] Lightweight Directory Access Protocol (LDAP): The Protocol. J. Sermersheim, Ed.. June 2006. (Format: TXT=150116 bytes) (Obsoletes RFC2251, RFC2830, RFC3771) (Status: PROPOSED STANDARD) [RFC4512] Lightweight Directory Access Protocol (LDAP): Directory Information Models. K. Zeilenga, Ed.. June 2006. (Format: TXT=108377 bytes) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD) [RFC4513] Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms. R. Harrison, Ed.. June 2006. (Format: TXT=80546 bytes) (Obsoletes RFC2251, RFC2829, RFC2830) (Status: PROPOSED STANDARD) [RFC4515] Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters. M. Smith, Ed., T. Howes. June 2006. (Format: TXT=23885 bytes) (Obsoletes RFC2254) (Status: PROPOSED STANDARD) [RFC4516] Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator. M. Smith, Ed., T. Howes. June 2006. (Format: TXT=30562 bytes) (Obsoletes RFC2255) (Status: PROPOSED STANDARD) [RFC4517] Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules. S. Legg, Ed.. June 2006. (Format: TXT=114285 bytes) (Obsoletes RFC2252, RFC2256) (Updates RFC3698) (Status: PROPOSED STANDARD) [RFC4519] Lightweight Directory Access Protocol (LDAP): Schema for User Applications. A. Sciberras, Ed.. June 2006. (Format: TXT=64996 bytes) (Obsoletes RFC2256) (Updates RFC2247, RFC2798, RFC2377) (Status: PROPOSED STANDARD) [RFC4520] Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. June 2006. (Format: TXT=34298 bytes) (Obsoletes RFC3383) (Also BCP0064) (Status: BEST CURRENT PRACTICE) [RFC4521] Considerations for Lightweight Directory Access Protocol (LDAP) Extensions. K. Zeilenga. June 2006. (Format: TXT=34585 bytes) (Also BCP0118) (Status: BEST CURRENT PRACTICE) [RFC4526] Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters. K. Zeilenga. June 2006. (Format: Brooks Expires April 2013 [Page 12] Internet Draft LDAP psets October 25, 2012 TXT=10097 bytes) (Status: PROPOSED STANDARD) [RFC4527] Lightweight Directory Access Protocol (LDAP) Read Entry Controls. K. Zeilenga. June 2006. (Format: TXT=15987 bytes) (Status: PROPOSED STANDARD) [RFC4529] Requesting Attributes by Object Class in the Lightweight Directory Access Protocol. K. Zeilenga. June 2006. (Format: TXT=11927 bytes) (Status: INFORMATIONAL) 7.2. Informative References [RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC2307, March 1998 [2307BIS] Howard, L., Chu, H., Ed., "An Approach for Using LDAP as a Network Information Service" draft-howard-rfc2307bis-02, August 2009 http://tools.ietf.org/html/draft-howard- rfc2307bis-02 [HARIPRIYA] Haripriya, S., Jaimon, J., Ed., Sermersheim, J. and Novell, "LDAP: Dynamic Groups for LDAPv3", draft- haripriya-dynamicgroup-02, January 2007 http://tools.ietf.org/html/draft-haripriya-dynamicgroup-02 [SRIVASTAVA] Srivastava, A., Allen, R., Huff, D., Siegel, E., "LDAP Schema for Internet Mail", draft-srivastava-ldap-mail-00, November 1998 http://tools.ietf.org/html/draft-srivastava- ldap-mail-00 [LASER] Lachman, H., Shapiro, G., "LDAP Schema for Intranet Mail Routing", draft-lachman-laser-ldap-mail-routing-02, January 2001 http://www.sendmail.org/m4/laser.txt [RFC4524] COSINE LDAP/X.500 Schema. K. Zeilenga, Ed.. June 2006. (Format: TXT=11245 bytes) (Obsoletes RFC1274) (Updates RFC2247, RFC2798) (Status: PROPOSED STANDARD) [FINDLAY] Findlay, A., "The LDAP groupOfEntries object class" draft- findlay-ldap-groupofentries-00 , September 2007 http://tools.ietf.org/html/draft-findlay-ldap- groupofentries-00 Appendix A: A Brief Discussion of Set Attribute Applicability In practice, determining the applicability of set attributes to individual members of a set can only be done by application logic in directory consumers. For example, a pset representing a POSIX group Brooks Expires April 2013 [Page 13] Internet Draft LDAP psets October 25, 2012 confers applicability of the gidNumber attribute of the pset to POSIX compliant access controls for individual members, but the gidNumber attribute of the pset must not override the gidNumber attribute of individuals. The LDAP service has no mechanism to determine what purpose a DUA (such as a POSIX operating system) intends for the output of a search, nor should it have one. Directory services cannot control the way that information drawn from the DIT is applied by applications. There are at least three different models for the application of set attributes, all of which are normally in simultaneous use. A.1 Attributes may Apply to All Members but not to the Set In practical use, there are some attributes which an object automatically aquires when it is added to a set, which are not necessarily attributes of the set. The most obvious of these is set membership itself, since infinite recursion is not mandatory. Applications requiring such attributes typically search for all sets with the desired attribute, then iterate through their membership. Psets can support this mode as a single operation or as sequential queries, or both. Alternatively a Directory consumer can be configured to search for objects with specific memberOfPset attributes. Fundamentally, however, the ability to support attributes which will be considered to be attributes of all pset members despite the presence or absence of such attributes within individual member objects is determined by application logic, not by an LDAP server or DIT architecture. A.2 Attributes may Apply to the Set but not to All Members It is a fallacy to suppose that all members of a set must possess all attributes of the set. For example, a set of objects may possess the attribute of objectionable odor, when only a few of these objects have any odor at all. Applications requiring such attributes may simply search for objects of objectClass pset having the required attribute, or may look for the attribute within the pset object(s) already in use. Such attributes may be manually defined and maintained, or may be provided by cleverly constructed psetMembership URIs. This last capability is unique to psets. A.3 Attributes applying equally to sets and their members This is mentioned for completeness, but is already sufficiently Brooks Expires April 2013 [Page 14] Internet Draft LDAP psets October 25, 2012 explained (see B.1 & 2). Examples include the gidNumber of POSIX groups. A.4 Attributes that do not apply to either the set or the members will not be discussed. Appendix B: Psets and Zermelo-Fraenkel Axioms A useful grammar of universal set representation needs to conform to our best understanding of the nature and uses of sets. The Zermelo-Fraenkel axioms, named after mathematicians Ernst Zermelo and Abraham Fraenkel, are the basis for Zermelo-Fraenkel set theory. In mathematics, ZFC (Zermelo-Fraenkel with explicit acknowledgement of the axiom of choice) is the standard form of axiomatic set theory and as such is the common foundation of modern math. Most of the ZFC base axioms are readily demonstrated by the Directory service itself; pset is just a configuration mechanism that does not unduly limit a Directory server's capabilities. Other extant set representation schema commonly violate ZFC by failing to support the empty set, or the infinite set, or by having no comparison rules. The author believes psets can be framed intelligently within the ZFC framework, noting that the Axiom of Infinity is explicitly supported by the possibility of defining both infinitely recursive and infinitely compounding sets. Such use is discouraged, and attempts to resolve such sets should generate errors (typically, timeouts) but any syntax that can usefully represent reality can also represent both infinity (Cantor) and paradox (Godel). Russell's Antimony and Grelling's Paradox are formally undecidable in set theory, but may resolve in practical use in some LDAP environments depending on timing and database environments. The user is advised to claim the barber is a woman and run away if confronted with such issues. Appendix C: Examples of Using Psets to Solve Common Problems RFC 2849, "The LDAP Data Interchange Format (LDIF)" specifies a file format suitable for describing directory information that is broadly supported and vendor neutral. NOTE: Formatting rules for RFCs and internet-drafts require that no line be longer than 72 characters. Therefore, in the following data set, the longer lines (typically RFC2255 LDAP URLs) are folded by inclusion of a newline and single space character, as per RFC2849 (page 5 note 2). Brooks Expires April 2013 [Page 15] Internet Draft LDAP psets October 25, 2012 C.1 A Very Simple Mailing List This LDIF fragment shows a pset object that when queried returns RFC822 compliant email addresses for both local and foreign users. dn: cn=droogs@example.org,ou=mailList,dc=example,dc=org objectClass: pset objectClass: applicationProcess cn: droogs@example.org description: Example of list of local users and one foreign user psetMembership: mail foreignAddress@example.com psetMembership: mail ldap://dc=example,dc=org?mail?(memberOfPset=droogs) psetMembership: mail ldap C.2 A Very Useful Polymorphic Set This set represents a single object - a corporate IT department. The membership of this set varies depending on which attribute is being queried, which allows the enterprise to simultaneously use multiple vendors' LDAP-aware applications that presuppose grossly divergent Directory organization. Pragmatically, real world objects work the same way; they are seen differently depending on what the searcher is looking for. In a University, if one member of the IT department has no telephone, the IT department phone list will not include a telephone number for that person, and if one member of the IT department wants to be contacted on multiple different email addresses, she may be permitted to do so. Without psets, Directories that attempt to emulate useful real world objects (like the scrawled phone list on the computer room wall) are forced to either falsify or denormalize data, which will impose significant adminstrator overhead as well as compromising efforts to maintain data integrity. Despite the varying results returned by search operations, this set requires little maintenance. Only special circumstances require any special actions - any change to the attributes of IT department staff Directory entries are not required to be manually replicated here. Because some extremely commonplace capabilities required by large enterprises cannot yet be implemented using standard schema that have been formally approved by the IETF, this LDIF fragment assumes the use of the LASER schema. LASER is one of several schema specified by expired internet-draft documents that are heavily used in the field. dn: cn=IT,ou=sets,dc=example,dc=org objectClass: pset Brooks Expires April 2013 [Page 16] Internet Draft LDAP psets October 25, 2012 objectClass: posixGroup objectClass: mailLocalRecipient objectClass: groupOfNames cn: IT gidNumber: 1066 mailLocalAddress: IT@example.org description: group object empirically required by an IT department psetScope: INTERNAL example.org psetMembership: mail ITwebBBS@example.org psetMembership: mail ldap://dc=example,dc=org ?mailRoutingAddress ?(memberOfPset=cn=IT,ou=sets,dc=example,dc=org) psetMembership: memberUid root psetMembership: memberUid ldap://dc=example,dc=org ?uid ?(&(objectClass=posixAccount)(|(gidNumber=1066)(memberOfPset=IT))) psetMembership: member ldap://dc=example,dc=org ?dn ?(&(objectClass=inetOrgPerson)(memberOfPset=IT)(!(uid=phb))) This set can be used by the Name Service Switch on Linux, Sun and HP-UX systems as a POSIX group. This group will include the local system root account, although root does not exist in this Directory for security reasons. The set can also be used by Sendmail as a mailing list, in which case it will include a web bulletin board process, and a Cisco Ironport network-edge mail hub can easily be configured to allow mail to this list only from internal users (by use of psetScope in the Ironport configuration dialog). Additionally it can be used as an authentication provider by the Apache web server (using groupOfNames), and in this use will prevent web authentication by the phb user account; presumably the user signified by phb is not trusted to operate IT web interfaces. Note also that the psetMembership attribute for memberUid references the gidNumber attribute as well as memberOfPset in its URI part - this is intentional, so that usermod operations on LDAP-aware systems such as SUSe linux will work as expected, and demonstrates pset flexibility as well as compatibility with existing uses. Similarly, the memberOfPset attribute repeatedly used by this set does not refer to a valid DN. It is up to the Directory administrator and users to determine optimal configuration, because psets do not impose arbitrary limits. Appendix D. Other Efforts and their Shortcomings Dozens of standard, nonstandard and proposed standard attempts to address the problems resolved by pset implementation already exist. Brooks Expires April 2013 [Page 17] Internet Draft LDAP psets October 25, 2012 Although none of those solutions are globally applicable and vendor neutral, psets are designed to allow users a straightforward transition and can co-exist with all other such objects known to the author, including POSIX groups, samba groups, AD groups, and LASER lists. In particular, the pset attribute type "psetMembership" is provided for both backwards and forwards compatibility. D.1 RFC3671 Collective LDAP Attributes The "collective" attributes of X.500 are optimized for use in an exclusively hierarchical database; they are held in a parent object and attributed to child entries by the server. This is a rigid and primitive structure that cannot accurately represent most modern human social, academic or corporate Directories. It is doubtful that this structure was particularly useful when it was created, but it may have made sense in terms of the limited storage and CPU power available in 1988. LDAP needs the ability to represent and interact with standard X.500 Directories, and collective attributes are an important part of that interoperability. However, their use is strongly discouraged for any purpose other than compatibility. D.2 RFC4519 groupOfNames The groupOfNames objectClass requires at least one member attribute and thus cannot hold the empty set. Member attributes are required to be fully distinguished names and thus ur-objects cannot be included. The former shortcoming is commonly addressed by creating dummy accounts or de-standardizing schema, the latter by creating dummy accounts. Large directories may contain hundreds or even thousands of dummy accounts, each of which complicates administration and auditing. Working with groupOfNames usually requires multiple searches; for example, a mailing list implemented as a groupOfNames will usually require a search first for the group object, then for each member's mailing address attribute. This is grossly inefficient when compared to methods that use a "member of" attribute, such as psetMemberOf. D.3 RFC4519 groupOfUniqueNames The groupOfUniqueNames object has all the failings of groupOfNames but adds a commonly misunderstood qualifier. The DNs of objects referenced by the uniqueMember attribute are not necessarily unique and do not necessarily refer to unique entities. This objectClass is rarely used. D.4 groupOfEntries (draft-findlay-ldap-groupofentries-00) Brooks Expires April 2013 [Page 18] Internet Draft LDAP psets October 25, 2012 The groupOfEntries objectClass is based on the the RFC4519 groupOfNames objectClass, but adds the ability to represent the empty set. Andrew Findlay's draft document contains a concise statement of the need for this feature. It is a significant improvement over groupOfNames but does not address the need for ur-objects. D.5 RFC2307 posixGroup This objectClass is one of the few capable of representing ur-objects. Many sites use it for precisely that reason; security and reliability of systems that use LDAP for account authentication can be significantly enhanced by configuring local-first lookups in the name service switch and maintaining local superuser and daemon accounts. This practice prevents most forms of "mass compromise" of superuser equivalents through LDAP account injection and offers other advantages that will not be detailed here. Most group and list objects do not allow the inclusion of non-LDAP accounts, but posixGroup's use of memberUids instead of member DNs offers this flexibility. It does not accurately model Unix user object behavior due to case insensitivity and inability to represent the empty set. Because it is a structural object class, it does not work and play well with other set representation mechanisms. D.6 RFC2307bis posixGroup RFC2307bis is a proposed revision to RFC2307 that is already widely implemented in the field. It removes the ability to support ur-objects but adds the ability to support nested groups (subsets), albeit with some difficulty, by reverting to the use of the member attribute rather than memberUid. In essence, both forms of RFC2307 represent a partial mapping of Unix semantics and structures onto LDAP. Although in a few ways the result canonifies the weaknesses of both systems, it has been instrumental in achieving the high level of integration currently enjoyed by unix/linux and LDAP accessible Directories. D.7 inetMailGroup (draft-srivastava-ldap-mail-00) This author had not studied the Srivastava draft extensively prior to designing psets. However, the representation mechanism defined there is nearly identical to that of psets, but specialized for mail routing and mailing list control. The InetMailGroup object class can hold the empty set, can support ur-objects (rfc822MailMember attribute) and can reference subsets and other individual objects (membershipFilter). It adds access controls and scope definitions that are not universally applicable to sets. Psets cannot achieve all the capabilities of Brooks Expires April 2013 [Page 19] Internet Draft LDAP psets October 25, 2012 inetMailGroup without the addition of other object classes, nor should they. Psets can co-exist with inetMailGroups, since neither is a structural object class, but some LDAP administrations will prefer to limit duplication of capabilities and will implement simpler mail routing mechanisms such as LASER. D.8 Dynamic Groups (draft-haripriya-dynamicgroup-02) The Haripriya draft defines a way that responses to requests for attributes of groupOfNames and groupOfUniqueNames objects can be satisfied through resolution of an LDAP URI. The method is well described although somewhat complex. Dynamic groups have been implemented in the OpenLDAP project as an overlay and are in use in the field. Both structural and auxiliary object classes are defined; since these object classes inherit from groupOfNames or from groupOfUniqueNames one would expect them to be unable to represent the empty set, but due to the mechanics of attribute resolution servers cannot prevent a dynamic group from returning zero members in practice. This can be viewed as a clever hack or an undesirable incongruity. Hariprya treats polymorphism as undesireable, rather than as a valuable feature (c.g. dgIndentity). The only types of ur-objects that can be supported are DNs. There is an explicit object exclusion mechanism that is more readable than including exclusions in URI filters, and an interesting approach to limiting recursion and scope. Just as the Srivasta objects are optimized for email, the Hariprya object classes and attributes are optimized for lists of distinguished names. They do not comprise a generic solution for the representation of sets. Dynamic groups have been implemented in the OpenLDAP project as an overlay and are in use in the field. Although dynamic groups are powerful and useful, they provide no capabilities that are not also achievable with properly configured psets. Psets and dynamic groups can co-exist, but this is discouraged. Authors' Address Charles Brooks HBCS, Ltd. Information Systems and Technology Research and Development 118 Lukens Drive New Castle, DE 19720 Phone: (302) 552-8091 Brooks Expires April 2013 [Page 20] Internet Draft LDAP psets October 25, 2012 Email: charlie@hbcs.org Brooks Expires April 2013 [Page 21]