Roles and permissions

Apologies for the heavy text – I still need to get good sketching software set up...

Groups / Roles / Permissions

Normal English usage has no problem distinguishing the meanings of "group", "role", and "permission", but most multi-user systems and web applications get by with just one or two of those terms.

That's because most collaborative software models a single sort of interaction in a single social context. Given that restriction, you can translate any of those terms into any of the others.

In fact, you might even be able to get rid of all of them. Let's say my application provides a simple chat room in which everyone sees the same UX and does the same things. Then we can do without any distinction beyond "person who's known to the application".

Now let's say we want to allow for a special type of person: people who can open and close the chat room and ban rowdy members. Then I might say "Fritz is in the Moderators group" or "Fritz is a Moderator here" or "Fritz has permission to Moderate," and mean the same thing no matter how I express it.

But why is that when I entered the first meeting of my Physics 101 course, straws weren't drawn to decide who had the talk-loudly-during-class ability and who had the receive-a-final-grade-and-later-a-diploma ability? Conversely, how was I allowed (and expected) to talk-loudly-during-class in Philosophy 210?

Let's start adding to our simple chat application and see what happens to the vocabulary...

• Say we want to support a moderated Q-and-A format. Then a moderator could give a audience member permission to speak without making them anything other than an audience member. Permission has a meaning that's not persistently tied to a type of membership.
• Say we want to host multiple chat rooms that have different memberships and different moderators. Then Fritz plays a moderator role in one room but not in another, and our software needs to be able to react properly to that role no matter how many new chat rooms get added. Role has a meaning that cuts across groups.
• Say we want to add wiki-style functionality so that chat room transcripts get made into editable web pages. Then we need to decide how chat room abilities ("Speak", "Observe", "Moderate") relate to wiki abilities ("Edit", "Read"). We might decide that a room's "Collaborators" can speak when chatting and edit when wiki-ing, whereas a room's "Viewers" observe when chatting and read when wiki-ing. Or we might decide something else. The important point is that we need to make a decision.
• Say we want each department in our school to automatically have its own chat room. Then we need to decide how to translate Fritz's job title in the department into Fritz's online chat room rights and responsibilities.

What I see here is a vocabulary of indefinitely many groups (sets of people), one or more sets of context-specific roles (which tell me about default expectations for a person in that context), and sets of functionality-specific actions, permissions , privileges, or duties.

As I say, most online applications haven't had to deal explicitly with these distinctions. But the combination of being pluggable and being integrated with external sources forces them into LMS/CLE suites like Sakai.

The hard problem of permissions

Not directly part of the Groups-and-Roles project, but a related aspect of Sakai 3

This may be hubris, but I (Ray) feel pretty comfortable batting around the concepts of group, role, and resource. Not that I have a great out-of-the-box solution at hand, but the issues seem theoretically manageable after all these years.

What really scares me is the application-specific part of the pluggable framework, or what Sakai 2 called tool-specific permissions.

Within a single social context, a person tends to play a single role. (Which is why we sometimes feel the need to explicitly announce changes of role: "Putting on my copyeditor hat...") However, that single role tends to be associated with a variety of rights, duties, responsibilities, expectations, privileges, or permissions. Disagreements over the specifics sometimes lead to lawsuits or courtmartials, but for the most part people take fuzziness for granted. However, software doesn't handle fuzziness so well.

From previous experience, we know that untrammeled exposure of tweakable tool-specific permissions will sabotage the ability of normal users to actually do that tweaking. We also know that it encourages bugs, since each tweakable privilege is another variable that should be taken into account by UX walkthroughs and QA testing. Six independently-settable permissions means 64 possible combinations to check.

It would make everyone's life a lot easier if we could mandate a limit of three Sakai-internal roles that all plug-in applications and services use for authorization decisions, with no tool-specific terminology at all. When I survey collaborative frameworks, it's clear that you can go a long way with just three types of person, so long as the types are defined vaguely enough: "Administrator", "Collaborator", and "Participant," say, or (as verbs) "Maintain", "Contribute", and "Access".

Unfortunately I'm not confident Sakai 3 can stick to such a mandate. Sometimes there really do seem to be more than three choices.

• "Moderator" frequently seems to tip applications past the magic number.
• In an online discussion board, can a "Participant" create a topic, or only add to a topic thread, or only read? If the answer is "It depends," then we're in trouble.
• When I'm in the Sakai 2 Gradebook application, I might be someone who "plans and schedule assignments," someone who "decides course grades," someone who "grades any student on any assignment," someone who "grades students who are in my assigned sections," or someone who "receives grades." Here, we deal with the decision by mapping four Gradebook "permissions" against four standard course site roles. The effect is more like mapping framework-role to application-role than like mapping framework-role to application-permissions, which simplifies the QA burden. But it's also a bit of a cheat: if we wanted to support "syllabus authors" who don't give grades, would we need to add another course site role and another Gradebook permission?
• Speaking of which, OpenSyllabus scenarios differentiate course author from section leader, although this may be an example in which breaking content-chunks out of the site-solo is enough to do the job. (E.g., what makes someone a "course offer" is that they have the Collaborator role in the context of canonical-course-oriented nodes but not in the context of class-section-specific nodes.)
• Some portfolio scenarios distinguish mentors from other reviewers, collaborators, and viewers.

Writing these out, I notice that the day-to-day scenarios speak in the language of roles, whereas the language of permissions gets used more in exceptional scenarios. We might be able to meet the highest-volume requirements by making a roles list part of the workspace template (as it more-or-less is in Sakai 2) and leveraging the same role-translation mechanism used to integrate with external groups.

Anyway, for now, I'm just watching the problem space.

Appendix: Roles and permissions in Nakamura

As of 2010-05-18

There are only two ways to handle authz in Jackrabbit (and thus in Sling and Nakamura):

1. Work around normal Jackrabbit access control by temporarily switching to an admin session. For example, a pseudo-privilege mechanism has cropped up in a couple of places already.
2. Create Jackrabbit ACLs that associate Jackrabbit users and groups with standard JCR permissions. If requirements don't happen to be met by normal ACL inheritance, then components may do extra work behind the scenes to set up standard ACLs where they can be used. For example, site creation cannot be supported by Jackrabbit ACLs alone and Jackrabbit access control does not understand site roles. But by jumping through some hoops, all operations except site creation eventually result in standard Jackrabbit authorization checks.