WebAuthnReleaseNotes

This is a patch release to fix three bugs:

• The management view search breaks after failing to find a user

• The donotcache directive was missing from the WebAuthn view

• Consent revocation choice is cleared: the users' choice to revoke consent is not carried over from the username input view to the main webauthn view

This release includes two bug fixes and one new feature.

Regarding the bug fixes:

• All view templates have been cleaned up by removing extra div tags and adding any missing end tags.

• The consent revocation feature, which was previously absent from the main WebAuthn template, has now been added.

  • Additionally, the default view has been updated to include this feature as an example.

The new feature includes an injectable predicate hook that signals the registration view to trigger the registration of a new credential on page load, without requiring user interaction.

This is a feature release of the WebAuthn plugin.

The default credential repository now contains two features to improve the performance of credential lookups:

• A cache to improve the speed of credential lookups during both authentication and registration.

• A JDBC-specific accelerator service for improving the speed of credential lookups by credentialId and userHandle. This is particularly beneficial for usernameless usage, but it will also help improve all modes of operation. This will only work for databases that support SQL/JSON—see the CredentialRepository wiki documentation.

Hooks have been added to enhance functionality or signal when a credential is added, deleted, or its nickname is updated. These hooks can be created by defining beans:

• shibboleth.authn.WebAuthn.audit.DeleteKeyAuditSuccessHook

• shibboleth.authn.WebAuthn.audit.DeleteKeyAuditFailureHook

• shibboleth.authn.WebAuthn.audit.AddKeyAuditSuccessHook

• shibboleth.authn.WebAuthn.audit.AddKeyAuditFailureHook

• shibboleth.authn.WebAuthn.audit.UpdateCredentialNicknameAuditSuccessHook

• shibboleth.authn.WebAuthn.audit.UpdateCredentialNicknameAuditFailureHook

This is a feature release of the WebAuthn plugin.

Nicknames for registered credentials can now be updated, which was not previously possible unless you manually edited the underlying storage record. The default registration view in webauthn-register.vm now includes an example form for nickname input. Please ensure you copy the new webauthn.css file from /edit-webapp/css to properly render the updated form.

This is both a bug and a feature release of the WebAuthn plugin.

Nickname collection can now be disabled by setting the property idp.authn.webauthn.registration.nicknameRequired. This can streamline credential registration.

In addition to the Authentication Credential Policy, which determines whether the credential a user has used for authentication is accepted or rejected, a new Filter Policy engine can be implemented for passwordless and second-factor authentication flows. This engine restricts the credentials that users can use before they attempt to authenticate. This can not be applied to the usernameless mode, as the user (and credentials) are not identified until after the WebAuthn authentication ceremony has been performed.

An oversight in the first version prevented the configuration of the registration and management views to require re-authentication (forceAuthn). This can now be achieved by setting either of the properties idp.authn.webauthn.admin.registration.forceAuthn or idp.authn.webauthn.admin.management.forceAuth.

For the more cautious, a new access control policy is included in the distribution that guards against the use of ‘weak’ authentication methods from accessing the registration page if the user already has FIDO2 credentials. For example, as extra protection against using only single-factor Password authentication to access the registration page when the user has already registered a FIDO2 credential.

Note if you have another second-factor authentication method available you can already mandate the use of ‘strong’ authentication by setting the defaultAuthenticationMethods property. Also, now v1.1.0 allows you to force re-authentication, if you have a suitable MFA configuration, the guard is likely not needed (although you’d need to evaluate that).

A new field has been added to the storage record to store the last used time of a credential.

In the default registration and management view templates, the ‘Registration Time’ column has been replaced with either ‘Registration Time’ or, if enabled, ‘Last Used Time’. You’d need to update your templates on upgrade if you wanted to add $cred.credentialRecord.lastUsedTime value (use the new templates as an example).

By default, this feature is disabled to preserve backward compatibility and to prevent additional writes to the storage service, likely a database. To enable, set the property idp.authn.webauthn.updateLastUsedTime to true.

The first version of the WebAuthn plugin.

The WebAuthn login flow facilitates FIDO2 authentication within the Identity Provider (IdP) by utilizing the Web Authentication API. This enables strong, public-key-based authentication. The plugin can operate in various ways: as a single-factor option within a broader multi-factor authentication, as passwordless authentication after the user enters their username, or as usernameless authentication where the user is implicitly identified from the credential they choose.