Group Practices Survey Interview with Louise Miller- Finn, Johns Hopkins July 31, 2001 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? Don't have groups deployed yet, have a container laid out for them. Static, i.e., a group object is instantiated with an attribute listing the (person or other) objects, which are members. Plan to use - lots of static groups on campus, fixed -stay that way for at least for an academic term. They are the "natural groups" Dynamic, i.e., defined by evaluating an ldap URL. A group object may, but need not, exist. Plan to use, Ad hoc, special interest committee, club -may be self-subscribing, will use to generate email lists, granting access to applications, resources on the network 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. See dynamic and dynamic forward referential very very similar - hard to discern the difference, very much waiting to see what Mace comes up with. If have a group that is self-subscribing-it is problematic. What happens if owner leaves? Is there a date for renewal? How to keep "self cleansing" Spatial, another special case of dynamic representation in which group membership is inferred from location in the DIT. Don't plan to use 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? (Too much to answer in one question - plus not seeing ahead of time) Would probably be Object classes-and it may depend.... we've looked at those that exist - those built into iPlanet or LDAP in general. And it was hard to find object classes that lend themselves easily to groups -seems as though will have to go about creating an object class. Once you've done that - the attributes have to adaptable to the different types of groups. One of the things we plan on doing is creating a Group ID that is maintained as the DN for the group. Then assigning membership into that group. Static groups are easy.--- if OU = X - then you are automatically a member of the group. 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? Automated as much as possible-knowing full well that there will need to be some type of manual intervention. Currently we have 3 types/levels of administrators 1. Directory Managers, 2. email administrators, 3. Departmental HR type administrators (their counterpart would be the Registrar directory administrators) They would be able ( this is all theory) to add people to groups as people needed to be .... If dynamic type of group, --there has to be someone who owns that group-that person could also have the ability to add or remove members as needed. The plan is to build utilities as needed to accommodate this type of administration. -a web interface - (asked about platform) Every thing we are doing is in cold fusion. A.4. Can group objects be members of groups? Yeah...then laughed---See, that could be a can of worms right there. Yes, they would have to be-a department is part of division, there are several departments within a division. What object types can be members of groups? That I can't answer at this time. Obviously people, applications, resources - and groups themselves. 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? Have been watching Keith talk about that. We haven't thought that far down the road yet. Mainly focused on getting the initial things set up for groups. As far as doing the set operations, we haven't even considered it. 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? Would have to be an expiration date on dynamic type groups--- would have to be an expiration date where each year - probably at the end of the academic year there would be an updating cleansing audit type process that would occur. The static groups would be mandatory membership, the other ones that are more dynamic - the issues that I see are with ownership - if the owner leaves during the year... what happens to the group? The dynamic groups should be self cleansing----Referring over to members in the people container. As soon as someone gets deactivated or removed from the directory their group memberships should go away as well. 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? No policy today. Given that we have lots of issues involving policies expect they will be ad hoc or implied as far as privacy and security of groups --- something that would be managed by the enterprise directory maintainers. As far as publishing members of groups--dynamic would not be public information, static groups would be public information-just because a matter of public record anyway... A.8. What conventions for group names (will likely) exist? What motivates them? Group names will probably... is what your saying -would we standardize on how we assign group names? Responded: let's assume that--- will you, standardize on the way they are formed, so that you are able to identify the static versus the dynamic? Haven't thought about it.... A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? That's something we're working on right now. Definitely-there is no next version of List Proc. One of our goals over the next 6 months is to replace it with dynamically generated group mailing lists generated from LDAP inquiries. 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? (that's a lot of question) User groups-- let's take it from that angle--- and supportability of them- probably the biggest gray area for us---that we are very much fearful going down that path and having it take us over. Knowing that people will want to opt in/out of lists. Don't want to / but will need manual intervention. This will be a challenge for us -static groups will be a "no brainer"-it's these dynamic ones.... Initially when we start to use groups and we'll use them for creating mail lists and things like that and access to other things. We probably will not start out allowing user defined groups - where people can opt in and out of them. Probable tackle in stage two- harder and dangerous. 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, very interested - looking at a couple of different products one is by Business Layers a product called "e-provision day one", other product is Access360. To do e-provisioning for accounts, access to applications. That is where we see value of what roles for provisioning of services that is roles based. Not sure how we'll do it - the 2 products very expensive - may do something in house The main reason we want roles is to do provisioning of services. C. What aspects about your (planned) implementation of groups worries you? Going back to user defined groups-and the ability of people to subscribe in and out automatically and not have them grow out of control, take over resources on mail hosts, mail relays and things like that ...Sort of keeping them under control. What group related operations or facilities don't exist that would significantly simplify your task if they did? The ability to integrate List Proc w group mailings - something that we plan to automate. 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. Another way we plan on using groups is through applications. Some are unable to do internal authorizations and so what we will do is store information about a person within the application area which really filters down into a group which gives them access to an application-and then storing attributes about that person, that the application can use to authorize them into the app-giving them different levels of access-that's one way we plan on using groups. Resources--same thing, adding people into groups to grant them access to various resources around the network. Maybe membership in a v-LAN, or a level of QoS on the network ---integrating a directory enable type network component E. Thanks for sharing that information. In addition, we'd appreciate your direct advice on the direction mace ought to take in this area. From watching mace develop eduPerson - very, very conservative-trying to find one solution to fit all. Took an inordinate amount of time to do that--- it was almost paralysis through analysis. Afraid to do anything because afraid to do the wrong thing Just take a stab at it - bring things to the public faster. Use Internet2 as a forum to present the latest and greatest ideas-and just have a public debate on it-there are enough people out there familiar enough with the problems and the issues at hand that there can have some pretty good discussion - maybe have a BoF or something like that. It's hard to get in tune with a conference call every other week - it's a very tough schedule - it's grueling. If at opportune times we have the ability to come together to hear the latest think is and offer up additional thoughts or suggestions Asked for suggestions for public airing: At 2 conferences - beyond that -it's a conference call so.... I've looked at the threads - it's a group of people who are very much in tune with where everyone else is on the issues...So if someone else joins - it's difficult for them to know what's been said --how far they've come - what ground they've covered. GROUP PRACTICES SOLICITATION 1