Modified per feedback from 18 July 2001 mace-dir groups subgroup conference call. -- GROUP PRACTICES SOLICITATION -- Response from: Aaron Brown Middleware Programmer University of Kansas, Academic Computing Services -- We would like to solicit information on current or anticipated practices and issues related to provisioning and using group objects in X.500 or ldap capable directories. An outline is provided below to which you might refer when describing your current and/or planned group practices. The information you provide will be used to help determine the direction mace ought to take with regard to group related middleware matters. A. Please address each of the following items. It would be especially interesting to relate how the nature of any planned or deployed applications constrains your choices in each of these areas. A.1. How is group membership (to be) represented? Are any of the following types used? What led you to decide on the membership representation(s) you've chosen? Static, ie, a group object is instantiated with an attribute listing the (person or other) objects which are members. Dynamic, ie, defined by evaluating an ldap URL. A group object may, but need not, exist. Dynamic forward reference, a special case of dynamic representation in which an object's group memberships are listed as the values of an attribute designated for that purpose. Spatial, another special case of dynamic representation in which group membership is inferred from location in the DIT. -- Static. We currently use centrally-stored/administered groups as a way to pre-process the dynamic group determination. This saves time and effort on the part of customer applications, who only need to ask "Is person X in this group? In what role?", as opposed to "Is person X included in the result set of applying this collection of group-generation rules?" which is a much more time and effort-intensive kind of question. The groups are updated as often as we deem necessary. So they are then statically stored, ready for very simplistic querying by various client apps. -- A.2. What objectclass(es) do you (anticipate) using to instantiate group objects, if you indeed (plan to) instantiate group objects: groupOfNames, groupOfUniqueNames, groupOfURLs, other object class(es)? If the latter, what functional requirements drive the design of the group schema? -- Group objects in LDAP are currently planned but not yet implemented. We will be using groupOfUniqueNames in the group object class. -- A.3. How are group memberships (to be) maintained? Automated processes? By hand? Using what tools? Do (or will) you maintain referential integrity, i.e., if an object is removed from the directory, are its group memberships also removed? How? -- Yes to all points. Automated processes and manual processes blend. The groups are built nightly according to a mixture of SQL queries on various generic registry data (e.g. department, major, employee type, etc.) as well as specific entities (people, functional account objects, other groups) which may be included or (in some cases) excluded from the more general query. Some groups are built entirely as a list of "exception" entities, having no common registry data against which to query. Ultimately, the entire group population is determined as the result of a series of SQL queries against the main repository of people and entities, therefore an entity which becomes inactive in some way will be missing from the result set the next time the query is run. -- A.4. Can group objects be members of groups? What object types can be members of groups? -- Yes, groups can be members of groups. Other members allowed: 1) people (actual humans possessing a unique logon ID at the university) 2) functional accounts (typically email accounts created for functional use by a department, but not actually OWNED by a specific person (e.g. "helpdesk@ku.edu", etc.) -- A.5. Do you (expect to) have a mechanism for representing a group whose membership is the result of an automated process together with a manually maintained set of exceptions (either inclusive or exclusive)? Does (or will) your implementation support any other forms of "group arithmetic", i.e., set theoretic operations on the membership lists of a collection of groups? -- Yes, we have such a mechanism in place (see above). No, the current implementation does not support "group arithmetic", though the concept sounds very interesting and possibly useful. Currently, when confronted with a desire for "Group C" which equals "Group A minus Group B", Group C is built by using Group A's SQL query in an "include" way, with Group B's SQL query in an "exclude" way, combining it all into a single large query which provides Group C. This requires knowledge of the rules that went into creating both Groups A & B, but at the moment that isn't an issue. In the future it may be, which makes "group math" an intriguing idea. -- A.6. What policy pertains (will pertain) to administration of group membership? Is administration of groups (to be) delegated? How is the set of groups (to be) groomed, i.e., stale ones made to go away eventually? -- Currently, our group management "policies" are a fine example of the tail wagging the dog. We build tools and functionality, in the hopes (often vain hopes) that policy will be written to guide the use of these things. It's a nice dream, anyway. There are a few basic policy guidelines that I (as the groups admin.) use as a way to spot red-flag group creation/change requests, so I can pass those requests on to the people who take responsibility for such things, like the registrar's office where student groups are concerned, and the provost's office for faculty/staff groups. Group management is not currently delegated to anyone. It is my personal dream that this will soon change. Yesterday, ideally. There is no current automatic grooming in place. Grooming takes place in two situations: 1) The original requestors of the group contact me asking that it be removed. 2) The membership of the group drops to zero, and is done away with. For example, student course groups empty out and are deleted at the end of each semester. -- A.7. What privacy or security policy pertains (will pertain) to any of your groups? Are there policies that prohibit or inhibit the exsitence of certain types of groups? -- FERPA plays the largest role here. Any group which includes students in their capacity as enrollees in the university (as opposed to their possible role as student employees of the state) is subject to mandated restrictions of creation, ownership, and visibility. 1) Groups with students MUST have their membership hidden from view by anyone (including by other members of the group) 2) Someone generally does have "view" permissions to the group, as a way of monitoring the accuracy of the group itself. This element is one of the reasons why the Registrar's Office is always contacted whenever a student group is requested - the "viewer" must be determined to be a person who has the right (under FERPA) to know who this group's members are. 3) When a group of employees is created (student or otherwise), the visibility of the membership is optional, as such information is readily available under the Open Records act anyway. The only restriction placed on these groups has to do with the breadth of people included - if the members are to be pulled from multiple organizations and units on campus, the Provost Office must give approval for the group. This is an email usage issue, a hoop which is jumped through to help cut down on spam. -- A.8. What conventions for group names (will likely) exist? What motivates them? -- Only a couple of conventions in place: 1) Group names are given a suffix which is connected with the intended primary use of that group. For example, all groups which were made to be placed in Microsoft Exchange as Distribution Lists will end in " - DL". This is similar to the convention of listserv lists ending in "-l" (e.g. mace-dir-l). The suffix also helps to keep the groups namespace distinct from the email address namespace. For example, the Econ. department may have an email account "economics@ku.edu", but may also want a mailing list of Econ. people, so the mailing list of their group would be "economics_dl@ku.edu". 2) Course groups are named according to a long and annoying naming convention which is necessary to ensure uniqueness, as there may be many different sections of "ECON 101" being taught in a given semester. An example group name might be "ECON101 (12345) Fa03 - DL" where "12345" is the unique identifier (per-semester) of the course section in the student enrollment system, and "Fa03" is the semester identifier. -- A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? -- Yes. This is almost exclusively the purpose of all the centrally managed groups. We have a few groups which populate Active Directory Security (non-mail- enabled) groups for purely security-related reasons (e.g. lab machine logon, etc.). We anticipate populating groups into LDAP soon, and possibly could use these groups for some role-based access model, however RBAC would probably require that the groups be updated in a more real-time kind of way, rather than the current nightly update scheme. -- A.10. Are you (or will you be) supporting "personal groups", i.e., groups created and maintained by ordinary users, or groups designated as "joinable", i.e., for which ordinary users can autonomously join or leave? For what purposes? Do such groups occupy the same namespace as other groups or other types of objects? -- We probably will be. The missing ingredient right now is the user interface whereby an individual may request inclusion or exclusion with respect to a group. We also will need many policy statements worked out to describe in what circumstances and for what kind of groups a member will be allowed to enter/exit voluntarily. In any case, we envision that the existing groups repository and maintenance scheme could be used to generate and maintain listproc mailing lists, in which case the idea of self-subscription, etc. must be provided for. -- B. Are you (or will you be) tracking "roles"? What does that mean to you? Are you (or will you be) implementing something like "role based access control"? If so, how? -- Yes, in a couple of senses of the word and the question. First of all, there are several roles that a person may fill with respect to a given group itself. In a mailing list context, a person may be a member (aka "recipient"), a sender, or may have some administrative role over the group (e.g. the "viewer" described above). Secondly, we may wish to use groups as a way of identifying whether a person has a given role at the institution or not. This is not currently in place, but would probably be the intent behind loading groups into LDAP from the existing groups repository. In this scenario, again, the groups would function as a kind of pre- processing step which would save time and effort in role determination by client apps. Role determination would then become merely a basic query about "isMemberOf". -- C. What aspects about your (planned) implementation of groups worries you? What group related operations or facilities don't exist that would significantly simplify your task if they did? -- Group management delegation would be fantastic. This requires very large advances in user-interface over what currently exists at KU. The software could also stand a complete re-write, since it was originally conceived as a single-purpose utility, but that is no longer true. The software has outlived its capacity for further expansion. Any other mods will need a re-write. Mostly, delegation would be the biggest help. The more people are able to manage their own stuff, the easier my life will be. I would also like for there to be something like a roles dictionary present in the groups registry, allowing for new group roles to be easily added and used, as this would aid in adding new consumer apps to the list of applications which access the groups registry in some way. -- D. Please list any further current or planned applications using directory groups that haven't already been discussed and provide a brief description of each. -- None. -- E. Thanks for sharing that information. In addition, we'd appreciate your direct advice on the direction mace ought to take in this area. -- I highly recommend the use of something like a "groups registry". In KU's case, this is a database construct holding all group information - all attributes describing each group, all entities which fulfill any role with respect to any given group. If this registry can be constructed in a generic enough way, ideally such that the list of different allowed roles is extensible to account for future client applications, then co-opting existing groups for other purposes becomes much easier, and keeps the groups representation independent (as much as possible) from both the source data registry and the consumers of the group data. All the consumer channels you need can be then written, each customized to a single consumer application, and allowing for any further data massaging that may be necessary for that application. It simplifies the group management by removing most of the worrying about how the data will be consumed. Secondly, any group management system, in my view, MUST be able to easily accomodate exceptions to any rule. Universities seem to have more exceptions than they have rule-followers. Additionally, bureaucracy is slow. There have been many times in my experience when a significant change happened (e.g. someone was fired with extreme prejudice), and it was in the university's interest that group affiliations be changed IMMEDIATELY, and the paperwork confirmation of that change can then filter through to the data registry in its own sweet time. This is one example, I'm sure you can think of others (enrollment changes, data changes during off-season periods, etc.). --