...
Discussion items
| Time | Item | Who | Notes | ||
|---|---|---|---|---|---|
| 35 min | Integration of institutional authN into FOLIO |
Action items
|
Notes
- While we are not currently expecting users to log into the FOLIO web interface, there is a need for patrons to authenticate themselves against Okapi APIs for processes such as checking the status of holds and renewing checked out items. Some sites are using bespoke applications for this (Cornell), have integrated it with locally-hosted discovery layers (like Blacklight), are using vendor-supplied discovery layers (such as TAMU with EDS), or have external companies developing apps for this (GBV).
- Sites are resistant using systems that perform "proxy authentication" for users (meaning: having a service taking in the username/password from the user and attempting to log in with those credentials on the server side). Cornell, for instance, is actively teaching users to only use their credentials at the campus identity provider system.
- The user management module has three identifiers for the user at the moment: an internal user id, a place for an external single-sign-on identifier, and a barcode.
- Of those represented on the call, Shibboleth is the mechanism needed to authenticate users to FOLIO.
Action items
- Cate Boerema (Deactivated) to check with Hkaplanian about specifying Shibboleth as the external authentication mechanism for Release 1.