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.
- Identify the use cases which need different authentication policies in one application.
- Create nevisFIDO instances for every identified use case.
- Ensure that every nevisFIDO instance has its corresponding nevisAuth
FidoUafAuthStateconnecting to it.
- Let the instances share the AppID, and ensure they connect to the same IDM client.
- 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.
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.
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 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.
As the nevisFIDO component itself is unaware of the concept of organisational units, a setup similar to the first example must be chosen:
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.