Skip to main content
Version: 2.8.x.x RR

Multiple Backend Support

The Nevis Access App can handle multiple backends provided they are sharing the same HTTP API configuration.

Use Cases​

This feature is useful for several scenarios:

  • Allow applications supporting multiple accounts to have those accounts defined in different servers. For example: an application can handle simultaneously accounts geographically distributed or that are defined in organisations using different backends.
  • Providing internal app testers an easy way to test the Access App with several backends sharing the same configuration. For example: production, integration and user acceptance testing backends.
  • Allowing the Apple App store verification, which requires manual testing by Apple, to test against a backend system not containing production data and accounts.
  • Offering a single Access App for end-users which can work with more than one backend. For example: trial and production instances.
Different backends with same access app

For this purpose, the Access App configuration holds a whitelist of backend URL domains, with which the application is allowed to communicate. For the detailed configuration information, see the Domain White List chapter in Ordering an Access App.

Limitations​

This feature has several important limitations:

  • The identifier of the user (labeled Technical ID in the Access App Settings, which is the username in the FIDO UAF terminology) have to be unique across servers. In other words, two accounts defined in two different servers cannot have the same identifier.

    This limitation is only relevant if you are using the Nevis Identity Suite. If the Nevis Authentication Cloud is being used, the username uniqueness is guaranteed.

  • All backends must share the same "base configuration" of HTTP API endpoint paths.

    This limitation is only relevant if you are using the Nevis Identity Suite. If the Nevis Authentication Cloud is being used, all backends have the same HTTP endpoints.

  • In case push messages are used, the backend systems has to share the same Firebase project.

The main difference between the various configured (e.g whitelisted) backends is the domain the backends are served under.

Behavior Change with Access App Version 2.8 and newer​

From version 2.1 of the Access App, the application allows configuring multiple backends. In versions 2.7 and earlier the Access App could only have accounts defined in a single server.

The Access App used a "lock" mechanism to handle this: during the first registration, the end-user was able to register in any of the backends defined in the configuration. Once the first registration completed successfully, the Access App was locked to the backend associated with the first registration, and that backend was used for all future operations.

Starting with Access App version 2.8, the behavior is different: the user can have accounts in different backends. The application does no longer "lock" itself to one of the configured backends.