Permissions Enhancements
This page is related to the Aggregated Layout Management Convergence 2.x effort that will be added to 3.x.
Meetings were held Monday, December 6th and Tuesday, December 7th 2004 in New Orleans at the JA-SIG Winter Conference in New Orleans to discuss the future of the permissions and groups infrastructures in uPortal. Attendees to these meetings varied. The core attendees were Dan Ellentuck, Alex Vigdor, and Mark Boyd. This page will be used to share thoughts around permissions and possible enhancements that can be made. All participants are welcome.
Introduction
The screen shots attached to this page portray a potential servant channel that can be used to grant permissions to use a new channel being published. This does not imply a specific implementation of such features but rather serves to communicate possible feature enhancements. Such functionality may be provided through extending the existing Groups Manager channel. As noted in the Miscellaneous permission granting is facilitated by this configuration resulting in a new group definition and the permission is then granted to that new group. These new groups assert membership by distinguishing bewteen users that meet the requirements of the configured statement.
However, the goal of constructing the possible solution outlined below is not solely to provide complex combinational logic and the addition of user attributes for granting permission. It also serves to solidify a more clear approach for applications like Channel Manager and Fragment Manager to delegate inline to a servant channel the granting of a permission for the artifact being create. The artifact used in this example is a new channel. See Existing Problems Outlined for more details. The discussion and images below portray the following:
1. The Current Groups Manager Servant
2. New Combinational Group Aggregator Servant Channel
3. Adding a New Phrase
4. Selecting a User Attribute to Differentiate Membership
5. Selecting an Attribute Specific Operator for Differentiating Membership
6. The Resulting Membership Differentiation Statement
7. Miscellanous Notes
1) Current Groups Manager Servant Channel
Below is a view of the current Channel Publishing step for selecting groups that can use the channel being published. Although not clearly evident the groups selection area within the Channel Manager channel is provided by a servant channel, namely Groups Manager. Selecting groups in this existing approach results in an implicit "OR" construct for granting the permission. Namely, if the user is a member of "group A OR group B OR group C" they can access the channel.
2) New Combinational Group Aggregator Servant Channel
Proposed changes are reflected in the view below. In this approach a new servant channel explicitly handles aggregation of the joining logic around policy statements provided by other servant channels notably the existing Groups Manager channel and a new User Attributes channel. The view shows that some combination criteria for the grant has already been selected. Now lets select the top most "add" link to add another statement to the top level "AND" construct.
3) Adding a New Phrase
In the image below the top most "add" link was selected to add another statement to the outermost "AND" construct. Those links now disappear and phrase selection area appears. When adding another statement it can be a nested logical block or it can be a policy statement from one of the two types mentioned above or others that have been registered with the system in the future. We are all familiar with the Groups Manager interface so for this discussion I'll select the link for the "User Attibutes" statement provider. Note that the interface also gives some indication where the statement being provided will fit into the larger existing logical statement.
4) Selecting a User Attribute to Differentiate Membership
In the image below the phrase selection area has now been replaced by a UI specific to selecting user attributes and values for distinguishing between users that will become members of this group. The UI specific to user attributes is provided by delegation to a plugged-in servant specific for that configuration. This servant allows for selecting specific user attributes to be evaluated as part of the policy for granting permission to view the channel being published. Lets select the link for the "Age" attribute.
5) Selecting an Attribute Specific Operator for Differentiating Membership
After selecting the "Age" attribute the servant is shown below presenting operators that are appropriate for evaluating the selected attribute, "Age" in this case. Lets select the link for the "Greater than" operator.
5) Selecting an Attribute Value for Differentiating Membership
Once the "Greater than" operator is selected then the user attributes servant is shown below presenting a mechanism for selecting a value for the comparison. For "Age" a drop down with all ages in an appropriate range is depicted.
6) The Resulting Membership Differentiation Statement
And finally, once a value is selected then the user attributes statement is complete and the statement is contributed as show below to the overall logic statement that differentiates between users to grant them membership in this group and hence the permission for using this channel.
7) Miscellanous Notes
The inclusion of user attributes for granting could quite readily use PAGS which defines a fixed set of groups that are evaulated at log-in time for a user. See:
http://www.ja-sig.org/wiki/display/GAP/uPortal+PAGS+documentation
However, PAGS may have to change to be more runtime-configured instead of XML base configured. Potentially, any statement like "Age > 30" added to a grant would cause a new PAGS group definition that would be checked and added into the set of groups for users at log-in. If such a comparison were already made in some other grant then a new definition would not be needed since such group membership is already being checked.
Some challenges with this approach are that PAGS doesn't have the meta data necessary to define which operators, test classes in PAGS, are appropriate for which attributes. The set of attributes that are available for use must also be available. And finally, there must be some way to convey the values that are appropriate for a given attribute. Such configuration would most likely be site specific. For example, Andrew indicated that the highest GPA at their institution was 3.5 not 4.0.
Dan pointed out that the complex logical expression represents a new group. Alex and Dan indicated that if these logical expressions were mapped into new group definitions available from a new composite group store then the permissions infrastructure would remain as is today. The grant for accessing the channel being published would then use the group id for this new group.
Dan, Alex, Andrew, etc., feel free to add more comments as needed to this page.