Use case: FIDO registration self-service

This article explains how a logged-in end-user can register FIDO Authenticator with the Airlock IAM account and.

End-users need to be authenticated for the registration self-service.

To register FIDO Authenticators during the login process, see Use case: FIDO token migration self-service instead.

Note that FIDO credentials can be managed by administrators in the IAM Adminapp, but they can only be registered by the end-user in a self-service.

Goal

    • Understand how the FIDO registration self-service works.
    • Learn details about the prerequisites and limitations of FIDO registration.

All following procedures are exemplary and will vary according to your setup or needs.

Initial thoughts

The FIDO registration is part of the Loginapp REST API and its web UI. The registration process is implemented as a protected self-service flow. This allows great flexibility in combining the FIDO registration with other steps and for any authorization and access conditions.

Great care should be taken especially regarding authorization and access conditions:
If FIDO should be used for strong authentication, it is mandatory to authenticate the end-user in a strong way before FIDO registration, because the authenticity of the registered FIDO Authenticators is based on the security prevalent during the registration self-service.

While it is possible to enroll FIDO Authenticators just based on username and password, the security risks of such a setup must be considered thoroughly.

Thus, we strongly recommended protecting the FIDO registration self-service flow with an access condition that guarantees sufficient end-user authentication. This is especially useful if different levels of authentication are allowed (or might be configured in the future).

In all cases, Airlock IAM acts as FIDO relying party.

Prerequisites

  • An end-user account exists in IAM and end-users can be authenticated (e.g. username, password, and a 2nd factor).
  • The end-user has a supported FIDO authenticator.
  • The FIDO authenticator complies with the settings in the FIDO configuration.
  • The end-users browser or mobile app supports FIDO.
  • To support FIDO passwordless authentication (now or in the future), make sure to require keys to be resident during the registration.
  • A protected self-service flow to register FIDO authenticators has been configured.
  • The FIDO registration flow's configured access condition is fulfilled.
  • The end-user is authorized to register FIDO authenticators (i.e. the FIDO registration flow's configured authorization condition is fulfilled).

Token migration

The following flow chart shows how the FIDO registration step can be used:

UC-FIDO-token-registration-self-service-with-IAM
(1)

The end-user is strongly authenticated with existing credentials and usually an established second factor. This may be another FIDO authenticator or a different second factor.

(2)

The end-user starts the FIDO registration self-service flow. This may be for example by clicking on a link or pressing a button in an app.

  • Airlock IAM verifies that:
  • the user is authenticated.
  • the configured access condition is fulfilled.
  • the configured authorization condition is fulfilled.
(3)

The end-user has to choose a display name for the registered FIDO Authenticator. The display name later helps the end-user (or the helpdesk) to identify the authenticator – this is especially important if a user registers multiple authenticators.

(4)

IAM sends a FIDO registration challenge to the FIDO client (browser or mobile app).

The challenge and a set of constraints for accepted FIDO Authenticators are sent to the FIDO client. The constraints depend on the FIDO settings in the configuration.

  • They include:
  • Signature algorithm constraints.
  • List of excluded FIDO Authenticators (e.g. already registered ones).
  • User verification preferences.
  • Type of authenticator (platform or cross-platform).
  • Whether FIDO passwordless must be supported.
  • FIDO attestation preferences.
(5)

The browser interacts with the user and the FIDO Authenticator to retrieve the response to the challenge, and it sends the response back to Airlock IAM.

If multiple suitable FIDO authenticators are available to the FIDO client, a selection dialog is presented to the end-user.

(5)

Airlock IAM verifies the response to the challenge and checks whether all FIDO Authenticator constraints are met. The verification details depend on the FIDO configuration settings in Airlock IAM.

If the verification succeeds, the FIDO credential is stored in the IAM user database and a confirmation is sent to the caller.

Arbitrary other steps may be added before and/or after the FIDO registration step in the self-service flow.

You may, for example, add another 2nd factor (e.g. Airlock 2FA) to further secure the FIDO registration flow.

Limitations

The following limitations apply in FIDO token migration.

  • FIDO is only supported by the Loginapp REST UI and the Loginapp REST API (not by the Loginapp (JSP)).
  • FIDO authenticators must support resident keys for (later) passwordless authentication. This can be enforced during FIDO registration (token migration and self-service) and enabled in the FIDO settings in the IAM configuration.
  • Not all FIDO Attestation statement formats are supported by Airlock IAM. Please review the set of supported formats in the documentation of the FIDO attestation verifying plugin in the FIDO settings.
  • There are no end-user self-services to list or edit registered FIDO authenticators. The only protected self-service is the one to register new FIDO authenticators. Registered FIDO authenticators can only be managed using the IAM Adminapp (or its Adminapp REST API).