Group Practices Survey 
Email response from Arlene Allen, University of California, Santa Barbara
August 15, 2001


In terms of a quick response, the usefulness of groups seems to have rapidly 
diminished in recent times.

At Catalyst, virtually everyone I spoke with agreed that Roles are much more 
adaptable to organizational circumstances, and that in many instances, policy 
based roles, rather than static, are the only ones that tend to reflect the 
organized anarchy of the typical business enterprise.

In your note herein, you captured it perfectly - "but not always correctly" 
(editor's note: referenced comment included as footnote 1.)  That's 
unfortunately damning. We have managers who are only managers because their 
supervisor has said it to be so, hence delegated admin. So... we're using multi-
valued affiliation for global status instances such as "student". Everything 
else will be role based. There will be no group of managers or department heads 
for example.

fwiw


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

No current or planned.  Some extremely minimal use for server management issues.


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

No intention at this time to implement group membership for public data.


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

None


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

n/a

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

n/a

C. Anything to do with People objects that crosses a single entry instance and 
that would also be useful to the org, is being implemented with (usually) 
policy-based roles.  Most access control scenarios tend to rely on this type of 
designation rather than static membership.

I see no point in creating groups in LDAP, given that the kinds of questions 
groups answer is not what we seem to be asking of our directory, and secondly, 
such questions belong to an sql database in any case.  I continue to track 
Radiant Logic's efforts in this regard.



Footnote 1. (Pasted from survey request).
.....I would like to know what, if anything, you all are planning WRT supporting 
groups, and the rationale.

Clearly there is an efficiency in predefining group membership, as opposed to 
deriving it from other rules. E.g. "employee" as an explicit attribute instead 
of derived from payroll title and current status. On the other hand, when things 
change, manual intervention may be required.

Other types of groups - e.g. member of the Chess Club - can't really be derived.

As an example, suppose HR wanted to email to all Managers & Supervisors. This 
could be derived from payroll title (usually, but not always correctly) but it 
could also be made an explicit field in each person's record. Which one chooses 
depends on a number of things.

Below is a questionnaire .... 
(end of reference)