Collaboration Architecture

Background

Because of their diversity, there is often little need for a commonality among collaboration tools. For example, there is little need for a common repository that is shared by a wiki, electronic mail list processor, and an electronic white board.  It may be nice to have a wiki that can send update notifications to an electronic mail list, or to incorporate a collaboratively-drawn image from a white board into a wiki page, but such integrations, while very useful, tend to be specific to each paring of tools.

The one thing that all tools need, however, is the list of people who are participating in a particular collaborating group and, perhaps, roles of individuals within subgroups. By maintaining these group definitions in a common repository, we gain the following advantages:

• Group leaders do not need to maintain group membership separately for separate tools and services.
• New tools and services can be used by existing groups without re-specifying the groups' membership.
• When security is an issue, group members can be denied access from all tools and services at the same time

Also, collaborating groups often include members that are not directly associated with UC Davis.  Because of this, the use of federated authentication (i.e., Shibboleth and InCommon / UCTrust) is highly desirable.

In general, the vision is to provide a collection of tools and services that can be useful to collaborating groups. Once a group's membership has been defined, these tools and services become available to the group and, according to the group's needs, used with little or no additional setup.

Proposal

• The Identity and Access Management project should implement group management through the use of the isMemberOf and hasMember attributes, as defined for LDAP and SAML by the Groups subgroup of MACE-Dir. Once this has been implemented, collaboration tools and services that are adopted for general use at UC Davis should make use of that group management service.
• Collaboration tools and services that are implemented or acquired before group management has been implemented should be capable of migrating after the service is available.
• Collaboration tools and services should utilize Shibboleth and InCommon for authentication whenever possible.
• Internet2's COmanage project should be tracked as a promising source of software that will extend this architecture over the next few years.