| Table of Contents | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
The plugin comes with an administration flow for registering and managing FIDO2 credentials. The inbuilt flow represents the minimum viable product for implementing such a feature. In the future other plugins may provide this functionality.
...
The registration flow collects the username as a first step so it can look up any registered credentials before passing control to the authentication system. This information can be accessed in the MFA configuration using the isWebAuthnAvailable() method on the WebAuthnRegistrationContext, to decide which flow to use. The example MFA Flow With Password Fallback is a suitable initial setup that allows users to register their first credentials upon inputting their username and password; other combinations are possible.
...
(Required) Configure a suitable access control policy.
(Optional) Configure how user account details are passed to the WebAuthn API and authenticator.
(Optional) Decide what type of authenticator you want to support.
(Optional) Decide if you want to require only ‘trusted’ (from FIDO Alliance Metadata) authenticators to be registered
| Anchor | ||||
|---|---|---|---|---|
|
...
This policy is essential if you plan on creating an MFA flow (such as MFA Flow With Password Bypass) which provides another authentication method if the user has no registered credentials: either using isWebAuthnAvailable() or when signalling a custom event.
The AccessByCurrentUser policy checks the username found in the registration context—collected by the username view when the user first enters the registration flow—is the same as the principal name (identity) of the user that authenticated. This is important, if we imagine a scenario where a nefarious user wanted to ‘change' or possibly 'downgrade’ a user’s authenticate method from WebAuthn to, say, username and password (or whatever else was configured as a ‘backup’), all they would need to do is enter a non-existent username into the username collection step of the registration page and then have the MFA flow direct them to a different flow (because they do not have any registered credentials) where, for example, they can proceed to try different usernames and passwords for authentication. Importantly, the registration flow uses the principal name of the authenticated user to register credentials against.
...
However, there are some caveats to consider. The principal name that results from authentication is determined by the Authentication flow, the SubjectCanonicalization flow, and possibly any transformations that have been applied to the username. It is, therefore, entirely possible (although probably not common) that the user who entered the registration flow is the same as the user who authenticated, but their username and principal name do not match. Generally, if this is the case, a different comparison predicate would need to be created and plugged into the AccessByCurrentUser policy: see the example below.
...
Noting, if you want to use the basic support for only allowing credentials to be registered from ‘trusted’ authenticators that are contained within the FIDO metadata feed, you’d typically need to enable ‘direct’ attestation.
...