[Airlock] How-to: Set up Futurae for a customer

Recent article updates:

18 June 2020 - Added Recommended Setup and Overview about Organization, Services and Users.

16 June 2020 - Added explanation about how each Futurae Service is configured to work only with a specified app, and how user migration can be facilitated.

7 May 2020 - It is now possible for Command & Control (formerly Futurae Admin) owners to add existing Futurae Admin users as collaborators in an Organization, without the need to contact Futurae Support.

9 February 2022 - Updated the article to reflect the fact that certain features can be switched on/off directly via Command & Control.

This is a guide for all our Ergon and integration partner friends who will be tasked with setting up Futurae authentication for new or existing customers (or even for internal purposes), which use Airlock as their favorite IAM platform.

This article contains the following sections, which should serve as your checklist:

• Define customer requirements
• Setup access on Command & Control
  • Recommended Setup
• Configure Airlock with Futurae API credentials
• Configure additional Service-level features 

IMPORTANT: When communicating to Futurae Support, always mention the Service ID to which you are referring to. NEVER share any Key (Auth API Key, Admin API Key, Web Key, etc.) with Futurae Support.

Define customer requirements

Depending on the requirements of a customer user case, there are certain configuration steps that Futurae might have to perform in order to make sure that the desired customer setup works as expected. Hence, it is necessary that these requirements are communicated to Futurae. 

We list the most important requirements below.

Type of authenticator app

What type of authenticator app will the customer use? There are a few alternatives:

• Futurae secure app
• Airlock 2FA app
• Futurae white label app for customer
• Futurae SDK integrated in customer's app

Each Futurae Service is designed to work only with a specific authenticator app. By default, a Futurae Service is configured to work with the Futurae secure app. To demonstrate what this implies, say for example that you create a Futurae Service (eg named "BankA") that is meant to work with another app, such as the Airlock 2FA app. Initially, BankA will work with the Futurae app, and let's assume that some users already use the Futurae app to enroll in this Service. At some point, Ergon needs to notify Futurae to make the switch, in other words, configure BankA to work with the Airlock 2FA app.

Once the switch happens the following will be true:

• Existing users that had previously enrolled with the Futurae app, can still use the Futurae app to authenticate.
• New activations are only allowed with the Airlock 2FA app (ie if you scan an activation QR code with the Futurae app you will get an error).

The above allows for all users to eventually migrate to the Airlock 2FA app, while at the same time not impacting users that haven't migrated yet.

Types of Futurae authentication technologies

Which of the following authentication technologies will the customer use? 

• Standard authentication (One-Touch, Offline/Online QR code etc)
• Single device authentication
  • Single app: main/business app acts as the authenticator app
  • Dual app: main/business app is separate from the authenticator app 
• Hardware tokens
  • QR code
  • TOTP

See also further below for some additional features that can be configured depending on the customer requirements.

Setup access on Command & Control

Command & Control gives you access to basic configuration and administrative functionality, such as creating Futurae Services and retrieving the corresponding API credentials, which are needed for configuring Airlock. We encourage you to first look at the overview on Organization, Services, and Users.

Each customer (e.g. Bank A, Bank B) must correspond to a different Command & Control Organization and each Organization can have one or more Futurae Services, each with its own set of API credentials. Multiple Futurae Services can be created and used for serving different customer applications (or Airlock instances) and also different environments (e.g. test, staging, production etc) of a particular customer application. 

The Owner of an Organization in Command & Control has access to all available functionality and can see, manage and create new Futurae Services, as well as invite collaborators who need access to the particular Organization. Collaborators can be invited as Owners, or alternatively, as Admin or Support. Admin and Support roles have access only to the Services that are assigned to, by the Owner. The main difference between Admin and Support roles is that an Admin has access to the Service's settings, and hence to the API credentials.

A user account in Command & Control will be able to participate in multiple Organization at the same time.

• For Organization owners who want to add collaborators to co-manage the Organization: You can freely add (and remove) other users as collaborators by specifying their email address. If the specified email address is not already registered as an account in Command & Control, the user will receive an invitation to sign up.
• For users that already have an account on Command & Control and need to create and manage an additional Organization: please contact Futurae Support, and we will set it up for you.

Recommended setup

For a specific Customer, we recommend and strongly encourage you to adhere to the following setup:

1. Create an Organization for that specific Customer (e.g., Customer AG) -- to do so please write an e-mail to support@futurae.com
2. Invite as Collaborators (Admin) anyone at Ergon that will support the Partner or the Customer with setting up the Airlock IAM
3. Create the same amount of Services as the Customer instances (e.g.: IMP, TST, PROD should be reflected into three Services in the Command & Control). This is best practice for security as well as SLA reasons.
4. Communicate to Futurae Support which of these services (if any) need to be set up to work with specific White Label Apps, Airlock 2FA App, Futurae App, SDKs.
5. [optional] If a Partner organization needs to provide support to Customer, you can invite Partner's employees as "support" collaborators to the Organization (they will not be able to see any keys, only users and devices), and specify which Services they will be able to get access to.

Configure Airlock with Futurae API credentials

In order to configure an Airlock instance to work with Futurae, you will need the corresponding API information and credentials which will enable Airlock to communicate with the Futurae backend. In particular you will need the following information:

• Service ID
• Auth API key
• Admin API key
• Base URL

You can find the above information by selecting the desired Service on the leftmost sidebar of the Command & Control interface and then clicking the Settings of the selected Service.

Configure additional Service-level features

There are a few additional features which can be configured for each Futurae Service (in other words these features affect all the users of a Service). Futurae gives you access to a set of different features and settings to tailor specific needs, refer to Settings >> Configuration at Command & Control for a selected Service.

The Service features are listed below.

If enabled, then upon tapping "Approve" within the authenticator app, in order to authorize a login or transaction confirmation request, the user will be prompted to authenticate themselves using the device's configured lock mechanism, e.g. biometrics, PIN etc.

If disabled, then this extra verification check upon tapping "Approve" will be skipped.

Default: Enabled

If enabled, it allows the user to override the Service User Verification setting in the authenticator app.

If disabled, then the user will not have the capability to change User Verification settings configured at the Service level.

Default: Disabled

If enabled, Futurae will maintain an audit log of all transaction authentication requests, as per your retention requirements.

If disabled, then no transaction audit log with explicit retention requirements will be kept.

Default: Disabled