Creating a white label service
What is a "white label service" ?
It's a fully customizable offer in the TrustBuilder MFA strong authentication cloud service.
It differs from our "standard service", which is built around Virtual Authenticator and TrustBuilder Authenticator mobile app.
For White label service, the authentication tools are different:
Helium
as a browser token, which can be deeply customized (look, colors, logo, templates,...).mAccess-based mobile application
as a mobile token. It means you'll have to develop you own application, or integrate our MFA library into an existing one to use mobile authentication.
As a consequence, please note that you won't be able to use Virtual Authenticator or the TrustBuilder Authenticator mobile app in a white label service.
Availability
White label service creation is only available to "Enterprise" or "Safe Transactions" clients
Where to start?
In the Administration console, select "Add a white label service" in the service "drop-down menu" displaying your service ID at the top of the page.
Setting up your service preferences
After defining your service name you have to select your preferences to build your service:
Global Helium and mAccess settings
Authentication mode
Without password: user's password is not required to generate an OTP
With password: user's password is required to generate an OTP
Password format
You can select here the format of the password. According to your needs this can be either an alphanumeric password or a PIN code with 4 to 8 digits.
Number of retries before locking password
You can define here the maximum number of tries a user may attempt with his password or PIN code, before locking his access.
Helium (browser)
Activated
Users will be able to connect to the "Secure Sites" and applications with Helium.
Authentication with notifications allowed:
If you activate this option, your users will be able to authenticate with Helium via mobile notifications
Authentication with notifications only:
If you activate this option, your users will be able to authenticate with Helium but ONLY via mobile notifications
Maximum number of devices
You can define here the maximum number 'Helium' instances a service user will be able to activate.
General settings
Password settings
Email password recovery:
If you activate this option, your users will be able to directly receive recovery codes on their email address to reset their password.
Other settings
Activate a new device per email:
If you activate this option, your users will be able to activate new devices directly from your website or application, by generating new 'Secure Site IDs' they will receive on their email address and without using My Account or TrustBuilder Authenticator on their mobile phone.
User login policy:
Real user logins are in use: if real user logins are used in the Provisioning Web Services and Management Console, TrustBuilder application can automatically insert the login of a user during the authentication procedure
User logins are aliases: if logins used in Provisioning and Management tools are aliases, the user will have to manually insert his/her login during the authentication procedure
Maximum number of devices of all types:
You can define here the maximum number of 'authentication' devices, (phone or browser) a service user will be able to register for his account.
Activate IP filtering (option):
Activate the filtering of IP addresses that will have access to TrustBuilder Web Services.
Authorized IP addresses (option):
You can define a list of authorized addresses here, using a semicolon-separated list of IP addresses.
(IP addresses of the authentication web server)
Once you have created your service, you'll have a new service ID, displayed in the "drop-down menu" at the top of the page.
Managing Service parameters
After the creation of your service you can still change your initial service settings or add more specifications in the "Manage service parameters" tab.
You will have the following settings you can adjust :
Parameters
mAccess activation
mAccess activation allows you to add the SDK to your client applications (MFA library for mobile authentication)
Maximum number of mAccess based devices
You can define here the maximum number of mAccess based applications, a service user will be able to activate.
Authentication with biometrics allowed:
Allows users to use their fingerprint to authenticate with the application instead of their password (It should be implemented by the appropriate mAccess functions in your code/Application)
Authentication with biometrics only:
If you activate this option, your users will be restricted to authenticate with their fingerprint only (This is only possible if the service has been set without password)
Transaction sealing
This option allows you to use mAccess to seal transactions with your application.
Connected OTP
If activated, authentication requests with connected OTP are accepted. If not activated, they are refused.
Connected OTP format
You can choose the format based on what your authentication interface supports.
Choose OTP length according to the security level required, meaning the probability of finding the correct OTP by luck or brute force: the longer the OTP, the safer it is.
Connected OTP validity duration (sec.)
You can define here the duration of validity for online generated (connected) OTPs. In case of complex network infrastructures operating numerous network equipments it might be useful to set this duration to a higher value. This guarantees that the OTP is still valid when submitted to TrustBuilder servers for the final verification.
Offline OTP
If activated, authentication requests with offine OTP are accepted. If not activated, they are refused.
Offline OTP format
Choose OTP length and complexity according to the security level required, meaning the probability of finding the correct OTP by luck or brute force: the longer the OTP, the safer it is.
mAccess timeout
This is the time in seconds during which your service doesn't request users to type their mAccess password again (for connected OTP only). To generate an offline OTP, users must type their password each time.
No PIN push allowed
Yes: the user's mAccess PIN or password is not required to authorize a connection request received via push notifications.
No: the user's mAccess PIN or password is required to authorize a connection request received via push notifications.
iPhone parameters
Settings to configure notifications for applications integrating the mAccess SDK for iOS with APNs.
Choose the certificate file.
Indicate whether it is a production certificate or a Sandbox certificate.
Enter the certificate password
Enter the AppID.
Android parameters
These parameters were used for GCM (Google Cloud Messaging) configuration which is now obsolete. They have been replaced by the Firebase parameters section.
Windows Phone parameters
No longer relevant. Deprecated.
Firebase parameters
Settings to configure Firebase notifications for applications integrating the mAccess SDK.
Active Firebase API:
None: no push is sent to mAccess (can be used to protect against push bombing attacks, for example).
Legacy API: (deprecated as of June 2024) push notifications are sent to mAccess - The Firebase Server Key is mandatory.
V1 API: push notifications are sent to mAccess - a JSON file from the Firebase console is mandatory.
Firebase Server Key: was specific to Android with Firebase Legacy API (now deprecated).
Serviceaccount (JSON): the content of the JSON file containing the private key for your project.
Notification Collapse Key (Optional): When several notifications are sent in a short period of time, it allows these notifications to be aggregated.
Application Package Name: was specific to Android with Firebase Legacy API (now deprecated).
Integration
After creating your "White label service" you can consult Helium integration documentation to help you with your integration.