2023-08-07 - Extending Folio's Authorization Model

Owned by Craig McNally

Last updated: Aug 09, 2023 by Florian Gleixner

Date

07 Aug 2023

Attendees

Discussion items

Time	Item	Who	Notes
1 min	Scribe	All	Craig McNally will take notes
< 10 min	Questions from previous session?	All	Nothing was added to the previous session's notes. Are there any questions before we proceed?
*	Platform & Application Formalization	Vince	Background: A presentation of this information has been given at a summit meeting in June 2023 at University of Chicago. See https://docs.google.com/document/d/1W1Pknn84cNd8esuv2BCzYXZunnZ66jNb9gQOhvSiQ78/edit?usp=sharing The purpose of this discussion is to share with a wider audience, specifically the Technical Council. Link to slide deck: https://docs.google.com/presentation/d/1X1hMzYbT3DTq7SDX-ICl61RxshLpcbV6mhACpk5fuoc/edit?usp=sharing Notes: Introduction was given This is a slight departure from the previous two sessions which focused on application and platform formalization Touched on the principle of least privilege Managing and auditing permissions is difficult - you get a flat list of (usually visible) permissions/permissionSets. Folio has patron groups, but doesn't have staff groups → having this would be helpful for enhanced consortia support It was acknowledged that patron groups are not used for authorization. patron / staff groups are more about organizing/grouping users Overview Terms were introduced: Capability Role Policy Maccabee Levine: It seems to me that this already exists, but with different naming VBar clarified that while that's true in some cases, policies are NOT currently possible, and one part of this is bringing additional consistency to the system and simplifying things Deeper dive into capabilities Marc Johnson: A lot of this has already been modeled by SIGs, etc. There may not be much of an appetite to "redo" that work VBar: This is at a different level, we'll get to this a bit later in the presentation. Marc Johnson: Related to procedural capabilities, what does the "execute" action actually relate to? VBar: These capabilities relate to the granular (BE) permissions/APIs Marc Johnson: Like Maccabee, I think we already have this Marc Johnson: A capability on it's own doesn't provide everything a user needs to actually do what they need to. That's where roles come in. Marc Johnson: If capabilities are fundamentally a backend thing, why would we create a UI experience for granting those in the UI? VBar: This is an attempt to simplify the management and auditability of privileges granted. VBar: Roles provide a way to roll up the capabilities as needed into a single thing which can be assigned to a user. VBar: There is a notion that we need to introduce something along the lines of a capabilitySet, but details have not been sorted out yet. The hope is that some of this will be ready to discuss at WOLFcon. Deeper dive into roles At this point we began running out of time, and deferred questions until the end. Brief Q&A: Jenn Colt acknowledged that improvements are needed to how permissions are managed, why can't we just make those improvements on what we have, instead of undertaking a larger "redo"? Maccabee Levine reminded us that there are functional and other considerations here that we shouldn't just focus on technical aspects of this. The plan for addressing questions which we didn't have time for is to capture them below and VBar will try to answer them at the next TC meeting ( 09 Aug 2023 )
-	Questions	All	Place to ask questions not answered during the presentation. To be answered later (e.g. at the next TC meeting). Florian Gleixner Is it intended to switch to ABAC? https://en.wikipedia.org/wiki/Attribute-based_access_control Probably using XACML? Or is rather a policy extended RBAC planned?
	Zoom Chat	-	Marc Johnson to Everyone 11:10 AM How are patron groups used for authorisation? It is my understanding that isn’t what they are used for Maccabee Levine to Everyone 11:13 AM "Roles" to me sounds like the existing "Permission Sets". I assume the next slides will explain the diff Marc Johnson to Everyone 11:21 AM IIRC one of the reasons that FOLIO does not have canned roles out of the box is that each organisation models their roles differently And thus canned roles would only add noise Marc Johnson to Everyone 11:32 AM I don’t think I understand, because granting back end capabilities is NOT the same as granting capabilities in the front end 😕 Jenn Colt to Everyone 11:35 AM Capabilities are equivalent to “hidden permissions”? Maccabee Levine 11:36 AM And we are now un-hiding them? This has major functional implications. Big increase in complexity. Jenn Colt 11:37 AM I see the appeal of making them clearer when you need to see them. I’m not really getting the language/modeling change. Maccabee Levine 11:38 AM "When you need to see them" I think is the functional question. As Marc just said the granularity of these backend permissions (currently hidden) is much greater than FE. Jenn Colt 11:39 AM Right. When we have set up integrations we have messed with them. Also when dev forget to put them in their UI sets… Marc Johnson 11:40 AM If roles are made in the UI, these capabilities would need to be un-hidden Marc Johnson to Everyone 11:47 AM What is an example of a role? My classical understanding of a role is something like “circulation desk staff”. However the impression I’m getting here is that a role would be more like “can edit instances” or “can check out an item”. Jenn Colt to Everyone 11:48 AM Right I’m still not getting why this isn’t just a best practice recommendation + addition of perm set to the user facets UI. Why. Can’t policy be an add on to the existing system You to Everyone 11:48 AM I think a role generally would align with things like circulation librarian, acquisitions manager, etc. Marc Johnson 11:50 AM That doesn’t fit with how I interpreted Vince’s explanation of them You to Everyone 11:50 AM Vince mentioned that he thinks there's still a need for visible and invisible capabilities You to Everyone 11:51 AM In my mind, it would be possible, if desired to see invisible capabilities in the UI, but they'd be hidden by default. Much like we have with permissions in the UI today. You to Everyone 11:50 AM Marc I think what you're missing is the capabilities are defined by backend modules. These are typically not visible in the UI. There will need to be something else (e.g. capabilitySet) which is a grouping of those which would generally be visible in the UI. Marc Johnson 11:52 AM Vince just demonstrated a UI for exposing capabilities to a user via the UI Which means that doesn’t fit with how I interpreted Vince’s model. And the proposed model doesn’t have capability sets. Which is what I interpreted Vince as describing as roles. It seems you have a very different model of this than what is described in this deck / presentation You 11:53 AM We've been discussing the topic, but details haven't been sorted out yet (hence the presentation not mentioning capabilitySets) Marc Johnson 11:54 AM Sure. That makes it confusing for folks like me when you and others are operating on a different understanding of the model than what is being presented Maccabee Levine to Everyone 11:54 AM Vince, do the backend and frontend modules still check for permissions before doing X operation, or do they ever check for capabilities? Marc Johnson 11:55 AM If this is an optional layer on top of what we already have, then the system would still have to depend upon permissions Maccabee Levine 11:55 AM I agree, just want to confirm with Vince -- I'm not missing another "next level" idea

Action Items