High-Level Architecture

To provide mobile authentication, Nevis Mobile Authentication relies on several Nevis components which contribute to the overall mobile authentication solution. The central components use are depicted in the following figure.

Within the Nevis architecture, nevisFIDO acts as a service to implement the FIDO UAF 1.1 specification standard.

The nevisFIDO component tightly integrates with other Nevis components to deliver the complete mobile authentication feature. In the sections that follow, we highlight briefly the functions of the subsystems that work together to ultimately deliver mobile authentication to the client device in the hands of a user.

Client Device

The client device represents the physical device owned by a user, e.g. a mobile phone. To use and benefit from Nevis Mobile Authentication, the client device requires a Relying Party mobile client to interact and authenticate against a Relying Party backend. The Relying Party mobile client consists of a Client (Business) Application and the FIDO Client.

Relying Party Backend

The relying party backend characterizes the group of components which in combination act together as the Relying Party backend of a FIDO Relying Party client. In the context of FIDO, communication between a FIDO Client and a FIDO Server always occur via the Relying Party client and Relying Party backend. In Nevis Mobile Authentication, it not only includes the necessary Nevis components described below but also the protected backend entity named Web application in the above figure.

Perimeter Infrastructure

nevisProxy

Towards the client-facing edge of the system, the nevisProxy component serves as the perimeter server. It's able to protect web applications from unauthenticated access and ensures that authentication takes place before requests are passed to those web applications. In Nevis Mobile Authentication, nevisProxy is configured to accept requests according to the FIDO UAF 1.1 protocol and forwards them to the authentication subsystem. As in all Nevis setups, additional functions of nevisProxy are web application firewall, session management (single sign-on), and reverse proxy functionality like routing and rerouting of requests to downstream components. In Nevis Mobile Authentication,o pevisProxy will route HTTP requests to the communication endpoints of nevisFIDO and nevisAuth, which in combination form the authentication subsystem.

Authentication

nevisFIDO

At the core of the system, the nevisFIDO component is a specification-compliant implementation of a [FIDO Server], but in such cases, the client is expected to possess an existing Nevis authentication.

nevisAuth

Participating in the Nevis Mobile Authentication solution, nevisAuth acts as bridge between the [FIDO Client] and the FIDO Server, making up for the Nevis authentication specific details nevisFIDO cannot account for. As usual,d tevisAuth is used to implement sophisticated authentication flows, including flows that rely on IAM provided byd tevisIDM. It does not deal with FIDO UAF protocol level messages but dispatches them to nevisFIDO, delegating the authentication to that component.

Identity Management

nevisIDM

In the context of Nevis Mobile Authentication, nevisIDM is acting as a persistent storage of FIDO UAF authenticator credentials. With every user-performed registration on a client device that takes part in Nevis Mobile Authentication, cryptographic information such as an authenticators public key are stored in nevisIDM.

Third Party Backend

The third party backend characterizes components that are not part of either the Relying Party Backend or the Client Device. Usually these components are located outside the managed infrastructure.

Push Service Provider

Nevis Mobile Authentication uses push service providers to send push messages to Relying Party Mobile Clients. Push messages are used in out-of-band scenarios to allow communication with a Relying Party Mobile Client without the need to open a channel beforehand.