Group Practices Survey Email response from David Henry, University of Maryland August 10, 2001 A. Please address each of the following items. It would be especially interesting to relate how the nature of particular 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? I think there are cases where each of the listed representations may be appropriate. It all depends on the attributes you have, the way they are managed, and what you are doing with them. Static, i.e., a group object is instantiated with an attribute listing the (person or other) objects which are members. Yes, we do have static groups. We use this type of group when defining authorization ids. Essentially we establish a group which has certain access rights on a set of attributes. Then when granting rights to a particular DN for access to that set of attributes, we just add the DN to the group. Dynamic, i.e., defined by evaluating an ldap URL. A group object may, but need not, exist. I interpret this question in two ways. One, define an instance of a group object whose value is something like an LDAP filter or URL, which when evaluated results in a set of matching entries. The other is nothing more than an LDAP search using such a filter. I see value in both. In the first case, it allows certain commonly or frequently used filters to be predefined for easy access and put the onus on the LDAP administrators to get it right. In the second case, the onus is on the individual applications to get it right. The first is less flexible, should a change be needed, the second is more difficult to maintain if a particular filter is widely distributed in many applications. Whichever is intended by the question, this is likely the most common form of group. For instance, class membership lists, membership in a college or department, etc.. Anytime an authorization or inclusion question is raised based on attribute values, it can be considered to be a dynamic determination of group membership. 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. We do not do this at this time. I could imagine using something like this when the cost of constructing the dynamic group was high and/or the frequency of use was high. By preconstructing group membership periodically (hourly, daily, weekly, etc.), the search could be short circuited and save a lot of cycles. Spatial, another special case of dynamic representation in which group membership is inferred from location in the DIT. Our people are all stored at the same level so we do not do this. Most of what I say relates to the University of Maryland, College Park, one of the 13 institutions in University System of Maryland. At the USM level, we have been talking about constructing a system wide directory to support system wide initiatives and/or the University Library (which is also system wide). In these cases, it is likely we would segregate by location in the DIT where each institution would be contained in a separate branch of the tree. We would also, likely delegate maintenance authority to the different institutions, but this is all in the ether at this point. 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 perhaps custom object class(es)? So far we use groupOfNames and/or groupOfUniqueNames in support of the authorization groups described above. I can't think of situations where we would need custom group objects. If you (will) use a custom group objectclass, what functional requirements drive the design of the group schema? If we were to find a need for a custom group object, clearly, the functional requirements would be driven by the specific need that could not be met by the existing classes. A.3. How are group memberships (to be) maintained? Automated processes? By hand? Using what tools? So far, we have been managing the authorization groups by hand. We have not had to create too many of them so far, so this is feasible. We haven't really considered tools to assist in this activity. The dynamic groups, since they are based on attribute values, are managed through the automated processes used to construct and maintain the directory. With a small number of exceptions, the primary source for almost all of the data in our directory is elsewhere. Thus, we must process the information from HR, SIS, etc. to maintain and update the directory. If we had any dynamic forward reference groups, they would most likely be maintained by a homegrown application that was run periodically to update the group membership. In some sense, spatial groups should be considered very similar to dynamic groups. Most of the spatial relationships would be established in the construction of the directory and based on the value of certain attributes. Changes in the organization of the directory would be driven by certain external inputs (not unlike an attribute value change) that would trigger an adjustment to the spatial positioning of the object. This activity, if it is going to be supportable, must be managed through an automated process. Do (or will) you maintain referential integrity, i.e., if an object is removed from the directory, are its group memberships also removed? How? For authorization groups we do maintain referential integrity. This is done by hand. For dynamic groups this is automatic. For dynamic forward reference groups this would be automatic, modulo the frequency of update as described above. A.4. Can group objects be members of groups? What object types can be members of groups? We don't do this at this time. I can imagine situations where this might be appropriate. Some questions come to mind. Can a group contain group and non- group objects? If a group A contains group B, do the members of group B belong to A? If group A can contain group and non-group objects, the answer is probably yes. If group A may contain only group objects, the answer might be yes or might be no. This is an interesting area and probably deserves some additional consideration by MACE-Dir. 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)? Yes we expect to have something like this. We periodically construct contact lists of the Deans and Department heads. In some cases, the contact is delegated to an assistant. This delegated relationship is not something that can easily be represented by a dynamic group, while the primary role of dean or department head may be represented by a dynamic group. 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? We don't do this today, but I can imagine doing so. One example might be a cross listed course, where the registration in the course could be two different things depending on how the student registered. A dynamically constructed address list for the class membership would need to be constructed from the union of the two sets of registration information. A.6. What policy pertains (will pertain) to administration of group membership? At this time it is all ad hoc. Is administration of groups (to be) delegated? So far, all administration is localized to a very small group. I expectthat ultimately we will delegate some group management authority. How is the set of groups (to be) groomed, i.e., stale ones made to go away eventually? This hasn't been an issue up to now. I expect we will do a periodic review, manually. If we find ourselves with many groups, I imagine the best way to manage this would be to establish a time-to-live for each group that is created. We would then cull out all groups ready to expire to be reviewed. If we ultimately were to delegate group management authority, the respective authority would be responsible for review and renewal of their groups. Having just written the above, it seems to me like we should establish a time- to-live for the groups we have now, so we can get automated reminders to review specific groups at appropriate intervals. 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? I am sure there will be cases where we will not want to establish certain types of groups. Our Registrar has very particular ideas about what is and isn't appropriate use of the student data. A.8. What conventions for group names (will likely) exist? What motivates them? The authorization groups are typically named based a mnemonic for the purpose of the group. In some cases, the campus unit id and/or function is used. While we have good records related to the groups created thus far, a well chosen name will help us keep them straight without requiring regular references to the records. So far, this hasn't been an issue, but as the number grows, it may become an issue. A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? There are two major categories of lists. One is a dynamic email list (e.g. all students enrolled in MATH101). The other is a user managed email list, where a list owner would be authorized to update the membership. I expect to do the first. I haven't decided if we want to do the second. 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? We do not expect to provide this capability. I can, however, imagine several examples where this type of support might be used. For example, student club membership, listserv type email services, authorized academic advisors, and more. In any case, some consideration of how these groups are represented in the directory should be given. For example, it might be appropriate, in some cases, to use one of the defined group objects where membership in the group object represents membership in the group. In other cases, it may be more appropriate to represent group membership by setting an attribute in the person object. In each case, a number of factors should be considered. These include the size of the group, the frequency of access, the source of the information (institutions, user input, group manager, etc.), the frequency of update, and probably others I can't think of right now. Do such groups occupy the same namespace as other groups or other types of objects? If we did, they would be kept in a separate part of the DIT. The names of the groups would likely be in a separate namespace. B. Are you (or will you be) tracking "roles"? What does that mean to you? In my mind a role is almost the same as a group. The semantics are slightly different, but technically, they could be managed just like groups. Are you (or will you be) implementing something like "role based access control"? If so, how? If you accept the premise that a role is a group is a role, then we already have applications that implement role based access control. For instance we have some web sites that require authorization, based on certain attribute values, to enter. 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? I don't think I have been playing in this space long enough to be really concerned. Am I being naive? Probably, I am. I suppose I have some concerns related to scaling. If we start using groups for more things than we do today, we will need some tools to help manage them. D. Please list any further current or planned applications using middleware groups that haven't already been discussed and provide a brief description of each. I've given a few examples in the text above. I think you have addressed the major categories of applications in the questions raised. E. Thanks for sharing that information. In addition, we'd appreciate your direct advice on the direction MACE-Dir ought to take in this area. The concept of groups of groups is an interesting one. The issue of self managed groups seems intriguing, even though we are not planning on doing it. Tools for managing, reviewing, delegating administration would all be worth looking at. Best practices on how to manage groups (how often should reviews be done? how much delegation is desirable? what policies should be instituted? etc.)