SSO et SCIM. Enterprise identity, zero friction.

Elido utilise WorkOS comme courtier SSO et SCIM, prenant en charge Okta, Azure AD / Entra ID, Google Workspace, OneLogin, PingFederate, Shibboleth, ADFS, JumpCloud et tout IdP compatible SAML 2.0. Les connexions OIDC sont également prises en charge pour des fournisseurs comme Google Workspace et Azure. Si votre IdP n'est pas dans la liste standard de WorkOS, le type de connexion 'Generic SAML' de WorkOS fonctionne avec n'importe quel flux initié par le SP SAML 2.0. Contactez-nous si vous avez besoin d'une connexion IdP spécifique non listée.

Le provisionnement JIT (Just-in-Time) crée un compte utilisateur dans Elido lors de sa première connexion SSO — aucun pré-provisionnement requis. C'est plus simple à configurer mais ne donne aucun contrôle sur qui peut se connecter (toute personne ayant une assertion SSO valide obtient un compte). Le provisionnement SCIM donne le contrôle à votre IdP : seuls les utilisateurs du groupe provisionné peuvent se connecter, et les comptes sont créés avant la première connexion. Pour les environnements d'entreprise où l'accès doit être pré-approuvé, SCIM est requis. Lorsque SCIM est actif, le provisionnement JIT est désactivé.

Dans les paramètres SSO de l'espace de travail, vous mappez vos groupes IdP aux rôles Elido : ex, 'groupe Okta : Admins Elido' → 'rôle Elido : Admin', 'groupe Okta : Membres Elido' → 'rôle Elido : Member'. Le rôle d'un utilisateur dans Elido suit son appartenance au groupe IdP — s'il passe du groupe Admins au groupe Members dans Okta, son rôle Elido est déclassé lors de la prochaine synchronisation SCIM (généralement moins de 60 secondes). Un utilisateur appartenant à plusieurs groupes prend le rôle le plus privilégié parmi les mappages correspondants.

Le SSO peut être configuré comme forcé (tous les utilisateurs doivent se connecter via SSO — la connexion par mot de passe est désactivée) ou facultatif (les utilisateurs peuvent choisir entre SSO ou e-mail+mot de passe). Sur Business, le forçage est configuré dans les paramètres SSO de l'espace de travail. Une fois forcé, les utilisateurs qui n'ont pas d'identité SSO active sont bloqués — assurez-vous que le provisionnement SCIM ou JIT a créé les comptes avant d'activer le forçage. Les comptes administrateurs peuvent être exemptés du forçage SSO comme mécanisme de secours ; ceci est configurable.

Lorsque SCIM désactive un utilisateur, Elido suspend toutes les clés API créées par cet utilisateur. Les clés suspendues renvoient HTTP 401 lors de l'authentification. Les clés ne sont pas supprimées — elles restent visibles pour les administrateurs de l'espace de travail à des fins d'audit, avec un libellé de statut 'suspendu — utilisateur offboardé'. Si un compte de service utilisait une clé API personnelle (et non une clé de service d'espace de travail), la suspension de la clé interrompra cette intégration — c'est intentionnel. Pour les intégrations de production, utilisez des clés de service au niveau de l'espace de travail plutôt que des clés API utilisateur.

Le SSO et le SCIM sont des fonctionnalités réservées au plan Business. Les espaces de travail Pro utilisent l'authentification intégrée d'Elido (e-mail + mot de passe via Ory Kratos, OAuth Google/GitHub en option). Si le SSO est une exigence absolue pour votre approbation d'achat, le plan Business est le point de départ. Contactez le service commercial pour un essai Business si vous devez évaluer le SSO avant de vous engager.

Chaque espace de travail Elido possède sa propre configuration SSO — si vous gérez plusieurs espaces de travail (ex: par marque, par unité commerciale), chacun dispose de sa propre connexion IdP et de son propre provisionnement SCIM séparément. Les utilisateurs peuvent être membres de plusieurs espaces de travail avec des rôles différents dans chacun ; leur identité IdP est la même, mais les mappages groupe-rôle sont évalués par espace de travail. Un groupe Okta partagé peut correspondre au rôle Admin dans un espace de travail et Member dans un autre.

Oui. Les tentatives de connexion SSO échouées (assertion SAML invalide, session expirée, compte SCIM manquant lorsque le JIT est désactivé) sont enregistrées dans le journal d'audit de l'espace de travail avec le code de raison. C'est utile pour diagnostiquer pourquoi un utilisateur spécifique ne peut pas se connecter et pour détecter les tentatives de sondage SSO par force brute. Les tentatives échouées provenant d'adresses IP dépassant un seuil déclenchent une alerte d'espace de travail (configurable dans les paramètres de sécurité de l'espace de travail).