]> git.proxmox.com Git - pve-access-control.git/commit - debian/control
use TFA authentication api v2
authorWolfgang Bumiller <w.bumiller@proxmox.com>
Mon, 15 May 2023 07:06:28 +0000 (09:06 +0200)
committerWolfgang Bumiller <w.bumiller@proxmox.com>
Mon, 15 May 2023 07:06:28 +0000 (09:06 +0200)
commitd9f02efe497b0e24d33208f27e07b01295f92697
tree350cfebb7105844320d3b13f3cc7c766542b5815
parent95fb22e69625fd8ee454c6111fd0355aea7fe737
use  TFA authentication api v2

Previously `authentication_verify` just `die`d on error and
would only return a boolean whether `priv/tfa.cfg` needs
updating as a positive result.

Since we want to support locking TOTP as well as a general
TFA lock-out via the config, we also want to be able to tell
when this occurs. Most of it is handled by the TFA rust
crate already, but notifying users needs to be done on this
end instead.

In pve-rs we now have a different API for this:
`authentication_verify2`, which, instead of die()ing on
errors, always returns a hash containing the result as well
as the flags 'tfa-limit-reached' and 'totp-limit-reached'
which, if set, tell us to notify the user.

However, doing so will introduce new fields in the
`priv/tfa.cfg` in a struct marked as `deny_unknown_fields`,
so in a cluster, the limits & notification handling should
only be done once we can be sure that all nodes are up to
date.

These fields are only introduced on login errors, so for
now, handle a failed result early without saving
`priv/tfa.cfg`.
The only case where saving the file was previously required
was when *successfully* logging in with a recovery key, by
which we cannot be reaching a limit, so this should still be
safe.

Once we can validate that all cluster nodes are up to date,
we can implement the notification system.
A commented-out code structure for this is included in this
patch.

Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
debian/control
src/PVE/AccessControl.pm