Procédures d'authentification pour accéder à l'interface
Procédures d'authentification pour accéder à l'interface
Cette fiche présente les différentes procédures d’authentification permettant d’accéder à l’interface Eulerian. Elle décrit les modes de connexion disponibles, leurs prérequis, leurs règles de sécurité ainsi que les principaux cas d’usage associés.
Les utilisateurs peuvent accéder à l’interface via une authentification standard par identifiant et mot de passe, renforcée si nécessaire par une double authentification MFA par SMS ou TOTP via une application d’authentification. La fiche détaille également le fonctionnement de l’authentification SSO basée sur SAML2, ainsi que les possibilités d’authentification de repli pour certains comptes spécifiques.
L’objectif est de fournir un cadre clair aux équipes support, administrateurs et webmasters afin de configurer, comprendre et accompagner les utilisateurs dans les différents scénarios d’accès à la plateforme.
Les paramétrages sont définis au niveau d'un grid et s'appliquent à tous les utilisateurs de ce grid.
Paramètre
Valeur par défaut
Description
Limitation par IP
Non activée
Restreindre les connexions à une ou plusieurs adresses IP
Tentatives avant blocage
5
Nombre d'échecs consécutifs avant blocage du compte
Délai de déblocage
30 minutes
Temps d'attente avant de pouvoir réessayer après blocage
Toutes les tentatives de connexion, qu'elles soient en succès ou en échec, sont tracées et accessibles via l'interface webmaster.
2. Authentification standard
L'authentification standard repose sur la combinaison identifiant + mot de passe, avec les règles de format suivantes.
Règles de format
Identifiant
Caractères alphanumériques autorisés
Symboles autorisés : . - @ _
Longueur minimale : 3 caractères
Mot de passe
Doit contenir au moins : un symbole, un chiffre, une lettre minuscule, une lettre majuscule
Longueur minimale : 8 caractères
La réutilisation d'un ancien mot de passe est interdite
Stockage : chiffré en AES-256
Options avancées (sur demande)
Stockage en hashé/salté via Argon2
Forcer le renouvellement du mot de passe automatiquement tous les X jours pour tous les comptes
Flux de connexion
flowchart TD
A([Page de connexion]) --> B[Saisie de l'identifiant - email]
B --> C{Type d'authentification associé au compte ?}
C -->|Standard / MFA / TOTP| D[Saisie du mot de passe]
C -->|SSO| E[Redirection vers l'IdP SSO]
D --> F{Mot de passe valide ?}
F -->|Non| D
F -->|Oui| G{2FA activé ?}
G -->|Non| Z([Accès accordé])
G -->|MFA| H[Envoi code SMS]
G -->|TOTP| I[Demande code application]
H --> J[Saisie du code SMS]
I --> K[Saisie du code TOTP]
J --> L{Code valide ?}
K --> L
L -->|Non| M([Accès refusé])
L -->|Oui| Z
E --> N[Authentification auprès de l'IdP]
N --> Z
Cette méthode peut être renforcée par deux options d'authentification à deux facteurs, activables indépendamment au niveau du compte utilisateur.
Note : MFA et TOTP sont des options exclusives l'une de l'autre. Un compte ne peut pas activer les deux simultanément.
2.1 MFA — Authentification par SMS
Prérequis
Le compte utilisateur doit avoir un numéro de téléphone valide renseigné : cette information doit être saisie par le support.
Activation
L'activation est gérée par l'administrateur ou par le support depuis le compte utilisateur.
Flux de connexion avec MFA
flowchart TD
A([Page de connexion]) --> B[Saisie de l'identifiant - email]
B --> C[Système détecte : authentification MFA requise]
C --> D[Saisie du mot de passe]
D --> E{Mot de passe valide ?}
E -->|Non| D
E -->|Oui| F[Envoi d'un code unique par SMS]
F --> G[Saisie du code reçu par SMS]
G --> H{Code valide ?}
H -->|Non| I([Accès refusé])
H -->|Oui| J([Accès accordé])
Points importants
Le code SMS est à usage unique et a une durée de validité limitée.
Sans numéro de téléphone renseigné, le MFA ne peut pas être activé sur le compte.
En cas de non-réception du SMS, un renvoi du code doit être possible depuis l'interface.
2.2 TOTP — Authentification par application
L'authentification TOTP (Time-based One-Time Password) repose sur une application d'authentification installée sur le téléphone de l'utilisateur (ex. : Google Authenticator, Authy, Microsoft Authenticator, etc.).
Prérequis
L'utilisateur doit disposer d'une application d'authentification compatible TOTP sur son appareil mobile.
Activation (procédure en deux étapes)
L'activation se fait depuis « Gérer mon compte > Modifier mes informations ».
Étape 1 — Scanner le QR Code
Un QR Code est généré et affiché dans l'interface. L'utilisateur doit le scanner avec son application d'authentification.
Étape 2 — Valider l'activation
Après le scan, l'utilisateur doit obligatoirement saisir la première série de codes affichée par son application afin de confirmer que la liaison est correctement établie. Sans cette validation, l'activation TOTP n'est pas finalisée.
flowchart TD
A([Gérer mon compte - Modifier mes informations]) --> B[Affichage du QR Code]
B --> C[Scan du QR Code avec l'application d'authentification]
C --> D["Saisie du premier code affiché par l'application ⚠️ OBLIGATOIRE"]
D --> E{Code valide ?}
E -->|Non| D
E -->|Oui| F([TOTP activé sur le compte])
Flux de connexion avec TOTP
flowchart TD
A([Page de connexion]) --> B[Saisie de l'identifiant - email]
B --> C[Système détecte : authentification TOTP requise]
C --> D[Saisie du mot de passe]
D --> E{Mot de passe\nvalide ?}
E -->|Non| D
E -->|Oui| F[Demande du code TOTP]
F --> G["Saisie du code affiché par l'application (renouvelé toutes les 30 s)"]
G --> H{Code valide ?}
H -->|Non| I([Accès refusé])
H -->|Oui| J([Accès accordé])
Points importants
Le code TOTP est renouvelé automatiquement toutes les 30 secondes.
La saisie du premier code lors de l'activation est obligatoire pour valider la liaison.
En cas de perte d'accès à l'application (perte du téléphone, réinstallation), une procédure de récupération doit être prévue par l'administrateur.
3. Authentification SSO
L'authentification SSO (Single Sign-On) permet aux utilisateurs de se connecter via un fournisseur d'identité centralisé (IdP), en utilisant le protocole SAML2. L'identifiant utilisé est l'adresse e-mail (NAMEID) telle que définie dans la configuration SSO.
L'utilisateur doit impérativement avoir été créé au préalable dans l'interface par le webmaster, qui doit également lui associer les droits d'accès nécessaires pour les sites concernés. La création automatique de compte n'est pas supportée.
Si vous rebasculez de l'authentification SSO à une authentification standard, alors tous les mots de passe devront être réinitialisés.
3.1 SSO global — Plateforme entière
Lorsque le SSO est configuré en mode global, il s'applique à l'ensemble des utilisateurs de la plateforme, sans exception.
Prérequis
Chaque utilisateur doit disposer d'un compte actif sur la plateforme, avec comme identifiant l'adresse e-mail correspondant exactement au NAMEID déclaré dans l'applicatif SSO.
Les utilisateurs doivent être enregistrés dans l'annuaire SSO de l'organisation.
Flux de connexion SSO global
flowchart TD
A([Page de connexion]) --> B[Saisie de l'identifiant - email]
B --> C[Système détecte : authentification SSO requise]
C --> D[Redirection vers le fournisseur d'identité - IdP]
D --> E["Authentification auprès de l'IdP (selon la politique de l'organisation)"]
E --> F[Retour sur la plateforme avec assertion SAML]
F --> G{Compte existant avec l'email NAMEID correspondant ?}
G -->|Oui| H([Accès accordé])
G -->|Non| I([Accès refusé compte inexistant sur la plateforme])
Points importants
En mode SSO global, aucun utilisateur ne peut se connecter avec un login/mot de passe classique, sauf exception explicitement configurée (voir section 2.2).
L'adresse email du compte sur la plateforme doit correspondre exactement au NAMEID fourni par l'IdP.
La gestion des mots de passe est déléguée entièrement au fournisseur d'identité.
3.2 Comptes avec authentification de repli - mode hybride
Dans un contexte SSO global, certains comptes peuvent être configurés pour utiliser une authentification de repli (standard, MFA ou TOTP), notamment pour des comptes de prestataires ou de tiers n'ayant pas accès au service SSO de l'organisation.
Cas d'usage typique
Prestataires externes
Comptes de service ou techniques
Utilisateurs temporaires sans accès à l'IdP
Méthodes de repli disponibles
Méthode
Description
Standard
Login + mot de passe uniquement
MFA
Login + mot de passe + code SMS
TOTP
Login + mot de passe + code application
Configuration
L'activation de l'authentification de repli est effectuée compte par compte par un administrateur. Elle ne peut pas être activée par l'utilisateur lui-même.
Flux de connexion avec repli
flowchart TD
A([Page de connexion]) --> B[Saisie de l'identifiant - email]
B --> C{Type d'authentification associé au compte ?}
C -->|SSO sans repli autorisé| D[Redirection vers l'IdP SSO]
D --> E["Authentification auprès de l'IdP"]
E --> Z([Accès accordé])
C -->|Repli autorisé standard / MFA / TOTP| F[Saisie du mot de passe]
F --> G{Mot de passe valide ?}
G -->|Non| F
G -->|Oui| H{2FA activé ?}
H -->|Non| Z
H -->|MFA| I[Envoi code SMS]
H -->|TOTP| J[Demande code application]
I --> K[Saisie du code SMS]
J --> L[Saisie du code TOTP]
K --> M{Code valide ?}
L --> M
M -->|Non| N([Accès refusé])
M -->|Oui| Z
Points importants
La coexistence SSO + authentification de repli est gérée au niveau du compte individuel, pas au niveau global.
Les comptes en repli conservent toutes les options de sécurité supplémentaires (MFA, TOTP).
Il est recommandé de limiter au strict nécessaire le nombre de comptes bénéficiant d'une authentification de repli.
3.3 Configuration — Exemple avec Google
La procédure ci-dessous illustre la configuration d'une application SAML via Google Workspace. Pour le détail des étapes côté Google, se référer à la documentation officielle : Google - application SAML.
Paramètres à renseigner dans Google
Champ
Valeur
ACS URL
https://{grid}.ea.eulerian.com/login
Entity Id
eulerian (valeur exacte, sans variation)
Attributs SAML obligatoires
La configuration SAML doit impérativement renvoyer les attributs suivants : - NAMEID : adresse EMAIL — doit correspondre exactement à l'identifiant du compte côté plateforme - Attribut email - Attribut téléphone - Attribut nom - Attribut prénom
Finalisation
Une fois l'application configurée côté Google, envoyer au support le fichier metadata contenant les informations du fournisseur d'identité afin qu'il soit déclaré côté plateforme.
3.4 Limitations connues
Les fonctionnalités suivantes ne sont pas prises en charge à ce jour :
Création automatique de compte : le webmaster doit créer manuellement le compte sur la plateforme en s'assurant que le NAMEID correspond bien à l'identifiant de connexion.
Association automatique à un groupe SCIM : si des restrictions d'accès à certaines parties de l'interface sont souhaitées, elles doivent être configurées manuellement pour chaque compte concerné.
4. Récapitulatif
Mode
Qui est concerné
2FA possible
Géré par
Standard
Tous les utilisateurs (hors SSO global)
MFA, TOTP
Utilisateur / Admin
MFA
Comptes avec numéro de téléphone (renseigné par le support)