Making a distinction between patrons and system users, particularly with a perspective on permissions

@filipjakobsen: Thanks for the demo you gave us in Copenhagen. I am just starting to think about the permissions stuff, in view of what we have already designed for the back end. At the first look, our designs seem to differ in two major points:

• You seem to consider patrons and users as the same thing. So far we have assumed that ‘user’ refers to library staff of some sort, and ‘patron’ is someone who can make use of the library, but not manage anything.
• Your permission model includes the location of the user, for example the music library’s circulation desk. Yet you have the option that the user may just change to a different location, from the top menu rightmost item. I assume the user would need a permission to set the location for the ‘fine-processing counter’, and the operation ‘forgive-all-fines’ would require the location to be the ‘fine-processing counter’, and it would also require a specific permission for that operation.

What are your thoughts on these issues, especially the locations? The user/patron issue probably deserves a discussion of its own.

@Heikki: Just a thought regarding user/patron. I’m not sure why we would want to split these two user groups. I can see a user being both a user of the back office system, but also a patron of a library or libraries. Could a user not just have a number of authorizations assigned to their profile (cataloger, circ, circ manager, staff patron of library x, graduate patron of library y)?

@Christopher_Spalding: The main reason to separate those would be security. Patrons come and go, get bulk-imported from external systems and mass-deleted. Occasionally they are not authenticated at all (member of the general public browsing the catalog). Should there be some technical glitch, we don’t want accidentally promote regular patrons to have any admin access. Also, the number of patrons will exceed the staff by orders of magnitude, so there may be things that can be optimized differently. It is my understanding that many other ILSes maintain that separation too. But I don’t have any strong opinions, at this point I am just trying to understand the implications and reasons for going one way or the other.

I think that going forward, and already, libraries want to provide increasing privileges for patrons for self service functions. And to provide services that span organizational boundaries will require a more nuanced understanding of the user/patron divide. When we talk about “extended” services, we can easily imagine services that begin to blur the lines between these traditional roles.

From my perspective, all librarians are also patrons. So it would be awkward to partition users into two specific and distinct classes.

Since we’re on the topic of permissions… I noted in the recent recording (though not found in the online demo) that the proposed permissions model appears to lack the concept of Roles. This is an important abstraction which avoids having to explicitly and directly assign permissions to users.

The pitfall with the majority of permission/role management implementations is the lack of clarity between the available permissions/roles and a particular desired functionality. From a security perspective it is always best to provide the narrowest of needed permissions. But when that is not obvious, the result is that users mostly receive elevated permissions. The interesting challenge is how to design the permissions management UX in order to ensure clarity on how to grant specific functionalities.

@Christopher_Spalding @filipjakobsen : Hi - We need very different sets of information about patrons and users and we do very different things with their record histories.

-The first issue can probably/hopefully be overcome by display preferences. If it can’t then a combined record is going to be a big problem.

• When I’m assisting someone as a patron, I really don’t need/want to see their user permissions. I don’t care if they they have them or not, at that moment they are a patron, not a colleague. Data about their user status and permissions is just a distraction taking up space for information that I need to serve them as a patron. This could also be a point of confusion for inexperienced staff (student workers) for whom a uniform layout and simplified information is key.

• When I’m looking at these people as users, I don’t care what they are as a patron, if they’ve run up fines or have a book on hold. Again, it is a distraction taking up visual space for information that I need to deal with them as a user. Looked at another way - It is inappropriate/impolite for me to look up which books my colleagues have checked out unless I’m dealing with them as a patron. But that information is usually key to my service to them in that capacity.

-The second issue (record history) may be a very different story.

• At my institution, we batch purge expired patrons from our system every year. There are several reasons for this, but it’s mostly a combination of patron privacy, storage space and processing speeds. We retain loan history, to the point that we know which items were checked out when, but they become dissociated from an individual.

• We don’t delete staff records, ever. We may remove their permissions, but we generally leave them in they system. This allows us to know specifically who did what to a bibliographic record or conducted a particular transaction long after a staff person has gone.

Oddly, this is the exact opposite of the policy at my last institution. Patrons were never deleted, but staff were supposed to be cleared out shortly after they left. These differences may be the result of the way they two different ILS’s retain data or a different thought process, but in either case, the question becomes . . . if the records are combined how can you retain 1 but not the other.

