In-Band Registration

Description

Before a user can authenticate with the FIDO UAF protocol to access an application, FIDO UAF credentials must be created and stored both on the user's device and on the FIDO Server. This operation is called Registration. The security requirements of the application protected by the Nevis Mobile Authentication Solution define the nature of the authentication, which can be, for example, fingerprint, PIN/password, face recognition, or a combination of several authentication mechanisms.

Prerequisites

• The user's mobile client application, which is generating the credentials, has FIDO capabilities. It contains an embedded FIDO Client with access to one or several FIDO Authenticators.
• The user already has existing credentials (a password, for instance) that can be used to authenticate.
• Nevis is configured in such a way that only authenticated clients can register FIDO UAF credentials.
• The Mobile Client Device successfully executes a legacy authentication before starting the registration flow.

Example

1. The user launches the application on the mobile device. The application detects that there are no credentials and asks the user to start a registration.
2. The mobile application sends a request to register new FIDO credentials.
3. Nevis detects that the mobile application is not authenticated and now tries to register. Nevis asks the user to authenticate. This authentication must follow the security policy required to register new FIDO credentials (a password).
4. The user authenticates providing a password. Nevis allows the mobile application to perform the registration.
5. The mobile application sends a request to Nevis to do the registration.
6. Nevis responds by describing the authentication methods (fingerprint) allowed by the e-banking server application, which is protected by the Nevis Mobile Authentication Solution.
7. The user authenticates using an authenticator that complies with the requirements of the server application. New FIDO credentials are created on the client device.
8. The credentials are sent to Nevis.
9. The application stores the credentials and notifies the mobile application about the successful registration.

Technical Flow

info

The technical flow in the following figure explains the component interaction in detail. The step numbers in the next figure do not correlate with the simplified example above.

The numbers in the list correlate with the step numbers in the previous figure.

1. The Relying Party mobile authentication sends a GetUAFRequest to the Registration Request Service endpoint defined in nevisProxy.

   During this step, the mobile client accesses the same endpoint as in the legacy authentication step, but now with an existing authentication.

   info

   The legacy authentication step takes places before all other steps described in this table. You find the legacy authentication flow at the top of the previous figure. It does not have a number.

   The GetUAFRequest must be created with the operation set to "Reg".

   Endpoint: https://<nevisProxy-host>:<nevisProxy-port>/nevisfido/uaf/1.1/request/registration

   info

   This endpoint is an example of mapping nevisProxy to the nevisFIDO Registration Request Service endpoint.

   References:

   • nevisFIDO Reference Guide
   • GetUAFRequest Specification

2. nevisProxy includes the SecToken and the UserId into the forwarded request.The inclusion of the SecToken_ensures that nevisFIDO will receive the user information in a secure way. It also allows nevisFIDO to verify that an authentication has already been successfully completed. This information is necessary to initiate the FIDO registration. The_UserId is delegated to generate a correctly formatted authorization header.

3. nevisProxy forwards the GetUAFRequest to nevisFIDO.

   Endpoint: https://<nevisFIDO-host>:<nevisFIDO-port>/nevisfido/uaf/1.1/request/registration

   References:

   • nevisFIDO Reference Guide
   • GetUAFRequest Specification

4. The signature of the SecToken is verified by nevisFIDO, which thus ensures that a previous authentication has happened.nevisFIDO extracts the username from the Context of the GetUAFRequest. The username can be the user's extId or the loginId from nevisIDM - this is configurable.

5. nevisFIDO responds with a ReturnUAFRequest containing the generated RegistrationRequest. The RegistrationRequest contains policies that specify the requirements for the authenticators to be registered.nevisProxy forwards the ReturnUAFRequest to the Relying Party mobile application.

   References:

   • nevisFIDO Reference Guide
   • ReturnUAF Request Specification
   • RegistrationRequest Specification

6. The Relying Party mobile application triggers a request to fetch the trusted facets.The information accessible at the Facets Service endpoint helps FIDO clients to identify whether the application the user wants to access is an authorized facet of the protected application (for example, whether the e-banking app on the user's mobile phone is an authorized facet of the e-banking application).

   Endpoint: https://<nevisFIDO-host>:<nevisFIDO port>/nevisfido/uaf/1.1/facets

   References:

   • nevisFIDO Reference Guide
   • Facets Specification

7. nevisFIDO returns the trusted facets it maintains. nevisProxy forwards them to the FIDO client.

   References:

   • nevisFIDO Reference Guide
   • Trusted Facets Specification

8. The user authenticates in the device according to the policy that is provided in the RegistrationRequest.

9. The FIDO UAF authenticator generates the assertion that is proof of the authentication the user has completed in the previous step (9). The assertion contains the public key of the generated key material. For security reasons, it is signed by the attestation private key of the FIDO UAF authenticator. For more information about attestations, see the FIDO specification.

   References:

   • AuthenticatorRegistrationAssertion Specification
   • authenticator Attestation Specification
   • Registration Response Specification

10. The Relying Party mobile app sends a SendUAFResponse to the Registration Response Service endpoint defined in nevisProxy. The SendUAFResponse contains a RegistrationResponse. The RegistrationResponse contains the assertion, and thus the public key of the generated key material.

    Endpoint: https://<nevisFIDO-host>:<nevisFIDO-port>/nevisfido/uaf/1.1/registration

    References:

    • nevisFIDO Reference Guide
    • SendUafResponse Specification
    • RegistrationResponse Specification

11. nevisFIDO creates a FIDO credential containing the received public key. nevisFIDO stores the FIDO credential in nevisIDM, such that it is related to the relevant username.

12. nevisFIDO returns the ServerResponse to the Relying Party mobile application through nevisProxy. The ServerResponse contains information regarding whether the registration was successful. nevisFIDO concludes the operation. At this point, the Nevis Mobile Authentication Solution considers the registration as completed.

    References:

    • nevisFIDO Reference Guide
    • UAF Server Response Specification

Configuration Snippets

You will find example configuration snippets for all involved components in Nevis Component Configuration Examples.