Although there isn’t a formal Authentication/Authorization SIG yet, there is a Slack channel on the topic. Over the past couple of days, there has been a discussion on the permissions model. In the interest of getting this to a wider audience, I’m going to summarize some of the discussion here. For those with Slack accounts, you can start reading the full discussion here in the Slack log. (You can sign up for a FOLIO Slack account at https://slack-invitation.folio.org/.)
Statement of concern
The concern originated with the UI wireframes which show a tight coupling between users and permissions - where users are directly assigned permissions. There appeared to be no intermediate abstraction layer: i.e. roles. I think it’s important to clearly identify from the start a more complete permissions model to be used with FOLIO, since these things are cumbersome to retrofit. Furthermore, since existing permission models are well established, we should simply select one to implement - rather than grow one organically. I recommend that FOLIO adopt _a_ Role-based Access Control (RBAC) permissions model: [https://en.wikipedia.org/wiki/Role-based_access_control][8]
This will provide for the Role abstraction layer and enforce a separation of concerns.
- Actual Permissions (mapped to Operations)
- The assignment of those permissions and the management thereof (i.e. hierarchies, inheritance, etc) which is provide by Roles.
I think this would be a very relevant topic to bring up in the new SIG named LSP Rights Management (User Management).
Models for handling permissions
The concept set forth in the prototype supports as many layers as you want. You can wrap 20 permissions in a set and assign it to 10 people, then change the set and everyone’s permissions are updated.
We looked into multiple ways of doing it, and looked into what other systems have done. We considered having roles and other ways of structuring it. The solution with permission sets and sets of sets allows for the same functionality as roles would, but with more flexibility for people who need to do more fine grained, multi-layered or a different kind of permission handling. My impression was that the ‘permission set’ model had arisen from a desire in the UX group to have a flexible mechanism by which to model staff privileges.
“Permission Sets” Model
Permissions can be bundled in sets. If I recall correctly, sets can be nested. The system will be shipped with a bunch of predefined permission sets that will fit the most common needs. People can then use those or make their own. But removing the multilayered permission sets would really compromise the flexibility of the system for different people and different kinds of institutions.
There’s nothing to say that “permission sets” are labeled as such on the UI, but are actually roles behind the scene. It’s an architectural consideration to how tidy we want to make the underlying system. Specifically, this is one of those areas where there is a reasonable expectation that the UI/UX may need to change in the future. If we design a backend system which only supports a simple model, then we will be in trouble later when we need to provide support for a more one.
“Role-based Access Control” Model
I think the current system would allow for roles to be emulated rather then implemented. But we would be doing so at the price; an awkward implementation which may eventually need to be refactored. The alternative is to recognize that we should adopt a tried-and-true permissions model and then choose whether or not to expose it in the UX.
In the permissions set model, permissions _can_ be directly assigned to users. The RBAC model does not allow that. Assignments are to roles only and roles are mapped to permission(s). This introduces and enforces an abstraction layer. It’s about the separation of concerns. Permissions are tied to Operations. Roles are essentially a grouping mechanism for Permissions, but RBAC is recognizing that permission groups are not the same thing as permissions - so let’s call them roles. That is not to say that roles must be things like {librarian, chief librarian, check out clerk, etc…} - i.e. job functions. That’s the wrong way to implement roles. Roles should be used to model activities - activities invoke operations which require permissions. (You can then always add a job function related role at the top of the hierarchy.)
RBAC adds an abstraction layer, that should by definition be more flexible. The abstraction layer is also the idea place provide permission mapping for external systems. Operations and their permissions will vary according to the particular external system (be it a printer, a barcode scanner, a KB or an external holdings system). You don’t want to be exposing the individual permissions of each system when it comes time to assign them to users. You will much prefer to have a consistent set of activities to present for user assignment, regardless of the specific external system.
Issues, Questions, Experiences
I think it boils down to a question of whether we support explicit or implicit roles. I think that the current system allows for roles to be implemented, but it doesn’t make it a hard requirement. Indeed, it would leave that management off to another layer.
I’m hearing that with the RBAC model, I have to create a role for every set of permissions, even if there is only one person in the role?
I’m not an expert at all, but my sense is that 90% of libraries are nothing like enterprises. They have relatively few staff that wear a ton of hats, and they want a fair amount of flexibility to manage things. Even large libraries may have somewhat creative and ad hoc assignment of roles/responsibilities. [A followup:] I can attest to this. As an Active Directory administrator, I tried to dogmatically impose order on the chaos that was the permissions assigned to users in our LMS. In the end I had to be pragmatic and realise that fact: “Libraries are not Enterprises”.
At my library, I have been told that rather than create a specific role for a staff person who works at two different circulation desks at different times, the staff person is given two different accounts for each desk where they work. This is to address both the issue of needing to create a role for just one person, and the problem that there are things staff are authorized to do while working at one circulation desk that they should not be able to do while working at another.
This is definitely a place where striking the balance between good practice and flexibility is going to be tricky. As an IT person, I can definitely see the attraction to RBAC and the level of discipline that it encourages. As someone who’s struggled to fit the actual practice of a library into an RBAC scheme, I can also see the attraction of being able to be less abstract about it. Sometimes, the reality is simply that the work of the library doesn’t fit into any rational scheme, and trying to impose something like RBAC really is cumbersome. On the other hand, sometimes I think people are just unwilling to think past their tactical need to get a job done and really should abstract things a bit more for better long-term management.
The location-specific permission issue seems to keep coming up. Maybe a more generalized model for mutually exclusive roles would be that staff would log into one of their roles, rather than the system trying to keep track of their locations.
Whether or not it is permissible to assign permissions directly to a person might conceivably be a local policy decision?
