Comparing the uPortal Groups Service and Grouper

Owned by Gary Brown
Last updated: Sept 22, 2005Version comment
3 min read

My perspective

My primary role is working on Bristol University's portal project which is based on uPortal. I am also working on the Grouper project (writing the web UI). One of the reasons Bristol got involved with the Grouper project was to build a manageable and scaleable groups repository which, amongst other things, would work
with uPortal.

Below I try to point out some key aspects of the uPortal Groups Service and Grouper in order to facilitate discussions on future collaboration.

uPortal's primary requirements for a Groups service

  • Group channels as categories to facilitate finding channels.
  • Group people and groups of people to support permissions (including aggregated layouts*).
  • Must have bootstrap groups service.
  • Must integrate with existing groups repositories.

* Aggregated layouts is a mechanism by which a user's portal view is dynamically constructed at login by combining the user's own layout with that of any layout fragments defined for groups the user is a member of (push), or has subscribed to (pull).

Implied requirements

  • Ideally want a composite groups service which appears as a single service but which can aggregate results from multiple groups services (representing different groups repositories)
  • Need to browse/search groups, determine all memberships for a given 'member', and manage memberships
  • Need to find groups to assign permissions to them
  • Want to manage permissions over groups themselves
  • Want to map 'unknown' users into groups at runtime by applying attribute matching rules

Differences between uPortal's Groups Service and Grouper

  • Grouper is designed to be an authoritative central groups service. It may periodically import groups data from other systems, but it does not try to aggregate external groups data in real time.
  • uPortal uses the IEntity / IGroupMember interfaces to allow (amongst other things) 'objects' of different types to be grouped. Grouper can group objects which have an implementation of the Subject API http://www.stanford.edu/dept/itss/infrastructure/signet/project/doc/subject-api-spec-0.1-draft-02.html.
  • Grouper currently has no dynamic groups per se or any mechanism to evaluate user attributes to associate a 'new' subject with existing groups.
  • Grouper has an internal privilege model which is defined as a pluggable interface. Some of the permissions uPortal can assign to groups have equivalents whereas others would be specific to uPortal i.e.
    • Delete this group -> ADMIN
    • Rename this group -> ADMIN
    • View this group -> VIEW (to see group exists), READ (to see membership)
    • Manage this group's members -> UPDATE
    • Assign Permissions for this group -> ADMIN (internal), external not defined
    • Select this group -> no equivalent
    • Create a group in this context -> CREATE privilege on a stem (see below).
  • Grouper also has the concept of OPTIN and OPTOUT where some one can add / remove themselves from a membership list.
  • Every Group in Grouper has a set of base attributes which can only be modified by some one with ADMIN privilege, however, Grouper will support custom group types and arbitrary attributes which may be configured to allow some one with a lesser privilege to view and/or modify them.
  • Grouper supports 'subgroups' but this is not how a grou phierarchy is built (see below)

Grouper and hierarchies

The most significant difference between uPortal's Groups Service and Grouper is the hierarchy. In uPortal the hierarchy is comprised solely of groups, and a group inherits any permissions assigned to a parent group in the hierarchy (I've never been clear what happens when there are conflicts i.e. a permission which has been granted and denied). Therefore, the way in which you browse groups is closely linked with how the permissions engine determines inheritance.

Grouper has the concept of 'stems' or namespaces in which groups exist, and these can be browsed. Stems are not groups i.e. do not have members and in Grouper the spatial arrangement of groups within the stem hierarchy has no significance - internal permissions are not inherited through the stem hierarchy.

Groups can contain other groups as members and one group may be a member of any number of groups located anywhere in the stem hierarchy. If Group B is a member of Group A then all Group B members are 'effective' members of Group A. Grouper maintains a flattened list of 'effective' memberships and so can readily determine the list of groups a subject is a member of without recursively traversing a hierarchy.

Different users get different views of the Grouper group hierarchy, achieved by a user obtaining an individual GrouperSession. uPortal's GroupService does not know who is asking for groups information and so there is no way, currently, of personalising the underlying group repository.