...
The set you specify for the flow is entirely up to you based on the type of authentication flow you have configured, and what authentication assurances you want. For example, when used as a second-factor in 2FA mode, it seems feasible to signal MFA from the WebAuthn plugin. On the other hand, using the plugin alone, in either passwordless or usernameless modes, may not be enough to signal MFA unless you are certain that the credential is tied to a specific device—which cannot currently be determined from the plugin. Even if the typical passkey process (which requires user verification) combines ‘something you are’ (biometrics) or ‘something you know’ (pin) with ‘something you have’ (an authenticator), if the credential is synchronized (as is common with passkey providers like iCloud Keychain and Google Password Manager), it could be argued that the authenticator does not really qualify as 'something you have'. Either way, it is up to you to decide how best to handle this.
Authentication Credential Policies
The authentication flow comes with a basic, extendable, policy engine for accepting and rejecting FIDO2 credentials at the point of use. To enable policy checks, set the property idp.authn.webauthn.credential.policy.enabled to true in conf/authn/webauthn.properties.
Reference
| Expand |
|---|
|
Name | Type | Default | Description |
|---|
idp.authn.webauthn.usernameless.enabled | Boolean | false | Which type of flow is supported? Usernameless (true) or passwordless (false) | idp.authn.webauthn.2fa.enabled | Boolean | false | Enable this flow to act as second factor authentication | idp.authn.webauthn.2fa.allowedPreviousFactors | String list | authn/Password | Which previous factors are acceptable to allow the WebAuthn flow to act as a second factor of authentication | idp.authn.webauthn.2fa.forceSecondFactorFlow | Boolean | false | Force second factor even if no acceptable previous factors ran | idp.authn.webauthn.2fa.username.strategy | Bean reference | shibboleth.authn.webauthn.CanonicalUsernameLookupStrategy | The bean name of the username lookup strategy. By default, this comes from the principal name established by the first factor. | dp.authn.webauthn.updateSignatureCount | Boolean | true | Should we update an authenticators signature counter inside the credential repository after each successful authentication? | idp.authn.webauthn.passwordless.signalEventOnNoCredentials | Boolean | false | Should an event be built if there are no credentials found for the given user? Only applicable to passwordless authentication. | idp.authn.webauthn.passwordless.noCredentialsEventId | String | NoRegisteredWebAuthnCredentials | If an event is triggered when no credentials are found for the user, what should the event ID be? | idp.authn.webauthn.signalEventOnNoCredentialsRegisteredForUserHandle | Boolean | false | Should a custom event be built if the userHandle supplied by the authenticator during authentication is not related to any registered credentials? | idp.authn.webauthn.userHandleNoRegisteredCredentialsEventId | String | NoCredentialsRegisteredForUserHandle | If an event is triggered when no credentials can be found for the given userHandle, what should the event ID be? | idp.authn.webauthn.passwordless.username.uppercase | Boolean | false | Basic transformations that should be applied to the username that is collected as part of the passwordless flow | idp.authn.webauthn.passwordless.username.lowercase | Boolean | false | Basic transformations that should be applied to the username that is collected as part of the passwordless flow | idp.authn.webauthn.passwordless.username.trim | Boolean | false | Basic transformations that should be applied to the username that is collected as part of the passwordless flow | idp.authn.webauthn.passwordless.c14n.postUsernameFlows | Bean ref | shibboleth.PostLoginSubjectCanonicalizationFlows | The ID of the bean that supplies the c14n flows that are applied to the username entered during the passwordless flow |
|
...