Sorry about the length of this

@michael.winkler - Now I’m curious, what kind of extended services are you thinking about??

Well, without baking the cake fully…patron-driven services that let patrons engage in record enhancement or social interaction; services that libraries offer to their institutions that include collection building and sharing for research or pedagogical teams; repository ingest, distribution, and integration services that let authors better manage their output and better adhere to compliance requirements; services across institutional boundaries to improve patron self-service with entitlements they discover at libraries with which their home library has some relationship. Really looking at the descriptive and workflow capabilities in FOLIO as services that the library can offer to their campus that could benefit from a more malleable and fluid set of roles.

From my perspective, FOLIO is not simply a service to the library to improve its internal business, but a platform for services and innovations that our patrons can harness to inform or support their research and learning needs.

Also not saying one or the other, Django is an example of unified staff and users, and where users typically vastly outnumber staff.

Good to split this into its own discussion. I should have started it this way.

I still have no opinion which way we should handle this, there has been good arguments for both ways. I came to think of one more: Modularity. I can imagine someone wanting to write a completely new patron module, perhaps one that leans on some external student-management system and has no patron database in folio at all - a bit like we can possibly have a system that uses an external catalog. This would be more difficult if the same system had to manage fine grained permissions for staff.

I can see the appeal of treating all users alike, but we can never reach that one hundred percent. There will always be superusers outside the hierarchy, if nothing else, at least the system administrators who manage the cluster that serves multiple tenants (with their own staff and patrons).

I was worried about how those location-specific permissions will play with Okapi’s auth model, and the auth module we have already started. Turns out that it is a fairly trivial change. I have written a brief outline in https://issues.folio.org/browse/FOLIO-305#comment-11919

This point is valid, for sure (and is linked to your comment above regarding patrons coming and going). So, for simplicity, it makes sense to separate.

However, the most prized patron interactions are with a relatively stable population on campus - faculty - who do not come and go, and for whom, libraries may want to build services that let them build, manage, and distribute collections, etc. Often, privileged users are managed within some central authN infrastructure (like Windows AD) alongside users.

The decision to split staff from patrons is a decision that limits some of the innovation that can occur in FOLIO. That may not be compelling enough based on security, ergonomics of management, or simplicity - but we should be clear about the decision.

One reason NOT to distinguish between patrons and users (operators?) may be authentication. Presumably, patrons are authenticating against an IDM that is canonical and secure. Operators, on the other hand, authenticate against the ILS where passwords are stored locally. Also, Operator accounts are typically shared by multiple agents - for example, student desk workers may share a login.

Some patrons may be given ROLES as Operators but their unique and secure login allows for a meaningful audit trail.

There may be reasons to allow a few locally created (and authenticated) user accounts - for student desk workers and student supervisors - but for the most part it seems that external IDM with a variety of roles and permissions is the way to go …

A couple of thoughts:

• if operators and patrons are authenticating through different interfaces, combining their records shouldn’t matter one way or the other. They could both use whatever secure system the institution chooses and see / access what they need.

• if the reasons to split staff and patrons are “ergonomics of management and simplicity” then this isn’t so much a matter of splitting authentication, as it is splitting search & display
  functionality.

• what we can NOT do is restrict either set of authentications so that they require a canonical source for authentication (@michael.winkler - sound familiar) .

• Most libraries allow outsiders (Friends of the library, local or state residents, extra-institutional agreements, etc.) that require us to create patrons who will simply not be able to authenticate through our institutional systems.

• From the user side, I’ve never seen a system that was flexible enough that faux users weren’t required in order to make the workflows function (yes, FOLIO may be the exception, but I wouldn’t take that bet).

• In either of these cases will there be no way to authenticate against anything but the system itself.

To build on this… It is our desire to support more direct patron engagement with foreign systems. That is, libraries are more and more dependent on consortial and partner collections to fulfill needs by patrons. Our authorization schemes need to support these relationships. Sadly, I think that @andrealoigman point is that we need to cascade, potentially, through many sources of authN/authZ, and not a single one. However, in practice, what library systems tend to do is aggregate those privileges into a single canonical source, the LMS patron database. My advocacy is that we take a view that network citizens have relationships to organizations, and that we build in to FOLIO the abilities to leverage those relationships natively. That we only aggregate when we have no other options.