Add support for optional require_2fa argument

[dsupru]

Hi again !
Following up on #1137
This PR implements the suggestion to return “insufficient credentials” when require_2fa is set and the current auth mode is password-only (1FA).

I tested it with my setup and it worked as expected.
I added a currentAuthMode state variable to the authenticationModel struct. Since it already has fields like currentBrokerId and currentSessionId, this seemed like a reasonable place for it, but please let me know if you have any reservations. I think this is cleaner than adding an env variable, which feels brittle and likely to break in the future. Here i'm assuming "password" auth mode is 1FA (defined here). That’s not perfect, but it should be easier to evolve later without breaking changes.

I also considered passing require_2fa down to the brokers and returning authNext if the auth mode is password, but that seemed a bit more invasive, and we’d still need logic somewhere to error out with insufficient creds. Happy to hear which design you prefer.

the pam config I used for testing:

auth    [success=ok user_unknown=ignore default=bad] pam_succeed_if.so user != root quiet_success
auth    [success=1 cred_insufficient=ignore ignore=ignore default=die authinfo_unavail=ignore] \
        pam_authd.so debug=true require_2fa=true
 
auth    required pam_u2f.so cue
 
auth    requisite pam_nologin.so
auth    optional  pam_gnome_keyring.so

^ when i log in with a password and the config above

I'll keep #1137 open in case you prefer that approach, but please let me know if we can move forward with either of these. Super interested in getting this out, let me know what else I can do to get this to a mergeable state 🙂
I suppose before (or after?) merging it you'd like to update the docs, please point where I can suggest that edit

[dsupru]

Gentle nudge @adombeck , @3v1n0

[adombeck]

I'll let @3v1n0 handle this because he's the expert for PAM

[dsupru]

@3v1n0 another ping. Please let me know what your thoughts on this change are. I think it adds quite a bit of value for all business Ubuntu customers

[3v1n0]

@dsupru hey, I've worked a bit on this, and I pushed here how I was thinking to handle this.

Give it a try, however my feeling is that even by doing this or exposing the authentication modes as PAM values, we're ending up with an hacky solution and potentially not future proof.

The fact is:

• At PAM level we don't know exactly what are the authentication methods that have been used: their names are just IDs that are provided by the broker and that can change at any given time
• We may only be sure that we authenticated using a web-authentication, or using multiple input fields, or a new password has been set.

The proposed solution here is "good enough", but if some broker will support a multi-factor authentication system based on typing some PIN that you got through SMS (or any other device), then we won't be able to know that an MFA method has been used.

Reason why, I think that the proper solution to this would be leaving this driven by the broker (as everything else in authd, since it's the only one that really knows what's going on), and so introducing another error message that the broker can return and thus make authd to react to that.

[dsupru]

Doesn't quite work for the "device authentication" auth flow: a user is presented with a qr code layout, and then the new password layout. That adds up to 1 factor (layouts.QrCode), so a user will be locked out if they ever loose their 2nd factor device for example.

[dsupru]

Thank you so much for working on this @3v1n0 !

The main concern with the proposed change is that the “device authentication” method (QR-code layout) is now counted as a single factor.
I agree that this is arguably the more correct modeling, since whether it’s effectively single or multi-factor depends on how the IdP is configured, and we shouldn’t assume it implies 2FA.

That said, treating device authentication as a single factor has a downside: users may not have a viable self-service recovery path if they lose their 2nd factor. This might be workable in smaller orgs, but at larger companies it’s common to require a recovery flow users can complete on their own. Even for my org, I can see cases like “someone loses a YubiKey while remote and can’t log in to their device.”

Also, I can approximate the same behavior today by always requiring a second factor (e.g., an inserted YubiKey) via PAM configuration.

If we can’t treat device authentication as 2-factor within authd, it may indeed make sense to implement this at the daemon level like you suggested. I took a quick look at OIDC: the amr claim may indicate which authentication methods were used (assuming the provider supplies it). If "mfa" is present among the Authentication Method Reference values, that seems like the cleanest way to distinguish MFA-backed logins.

I’m planning to spend some time around New Year’s to put together a PR, but if you have bandwidth, I’d appreciate another set of eyes on it.

Thank you and happy new year!