How to auto-populate SIP2 PIN field

The User Management SIG is currently discussing the introduction of a separate PIN field for SIP2 authentication on self check kiosks as requested in UXPROD-1811. At the moment SIP2 authenticates against the password field which is considered as not practical for different reasons. The idea is to extend the schema by this field but we see no need to display it in the Users App UI at the moment. The question came up whether and how this field should be auto-populated when creating a new user via the UI.

If the PIN is used at your library, it is obvious that an initial PIN must be generated and communicated to the user. Some SIG members propose to use 4 digits from the date of birth, e.g. DDMM, MMYY or YYYY - but what if we have no date of birth? In general, several options could be implemented and selected via settings. The question to the community is, which methods are currently used or needed to auto-fill this field? The development could start soon, so we appreciate any feedback on this topic. Thank you!

I would argue that we shouldn’t assume auto-population of the field. If not set, authentication should fail, and there should be creation/reset workflow similar to what exists for the user password.

That implies adding a UI field, which is one of the things we were trying to avoid. But yes, from a security perspective, it makes sense not to auto-populate. But there are many institutions that will not rely on a PIN feature and would be unhappy to add yet another field they aren’t going to use.

I don’t think this implies a UI field or function. The initial setting or changing of the PIN cannot be done by the service staff, because this would be too time consuming. This must be done via a patron interface, calalog etc.

We at Chalmers have created a website to let patrons create their own accounts in folio. Our self check kiosk are set to use six digits as a pin code to make them a bit more secure than four digits. We also check so that they can’t set the pin code to a sequence from their personnummer (Swedish social security number sort of) which consist of the birthdate + 4 digits where the last digit is a checksum digit for validation. If they forget their pin code they can change it via the site too. When they visit a service desk we have a separate electron app that where they can set a new code after identifying them selves with an id to the staff.

So if it is mandatory to set a pincode at account creation I think it should just be random digits at first or entered by the user and be changeable/reset from other sources via an API.

Btw the pincode is used by our patrons to log in to EDS as well and the username field is populated with the personnummer.

Bjorn, could you elaborate on why it is obvious to you to have a pin auto-populated from the start?

To me, auto-population would mean that the pin needs to be either predictable, stored in clear text in the database, or even stored outside of the user record. I do not think either is acceptable We do not know what the libraries will use SIP2 for in the future, and I want to argue for having high-security standards for these pins from the start.

As an example, I know libraries that gives access to computers and their network by letting patrons authenticate over sip2. In that case, having prepopulated pins based of public personal data is a security risk.

If a library wants to auto-populate pins and have lower standards, I think that should be configurable. But that needs to be a conscious decision and not something we encourage.

For the population of the field, I think you need to set things up as Chalmers, with a registration form, calling the underlying FOLIO API:s and letting the user set the pin themselves.

If you are handing out library cards over the desk anyway, I believe you could as well let the patrons set the pin through the UI at the same time.

The workflow that the above does not solve is where you have libraries that get their users from a central feed, and those users are able to check things out without a library card or ever having to visit the library (virtually or physically) to register. In that case, the pin needs to be populated.

But I think that pin-polulation should be part of the seting up of the user feed and for library to decide on how it should be handled, and not be put on FOLIO.

I always forget to come back here and check on my threads. I guess I’m just not sure why we aren’t just duplicating the implementation of the user password for this, but just not making it work for mod-auth logins. It should have the same setup/reset workflow as the password. Eg. you call a reset API that generates a PIN reset URL which allows the user to set their own PIN. That, or you can use an API to set it programmatically without validation, like to also do for passwords.

Thanks for all your feedback and sorry for the late reply! There seems to be a strong opinion against auto-pupulation of the PIN field, especially from a security point of view. So I admit defeat and go along with your approach. After recent discussion in the UM SIG, Leipzig dev team will now include the additional PIN field in the user record for Juniper release. In this context the SIP authentication would then still need to be directed to this new PIN field (since it uses password field at the moment), we will pass this on to the appropriate team. For all libraries who already use PIN authentication (via password field) or want to use SIP authentication with Juniper I would communicate this in Slack #folio-implementers so that it is in line with the local plans.