SSO & annuaire (OIDC / LDAP / SCIM)
En édition Entreprise, le service cloud peut s'adosser à l'annuaire d'identité de l'organisation. Trois ponts sont disponibles ; tous fonctionnent de la même façon : une identité vérifiée (email + groupes) est transformée en rôles selon une table de correspondance groupe → rôle configurée par l'opérateur (voir Organisations, espaces & rôles).
Principe anti-escalade : le client ne fournit jamais son rôle, son groupe ou son email. L'email et les groupes proviennent uniquement de la vérification faite par le pont ; les rôles proviennent uniquement des groupes mappés par l'opérateur.
OIDC (OpenID Connect)
ycell agit comme client OIDC confidentiel, indépendant du fournisseur via la découverte OIDC : Keycloak, Authentik, Microsoft Entra, Google… fonctionnent de la même façon. L'opérateur fournit, par organisation, l'URL de l'émetteur, un identifiant client et un secret client ; le secret client est chiffré au repos.
À la connexion, l'utilisateur est redirigé vers son fournisseur d'identité ; au retour, le jeton d'identité est vérifié rigoureusement (signature, émetteur, audience, expiration, nonce, algorithmes asymétriques uniquement). L'email vérifié et les groupes déclenchent l'attribution des rôles. La vérification est stricte : tout contrôle qui échoue interdit l'accès.
LDAP / Active Directory
Un utilisateur s'authentifie par l'annuaire LDAP ; son email et ses groupes d'annuaire déterminent ses rôles, via le même mécanisme. Deux modes sont disponibles : une liaison directe (le nom de l'utilisateur est construit depuis un gabarit), ou une recherche via un compte de service qui localise l'utilisateur puis vérifie son mot de passe.
Posture de sécurité : TLS obligatoire (ldaps:// ou StartTLS — une connexion en
clair est refusée à la configuration) ; une liaison anonyme / mot de passe vide
n'est jamais acceptée.
SCIM 2.0 (provisioning entrant)
Le fournisseur d'identité (Entra, Okta…) pousse les utilisateurs et groupes vers ycell, de sorte que les appartenances existent avant toute connexion, avec un cycle de vie complet (désactiver un utilisateur lui retire son accès).
SCIM maintient un annuaire d'identités provisionnées par organisation (email, groupes, état actif). Les rôles sont toujours attribués à la connexion, et lorsque SCIM est activé :
- l'email de la personne qui se connecte doit correspondre à une identité active (sinon aucun accès) ;
- les groupes utilisés pour la correspondance sont ceux provisionnés par SCIM (la source de référence).
Désactiver un utilisateur → sa prochaine connexion ne correspond à aucune identité active → aucun accès n'est accordé.
Authentification SCIM : l'opérateur active SCIM pour une organisation depuis la console ; un jeton est alors généré et affiché une seule fois. Chaque appel SCIM exige ce jeton et n'agit que sur cette organisation.