[FOLIO-660] Discussion: Controlling Login to FOLIO Created: 09/Jun/17  Updated: 12/Nov/18  Resolved: 06/Sep/18

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Umbrella Priority: P3
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 1 hour, 30 minutes
Original estimate: Not Specified

Issue links:
Relates
relates to UIU-60 Don't Display Granular Login Permissi... Closed
relates to FOLIO-664 Get feedback on Bulk User Import prer... Closed
Sprint:

 Description   

Problem: Any FOLIO user can log into FOLIO and only a small fraction of those users (library staff) currently have anything they can/should be doing in FOLIO.

Possible solutions:

  • Not an Option: Using the existing Status flag on the user record to control this isn’t an option. The Status flag will be used for other things in FOLIO. For example, when a user graduates, they would be switched to inactive which should mean they could no longer log into FOLIO and they can no longer check out books. This is distinct from another flag we plan to implement on the user record called Patron block which would also disallow checking out books due to fees, fines and other FOLIO logic. Patron block will likely be auto triggered by certain data in FOLIO while Status will be driven by data in the Student Information System.
  • Option 1: Allow any user to log in but just ensure that they can’t do anything at all in FOLIO (not even change their own username and password) without additional permissions assigned. Taking this approach is potentially confusing to users who manage to accidentally log in, though. If we are going to do this, SIG would want us to have a configurable landing page that says something like “Oops – you landed in our system. Here are some links to where you might want to go from here” (with links to discovery etc). One advantage to this is that, if someone does eventually build a patron-facing app in FOLIO, nothing additional needs to be done to allow them to log in.
  • Option 2: Have a logical permission for “Can log in”. One downside to this approach is that you will have to remember to assign this permission set to every user that needs to log into FOLIO (or put into every permission set you create). That’s probably not a deal-breaker.
  • Option 3: Add a data element to the user record for “Can log in” which, if set to N, disallows login. If set to Y, allows login. So, it would work like Status, but be distinct. It would need to be manually set to Y for all people who need to log into FOLIO. If we take this approach, we’d need to make sure the regular user import doesn’t reset this flag all the time. We could handle this by saying that, as long as this field is left blank in the patron import, the system doesn’t alter the setting.
  • Other?


 Comments   
Comment by Heikki Levanto [ 09/Jun/17 ]

I just want to mention that we have two login concepts here that should not be confused. One is logging in to the (current) administrative Folio interface, and another is logging in to the folio system. Regular patrons should probably not be allowed to do the former, but must be able to do the latter, or they can not do any operations on the system, for example check out books.

  • Option 1 seems clumsy. Someone will have to build and maintain the Oops page, for each library. So we need to make a oops-page management system, etc.
  • Option 2 is possible. I don't like the permission name "can log in", because even regular patrons need to log in, at some point. "can administer Folio" sounds like a better name. The logic could be done in the UI, or by adding a parameter to the login request specifying what permission (or permissions) the user must have before login can be accepted.
  • Option 3 is possible. Again, "can log in" is a misleading name, perhaps "administrator" would be better. Or some kind of "security level" that could start with values "patron" and "staff", with possibility to add stuff like "admin" or "superuser", if we need such. In any case, the login service needs an extra parameter to specify what level is required for this application.

Although option 2 needs some care in maintaining some permission sets, I think I have a slight preference towards it, as it allows all kind of applications to require different permissions in a nice flexible way. But option 3 would work too.

Comment by Cate Boerema (Inactive) [ 09/Jun/17 ]

Regular patrons should probably not be allowed to do the former, but must be able to do the latter (logging into the FOLIO system), or they can not do any operations on the system, for example check out books.

I don't know that this is a correct assumption. My understanding is that discovery services that offer the ability to do renewals etc. and self-checkout machines do not require patrons to log into the ILS system. I will tag Chris Manly here to see if he can help clarify for us.

Comment by Mike Taylor [ 09/Jun/17 ]

