Mostly roles and privileges

5. Integrating applications and services

Application-determined privileges and roles

Multi-user applications and services often need to treat some users differently than others. A high-volume highly configurable discussion board tailors access to activities such as "attach files", "use a signature", "disable word censors", "upload an avatar", and "approve posts". A chat room gives "Moderators", "Speakers", and "Members" slightly different interfaces and capabilities.

Although integrated authentication is fairly common, most collaborative applications and services do not bother to expose their internal notions of roles and privileges to external management. However, plugging into a large collaborative framework sometimes forces such exposure. We can't ask instructors, researchers, and students (or even long-suffering administrators) to separately manage groups, roles, and privileges of dozens of applications and services across thousands of instances. To reduce the load, Sakai adds a level of indirection, bundling application-level mappings into larger and more familiar cross-application community roles. Instead of forcing administrators of five thousand course workspaces to assign hundreds of functions like "Course grader", "Section grader", "Grade receiver", "Quiz editor", and "Quiz taker", we let installation-wide roles like "Instructor", "Section leader", and "Student" decide them by default when possible.

Ideally, this decouples plug-in development from administration of local community roles. However, as with any public interface, careful design is needed. For example, if the application developer naively opens file-system-like CRUD access permissions to each object type in its internal data model, it becomes almost certain that integrators will accidentally create rights-combinations that wreck key assumptions of the UX or API design. Some other issues follow.

Adding a new plug-in to an existing installation

When a new application or service is added, existing users and workspaces need reasonable access to it. Among other things, this generally means adding the new plug-in's privileges to mappings from existing roles.

Updating a plug-in in an existing installation

Since roles and privileges are so central to application and service functionality, it frequently happens that a new feature or a fixed bug leads to a new plug-in privilege. An existing permission may even be given a new interpretation. (This is a good example of how not to maintain a public interface, but it has been known to happen.) Such software upgrades must include installation-wide changes of role-to-privilege mappings to prevent existing sites from behaving in unexpected ways.

6. Supporting local installations and institutions

Support existing institutional roles

Reflecting a wide variety of institutional organizations around the world, contextual roles in higher education differ widely. A "GSI" or "Head GSI" at UC Berkeley may have little in common with a "Tutor" or a "Coordinator" elsewhere. Most schools maintain (even if optionally) at least some basic split between "teacher" and "learner", but expectations (and therefore permission-mappings) differ even there. In some environments, for example, a lecturer might not be a grader, and a person who grades assignments might not have the right to view or change overall course grades.

Workspace types and other role-mapping hierarchies

Reflecting a wide variety of pedagogical approaches, community support levels, and research orientations, more than one set of roles or permission-mappings are needed within a single CLE installation.

The fact that someone grades a group of students in a lecture course does not dictate whether they have edit privileges in an independent research project's workspace. To meet this need, Sakai 2's realm-template approach lets installations define a set of workspace types, each with their own standard roles and mappings. The two types most commonly seen are "project sites" (with two default roles, "access" and "maintain") and "course sites" (with three default roles, "Instructor", "Student", and "TA"). (Unenforced expectations about these two types have resulted in a number of hard-to-catch Sakai 2 bugs over the years.)

The fact that someone is enrolled in a seminar doesn't always determine their function in a wiki or a discussion forum in that seminar's workspace. Default mappings are essential to reduce the cognitive cost of plug-ins, but those defaults frequently have to be overridden. (Which is another reason to treat exposed plug-in privileges as a public interface: they need to be comprehensible to non-developers if they're expected to be adjusted by non-developers.)

Even within a site type, expectations of associated roles may change from place to place within an institutional hierarchy. Medical, law, and business schools frequently support very different activity flows and responsibilities from undergraduate courses in the same institution. Virtually all the thirty-plus organizations at Cambridge University maintain slightly modified ideas of role functions.

In effect, we need a flexible hierarchy of role-to-privilege defaults which support easy deployment and maintenance but can be customized without unbearable pain.

New institutional/installation roles

After defining sets of roles and mappings, they're unlikely to stay static. Occasionally, institutional changes or new features lead us to define a new role with a new set of permissions: "Head TA", "Concurrent Student", or "Visiting Staff", for example. When users start showing up with the new role in existing contexts, its application-privilege mappings need to be in place.

Modified privilege mappings

A role's permissions might need to be changed due to a change in security policy (for example, "SIS is going to pull the plug unless we immediately block students from seeing other students' official roster photos"), or due to having misunderstood the meaning of a permission in the first place. When this real-life problem comes up, it needs to be solved in a hurry for all affected sites.

(This requirement might occasionally conflict with the desire for easily customized role-to-privilege mappings.)

7. Outside the ivory firewalls

This extensive list has stayed within the confines of a large university (perhaps with some cooperating partners via Shibboleth). However, the combination of financial pressures, user expectations, cloud computing services, and increased cooperation among social networking hosts moves the problem of federated authorization beyond the LMS/CLE border. Solutions to these new challenges should play a part in solving many of the old ones as well.

• Open access to selected LMS/CLE resources via OAuth.
• Directly reference social or professional contact lists from the LMS/CLE.
• Securely host all or part of an LMS/CLE on Google Apps.
• And so on...