Group Practices Survey Email response from Chad La Joie, Virginia Polytechnic Institute 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? We have chosen to use a static representation of groups. An object will be used to define a group and its membership. We chose this because it's similar to our current directory's concept of roles and thus we felt that the transition to this broader concept would be easier. 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? As mentioned above we will be using an object class called group, which will use another object, called member, in order to represent its membership list. Below is the planned layout for a group and a brief description of each attribute. - group attributes - UUGID - the unique name of the group displayName - the human readable name of the group contact person - the id of the person to contact for group info emailAddress - the email address for the group url - a url to a page describing the group administrators - list of ids who can administer the group members - a list that represents members of the group - member attributes - id - the id of this person used to cross reference to the person's entry in the directory visible - a field describing the visibility of the person within the group (see A.7 for further description) creationDate - the date the person was added to the group expirationDate - the date the person "expires" from the group. This only for applications to use, the directory does not do anything with a member if this date is exceeded. These objects were chosen for a few reasons. First we needed an object that mapped well to our current authorization system's concept of groups. We also needed something that mapped to our current directories' concept of roles. Also we are expecting to use groups as a replacement for departmental Ids. 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? Group membership will be maintained in a couple of ways. One way is through a batch/real-time update process that will take group defining information out of our enterprise data systems (such as Banner), process it, and update group membership information based on that. The second way will be through the use of online tools, which will be the method used by personal groups (described later). Administrators of the group will be able to maintain membership, contact, display name, and email information for the group through this tool. Referential integrity will be maintained within the directory. Applications that have the ability to remove users from the directory, which are very few, are expected to remove users from their groups when they remove the user themselves. In the event of problems however, a separate "garbage collection" process will also periodically check the integrity of the directory. It is not known yet how this process will work. A.4. Can group objects be members of groups? What object types can be members of groups? Currently only people, who are represented by the member object, can be in groups. It was discussed that groups should be able to be members of groups however this idea was abandoned for a few reasons. First the complexity this added to the directory, we felt, was not worth the benefits. Second we were very concerned about how programs might resolve the groups within groups and how the directory itself would ensure, without a doubt, that a recursive group could not be created. Lastly we felt that through the use of two or more very simple queries and basic set math the same behavior could be created on an application level with relative ease there by eliminating the two above concerns. 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? We currently do not expect to have a mechanism within the directory to do this. We feel that this is the job of the application(s) populating the directory and not the job of the directory itself. As far as set/group math, we expect to implement this at the application level, through helper libraries, and not at the directory level. 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? As discussed above administrators will be able to edit membership, display name, contact person, and email information through online tools designed for those purposes. This will allow the administration of groups to be delegated to the people who really work with the groups. Creation of groups however is centralized in two manners. University wide and approved groups will be created by our Information Resource Management (IRM) department, while user/personal groups will be defined by the users themselves. One discussed, though not yet agreed upon, process for grooming is as follows. A nightly process will go through and examine the expiration date of the group. Those that are found to be expired will have an email sent to the contact person. The email will contain a link to a small page with a single button on it, if the user is still using the group, they may click the button and their group is renewed for another given period of time. If after 30 days the group has not been renewed the group will be removed from the directory. 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? A user will have the option of setting their group visibility, defined as the visible attribute in the member object, with one of three values. A value of "public" means the user may be seen in any public listing of the group's membership. A value of "group" means the person will only be visible to other people in the group. A value of "private" means the person may never be displayed in a group membership listing. It should be noted that a value of "private" does not disallow services requiring this information to see group listings; it just means they cannot display the list. This is to protect people who are in groups that may be targeted for certain types of crude or bigotous behavior. Group creation, as stated above, which are University wide/approved will need to meet the requirements set forth by IRM. These requirements, however, have not yet been established. For user created groups, a rule set will be checked during the creation of the group to check that the group name is acceptable. It is felt that this is the best the University can do in monitoring these groups. A.8. What conventions for group names (will likely) exist? What motivates them? With the inclusion of user definable groups within the directory it was reasoned that separate namespaces must be set up for special groups in order to stop group name collisions, exhaustion, and resolutions. Therefore our groups will fall into one of two large namespaces. User defined groups will be prefixed with the creating user's id, creating a separate namespace for every user, and it becomes the responsibility of the user to maintain name uniqueness within his/her personal namespace. This name space is simply referred to as the user namespace. University wide groups will be controlled by IRM, which may or may not prefix the group name with a namespace identifier. It will be IRM's responsibility to ensure name uniqueness within this namespace, and its sub- namespaces. IRM may delegate responsibility of a sub-namespace though to other individuals through the use of external tools. This name space is referred to as the University namespace. A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? We expect to be using groups with some messaging applications. We are currently considering using them to represent "buddy lists" within instant messaging clients. We are also considering using them in conjunction with an email distribution list as the actual list of people to distribute to. 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? Yes, we will be having groups defined by ordinary users. The membership for these groups will work in exactly the same manner as other groups. Once a user has created a group, s/he will be the administrator of that group and can then edit the membership information. User defined groups will be usable for numerous things. A user can use a group to set rights and permissions within certain applications, like our content publishing program known as Filebox; these groups may also be usable, as stated above, for "buddy lists" in instant messaging programs. A user may use them, also mentioned above, as distribution lists for email. For a discussion of the namespace division of groups see A.8 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? VT's current directory has a concept of a role which may be one of a few values like: staff, student, employee, alumni, etc. The new directory will use groups to replace the concept of roles. Instead of a single role attribute associated with a person entry, groups will be created for each of the previous possible role values and those users that had that role value will now become members of that group. We will also be fully supporting the eduPerson spec that allows for role like information to be stored with a person's entry. These eduPerson "roles" may or may not be replicated in our group structure as well. This has not yet been decided. Groups in general, not just those corresponding to roles, may be used for access control information. A university club may choose to restrict a certain section of their website to group members, and could thus use the membership listing in their club's group member listing to do this. Other programs may use the group information in the same manner. 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? Our biggest worry currently is just that we are missing something. While we've talked with numerous departments to gather information on what they would like groups to do within this new directory, we still worry that we missed some one who will have a valid, but as of yet un-thought of, requirement for groups. 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. While I could list numerous (probably hundreds) of applications here, let me instead just give a basic overview of what types of applications will be using groups. Authorization Applications - These are applications that will use group information to authorize a user who has access rights to certain information/services (e.g. email systems). Personalizing Applications - These are applications that display certain information to certain groups of people (e.g. portal systems). This information may also be authorization restricted, but it may not.