Commit graph

4 commits

Author SHA1 Message Date
b93e15c235
Bug 30588: Add the option to require 2FA setup on first staff login
Bug 28786 added the ability to turn on a two-factor authentication,
using a One Time Password (OTP).
Once enabled on the system, librarian had the choice to enable or
disable it for themselves.
For security reason an administrator could decide to force the
librarians to use this second authentication step.

This patch adds a third option to the existing syspref, 'Enforced', for
that purpose.

QA notes: the code we had in the members/two_factor_auth.pl controller
has been moved to REST API controller methods (with their tests and
swagger specs), for reusability reason. Code from template has been
moved to an include file for the same reason.

Test plan:
A. Regression tests
As we modified the code we need first to confirm the existing features
are still working as expected.
1. Turn off TwoFactorAuthentication (disabled) and confirm that you are not able to
enable and access the second authentication step
2. Turn it on (enabled) and confirm that you are able to enable it in your account
3. Logout and confirm then that you are able to login into Koha

B. The new option
1. Set the pref to "enforced"
2. You are not logged out, logged in users stay logged in
3. Pick a user that does not have 2FA setup, login
4. Notice the new screen (UI is a bit ugly, suggestions welcomed)
5. Try to access Koha without enabling 2FA, you shouldn't be able to
access any pages
6. Setup 2FA and confirm that you are redirected to the login screen
7. Login, send the correct pin code
=> You are fully logged in!

Note that at 6 we could redirect to the mainpage, without the need to
login again, but I think it's preferable to reduce the change to
C4::Auth. If it's considered mandatory by QA I could have a look on
another bug report.

Sponsored-by: Rijksmuseum, Netherlands

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2022-10-21 11:36:57 -03:00
25c522fea1
Bug 28787: Rename the REST API route to /auth/otp/token_delivery
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Sponsored-by: Rijksmuseum, Netherlands

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2022-08-09 13:38:44 -03:00
c0864cfdea
Bug 28787: (follow-up) Changes in API auth, moved otp out of Letters
Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Sponsored-by: Rijksmuseum, Netherlands

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2022-08-09 13:38:43 -03:00
6e099d0bbd
Bug 28787: Send a notice with the TOTP token
Bug 28786 let librarians enable a Two-factor authentication but force them to use
an application to generate the TOTP token.

This new enhancement add the ability to send an email containing the token to the
patron once it's authenticaed

The new notice template has the code '2FA_OTP_TOKEN'

Test plan:
- Setup the two-factor authentication (you need the config entry and the
syspref ON)
- Enable it for your logged in patron
- Logout
- Login and notice the new link "Send the code by email"
- Click on it and confirm that you received an email with the code
- Use the code to be fully logged in

QA question: Is 400 the correct error code to tell the email has not
been sent?

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Sponsored-by: Rijksmuseum, Netherlands

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
2022-08-09 13:38:43 -03:00