uPortal 3.3 Groups and Permissions Changes

Owned by Jen Bourey
Last updated: Apr 06, 2010Version comment
2 min read

IPermissible Interface

The uPortal IPermissible interface attempts to describe permission system partitions in which an "Owner" is responsible for maintaining a list of permission "Activities." These activities may be assigned to principals over a number of legal targets. The existing IPermissible interface represents an owner and defines the registered activity key/name pairs as well as the valid target key/name pairs.

The existing permissions implementation persists owner to the database in the UPC_PERM_MGR table, which simply registers a list of IPermissible implementations. Activities are generally hardcoded into the implementation's code an do not appear as objects in the database, though the activity key is used in the permissions assignment table.

This interface is generally implemented by IChannels - perhaps the groups manager or the user account editing channel. In the past, plug-in channels like CAnnouncements also made use of uPortal's permissions architecture to assign local permissions. In that case, the channel was able to register as an Owner in uPortal, defining its own lists of activities and permission targets. While it would be useful to preserve this sort of behavior in uPortal 3.3 and beyond, our content is increasingly represented by portlets living outside of the uPortal classpath. In the future, it might be preferable to provide a mechanism for allowing portlets to register and query the permissions system via REST services.

JPA Refactoring

As of uPortal 3.3 we'd like to refactor as much of the IPermissible interface as possible as JPA/Hibernate code. Both owners and activities should be able to live in the database, and adding an activity database table will allow us to enforce a relationship between this new table and the existing UP_PERMISSION permission assignment table.

New database objects:

  • IPermissionOwner (UP_PERMISSION_OWNER)
  • IPermissionActivity (UP_PERMISSION_ACTIVITY)

Target Providers

The targets cannot be simply moved to the database, since targets might be PAGS groups or other external entities. Instead, we're proposing that we add a new IPermissionTargetProvider interface which is capable of returning information about valid permission targets. This interface will be paired with a target provider registry, and each IPermissionActivity will have a String key for an appropriate target provider.

New interfaces:

  • IPermissionTargetProvider
  • IPermissionTargetProviderRegistry

We will initially provide two implementations of IPermissionTargetProvider that should satisfy most existing uPortal use cases. The first target provider will provide IEntity targets and can be configured to allow different target types. The second will provide simple strings (e.g. the "DETAILS" target in the uPortal error channel).

JPA Refactoring of Groups and Permission Stores

As part of the groups and permissions portlet refactoring, it would be nice to refactor the RDBM implementations of the groups and permissions stores to use JPA/Hibernate. This would allow us to implement referential integrity between parts of these systems and the refactoring described above.

Affected Java Implementations:

  • RDBMEntityStore.java
  • RDBMEntityGroupStore.java
  • RDBMPermissionImpl.java

Affected Tables:

  • UP_ENTITY_TYPE
  • UP_GROUP
  • UP_GROUP_MEMBERSHIP
  • UP_PERMISSION

We may also be able to drop locking and cache invalidation tables