Audience

This document is aimed at enterprises deploying Movenda Egomet for strong authentication.
It is intended to provide guidance to architects and developers on how to integrate Movenda Egomet and existing IT Services provided through Web Applications or Mobile Apps.

Introduction

The FIDO UAF (Universal Authentication Framework) standard was created for password-less solutions relying on elements categorized as possession (the FIDO Authenticator), knowledge (Authenticator PIN) and/or inherence (the biometric characteristic supported by the authenticator).

The biometric verification is used as an initial factor to then unlock a second, more secure factor: a private criptographic key that works “behind the scenes” to authenticate a user to the service. Since biometrics and criptographics keys are stored on local devices and never sent across the network - eliminating shared secret - user credentials are secure even if service provider get hacked, thereby eliminating the possibility of scalable data breaches.

FIDO Authenticators generates and securely hold the user’s asymmetric key pair for each bound IT Service: the private key is used to sign cryptograms exchanged with FIDO Server, eventually making them verified on server side using user’s public key.

FIDO standard supports out-of-the-box the transaction confirmation mechanism: the server will send to the FIDO Authenticator a challenge and the transaction details. The authenticator will display the transaction details and ask the user to confirm the transaction, for example by scanning a fingerprint.
This will cause the authenticator to sign the challenge and the transaction details with its private key and return the signature to the server.

Use cases

Here follows common use cases which help better to understand how Movenda Egomet works and how to integrate it.

Relying parties (AKA Service Providers) can leverage on Multi Factor Authentication (MFA) in a simple and secure manner through the integration of Movenda Egomet.

Since there are far too many ways to integrate FIDO solutions with existing authentication flows, it is not possible to cover them all comprehensively here; here follows a couple integration model (direct and indirect) which outlines the core APIs calls; other integration models can be adopted in order to fulfill enterprises’ business and regulations requirements.

Some details have been voluntarily omitted in order to make the reading easier, thus focusing the essence of functioning of the system.

For a more detailed protocol description please read official documentation:

• FIDO UAF Architectural Overview
• FIDO UAF Protocol
• FIDO UAF Complete specifications

Enabling Webmail 2FA

Short description

Arnold wants to secure his access to webmail service (e.g.: webmail.acme.com) using 2FA instead of legacy credentials (username and password).

Actors

• End user
• Mobile App

Pre-Conditions

• User has an account for webmail service
• User has already enabled biometric verification on his smartphone

Post-Conditions

• 2FA is enabled for User’s account
• User’s private key is generated and stored into his smartphone

Normal flow

1. From App, User signs in using legacy credentials (username + password)
2. User taps “Register device”
3. App shows message “Do you want to register this device with https://webmail.acme.com?”
4. User approves through fingerprint verification
5. App shows “Registration complete”

Registration sequence diagram (direct model)

Registration sequence diagram (indirect model)

Passwordless 2FA Webmail access

Short description

Arnold wants to access to his webmail account using his laptop or desktop PC.

Actors

• End user
• Desktop Browser
• Mobile App

Pre-Conditions

• End user has already enabled 2FA using his Mobile App

Post-Conditions

• End user accesses to his account using 2FA

Normal flow

1. On Desktop, User opens the Browser and point at: “https://webmail.acme.com”
2. User enters username
3. Browser shows message “Approve sign in with Mobile App”
4. On Phone, App shows message “Sign in to https://webmail.acme.com?”
5. User approves through fingerprint verification
6. On Desktop, Browser shows restricted area

Web authentication sequence diagram (direct model)

Web authentication sequence diagram (indirect model)

Passwordless 2FA Mobile access

Short description

Arnold wants to access to his webmail account using his smartphone.

Actors

• End user
• Mobile App

Pre-Conditions

• End user has already enabled 2FA using his Mobile App

Post-Conditions

• End user accesses to his account using 2FA

Normal flow

1. User opens the App
2. App shows message “Sign in to https://webmail.acme.com?”
3. User approves through fingerprint verification
4. App shows restricted area

Mobile authentication sequence diagram (direct model)

Mobile authentication sequence diagram (indirect model)