Nevis Component Interaction

The diagram shows how the different Nevis components interact with each other.

Interaction Between the Nevis Components

nevisProxy

The nevisProxy component interacts directly with both the outside world, which is mobile and other clients, as well as with the Nevis authentication components.s ws is shown in the diagram, nevisProxy communicates using secure HTTP carrying FIDO UAF Protocol messages (or an internal SOAP protocol for nevisProxy/nevisAuth communication).

nevisAuth

nevisAuth interacts with nevisFIDO using the FidoUafAuthState. FidoUafAuthState acts as an HTTP client which sends JSON messages through an HTTPS connection to nevisFIDO. nevisAuth and nevisProxy interact using the proprietary inter-component SOAP interface on top of an HTTPS channel.

nevisFIDO

The nevisFIDO component lies at the center of Nevis Mobile Authentication and thus communicates directly with all the other Nevis Mobile Authentication components:

• nevisProxy forwards FIDO UAF Protocol messages (RegistrationRequest, etc., and the related JSON extensions) to nevisFIDO. FIDO UAF uses a protocol based on JSON messages, exposed via an HTTP API.
• nevisAuth interfaces with nevisFIDO using the HTTP API. The function of nevisAuth vis-à-vis nevisFIDO is that of a client: nevisAuth sends requests to nevisFIDO during its handling of the FidoUafAuthState.
• nevisIDM is accessed using client TLS. This component only serves as persistent storage that is used by nevisFIDO.
• If a persisted session and token storage is in use, nevisFIDO connects to a MariaDB instance using JDBC.

All channels shown in the diagram are secured as explained in Component Trust Model section for more information regarding requiring client TLS in nevisFIDO.

For further details on all of these component interactions refer to the nevisFIDO Reference Guide.

nevisIDM

nevisFIDO uses the nevisIDM admin interfaces' SOAP interface to create, delete and query credentials.

info

In the diagram the interactions between nevisIDM and nevisAuth are not included for the sake of simplicity, as they are not a necessary part of the FIDO authentication. Note however that in some use cases, nevisIDM interacts with nevisAuth.e nor instance, in the case of the In-Band Registration, nevM is used to authenticate the user with existing credentials, but this is used in a way that is not specific to Nes Mobile Authentication: the registration service of nevisFIDO is protected using nevisIDM credentials as any other resource can be protected using nevisProxy and nevisAuth.

nevisLogRend

nevisLogRend is responsible for providing the login pages to a user agent, that is, for displaying the user-facing login flow in Nevis Mobile Authentication login scenarios.

Component Trust Model

The different entities that take part in Nevis Mobile Authentication communicate with each others using the HTTP protocol. To keep the communication secure, Transport Layer Security (TLS) is used for confidentiality and authenticity. This section describes how the different elements trust each other from a cryptographic perspective at TLS-level.

In some cases access to nevisFIDO must be protected. For instance the user must authenticate before being allowed to perform a FIDO UAF registration. In this case a trust relationship of another nature is required: nevisFIDO must be aware that the user has been authenticated. This is done using a SecToken: when the authentication is done, a SecToken is issued by nevisAuth, which is signed by a private key it possess. The SecToken is sent to nevisFIDO, which verifies that it was actually signed by the nevisAuth instance using a truststore containing the public key of the certificate used to sign it.

Icon	Description
	Server private key
	Client private key
	Truststore containing public keys
	Communication channel. The arrow always points from the client to the server.
	One-way TLS communication: the server's identity is validated by the client using the contents of the truststore, which contains the server's public key. The server is the only element that is authenticated here (the client is not authenticated with the server). The communication is encrypted with the server's private key.
	Two-way TLS or TLS client communication: both the client and the server have a private key. They mutually authenticate with each other using their private keys. Both have truststores with the public key of the server and client respectively. The communication is encrypted with the server's private key.

info

All components possess truststores to verify the private keys, but for the sake of simplicity they are left out of the diagram. The following table describes the contents of the truststore for each entity:

Component	Truststore contents
Client device	Public key of nevisFIDO (if contacted directly and not through nevisProxy) and nevisProxy
nevisProxy	Public key of nevisAuth
nevisAuth	Public key of nevisProxy and nevisFIDO
nevisIDM	Public key of nevisFIDO
nevisFIDO	Public key of nevisAuth (for signature verification, see below) and nevisIDM. If client TLS is required, the truststore also contains the public key of the nevisProxy and nevisAuth client certificates.