Skip to main content
Version: 2.4.x.x Java 8 ELS

Deployment Scenarios

This section describes different deployments based on different general scenarios. The contents of this document are presented without getting into many details and are complementary with those of the operation use cases (such as the In-Band Authentication), which are more detailed. Actually, every one of the operation use cases can be implemented in the deployments described below.

Because of the manifold configuration and deployment options, it is important to understand the process when determining the correct solution based on the posed requirements. It is recommended to follow these outlined steps to ascertain the correct configuration.

  1. Identify the use cases which need different authentication policies in one application.
  2. Create nevisFIDO instances for every identified use case.
  3. Ensure that every nevisFIDO instance has its corresponding nevisAuth FidoUafAuthState connecting to it.
  4. Let the instances share the AppID, and ensure they connect to the same IDM client.
  5. Adjust each nevisFIDO instances' policy file to represent the use case it is responsible for handling.

FIDO Policy Determined by User Role​

In a scenario where the policy to be used is determined by the role of a user, deployment configurations come into play as well. Let's assume users are able to having different roles accessing a system, for example administrators might have stronger authentication requirement than non-administrative users. In such a scenario, separate nevisFIDO instances must be configured each supplying the policy configuration required for the users role. Using the correct nevisFIDO instance during authentication is in the duty of the nevisAuth component by configuring a role-based authentication flow.

Different authenticators with different policies

One Authenticator for Multiple Applications​

Another likely scenario is one where one authenticator can be used to authenticate against different applications (the same authenticator is used to generate different credentials). In such a case it's also required to create separate nevisFIDO instances and to configure them each with their own AppID.

One authenticator for different applications

Single Sign-on​

The previous scenario can be taken a step further: not only the same authenticator is used to provide access to different applications, but the same FIDO credentials generated by this authenticator are shared. Moreover, if a user has authenticated to one of the applications, then the user has access to the other applications without having to provide authentication again (single sign-on). nevisProxy provides single sign-on capabilities using the notion of Realms (or SSO domain). If several resources (i.e. applications) are protected using the same realm/domain, when authenticating to access one of the applications associated with the domain, the user will be allowed to access the other applications in the SSO domain without providing authentication again. Using the same nevisFIDO instance for all the applications implies that all the applications share the same authentication policy.

The different applications share the same AppID, but each of the applications will have its own Facet. This is a case where the notion of Facet goes beyond the idea of separating applications based on the operating system: multiple applications for Android with a different role can use the same FIDO UAF AppID. For instance a company might have separate internal applications: one for a calendar and another one related to human resources; both however can be used with the same credentials and provide single sign-on access.

In the diagram below, 3 applications are protected by the same domain, which uses the same nevisFIDO instance (and thus the same FIDO UAF credentials).

One authenticator for different applications - with realm

One nevisIDM Client Multiple Organisational Units​

A quite nevisIDM specific example is a situation where multiple organisational units exist all bound to one nevisIDM client and FIDO registration should be restricted to one of these organisational units.

The following scenario is assumed: One client "Bank" consists of two organisational units; "Private Customers" and "Business Customers". The requirements state that only users in the "Business Customers" OU are allowed to register FIDO authentication.

Client and Organisational Unit(s) Example

As the nevisFIDO component itself is unaware of the concept of organisational units, a setup similar to the first example must be chosen:

One nevisIDM client multiple organisational units

This setup can be achieved by using (for example) the IDM IdmGetPropertiesState. Based on that different nevisAuth flows can be configured based on the organisational unit.