2017-11-09 Resource Access Meeting Notes

Date

Nov 9, 2017

Attendees

• @Andrea Loigman

• @David Bottorff

• @Cate Boerema (Deactivated)

• @Deb Lamb

• @Cheryl Malmborg

• @Karen Newbery

• @Chris Manly

• @Kimie Kester

• @VBar

• @Michael Winkler

• @Julian Ladisch

• @Wendy Wilcox

• @William Weare

• @Peter Murray

• Carsten schwill

• @Joanne Leary

• @Maria Grzeschniok

• @David Larsen

• @Darcy Branchini

Goals

• Continue discussion of issues of joint interest to the UM and RA SIGs

Discussion items

Notes

• call re International Calendar re QUILTO, basing on google calendar in a general sort of way, useful conversation, Deb, Cheryl, Ushi, Mark Keeper, Andrea Loigman, will meet again when QUITO has something for us to look at

• RA/UM cross-interest discussion today

• password mockup (Kimie)

  • send reset password email - sends email and popup includes link and copy link function to send if user is not receiving emails from FOLIO

  • example email, 24 hours to reset

  • how will this work for SSO environment? would it be okay to disable/suppress all of this?

  • needs to work for all users, including patrons, in case someone builds a patron facing app

  • table the issue of what password would give access to in terms of outside users vs staff

  • another option: forgot password link at sign in screen, enter email, username, or phone number, which sends you your email

  • choose password should require double entry of password?

  • should password eventually support 2FA and ultimately biometric? Does the IDM security ultimately need to be pulled out as a separate app that can be updated, etc.?

  • Duke requires staff reset passwords every 3 months.Patron who is logged in can change password separate from forgot password workflow? Do we need also password expiration or mass reset?

  • security issues surrounding this? should password/security be stripped out?

  • Is this a problem or more complicated because we're trying to be all things to all users, staff and patrons?

  • permission for password reset and contact info edits by user level, people might need to view but not edit

  • right now you can either view it all, edit it all, or not see it at all

  • maybe just make passwords completely separate from other user information screen

  • useful to know the source of the contact info table this for another discussion, separate issue

  • do we ever need to let the user update their own information? the one exception would be things like pickup location, etc.

  • we do need SSO and password management, but need for test accounts for vendors, etc.

  • at the moment SSO implementation adds a link to sign on with SSO

  • login screen that offers SSO or username and password for those who are not SSO

    • examples:

      • From Karen Newbery https://gitlab.oit.duke.edu/users/sign_in

      • Andrea Loigman https://library.duke.edu/librarycatalog/login/?next=/librarycatalog/request/008020077&aeon_holdings=none

      • Chris Manly https://cornell.account.box.com/login

      • Chris Manly https://confluence.cornell.edu/login.action

  • is the need for separate password management alongside SSO a v1 issue?

  • sometimes dummy accounts are created as operators to allow for workflows that our systems don't support, there are always going to be likely need for workarounds

  • some of what Chicago can do is due to a flexible campus infrastructure

• request fulfillment option in user record - delivery and pickup options

  • an exception mechanism from within the feed for individual users for override rather than locking fields in FOLIO itself table this for future discussion

• We will need another joint discussion in the near future, Andrea and Chris will determine a time