Group Practices Survey 
Email response from Jim Fox, University of Washington 
August 10, 2001

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, i.e., a group object is instantiated with an attribute listing the 
(person or other) objects which are members.
Dynamic, i.e., 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.

Our groups are static.  Chosen because it is simple and sufficient.

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)?

We use groupOfUniqueNames

If you (will) use a custom group objectclass, what functional requirements drive 
the design of the group schema?

Do not.

A.3. How are group memberships (to be) maintained? Automated processes? By hand? 
Using what tools?

We use both manual and automatic.

Groups that contain class lists (students), for example,are automatically 
generated at the start of each quarter.

Most other groups are manually maintained.  We have a web interface for group 
maintenance.


Do (or will) you maintain referential integrity, i.e., if an object is removed 
from the directory, are its group memberships also removed? How?

Our people are identified as members of groups by a unique identifier, which 
NEVER goes away.

A.4. Can group objects be members of groups? What object types can be members of 
groups?

Groups can be members of groups.  For authorization purposes anyone in a 
subgroup has the same permissions as anyone directly in the main group.  For now 
only individuals and groups can be members of groups.

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?

At present we have only one example of this.  Membership in a course allows 
membership in either of two real groups: The "course list", which contains 
registered students and is automatically generated; and the "course group", 
which is a manually edited group of extras, e.g. TA or professor.  Checking both 
real groups for a "in the course" query is done by the client API and not by the 
server.

A.6. What policy pertains (will pertain) to administration of group membership?

Each organizational unit and group can have an associated ACL that identifies 
individuals (or groups) that can either read or maintain that organizational 
unit or group. The web page allows authorized users, by this ACL, to add new 
groups, add or delete members of groups, and add or delete administrators (via 
ACLs).

Is administration of groups (to be) delegated?

Yes, as described above.  I might, for example, create a group "depts.physics" 
and assign user "joebob" as an administrator, via the ACL on the group.  joebob 
then administers the group himself.

How is the set of groups (to be) groomed, i.e., stale ones made to go away 
eventually?

We have not established any policy here.

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 think we prefer a group not contain itself as a member. Other than that we 
have not dealt with this question.

A.8. What conventions for group names (will likely) exist? What motivates them?

This is undecided, and is the principal hindrance in full deployment of our 
system.  The groups are organized in organizational unit trees. One tree 
somewhat follows the departmental organization of the university; another is 
more related to projects; a third will be organized into 'personal' groups.

A.9. Are you (or will you be) using groups in support of messaging applications, 
e.g., email distribution lists?

We don't have any plan to do this.  We use listserv for mailing lists.

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 plan to have personal groups, which would be administered by the group's 
owner, much like listserv is administered. Our maintenance programs do not 
support the idea of autonomous maintenance.  The group's administrator would do 
the work.  Personal groups would most likely be used to provide authorization to 
personal web pages.

Do such groups occupy the same namespace as other groups or other types of 
objects?

Our namespace (kind of a global term) also includes a person registry.  Each 
'university person' (anybody really) has a record there.  We use some of the 
attributes in those records as part of our authorization, e.g. "Is this person 
an undergraduate?"


B. Are you (or will you be) tracking "roles"? What does that mean to you?

We are not, at least as a part of this effort.  If we were, I would implement a 
role as membership in a group (the role) which is itself a member of several 
other groups.

Are you (or will you be) implementing something like "role based access 
control"? If so, how?

For now just the group based access control.  Note that this already provides 
for the simple implementation of roles montioned in part B.

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?

The organization and naming of groups is in the hands of a committee of 
managers.  It could take forever.
I have not yet investigated the ease or difficulty of porting our authorization 
apache module to IIS.  Nor do I know what facilities IIS may already have to 
work with LDAP groups.

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.

Not quite sure what you want here.  We access the authorization groups through a 
'c' language API, and through .htaccess directives (custom apache module).  I 
may add some Java classes to provide easy authorization from Java programs, 
servlets and jsp pages.

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.

I'd say to develop some sort of standard path and group naming conventions, but 
that sound like an even bigger committee than the one we have here.

I do like to separate the arcane LDAP syntax from users.We use a dot notation, 
e.g. the .htaccess directive: require group Departments.C&C.AST.all maps to 
membership of the remote user in the group: 
cn=all,ou=AST,ou=C&C,ou=Departments,ou=Groups,dc=u,dc=washington,dc=edu