Skip to content

Delay 2FA until required by an application

Maxime Besson requested to merge feature-delayed-2fa-2124 into v2.0

Hi team. I am proposing the often requested feature of using 2FA only when an application requires it. (#2124 (closed))

This implementation is not perfect, and it will be disabled by default.

The key to this new feature is the new "Use 2FA for session upgrade" option in the manager (General -> Second factors)

A screencast is worth a thousand words:

vokoscreen-2020-06-11_19-23-14

Under the hood, here is how it works:

  • I implemented an authenticationLevel option for CAS/OIDC/SAML services
  • The "target" authentication level of the service you are logging in for is stored in a pdata value (targetAuthnLevel). This is the case for CAS/OIDC/SAML and also handler services
  • When the new "sfOnlyUpgrade" option is enabled in config, during authentication, the 2FA step doesn't run if the target authentication level is already matched by the first factor
  • When the issuer runs, if the target Auth level is too low, offer reauthentication (even if the sfOnlyUpgrade option is missing)
  • I had to rework the Upgrade.pm plugin a bit, so that there can be a clear difference between Renewing the session (1st + 2nd factor) and Upgrading the session (2nd factor only if sfOnlyUpgrade, else reauthentication)

In order to handle registration correctly, I had to slightly change the fix to #1878 (closed), @maudoux please check that 513aed40 does not break your use case.

And of course, any feedback is welcome before I merge this. Especially on my proposal to split between /renewsession and /upgradesession.

This MR is a first step towards #1848 but we're not there yet. In particular, this MR does not filter which authentication schemes the user is offered during authentication/upgrade. So a user can end up using a Second factor or authentication method that is not enough to satisfy the current service, and might find himself in a frustrating maze of choice screens.

Merge request reports