Sakai Permissions In-Depth
Actions in Sakai are identified by a text label, like “content.read” for ability to read content or “site.add” for the permission to create a new worksite with the Worksite Setup tool. These identifiers are called functions or locks. Sakai associates a group of functions with a role, and a group of roles with a realm (realms are also known as authz groups). A realm is peered with a worksite to define the roles (and functions) available on that site. A worksite has a one-to-one relationship with a realm, unless the site also has groups defined, in which case there is a realm for each group.
For example, a course worksite might have three roles: instructor, TA, and student. A hypothetical set of available permissions is described in this table:
| instructor | TA | student | |
|---|---|---|---|
| read documents | yes | yes | yes |
| write documents | yes | yes | no |
| submit grade | yes | no | no |
These permissions are assigned to a site “XYZ” with a realm called ”/site/XYZ”.
Sakai also has special user realms that are used behind the scenes for any permission request. These special realms have two special roles, ”.anon” and ”.auth”. When the user is logged in, the permissions (functions) from the .auth role will be applied. When the user is anonymous (not logged in), the permissions from the .anon role will be applied. A logged in user will carry with him a personal user realm, a realm for his user type, and a realm for all users of any type.
Whenever a Sakai user attempts to visit a page or perform an action, deep in the code all the user realms are gathered together with the site realm for the entity under request. A check is performed: “Does the user have this lock in ANY of this collection of realms?” Remember that the user has at least one role in each of the realms. The way roles are used is not intuitive: if the user has role X in any of the collection of realms, then the permissions for the X role in all of the realms are applied.
An example is in order. Let's say a user is a student in some course site. The student role in that site does not have permission to upload new files. However, if the user has a user realm with “content.new” in the .auth role, then that permission is granted in the course site, or indeed any site.
Sakai has one more special realm that applies at all times: !site.helper This realm is useful to Sakai administrators who want to ensure that particular permissions are available to particular roles without regard to how any other realms are configured. For example, if you want to guarantee that users with the instructor role will have permission to create new announcements in their sites no matter how their particular site realms are configured, you would make sure !site.helper has an instructor role in it, and add “annc.new” to that role. Remember the rule: when permission is computed, if the user has the instructor role in any of the collection of realms, then the permissions for the instructor role in all of the realms are applied.
Sakai's permission rules allow for another scenario: the user realms and !site.helper do not normally have users added to them, but if an administrator does add users to a role in one of the special realms, those users have the permissions of that role wherever they go in Sakai. For example, if I create a maintain role in !site.helper and then add Bob as a member of that role within !site.helper, then Bob gets the maintain permissions in any project site he should care to visit. Whether this is a feature or a security problem is open to debate. What it boils down to is that !site.helper and the user realms must be handled with care.
Account Type
There is an optional field on every Sakai user record called “TYPE”. If this field has a value, Sakai will look for a user realm with an id of the form !user.template.<type> and that realm will be used for the permissions of its .auth role for every permissions lookup performed on behalf of that user.
Out of the box, Sakai defines a few user realms, but they're not used for much. A “guest” user cannot create a new worksite, while a “registered” user can.
Leave a Comment