Bug 19886

Is this something that needs to be built into Koha, or is it better to make use of existing third party systems such as PrivacyIDEA (https://www.privacyidea.org/) that can be used in conjuction with normal SSO mechanisms?  For example we (Loughborough University) have tested Yubikeys with PrivacyIDEA and simpleSAMLphp IdP and it works, and we already know that Koha can use the SAML2.0 authentication assertions from the IdP (as that's what we're doing in production with PTFS-E).  PrivacyIDEA also can also support Google Authentication as suggested in Bug 19887.

Hi,
here some useful informations for implementing U2F in Perl
http://blogs.perl.org/users/mschout/2018/01/testing-fidou2f-two-factor-authentication.html

Koha needs additional layers of authentication. With the spread of equipment such as Amazon-locker type units to hold (often expensive) items obtained for interlibrary loan, and kit such as laptop loan units, there is the danger of unauthorised use via SIP2. Sites using RFID user cards with the cardnumber embedded on them are vulnerable to stock loss if a user card is lost and then found and used maliciously. Adding PIN functionality (for example) would reduce this risk.

(In reply to Jon Knight from comment #1)
> Is this something that needs to be built into Koha, or is it better to make
> use of existing third party systems such as PrivacyIDEA
> (https://www.privacyidea.org/) that can be used in conjuction with normal
> SSO mechanisms?  For example we (Loughborough University) have tested
> Yubikeys with PrivacyIDEA and simpleSAMLphp IdP and it works, and we already
> know that Koha can use the SAML2.0 authentication assertions from the IdP
> (as that's what we're doing in production with PTFS-E).  PrivacyIDEA also
> can also support Google Authentication as suggested in Bug 19887.

I wonder about this as well. I'm fond of Keycloak for this purpose. It can use SAML or OpenID Connect. I have a local OpenID Connect client I wrote for Koha, and I've thought about using Keycloak in the test plan for when I finish the patches for Bugzilla...

That said, adding support to Koha would make it easy for people to have more secure out of the box implementations without needing more third party software.

(In reply to Ray Delahunty from comment #3)
> Koha needs additional layers of authentication. With the spread of equipment
> such as Amazon-locker type units to hold (often expensive) items obtained
> for interlibrary loan, and kit such as laptop loan units, there is the
> danger of unauthorised use via SIP2. Sites using RFID user cards with the
> cardnumber embedded on them are vulnerable to stock loss if a user card is
> lost and then found and used maliciously. Adding PIN functionality (for
> example) would reduce this risk.

Additional layers of authentication could be used for Staff Client login or OPAC login, but I don't think the layers you describe are very realistic for most libraries (ie I worked on the front lines of libraries for years and getting patrons to remember a number or a card is hard enough in itself). I also think they're a different use case than what is being described in this bug report. But an interesting idea.

I'd be open to testing work to add support for Yubikey to Staff Client auth.

The FIDO alliance has published a new website promoting FIDO2 for both consumers and providers. FIDO2 includes Yubikey and other key vendor support, as well as biometrics (facial scans and fingerprint), and personal PINs.

https://loginwithfido.com/provider/

This is an established and well-supported standard, defined by both the FIDO Alliance and W3C's webauthn. Just dropping this here as I think it might be a better, all-encompassing approach to authentication in general, beyond just adding 2FA, and is way easier for the end-user with its multiple supported authenticators, not just a single vendor's hardware key.

(In reply to Aaron Sakovich from comment #7)
> The FIDO alliance has published a new website promoting FIDO2 for both
> consumers and providers. FIDO2 includes Yubikey and other key vendor
> support, as well as biometrics (facial scans and fingerprint), and personal
> PINs.
> 
> https://loginwithfido.com/provider/
> 
> This is an established and well-supported standard, defined by both the FIDO
> Alliance and W3C's webauthn. Just dropping this here as I think it might be
> a better, all-encompassing approach to authentication in general, beyond
> just adding 2FA, and is way easier for the end-user with its multiple
> supported authenticators, not just a single vendor's hardware key.

Sounds good to me.

Hi,
can we add this feature as extension of Bug 28786? HW USK key is "one touch" as opposed to TOTP, which requires writing code from apliaction from toter device, usualy smartphone?