Authorization in uPortal 1.x
uPortal 1.x authorization involved managing a flat set of roles, and associating a user with 0 more more of them. A function was protected by requiring the user to have a particular role in order to perform it, very much like 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 model a university
- a facility to distribute management of authorization
- use of data from outside sources (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 was meant to allow for many different organizational models. The Permissions design was fairly straightforward.
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.