[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: |
|
||||||||||||
| 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:
|
| 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.
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 ] |
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 (
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:
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. |