Discuss.FOLIO.org is no longer used. This is a static snapshot of the website as of February 14, 2023.

Permissions Models

2 Nov '16

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?

3 Nov '16

Thanks for distilling the Slack discussion into this form – that’s very helpful. The primary argument against RBAC seems to be that creating roles for individual users that don’t fit into existing roles is overkill, and it’s easier to assign the relevant permission(s) directly to the user(s). I would counter that creating a role just shouldn’t be that heavyweight of an operation. Need a new role? Creating it and assigning the necessary permisions, or copying an existing role and adding/subtracting permissions, shouldn’t take more than a minute or two. If it does, that’s an issue with the UI. Am I wrong?

Regarding a user having different accounts for different locations because they have different permissions at those locations: I feel like that’s an argument for having more flexible, granular permissions. For example, there’s the “lend from anywhere” permission, as well as separate “lend from location X”, “lend from location Y”, etc. permissions that different institutions can create (and assign to roles) themselves if they need them. It may sound like more work to create these location-specific-permissions, but it makes a lot more sense than having users with multiple accounts to me.

4 Nov '16

You’re welcome, @ccc2lu – happy to do so. @filipjakobsen might have an answer to your first question, although I’m not sure if they UI prototype is refined to that level yet.

I find the implications of your second paragraph fascinating. More generalized, what this seems to point to is permissions based on an attribute of the item. (In this specific example, the attribute is the items location.) Or, in the case of RBAC, the authorization engine would look at not only the role of the user but also attributes of the item being acted upon. I find this even more interesting in the context of a unified patron/staff user database as was discussed this summer. Might that set us up with the ability to have department assistants modify records in FOLIO for faculty in their department? Or allow department deans to read the alt metrics stats for everyone in their department?

Would that be generally useful?

4 Nov '16

I would think that the this location-based aspect of authorization would be incorporated into the circulation rules. That’s what would have information about an item as a transaction is happening. So, whatever the circulation rules engine ends up being (DROOLS?), it would need to be able to tie into the roles/permissions system to see if the circulation operator has the permission necessary to lend from the item’s location.

9 Nov '16

Hi @ccc2lu – we talked a bit about this at an all-Index-Data team meeting today. There is some specific activity happening to constrict circulation transactions based on where the transaction is taken place. (For example, circulation policies that are allowed because an operator is logged into a computer in the music library branch.) This wouldn’t constrict transactions based on the permissions of one staff member over another.

Let me try putting this another way: say Circulation-Staff-A and Circulation-Staff-B both have the permission to check out items to patrons. If Circulation-Staff-A logs into a computer that is associated with the music library branch, that person will be able to check out items from the music library. If Circulation-Staff-B is logged into a computer that is associated with the science library branch, that person will not be able to check out items from the music library. But if Circulation-Staff-A logs out of the music library computer and logs into the science library computer, then that staff member would no longer be able to check out music library items.

Is that sufficient for your use case? All Others: same question – is that sufficient or are there other requirements?

10 Nov '16

Does this approach scale beyond the single dimension that is location? Is it possible to extend it to support multiple arbitrary dimensions simultaneously? For example, adding a time constraint in addition to a location constraint: circulation policy only allows checkout by operators with checkout permissions, only from a specific station and only between specific hours on specific days of the week? Note that location could be a property of the item to be circulated, but time-of-day would not.

Are we supporting constraints or just locations?

10 Nov '16

Hey, Vince. In discussing this in Charleston, I was getting pushback from the developers on making the constraints based on arbitrary values. (Indeed, time-of-day constraints are an interesting additional idea to consider.) At the moment, the development team envisions doing location-based limitations to keep the initial version easier to implement, and that they would try not to do anything that would get in the way of a more complicated solution coming later.

9 Dec '16

6 posts were split to a new topic: On workstation- and/or location-based permissions

12 Nov '16

Following up briefly on Permission Sets model, this seems to be the model that Internet2’s Grouper uses. Grouper is used quite effectively on campus to manage authorization/entitlements for a wide variety of applications and services. The set model is largely used in a role-based way, because I am staff I have access to campus wireless, email, etc., because I am Library staff, I have further entitlements. The set model, as I understand it, also allows for exclusion, adding someone to a particular blacklist group can temporarily revoke certain entitlements, which are restored when the person is removed from the blacklist group.

In cases where our Identity Management group (or their delegates) believes it makes sense, entitlements may be assigned directly to individuals. Not used frequently, but available when needed.

The set model is a central feature in Grouper’s ability to manage authorization for a wide variety of applications. We manage entitlements to over 45 applications and services this way: wireless access, VPN access, VOIP, campus wiki, Grouper itself, 2FA, even Interlibrary Loan eligibility.

That’s all by way of saying that, given that we want FOLIO to flexibly support a wide range of environments, and given that the permission set model has worked so well in the Grouper context, it may well be a good choice for FOLIO. And there may be something to learn from Grouper in particular.

15 Nov '16

It might be worth looking into I2’s TIER (https://www.internet2.edu/vision-initiatives/initiatives/trust-identity-education-research/) that combines Shib, Grouper and COmanage. TIER exposes a set of APIs to provide consistency and flexibility. Use cases highlight library scenarios that are relevant (https://www.internet2.edu/media/medialibrary/2016/03/31/TIER_Campus_Use_Cases_-_Full_Set.pdf).

This may be a down-the-road kind of thing, but worth looking over. I’m unsure of the adoption rate.