Login | Register
My pages Projects Community openCollabNet
Project highlights: Architectural Overview

The Joist Framework


Joist ensures that only those users who are properly authorized can access any given application (i.e., web page). A user must have the proper permission to access the application, then must have the authority to access the requested data.


The underlying mechanisms evaluate access in a number of ways.

First, each application servlet has a base permission assigned via its properties file (as the value for permission=). This check is done right away when processing a request, and quickly weeds out users who have no business accessing the application.

Second, each action that an application servlet can process has an associated permission. The user must have that action-specific permission in order to proceed. These permissions are hard-coded in the application servlets themselves. They could be factored out into the servlet's properties file if we felt the need.


Since there are likely to be lots of permissions defined for a full suite of applications, joist provides a way to administer them. Users will be accessing applications in a variety of capacities, or Roles. For instance, some users will act as administrators, others as super-users, and others still as casual visitors.

Each Role represents a set of Permissions. The same Permission can be assigned to many Roles, and more that one Role can be granted to a User. So when a new user is added to the system, the administrator simply assigns a role to the user, rather than having to assign each permission individually. This is something akin to assigning groups for unix accounts.


Once the servlet has established that the user has the proper permissions to access the application and perform the action, it then determines if the user has the authority to be acting on the data that is the subject of the request. For instance, for a user account maintenance application, the user may have the permission to update information for users in his group (however that group is defined), but the application must ensure that he is updating only accounts he is authorized to update, i.e., are in his group.

The authorization check can be expensive. It usually involves hitting the database, perhaps several times, to resolve the issue. For this reason, the permission checking, which is fast and does not involve hitting the databse, is done first.


There is a notion of scoping underlying all this. In large part, a Role implies some degree of authority over a certain set of objects. The scope of authority is relative to the user (e.g., is the account in the user's group?). The rules for assessing the scope are specific to the definition of the role and the type of data (e.g., the Group Admin role implies some set of rules to establish what a group is and whether an account is in the group).

Since a user can have potentially many roles, the application must determine which scope is operative for a given request. The joist framework does not impose a one-size-fits-all mechanism for application servlets to establish scope of authorization, but instead prescribes an API; applications implement to that API in whatever way is optimal.