Skip to main content
Version: 1.15.x.x LTS

Nevis Component Interaction

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

Nevis component interaction

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. As 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 of 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. Note that nevisFIDO can be configured to require client TLS (as shown in the diagrams). This means that only trusted clients (usually nevisAuth and nevisProxy) are allowed to access nevisFIDO. See the Security Considerations 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.

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. For instance, in the case of the In-Band Registration, nevisIDM is used to authenticate the user with existing credentials, but this is used in a way that is not specific to Nevis 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.

Nevis Mobile Authentication Solution - Trust

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.

Indirect trust between nevisFIDO and nevisAuth

Server private key Server private key.

Client private key Client private key.

Truststore containing public keys Truststore containing public keys.

Communication channel Communication channel. The arrow always points from the client to the server.

One-way TLS communication 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 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.

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:

ComponentTruststore contents
Client devicePublic key of nevisFIDO (if contacted directly and not through nevisProxy) and nevisProxy
nevisProxyPublic key of nevisAuth
nevisAuthPublic key of nevisProxy and nevisFIDO
nevisIDMPublic key of nevisFIDO
nevisFIDOPublic 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.