Group Practices Survey Email response from Michael Gettes of Georgetown University, with a followup exchange with Tom Barton November 16, 2001 Questions: 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, Dynamic and Dynamic Forward Reference. At this time we don't know the expectations of applications now and in the future. The only logical choice is to pursue the maximal approach and represent all 3 in the directory. Spatial is not considered wise as org structure is not a strict tree structure in higher ed. Implementing the maximal gives the apps maximum flexibility and choice. It means more work for the infrastructure but I believe the infrastructure can handle it. 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 you (will) use a custom group objectclass, what functional requirements drive the design of the group schema? For static groups, it will likely be groupOfUniqueNames since we use the iPlanet directory. I can envision a future objectclass that adds additional attributes to a group that allow the group to better participate in roles or other authorization decisions. What this will be I am not yet sure. 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? We will have essentially 2 types of groups in the directory. Institutional groups are generated from data in core business systems. We expect to have thousands of these automatically maintained groups. All these groups will likely exist in the ou=Groups portion of the DIT and will likely be visible only to those applications which require access to the groups (web servers, mailing list managers and so on). The other type will be ad hoc groups. Ad hoc groups will be user owned and maintained. They will likely exist in the DIT beneath the user's object and controlled based on their location in the DIT with respect to the user. These groups will need an access control mechanism that would default to being private but would be allowed to be public if the user wished it so. How? See A.2 above. Referential Integrity for the automated groups will be handled by the system maintaining the groups. This makes it vendor independent. Users will be responsible for handling their own, or, we may write a process that performs ref-int checks for the user and emails them weekly to notify them of issues in their own groups (maybe). Should a user ever be removed from the directory, then all of the groups owned by that user should be removed as well. Institutional ad hoc groups will need to be associated with generic userids (like provost, registrar, president) and not with an individual's primary netid. A.4. Can group objects be members of groups? What object types can be members of groups? Have not yet decided on groups within groups. My current position is no, but this may change. Any object (besides another group at this time) can be a member of a group. 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? In our maximal approach to groups we intend to enumerate every possible group. This will make it easier to perform "group arithmetic" when we need to go that route. So, we don't necessarily have an answer right now but our plans are taking it into account and we expect to be able to support group math. 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? Institutional groups should be self-evident at this point. As to user groups, they will be administered by the user with an ACL given DIT location. Other ad hoc groups will allow the owner attribute to control the group membership. The owner attribute could consist of individuals and/or groups. So, we intend this to be delegated for non-personal ad hoc groups. A.7. What privacy or security policy pertains (will pertain) to any of your groups? Are there policies that prohibit or inhibit the existence of certain types of groups? As of now, there is no policy on groups. As of now I see no limits on the groups to be generated. As said before, all institutional groups will be private and made available to processes on a controlled basis. User groups will default to private but we will need a mechanism to allow them to be shared for things like web pages. This also applies to non-personal ad hoc groups. A.8. What conventions for group names (will likely) exist? What motivates them? Institutional groups will be generated from tree structures of data within our core business systems. We are in the process of developing a language to describe data elements in the various CBS and to construct a name based on strings and values we supply, thusly generating many many groups from a single specification. A program will process the language and handle the group maintenance. Users will be able to create group names as they wish since they will be in their own name-space. Non-personal ad hoc groups will have to into a special portion of the DIT and, as of this moment, there is no naming convention yet. It will likely be something organization/department oriented like we are doing with resources in our enterprise calendaring system. A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? Indirectly. We would like to take directory groups and use them to populate mailing lists in listproc or some equivalent product. It would be ultimate if we could use an LDAP enabled MLM. We do NOT want to expose groups to email clients (for the inst-groups). We may allow users to email to their own groups as this might be a personal address book feature which people are asking for -- but, a webmail product may negate doing this in the directory since many webmail products provide their own PAB functionality. 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? Most of this question has already been answered above. As for the joinable groups, I have considered it but not spent much time on the issue. I am sure there are uses and will cross that bridge when I come to do it -- I am confident we will end up supporting it. I would imagine that these types of groups would be of the non-personal ad hoc type and occupy the same namespace. It's simply a matter of whether or not the group is maintained by people or self-maintained by people subscribing to the group. It could be that we put these groups into a different branch of the DIT just to be able to define an access control for all such groups. 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? Roles. To me, roles are a collection of permissions that would be attributable to individual objects or a group (or set of groups). Yes, we are tracking roles and roles will be tackled after we populate groups. To me, groups are a poor- man's role based control. I believe roles will be more useful with groups in place. This may be just a juicy rationalization. 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? My only worry is the time and resources to implement the above. Group math is not obvious. As I see it, we need some external function -- maybe an LDAP directory unto itself in which someone asks for a group and that directory would be defined with group math related functions and handle all that for the requesting app and hand back the answer to the app -- akin to the grouper ability at Brown but more LDAP-like. 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. Blackboard for populating courses, CorporateTime calendar for handling group calendars, Shibboleth, I am sure there are others. Upon receipt of the survey responses, Tom Barton followed up with questions/reactions. Q&A exchange follows: Q: You say that personal ad hoc groups will be in their own namespace. Does that mean that you will not be using groupOf[Unique]Names for these groups? I ask because that objectclass requires cn, which seems to me would put them in your directory-wide cn namespace. A: I imagine them using groupOfUniqueNames but these objects would be beneath the user object. Example: uid=gettes,ou=people,dc=georgetown,dc=edu might have a group cn=My Friends, ou=Groups, uid=gettes, ou=People, dc=georgetown,dc=edu granted -- it will be a small group, but a group, nonetheless. Q: In a couple of places you mention need for a type of privacy and the need to carefully locate groups spatially in order to implement that privacy policy with ACLs. Have you given thought to using the value of some attribute to indicate a group's "privacy class", and writing group-policy ACLs that refer to that attribute? That should make management of the DIT itself a litle more flexible. A: Yes, I have had some of that consideration. DIT based would be as in the example above and the institutional groups all in ou=groups would be private. The ad hoc groups and the personal groups (also as in the example above) would also need some additional attribute to control privacy. What attribute? -- Maybe mace-dir will answer this. I imagine an additional objectclass to expose an attribute to allow me to control privacy will be necessary. Q: You say that institution groups will be private, but access to them provided on a controlled basis. Will that be done by issuing "service DNs" to qualified processes, coupled with ACLs that permit appropriate access to selected service DNs? Or something along those lines? A: Yes. Q: Are there likely to be any policy based constraints on the types of groups that you may create, eg, groups whose membership is determined in part by demographic characteristics like race or gender? A: Likely so, and this is why all inst groups will be private. Even class lists would expose who is taking what courses. Q: Have you noticed whether or not Corporate Time necessarily lists all groups in ou=Groups when you have the CT client look for "public" groups (when scheduling a meeting)? If the current version still does (old versions did), I wonder what impact that may have on your intention to place thousands of groups in that part of the DIT. A: I modified the CT search criteria for a group such that it will only find those objects with an objectclass=guctgroup. So, I can control which groups are visible to CT. Q: Regarding personal groups such as cn=A Name, ou=groups, uid=auid, ou=people, dc=some, dc=edu, although I know one can specify the group's DN to find it, one of the apparent "better practices" that has surfaced is to avoid making reference to the spatial location, preferring to first search for a group, much as apps should reference a person object by first doing a uid= search to find its dn. Maybe personal groups should be an exception, maybe a more sophisticated "search first" algorithm should be advocated, or... Do you have some wisdom to share along these lines? A: Well, here's what I've been thinking -- yes, allowing for personal group objects anywhere is a good practice, but, since ownership is such an integrated issue here it seems to make a lot of sense to put these groups under the owner. These are intended to be strictly personal groups. Anything beyond a personal group should be graduated to the non-personal ad hoc group (I have to come up with a name for these). This, if someone deletes the DN of the owner -- well, they can't because there are all these personal groups that need to be deleted as well. It prevents group orphans. I could imagine doing something similar with future objects (not sure what).