Permissions History and Requirements
- Dan Ellentuck
Authorization in uPortal 1.x
In uPortal 1.x, authorization involved managing the association between users and a flat set of roles. A portal function was protected by requiring the user to have a particular role in order to perform it, analogous to checking isUserInRole().
Requirements for uPortal 2.x
The authorization requirements for uPortal 2.0 were:
- finer-grained permission controls
- a more flexible role or groups structure to more closely model a university
- a facility to distribute authorization management (i.e., provisioning)
- the ability to use data from outside the portal (e.g., LDAP) to make decisions inside the portal
These requirements gave rise to separate services for Groups and Permissions. The Groups design was fairly complex since it tried to accommodate a range of environments. The Permissions design was fairly simple, since it focused on protecting a few core portal functions.
Requirements for uPortal 2.5+ and uPortal 3
As authorization began to be exercised more with distributed and aggregated layout management ("DLM" and "ALM"), a requirement arose for further enhancements to the permission model.
In addition, the goal for uPortal 3 was to make non-core functions like groups and permissions pluggable, that is, independent of uPortal.