Existing Problems Outlined

This page is related to the Aggregated Layout Management Convergence 2.x effort that will be added to 3.x._

A Need Exposed

The introduction of the JA-SIG Aggregated Layout Management feature makes reuse of the GroupsManager channel to define who receives pushed fragments or who can subscribe to pulled fragments. Although it appears to use the same assignment paradygm in the screen it varies significantly from the grant model used by Channel Manager. Namely, the new ALM functionality did not make use of the existing permissions infrastructure.

This exposed a problem that exists today with uPortal Permissions. There is not a lot of clear documentation on how applications, channels, should offer up permissions to be used by the portal. Worse, there is little understanding of how an application can make use of a granting mechanism inline for some artifact being created like a channel, a fragment, or an election.

Such functionality should be documented more clearly and enhanced to makes its use simple for applications to delegate to. Such is the drive behind this permissions effort.

Channel Manager Approach

Channel Manager is used to publish channels. For each channel published it holds a new permission consisting of owner, activity, and target. During channel publishing Channel Manager delegates to the Groups Manager servant channel to allow a channel publisher to select user groups that should be able to subscribe to and render a channel. It then gets back a list of group entities and creates a grant for the permission for each returned group using an updating permission manager.

This means that as an application it must know about more than just the permissions that it is offering to the system to be granted to users. It must know about the granting mechanisms itself and how to generate them using the perimssions manager.

A Better Approach

A clearer approach would be to have Channel Manager or any application that creates artifacts to be protected by permissions to only have to know about the permissions that they are offering for each new artifact. As part of the creation or editing of such artifacts it should be able to delegate to a servant to grant permission to use that artifact.

Using Channel Manager as an example it should pass to the servant channel a representation of the permission including the owner, activity, and target and the servant would allow for the visual configuration of which groups get the channel and then create the grants for that permission. Later on when a user is rendering a channel the same permission is created that protects that channel and the authorization principal is asked if this user was granted that permission.

By providing such a servant and clarifying how it should be used by applications such a servant should readily be usable by other applications including aggregated layout management.

Complex Logic and User Attributes

One aspect of permission grants is that they are inherently a simple boolean construct. If the user is a member of "group A OR group B OR group C" then they get the permission and hence can use the channel. More complex combination logic should be available for determining grants.

Additionally, only Group Membership has traditionally be available for granting access to channels. Not until recently could user attributes also be used. They are made available through static peron attribute groups defined in an XML file and evaluated at log-in time. Such is a good step toward more flexible assignment of permissions. However, there is currently no way to incorporate dynamic creation of such user attribute groups in the permission granting step.

Restricted Grants

Currently, if a person is granted Channel Publishing permission there is no way to attach to that grant criteria specifying to whom they can publish channels. Such a capability is accomplished by configuring permissions for the GroupsManager channel restricting what groups a particular user can view, select, update, edit, delete, etc.

This means that when fragment publishing is enhanced to use permissions correctly and fragment publishing is granted to a user along with channel publishing there is no way to distinguish different sets of user to whom they can publish channels versus those to whom they can publish fragments.

A suggestion for enhancment of grant restrictions has been outlined here: Grant Restriction Enhancements