Group Practices Survey interview with Tim Torgenrud, Stanford August 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 guess dynamic is close. We do our grouping through the LDAP Directory. But, the way we are representing grouping currently, is that the grouping is placed as an attribute in a persons LDAP entry. So it is not exactly a direct LDAP URL, but rather has to be done by processing the result returned. It can also be done as a basic attribute query on a person's entry, but you don't really do that query as a URL, you have to do it as an actual query. In the future, representation that will definitely be dynamic. The LDAP Repository is a read only store for a business object system, and since the business object systems is doing real time analysis or near real time analysis on people's privileges and membership we needed to have a way to match that for the business systems. The business systems all know how to read LDAP so we do it that way and it has be dynamic because of the nature of change that can occur across the audience spectrum. o Static, i.e., a group object is instantiated with an attribute listing the (person or other) objects which are members. o Dynamic, i.e., defined by evaluating an ldap URL. A group object may, but need not, exist. o 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. o Spatial, another special case of dynamic representation in which group membership is inferred from location in the DIT. 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)? That is our current discussion, which is why the dynamic URL for the group itself is not in place. We are currently debating whether to do a custom group object class or to use a more standardized one. We have not reached a decision yet. If you (will) use a custom group objectclass, what functional requirements drive the design of the group schema? Functional requirement would be interaction with other infrastructure systems, such as Campus ID Cards for door access, in working with how that system can integrate its data for privileges, Campus AFS File Systems and how we would map groupings into that structure. Those are the two major drivers at this point. A.3. How are group memberships (to be) maintained? Automated processes? By hand? Using what tools? The hope is that they will be automated processes that are done in our registry system, which is basically a business rules coordinator. It receives feeds from multiple institutional store systems, human resources, registrar, faculty appointments etc... applies business rules to them then takes the identity of that individual or individuals and places them with the appropriate attributes for their entry in their appropriate placement in groups. Currently, it does work for persons now, in terms of putting group names in to their individual entries, we just don't have the group representations itself in the directories. Do (or will) you maintain referential integrity, i.e., if an object is removed from the directory, are its group memberships also removed? How? Do we maintain referential integrity? mostly. That part is supposed to be automated but does not always appear to be working. In terms of the person record right now, yes, in 99% of the cases it works correctly. If an object is removed from the directory, its group memberships are also removed. It is done through a series of messages from the registry to its component parts and in response to those messages the different component parts will remove the object pieces they are responsible for. A.4. Can group objects be members of groups? What object types can be members of groups? This is still being debated, but the current stance is yes, object types that can be member of groups are the following object types: a person object, a group object, organization object, (kind of a meta group object), and one other called a service object (network identity that is not necessarily attached to a person, but rather a process). 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)? No, I don't think so, it sounds like basically doing the set of exceptions on the fly applying to the group - if that is the way the question is worded the answer is no. We do expect to have the ability to have people reference two groups together in a reference set. One which may be an automated group the other may be an additional group that they manually maintain themselves through the group assignment system but not in the form of saying "do an add or subtract of these members to the initial list", simply be an ability to reference both lists. It could sort of be seen as inclusive. 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? No A.6. What policy pertains (will pertain) to administration of group membership? Is administration of groups (to be) delegated? The policy is done in two forms, one is either through the organizational definition, which means that you can establish groups underneath your organization monitor and those groups will be basically stemmed or initially indicated as being owned by that organization. There maintenance is limited to those folks tied to that organization, department, division or student club. The other policy pertains to those who want to do ad-hoc group maintenance, they will be able to establish groups that are tied directly to their individual network identity and they can then delegate the authority to other people if they choose to. Organizational delegation can only be done up the tree. The individual ad-hoc group administration is also dependant on the fact that the network identity that it is being assigned to must be active, when it goes inactive the groups tied to that also go inactive. How is the set of groups (to be) groomed, i.e., stale ones made to go away eventually? The ones that are tied to individual network identities go away immediately upon expiration or inactivity that is near real time. In terms of organizational one, that dependant upon the registry system making an organization no longer existent. I suspect that although it has not happened yet, I am sure it will at some point soon. What will probably happen with that is that probably it will simply go through a warning and someone will have to reset the expire date on the organizational groups as they are set with an infinite expire date. Not sure that the issue has been totally addressed. 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? Privacy I believe we have. There are 3 types of privacy that can be assigned to a group, and that privacy is either considered private, where as the group is only visible to the group, domain wide or campus wide, which is only visible to those folks who are identified as members of the existing campus community, which does not include everybody with necessarily a network identifier, but rather those network identifiers that are identified as currently active students, facility, or staff. Other wise visible to anyone who has access to the network grouping system, which is pretty much anyone who has a web browser. Those are the three levels of privacy. Security policy is such that you have to have a Stanford network identifier in order to an any way create groups and your network identifier must be within the organizational id if you are creating organizational groups. You cannot make groups outside of your organizational boundaries nor outside of the stem monitor for your personal network identifier if you are making more of what we consider a personal group. A.8. What conventions for group names (will likely) exist? What motivates them? Current expectation of group name form is that it will be of the form of alphanumeric stem, colon separator, and alphanumeric leaf. With the stem being either the organizational or personal identifier, the colon being the separator, and the leaf being the choice of the person making the group. What motivates that primarily at this point is that it maps into the current format that both the campus id card system and campus AFS file system use for grouping indicators A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? We are currently not, but will be. That will actually start in approximately 47 days, they are currently coding. 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 will be allowing personal group and we currently do, but at the current moment since the system is under pilot, you actually have to have a bitfliped saying you are allowed to create personal groups. That bit will be flipped on automatically for any one identified as a Stanford community member when the system goes fully live. That can be created and maintained by "ordinary" users. Groups will not be designated as joinable by individuals outside the owner, the owner must maintain the personal group. Purposes will be typically primarily in that case probably for things to do with access to web pages and control in the campus file system. Do such groups occupy the same namespace as other groups or other types of objects? Yes B. Are you (or will you be) tracking "roles"? What does that mean to you? Yes we are currently tracking roles. We are currently extending the roles that they track What that means to us is the person's status with in the institution, we currently have four major role categories, they are student, staff, faculty and affiliate. We are working on refining those in terms of adding secondary tags on to that role level, such as incoming student, active student vs. alumni. In terms of Role based access control, we are also doing that in two ways, we have the notion of tracking that affiliation and the major role in terms of student, faculty, staff, or affiliate, we also have the notion that groups can be used in terms of being automatically built by the registry system, certain groups that start with a Stanford stem, those allows us to actually group sets of individuals, by putting that privilege group as an attribute into their personal entries so we can have for example for myself I have a privilege group known as Stanford:Staff that can then be used to by different systems to allow or deny access based on the fact that my entry indicates I have the role of Stanford:Staff. That particular role is being used currently with access to web pages and also to benefit system. Are you (or will you be) implementing something like "role based access control"? If so, how? 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? Probably the biggest thing that worries us is in terms of groups is not actually the specific gesture groups, but is simply the issue in our area that we are still technically bound by 8 character user id for some of our Unix implementation and such have a limited size name space for personal user name space which limits our stemming for personal groups. Means people are exposing perhaps identifiers they just assume no one ever saw because they think they are ugly. Beyond that we have the issue of how we expose and maintain the privacy settings of this implementation of groups as we start pushing it out in XML and different varying formats, as they become standards. Group related operations or facilities that don't exist is probably the manner in which we can tie the idea of group authority into the fixed individual authentication system, since we are using the KERBEROS systems as our core authentication systems, given that a lot of different applications do not use any kind of generic notion of group and/or for that matter individuals. They like to force the identities and groups personally basically directly into their applications instead of going to an external resource in a generically defined fashion. 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. Probably one of the groups that have not been discussed that is of particular interest to us as an educational entity is trying to focus on the idea of grouping within the course work framework. How do we deal with entities that typically an instructor wants to deal with from a grouping aspect? Where they typically bring in entities that we wouldn't typically consider as part of our normal identifier space. Say, an individual lecturer's, one-time users, that they basically want in for a week and then will never see again. So, kind of the idea of an ability to incorporate into a group something we think of as a one time or short term use identifier and how we would track that in a system without making it cumbersome. The other is something I know is being focused on, which is to cross authentication frameworks. Being able to share authentication identity, so that we can incorporate authentication identities that are actually confirmed simply from another trust authentication source into a group framework. We have not tried to tackle that issue yet. But basically as our faculty starts doing a lot more with online course interaction they are wanting to have the system be able to scope in a group sense, across the individuals they interact with. Whether the individuals be local to campus or totally outside the framework of the campus boundaries in terms of authentication. 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. Probably have to drill back in, in terms of what MACE is doing right now, to feel like I was giving any kind of valuable input there. But I think one of the things that pop to mind is a clear definition for folks in terms of areas where things can be delivered across multiple technologies. I know that is a goal, but, it would be good as it comes up often in discussions that making sure the issues of authentication vs. authorization are clearly and separately defined. The line often gets bleared, and every time it does we have to go back over it.