Provisioning Groups

The purpose of this document is to discuss methods of provisioning groups in the Registry.
The potential uses of groups has not been explored to its fullest, but any design should be as simple and flexible as possible.
This document will explain what groups are, what information is associated with them, and scenarios for using groups.
The most basic definition of a group is an arbitrary collection of zero or more people in the directory.

Groups have two attributes which control membership:

• joinability
• leaveability

These two attributes can have values of either: open or managed.
A value of open indicates that a person can control whether they join or leave a group.
A value of managed indicates that only an administrator can add or remove people from a group.

Groups have one attribute which controls membership display:

• viewer

This attribute contains the DN(s) allowed to view the group membership in the ou=Groups branch.
If this attribute is empty, then group membership can be seen anonymously in the ou=Groups branch.
If this attribute is set, then one or more services/people can view the group membership in ED-ID and the group will not display anonymously.

Group membership can be determined in two ways.
If you need to know the groups a person is in, the person's groupMembership attribute will return the DNs of all groups that person is a member of.
A person's groupMembership attribute can only be viewed by ED-ID services (with appropriate permissions) or by that authenticated person.
If you need to know the people in a group, the group's member attribute will return the DNs of all people who are members of the group.
A group's member attribute can only be viewed by ED-ID services (with appropriate permissions) or anonymously if the viewer attribute is not set.

A group has several attributes which contain demographic data:

• displayName
• emailAddress
• groupData
• labeledURI
• suppressDisplay

The groupData attribute is reserved for miscellaneous data such as meeting times, meeting places, etc.
The suppressDisplay attribute controls whether or not this data is viewable in ED-Lite.

There will be two web interfaces for maintaining groups:

• The DAT
• The Groups web application

The DAT will contain administrative functionality reserved for IRM that can operate on any group.
The Groups web application will be for people to create and manage their own groups.

• search for groups
• create groups
• add/remove administrators
• add/remove members
• set the group contact person
• add/remove viewers
• set joinability/leaveability
• set the suppressDisplay field
• set the group display name
• set the group email address
• set group data
• set group URIs

ED-ID services with appropriate permission will be allowed to create and maintain groups programmatically.

These are functions performed automatically by the Enterprise Directory.

• Pruning expired groups (notice will be given)
• Pruning shelved people from groups (no notice will be given)
• Setting the group expire date if all administrators are removed from the group

• Authorization
• Personalized content
• GroupFinder for searching for groups (displays only group demographic information)

These schemas are provided here for easy reference.

(unrelated attributes have been removed)

• DAT interface:
  • search for groups
  • create groups
  • add/remove administrators
  • add/remove members
  • set the group contact person
  • add/remove viewers
  • set displayName
  • set emailAddress

• ED Services for deprovisioning groups and people from groups
• Update ED Ldap libraries to work with groups

• Public groups admin interface: (creation restricted to VT Employees)
  • view groups you are administrating
  • create groups
  • add/remove administrators
  • add/remove members
  • set the group contact person
  • add/remove viewers
  • set displayName
  • set emailAddress

• DAT interface:
  • set suppressDisplay
  • set groupData
  • set labeledURI
• Public groups admin interface:
  • set suppressDisplay
  • set groupData
  • set labeledURI
• Public groups finder interface: (may reside in search.vt.edu, but won't reside in the DAT)
  • anyone can search on group demographic data
• 'My Profile' in portal updated to show a person's group membership

• ED-ID services allowed to create and maintain groups (web service or direct ldap?)
  • begin leveraging the new manageGroups attribute

• Public groups interface:
  • anyone can view their group memberships
  • anyone can add themselves to open joinable groups
  • anyone can remove themselves from open leaveable groups

• Do we need to consider groups as members of groups?
  • We have spoken about this, but could never determine if it was useful. — dhawes@vt.edu 2005/08/24 19:02
• Is the groupData attribute of a group free-format? any restrictions on its contents / content type?
  • It is currently defined as a directory string, and I don't think we would put any restriction on it. I like to call these types of attributes “void pointers”. :) — dhawes@vt.edu 2005/08/24 19:04
  • Example uses would be: meeting time, meeting place, etc. Basically anything we want to add for future demographic use. — dfisher@vt.edu 2005/08/25 11:31
• When a VT employee creates a group using the web application, is that person automatically added as the administrator? At that point are most of the interface functions limited to the administrator(s)?
  • Group creation would make the group creator the sole administrator. At that point the admin can add other people and even remove themselves. — dfisher@vt.edu 2005/08/25 11:31
  • All management interface functions would be restricted to administrators. — dfisher@vt.edu 2005/08/25 11:31
• In the interface functions, why are some listed as add/remove and others as set? Some of the 'set' ones seem like they should be removable once set, such as email address or group data. Maybe 'set' implies a way to remove the attribute.
  • Don't get hung up on the language, it just represents how single value attributes are handled versus multi-value attributes. And really I just want to show what functionality will be available and what times. — dfisher@vt.edu 2005/08/25 11:31
• If all administrators of a group get removed, how does the first one get added back?
  • The group gets marked for expiration. IRM must be contacted for an administrator to be added back. — dfisher@vt.edu 2005/08/25 11:31
• Are we going to explore the concept of “auth groups” (a group with a userPassword)? — dhawes@vt.edu 2005/08/24 19:14
  • I think we had some security concerns with this model, but if there is a use case for it we can investigate. Since this is solely a replication issue it would be easy functionality to add. — dfisher@vt.edu 2005/08/25 11:31
• From discussions with Daniel, I think you might want to talk about a group's lifecycle and how to properly entertain the notion of required ownership of the group. I'd suggest requiring an employee to “sponsor” a group. Have them tied to it as a primary admin (who has full function over the group). Then, they can delegate some subset of admin functions (like add/remove of members) to a non-employee. If the employee tried to remove themself from the group, slap a expiration on it for auto-deprovisioning. That way, down the road, when that employee is de-provisioned they can be indentified as the owner of these groups and they can be taken care of as well. — marcd@vt.edu 2005/10/13 17:17

IRM, as the sponsor of the ED project, is not ready to release for deployment any of the following functionality associated with the Public Groups Admin Interface except “add/delete members” and “view groups you are administrating”.

Public groups admin interface: (creation restricted to VT Employees)

        o
          view groups you are administrating
        o
          create groups
        o
          add/remove administrators
        o
          add/remove members
        o
          set the group contact person
        o
          add/remove viewers
        o
          set displayName
        o
          set emailAddress