Authentication procedures for accessing the interface - English
Authentication procedures for accessing the interface - English
This document presents the different authentication procedures for accessing the Eulerian interface. It describes the available connection methods, their prerequisites, their security rules, and the main associated use cases.
Users can access the interface via standard username and password authentication, reinforced if necessary by two-factor authentication (MFA) via SMS or TOTP through an authenticator app. The document also details how SAML2-based SSO authentication works, as well as fallback authentication options for specific accounts.
The objective is to provide a clear framework for support teams, administrators and webmasters to configure, understand and support users in the different scenarios of accessing the platform.
The settings are defined at the grid level and apply to all users of that grid.
Paramètre
Valeur par défaut
Description
IP limitation
Not activated
Restrict connections to one or more IP addresses
Attempts before blocking
5
Number of consecutive failures before account blocking
Unlocking time
30 minutes
Waiting time before being able to retry after being blocked
All login attempts, whether successful or unsuccessful, are tracked and accessible via the webmaster interface.
2. Standard authentication
Standard authentication relies on the username + password combination, with the following format rules.
Formatting rules
Identifier
Allowed alphanumeric characters
Allowed symbols: . - @ _
Minimum length: 3 characters
Password
Must contain at least: a symbol, a number, a lowercase letter, an uppercase letter
Minimum length: 8 characters
Reusing an old password is prohibited.
Storage: AES-256 encrypted
Advanced options (on request)
Hash/salt storage via Argon2
Force automatic password renewal every X days for all accounts
Connection flow
TD flowchart
A([Login page]) --> B[Enter username - email]
B --> C {Authentication type associated with the account?}
C -->|Standard / MFA / TOTP| D[Password Entry]
C -->|SSO| E[Redirection to SSO IdP]
D --> F{Valid password?}
F -->|No| D
F -->|Yes| G{2FA enabled?}
G -->|No| Z([Access granted])
G -->|MFA| H[Send SMS code]
G -->|TOTP| I[Application code request]
H --> J [Enter SMS code]
I --> K [TOTP code entry]
J --> L{Valid code?}
K --> L
L -->|No| M([Access denied])
L -->|Yes| Z
E --> N[Authentication with the IdP]
N --> Z
This method can be enhanced by two two-factor authentication options, which can be activated independently at the user account level.
Note: MFA and TOTP are mutually exclusive options. An account cannot activate both simultaneously.
2.1 MFA — SMS Authentication
Prerequisites
The user account must have a valid phone number entered: this information must be entered by support .
Activation
Activation is managed by the administrator or by support from the user account.
Connection flow with MFA
TD flowchart
A([Login page]) --> B[Enter username - email]
B --> C [System detects: MFA authentication required]
C --> D [Password entry]
D --> E{Valid password?}
E -->|No| D
E -->|Yes| F[Sending a unique code via SMS]
F --> G [Enter the code received by SMS]
G --> H{Valid code?}
H -->|No| I([Access denied])
H -->|Yes| J([Access granted])
Key points
The SMS code is for single use only and has a limited validity period.
Without a phone number provided, MFA cannot be activated on the account.
If the SMS is not received, it should be possible to resend the code from the interface.
2.2 TOTP — Application-based authentication
TOTP ( Time-based One-Time Password ) authentication relies on an authentication application installed on the user's phone (e.g., Google Authenticator, Authy, Microsoft Authenticator, etc.).
Prerequisites
The user must have a TOTP-compatible authentication application on their mobile device.
Activation (two-step procedure)
Activation is done from "Manage my account > Edit my information" .
Step 1 — Scan the QR Code
A QR code is generated and displayed in the interface. The user must scan it with their authentication application.
Step 2 — Confirm activation
After the scan, the user must enter the first set of codes displayed by their application to confirm that the connection is successfully established. Without this validation, TOTP activation is not completed.
TD flowchart
A([Manage my account - Edit my information]) --> B[Displaying QR Code]
B --> C [Scan the QR code with the authentication application]
C --> D ["Enter the first code displayed by the application ⚠️ REQUIRED"]
D --> E {Valid code?}
E -->|No| D
E -->|Yes| F([TOTP enabled on the account])
Connection flow with TOTP
TD flowchart
A([Login page]) --> B[Enter username - email]
B --> C [System detects: TOTP authentication required]
C --> D [Password entry]
D --> E{Invalid password?}
E -->|No| D
E -->|Yes| F[TOTP code request]
F --> G["Enter the code displayed by the application (renewed every 30 seconds)"]
G --> H{Valid code?}
H -->|No| I([Access denied])
H -->|Yes| J([Access granted])
Key points
The TOTP code is automatically renewed every 30 seconds .
Entering the first code during activation is mandatory to validate the connection.
In case of loss of access to the application (loss of phone, reinstallation), a recovery procedure must be provided by the administrator.
3. SSO Authentication
Single Sign-On (SSO) authentication allows users to log in via a centralized identity provider (IdP) using the SAML2 protocol. The identifier used is the email address (NAMEID) as defined in the SSO configuration.
The user must have been previously created in the interface by the webmaster, who must also grant them the necessary access rights for the relevant sites. Automatic account creation is not supported.
If you switch back from SSO authentication to standard authentication, then all passwords will need to be reset.
3.1 Global SSO — Entire Platform
When SSO is configured in global mode, it applies to all users of the platform, without exception.
Prerequisites
Each user must have an active account on the platform , with the email address corresponding exactly to the NAMEID declared in the SSO application as their identifier.
Users must be registered in the organization's SSO directory .
Global SSO login flow
TD flowchart
A([Login page]) --> B[Enter username - email]
B --> C [System detects: SSO authentication required]
C --> D [Redirection to the identity provider - IdP]
D --> E["Authentication with the IdP (according to the organization's policy)"]
E --> F [Return to the platform with SAML assertion]
F --> G {Existing account with the corresponding email NAMEID?}
G -->|Yes| H([Access granted])
G -->|No| I([Access denied, account does not exist on the platform])
Key points
In global SSO mode, no user can log in with a classic login/password, except for an explicitly configured exception (see section 2.2).
The email address of the account on the platform must exactly match the NAMEID provided by the IdP.
Password management is entirely delegated to the identity provider.
3.2 Accounts with fallback authentication - hybrid mode
In a global SSO context, some accounts can be configured to use fallback authentication (standard, MFA or TOTP), particularly for accounts of service providers or third parties who do not have access to the organization's SSO service.
Typical use case
External service providers
Service or technical accounts
Temporary users without IdP access
Available fallback methods
Méthode
Description
Standard
Login and password only
MFA
Login + password + SMS code
TOTP
Login + password + application code
Configuration
The activation of fallback authentication is done on an account-by-account basis by an administrator. It cannot be activated by the user themselves.
B --> C{Authentification type linked to account ?}
C -->|SSO no hybrid flow| D[Redirect to SSO IdP]
D --> E["IDP Authentification"]
E --> Z([Access granted])
C -->|Allowed hybrid mode standard / MFA / TOTP| F[Provide password]
F --> G{Password is valid ?}
G -->|No| F
G -->|Yes| H{2FA enabled ?}
H -->|No| Z
H -->|MFA| I[SMS code sent]
H -->|TOTP| J[Authentifcator app shown]
I --> K[SMS code provided]
J --> L[TOTP code provided]
K --> M{Code valid ?}
L --> M
M -->|No| N([Access denied])
M -->|Yes| Z
Key points
The coexistence of SSO and fallback authentication is managed at the individual account level , not at the global level.
The fallback accounts retain all additional security options (MFA, TOTP).
It is recommended to limit the number of accounts benefiting from fallback authentication to the bare minimum.
3.3 Configuration — Example with Google
The procedure below illustrates how to configure a SAML application via Google Workspace. For detailed steps on the Google side, refer to the official documentation: Google - SAML application .
Settings to enter in Google
Champ
Valeur
ACS URL
https://{grid}.ea.eulerian.com/login
Entity ID
eulerian (exact value, without variation)
Required SAML attributes
The SAML configuration must return the following attributes:- NAMEID : EMAIL address — must exactly match the account ID on the platform- email attribute- phone attribute- first name attribute- last name attribute
Finalization
Once the application is configured on the Google side, send themetadata file containing the identity provider information to support so that it can be declared on the platform side.
3.4 Known limitations
The following features are not currently supported :
Automatic account creation : the webmaster must manually create the account on the platform, ensuring that the NAMEID matches the login ID.
Deactivation via SCIM : an account cannot be deactivated from SCIM.
Automatic association with a SCIM group : if access restrictions to certain parts of the interface are desired, they must be configured manually for each account concerned.