Groups and Permissions

GaPs is "Groups and Permissions". It exists as a general framework embedded in uPortal 2 and, separately, as a standalone project that is used in uPortal 3. It is likely that uPortal 2 will evolve to drop its embedded GAPs code and instead use the externalized GaP. They are very similar.

http://www.ja-sig.org/wiki/display/GAP/Home

PAGS ("Person Attribute Group Store") is just one group store implementation that plugs into GaPS. Person Attribute Groups are clever just-in-time groups that are defined by logical expressions on user attributes. (A Group "Class of 2004" could be defined as all users such that their classYear user attribute is "2004"). This allows you to leverage user attribute stores such as LDAP to define groups for use in the portal.

Other currently implemented group stores include the uPortal database group store and a couple LDAP group stores.

In theory one could write a Sakai Group store that is backed by Sakai web services and exposes Sakai course affiliations as groups.

Group stores can be manageable via the portal (read/write) or not (read-only). They can be enumerable (e.g., a database backed group store) or not (in PAGS I can only ask the system what groups a given user is in; I can't ask it for all members of some particular PAGS group).

For instance, plausibly a Sakai group store would be externally managed (read-only) and enumerable.

Permissions are distinct from groups but use groups. Roles are not a separate data structure, but it is a typical practice to create a group for a role.

Permissions take the form of is allowed to on . E.g., Students are allowed to Subscribe to the Campus News Channel. Various modules can register permissions to be managed by the Permissions Manager. When you create an announcements topic in the Columbia Announcements Channel, this brings into existence permissions for who can create announcements in the topic, delete announcements, etc. Zero or more Groups (and/or individuals) can be granted each of these permissions.

There is a hierarchy and inheritance scheme for permissions; I'm not prepared to speak to it authoritatively off-hand. It's fair to say that it's less well-understood than it should be.

Dan Ellentuck is the authority and primary developer of uPortal / standalone GAPS. He has been working to take the "standalone" GAPS to releasable state. uP3 developers have been pitching in, particularly to use this in uP3 and develop uP3 UI around it.

"Standalone" needs to be in quotes because while GAPS becomes a standalone library with this refactoring, it does not provide its own UI. Both uPortal 2 and 3 provide UIs for administering portions of GAPs. (Other portions use file-driven configuration).

I hope these notes prove helpful. Dan Ellentuck is really the person to approach about this.