Group Practices Survey 
Email response from Marilyn Shesko, Harvard

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?

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.

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

groupOfUniqueNames

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

A.3. How are group memberships (to be) maintained? Automated processes? By hand? 
Using what tools?
Most memberships will be maintained by automated processes as part of loading 
LDAP data; in the initial implementation groups will indicate affiliation with 
two levels of organizational unit (roughly equivalent to a department and a 
school); the custom-coded processes that currently translate transactions into 
LDIF will maintain the group relationships. Security-related groups of 
applications that use the LDAP service will be maintained manually.


Do (or will) you maintain referential integrity, i.e., if an object is removed 
from the directory, are its group memberships also removed? How?
We will maintain referential integrity, both through the custom code that 
generates LDIF and by turning on referential integrity checking in the iPlanet 
Directory Server for the relevant attributes.

A.4. Can group objects be members of groups? What object types can be members of 
groups?
No, we do not expect to have groups 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)?
No; groups will be either automatically maintained or maintained manually. Any 
exceptions would have to be implemented in the source system providing data to 
the LDAP service, not in the LDAP service itself.

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, we do not expect to support any of these.

A.6. What policy pertains (will pertain) to administration of group membership?
Our standard LDAP access and security policies will govern membership in 
manually maintained groups. Other groups will be governed by data originating in 
Human Resources and in registrars' systems.

Is administration of groups (to be) delegated?
No

How is the set of groups (to be) groomed, i.e., stale ones made to go away 
eventually?
When the originating system flags a group code value as obsolete, that group's 
entry will be removed.

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?
N/A

A.8. What conventions for group names (will likely) exist? What motivates them?
Group names will be determined by the originating system.

A.9. Are you (or will you be) using groups in support of messaging applications, 
e.g., email distribution lists?
This is likely, but work around definition of these groups is actually preceding 
clearly defined business needs for creation of the groups. That is part of the 
reason why we are not building the groups into our upcoming release. We have 
done much of the theoretical design work but do not currently have an 
implementation date, and may defer implementation until we can see a business 
need.

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

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

B. Are you (or will you be) tracking "roles"? What does that mean to you?
The underlying system that supplies data to LDAP has three basic "roles" of 
employee, student and other/special. People may have multiples of these (two 
employee roles, or mixes of all three, though this is rare). We include in LDAP 
flags like "harvardEduIsActiveStudent", and some detailed information about 
every role a person has. Only the "job" roles wind up as separate entries, which 
we need to support finer-grained access controls around the job-related 
attributes.

Are you (or will you be) implementing something like "role based access 
control"?  If so, how?
For the moment, our target audience for the LDAP service is applications, not 
individuals. Therefore, we would not expect to need such a facility.

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?
groupOfUniqueMembers is clearly more useful for us if we ever want to use groups 
for messaging applications. Otherwise, we will be shipping out multiple copies 
of messages to a single person.  An ability for the server to maintain the 
uniqueness for us would definitely simplify the process.