Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

A Need Exposed

The introduction of Aggregated Layout Management 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

One aspect of permission grants It then creates a grant as a servant

  • No labels