Heikki's comment beat me to it. We mustn't fall into the trap of thinking the present Stripes-based UI is FOLIO. It's just one of many UIs that can be built on top of the FOLIO services; and indeed just one of many UIs that can be built on top of the Stripes toolkit. (That's why I dislike our overloading of the name "Stripes" to mean both the UI toolkit and this particular application that's built on top of it.)

I also agree with Heikki that option 1 is clumsy – it's like letting people into the atrium of a building but having all the inner doors locked to them.

Option 2 could work – but we don't yet have the ability to search users by permission, and adding that ability is hard ( MODUSERBL-3 In Progress ). So we'd need to make a manual check in the UI, which is a bit clumsy. But more importantly ...

Option 3 feels more natural. I resist Heikki's idea of generalising "can login to the admin application" to different admin levels, because then we start reproducing concepts that we presently express using permissions.

Meanwhile, Cate Boerema:

My understanding is that discovery services that offer the ability to do renewals etc. and self-checkout machines do not require patrons to log into the ILS system.

Patrons definitely do need to login, otherwise the system won't know who is using it (e.g. which patron to place holds for). The operation may not look like a standard login from a UX perspective – it might be a card-swipe or something – but in system terms, it's a login.

Comment by Jakub Skoczen [ 13/Jun/17 ]

Since the login procedure is used to establish who the user is and we need that information for reporting e.g circulation events, patrons should be able to "log in". I wouldn't necessarily equate this operation with accessing the FOLIO UI, which could be an additional privilege.

So I guess there is yet another option: All users (staff and patrons alike) can "log in" (meaning request and authentication token, e.g to perform circulation operations) but to access FOLIO UI additional permission is required, eg. "Can access FOLIO UI". This permission would need to be granted for all "staff" members, which less than granting the "Can log in" to all users. Additionally, patron users would need a permission set to "Can place loans and holds".

To make this less clumsy and error prone (having to remember to assign those permissions when creating importing users) we could have a place to auto-configure permission assignment at the point of user creation based on certain meta-data elements.

Comment by Nagy István [ 19/Jun/17 ]

It's worth mentioning that self-checkout machines are usually working with non HTTP-based legacy protocols.

With SIP2 the self-checkout machine uses a separate terminal password to authenticate itself to the ILS. This doesn't have anything to do with an actual patron.

When a patron starts interacting with the machine, his/her patron ID is sent as an argument with SIP2 commands. Also by a self-checkout machine the user usually enters some kind of PIN code, which might not be the same as the password associated to his patron account in other systems (like on an OPAC). The same as an ATM requesting a PIN code for operation, even thought by a web-banking UI other credentials are used. The patron ID and PIN is sent with each command during the operation together with the machine's terminal password.

SIP2 usually works with short burst connections consisting of the machine specific authentication and the actual SIP2 command/response. Then the connection is closed. So even though the patron might use the machine for minutes, each action is running in it's own short-lived connection.

This possibly adds an interesting perspective to the collected thoughts above.

Comment by Katalin Lovagné Szűcs [ 21/Jun/17 ]

We had a discussion about this on today's SIG meeting.

We have come to the conclusion that it is preferred not to use a flag in the user's data for "Can access FOLIO UI". If a user has no permissions for any of the available plugins, none should be shown to them but a welcome page which can be configured.

An option for changing password should be available for users without any other permission. Although it brings up another question: what about SSO-authenticated users? Should they have an option to create/change their password (obviously not their SSO password, just the one used in FOLIO-based login)? Do we plan on allowing SSO users to log in with a custom password also? If so when importing users do we have to generate a password for them or leave it empty so that they can change it later? Maybe we can use the "empty password" to indicate that the user can only login via SSO.

Comment by Khalilah Gambrell [ 05/Sep/18 ]

Cate Boerema, can we close this story?

Comment by Cate Boerema (Inactive) [ 06/Sep/18 ]

Yep. Seems like folks agreed to option 1 which doesn't require any additional development. I'll close it.

Generated at Thu Feb 08 23:07:25 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.