Users App (UXPROD-784)

[UXPROD-1811] Implement patron PIN number as separate password field (authentication token) for circulation Created: 26/Jun/19  Updated: 12/May/22

Status: In Refinement
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Users App

Type: New Feature Priority: P3
Reporter: patty.wanninger Assignee: Ian Ibbotson (Use this one)
Resolution: Unresolved Votes: 0
Labels: resourceaccess, security, security-reviewed, usermanagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
blocks UXPROD-3040 INN-Reach: Support PIN-based verifica... Closed
Defines
is defined by MODUSERS-254 Implement back-end-only field to stor... Closed
Relates
relates to SIP2-89 Implement patron PIN field instead of... Draft
Epic Link: Users App
Development Team: None
Kiwi Planning Points (DO NOT CHANGE): 15
PO Rank: 10
PO Ranking Note: It would be the right thing to do (separate pwd from pin) in the long run
Rank: Chalmers (Impl Aut 2019): R2
Rank: Chicago (MVP Sum 2020): R5
Rank: Cornell (Full Sum 2021): R5
Rank: Duke (Full Sum 2021): R5
Rank: 5Colleges (Full Jul 2021): R5
Rank: GBV (MVP Sum 2020): R5
Rank: Grand Valley (Full Sum 2021): R4
Rank: Lehigh (MVP Summer 2020): R5
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R5
Rank: U of AL (MVP Oct 2020): R5

 Description   

Many libraries require PIN code as an additional patron validation. If the numeric PIN is stored in the password field and a patron attempts to change their PIN, password validation rules would not allow the password to be numeric only and would force the patron to make the PIN alphanumeric. PINs are often used as a validation in self-checkout kiosks. If the kiosk is configured to use numeric PIN, the patron after the change of their PIN will not be able to use the self-checkout kiosks.



 Comments   
Comment by Theodor Tolstoy (One-Group.se) [ 05/Jul/19 ]

Magda Zacharska Does this mean the addition of another field on the user record, or is this JIRA an umbrella issue for the various tasks of adding PIN verification from SIP2 and other services?

Comment by Theodor Tolstoy (One-Group.se) [ 05/Jul/19 ]

Assuming the latter and setting it as Go live

Comment by Magda Zacharska [ 08/Jul/19 ]

Theodor Tolstoy (One-Group.se) This is just a placeholder for the work that will need to be defined if we decide to add PIN field (in addition to the existing password field) to the patron record. The work that is required for Chalmers go-live is tracked by SIP2-61 Closed and SIP2-68 Closed

Comment by Theodor Tolstoy (One-Group.se) [ 08/Jul/19 ]

Ok, thank you. Updating ranking accordingly

Comment by David Bottorff [ 09/Jul/19 ]

Would this include being able to use a PIN to sign in to discovery layer and auhenticate for user services (such as renewing items) for users who like LDAP credentials?

Comment by Cate Boerema (Inactive) [ 29/Jul/19 ]

Hi Magda Zacharska can you please give this a PO rank?

Comment by Björn Muschall [ 25/Sep/19 ]

sorry for late reply

Comment by Marie Widigson [ 09/Nov/20 ]

We are currently using the password field as a workaround but are experiencing more and more problems with this. We would need one separate PIN-field for SIP2 and use the present password field only for staff login to FOLIO. Changing prio from Not needed to R2.

Comment by Brooks Travis [ 13/Apr/21 ]

patty.wanninger Maura Byrne It's probably worth discussing this again in the SIG and seeing if we can't find some development resources for it. The feature probably needs to be fleshed out a bit more, as well.

Comment by John Coburn [ 05/May/22 ]

On behalf of the folio-security-group, the pin needs to be stored in a way in which it can only be read by the back-end - the pin itself should not be visible in UI to staff. Please include this detail in the requirements. If any advice is needed regarding this, please reach out to the folio-security-group: https://folio-org.atlassian.net/wiki/display/SEC/Security+Home . Thank you!

Comment by Brooks Travis [ 05/May/22 ]

John Coburn Does the requirement to implement this with the same security level as FOLIO’s existing passwords satisfy your comment? (See MODUSERS-254 Closed )

Comment by Craig McNally [ 12/May/22 ]

Brooks Travis yes, that's fine.

Generated at Fri Feb 09 00:18:43 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.