Webauthn support

[laurivosandi]

The scope of this ticket is the introduction of meaningfully secure U2F support. For example resetting U2F keys via e-mail doesn't add meaningful security.

Global enrollment flag options:

• Mandatory: all users enrolled in Passmower must have U2F keys enrolled, U2F enrollment is part of user signup procedure
• As needed basis: if application requires U2F user is expected to enroll a key during authentication
• Disabled, no U2F functionality enabled at all

Global update flag options:

• Users are allowed to update their own keys assuming they can authenticate with another. This would go hand in hand with minimal number of keys user is expected to enroll
• Users can not update their keys at all. Provide admin view for enrolling keys for users

Introduce policy attribute for OIDCGWClient to specify what is the authentication policy for the application

Adjacent topics: Export Prometheus metrics per application/group about how many users can log in and using which policy. This would go hand in hand with as needed basis U2F, it should be possible to write an alert that triggers if user has access to OIDC application with U2F policy enabled, yet hasn't enrolled keys in a reasonably short time (eg 7 days)

[jtagcat]

Consider U2F legacy. Instead of U2F, you want FIDO2. WebAuthn is the thing you are implementing ($ sed -i s/U2F/WebAuthn/g).

Imo enrolment should be managed by RBAC.

Authenticator management

Allow admin to exclude the requirement for 2FA on a specific user for a time period. If the policy is minimum 2 authenticators, allow the user to be good with either (chosen by admin) 0 or 1 authenticators.

Self-service

To access the page, users must authenticate with a valid device. This authgate can be reused from normal auth flow.

If configured (RBAC or global flag?) to forbid self-service, there will only be an admin bypass request button¹.

Admins should be able to add custom text to the page (localization, out of band contacts, instructions, etc).

Admin bypass

A 'request admin button'². Admin has a dashboard to view all pending requests + optionally notification³ to lessen time the user waits.

After admin permission, the user can access the self-service page from the same device. The first access must be done within n hours. After the first open, the access is shortened to x minutes (extended with every interaction), capped to y hours.

If the user reached the page by using an authenticator (not admin bypass), then removing the same device promts for authentication of another device or admin bypass (to prevent lockouts).

Adding devices takes serial code (using the scary prompt below) instead of letting the user insert a name. Users such as @jtagcat are known to mix up their identical-looking authenticators. If the authenticator is a (non-USB) device, ask for name.

(from https://demo.yubico.com/webauthn-technical/registration, worst case anonymized IDs can be used as well)

On the page, provide a button to identify/verify a device + where to find the serial code⁴ physically.

For all actions, there is an audit trail. Rate limits (&/ admin notification/view) for adding devices.

Footnotes

1. Admin view for enrolling keys is unacceptable. Most environments will partially use security keys in a form of Windows Hello, Touch ID (Mac, iOS) and Device Biometrics (Android). This would mean the admin signs in to the user's device + the ideology doesn't account for remote / global users. ↩

2. I don't know of a good UI to keep the experience responsive — how to avoid 'request sent' + user goes to a coffee for a workday. What if the user needs a person to look at it right away instead of 2 working days? Pingback for 'request granted'? ↩

3. Webhooks or something like https://github.com/caronc/apprise — generic way of sending notifications. ↩

4. Yubikey Manager (and $ ykman info) can also be used by users to get the info. Apparently, the blue YubiKeys don't have serial codes. ↩