Authentification unique

Connecter votre fournisseur d'identité en SAML ou en OIDC, relier ses groupes aux rôles Ctadel et créer les comptes à la première connexion.

Ctadel accepte deux protocoles d'authentification unique : OIDC, parlé directement par l'application, et SAML 2.0, pris en charge par un composant dédié de votre instance. Cette page décrit les deux formulaires, ce que votre fournisseur d'identité doit recevoir, la correspondance entre groupes et rôles, et la création des comptes à la première connexion.

Avant de commencer

L'onglet se trouve dans « Paramètres », « Utilisateurs & Accès », sous-onglet « SSO ». Il demande la permission manage:sso ; sans elle, l'onglet affiche « La gestion de l'authentification unique demande la permission manage:sso. »
L'onglet contient deux cartes : « Exiger la connexion SSO » et « Fournisseurs d'identité », avec deux boutons d'ajout, « OIDC » et « SAML ».
La correspondance entre groupes et rôles utilise l'identifiant numérique des rôles Ctadel. Préparez les rôles dans le sous-onglet « Rôles » avant de configurer le fournisseur ; voir Utilisateurs et rôles.

Fournisseur OIDC

Le formulaire « Nouveau fournisseur OIDC » demande :

Champ	Contenu
« Nom d'affichage »	Le nom du bouton sur la page de connexion
« URL de l'émetteur »	L'URL d'émetteur de votre fournisseur ; la découverte lit `<émetteur>/.well-known/openid-configuration`
« Client ID » et « Secret client »	L'application enregistrée chez votre fournisseur
« Scopes »	`openid profile email` par défaut ; ajoutez `groups` ou l'équivalent de votre fournisseur pour recevoir les groupes
« Claim de groupes »	Le nom du claim qui porte les groupes, `groups` par défaut
« ID de rôle par défaut »	Facultatif : le rôle donné à toute personne qui se connecte par ce fournisseur
« Activé », « Par défaut », « JIT »	Trois interrupteurs ; « JIT » autorise la création de compte à la première connexion

Le nom, l'émetteur et le Client ID sont obligatoires. Après « Créer », l'onglet affiche : « {name} créé. Ajoutez cette URI de redirection exacte dans les callbacks autorisés de votre fournisseur d'identité : » suivi de l'adresse à copier, de la forme https://<CLIENT>.ctadel.eu/api/auth/callback/oidc-<ID>. Cette « URI de redirection » reste visible sur la ligne du fournisseur.

Le secret client est chiffré avant stockage et n'est jamais réaffiché. Le bouton « Tester » lit le document de découverte de l'émetteur et répond « Fournisseur accessible » ou « Fournisseur inaccessible ».

Fournisseur SAML

Le formulaire « Nouveau fournisseur SAML » demande :

Champ	Contenu
« Nom d'affichage (ex : Okta SAML) »	Le nom du bouton sur la page de connexion
« Métadonnées IdP : »	Au choix « URL » (l'adresse des métadonnées publiées par votre fournisseur) ou « XML » (le document collé tel quel) ; l'un des deux, pas les deux
« Attribut de groupes (défaut : groups) »	L'attribut SAML qui porte les groupes
« ID de rôle par défaut (optionnel) »	Comme en OIDC
« Activé », « Par défaut », « JIT »	Comme en OIDC

Votre fournisseur d'identité a besoin de deux valeurs, affichées sur la ligne du fournisseur avec un bouton de copie :

« ACS URL », où il envoie la réponse SAML : https://<CLIENT>.ctadel.eu/jackson/api/oauth/saml.
« Entity ID », l'identifiant de Ctadel comme fournisseur de service : https://<CLIENT>.ctadel.eu.

Les métadonnées de votre fournisseur sont conservées par votre instance. Seules les adresses nécessaires au navigateur et à votre fournisseur (autorisation, jeton, ACS) sont joignables depuis Internet. Le bouton « Tester » d'un fournisseur SAML vérifie que le point d'entrée SAML de votre instance répond, pas que votre fournisseur est joignable.

Correspondance entre groupes et rôles

À chaque connexion, Ctadel recalcule les rôles gérés par le SSO :

Le « ID de rôle par défaut » s'il est renseigné.
Pour chaque groupe reçu dans le claim ou l'attribut configuré, le rôle indiqué dans la correspondance groupe vers rôle, saisie une ligne par correspondance sous la forme nom-du-groupe=ID-du-rôle (« Une correspondance par ligne : nom du groupe dans l'IdP = ID du rôle Ctadel. Vide = aucune correspondance. »).

Les attributions issues du SSO sont effacées puis réécrites à chaque connexion : une personne retirée d'un groupe chez vous perd le rôle correspondant à sa connexion suivante. Les rôles attribués à la main dans « Utilisateurs » ne sont pas touchés. Un rôle supprimé depuis l'écriture de la correspondance est ignoré et journalisé, sans bloquer la connexion.

Création des comptes à la première connexion

Avec « JIT » activé (par défaut), une personne inconnue qui s'authentifie chez votre fournisseur obtient un compte Ctadel : adresse et nom reçus du fournisseur, sans mot de passe, adresse considérée comme vérifiée. Avec « JIT » désactivé, seules les personnes qui ont déjà un compte (invitées au préalable) peuvent se connecter ; les autres sont refusées.

Un compte existant portant la même adresse est rattaché à l'identité SSO dans deux cas : fournisseur SAML, ou fournisseur OIDC qui affirme avoir vérifié l'adresse (email_verified, ou xms_edov pour Microsoft Entra). Sinon la connexion est refusée et journalisée, pour éviter qu'un fournisseur où chacun choisit son adresse ne s'approprie un compte existant.

Un compte créé par SSO ne peut pas utiliser le mot de passe ni « Mot de passe oublié ? ». Il ne passe pas non plus par le code de connexion envoyé par courriel.

Modifier un fournisseur sans perdre le secret

Le bouton « Modifier » ouvre le formulaire « Modifier {name} ». Seuls les champs changés sont envoyés.

OIDC : « Nom affiché », émetteur, Client ID, « Secret client » (« Laissez vide pour conserver le secret actuel ; saisissez-en un nouveau pour le renouveler. »), scopes, claim de groupes.
SAML : « Nom affiché » et attribut de groupes. « Les métadonnées de l'IdP ne se modifient pas ici : supprimez le fournisseur et recréez-le pour le faire pointer vers un autre IdP. »
Les deux : « ID de rôle par défaut », la correspondance groupe vers rôle, « Activé », « Par défaut », « JIT ».

Un seul fournisseur peut être « Par défaut » ; en cocher un retire l'indicateur à l'autre. Les changements s'appliquent à la tentative de connexion suivante, sans redémarrage.

Exiger la connexion SSO

La carte « Exiger la connexion SSO » porte un interrupteur : « Lorsqu'activé, seuls les fournisseurs SSO configurés peuvent se connecter. La connexion par mot de passe et OAuth (Google, GitHub) est bloquée. » Deux gardes évitent de verrouiller l'instance :

L'interrupteur refuse de s'activer sans fournisseur activé.
Tant qu'il est activé, désactiver ou supprimer le dernier fournisseur actif est refusé : « La connexion SSO est obligatoire et c'est le dernier fournisseur actif : désactivez d'abord « Exiger la connexion SSO », sinon plus personne ne pourrait se connecter. »

Si votre fournisseur devient injoignable alors que l'obligation est active, la page de connexion affiche « SSO requis mais non configuré » et le mode de secours : à votre demande, l'équipe Ctadel rétablit la connexion par mot de passe sur votre instance le temps de la réparation. Ce mode de secours n'est pas activable depuis l'application.

La page de connexion

Sur /login, chaque fournisseur activé apparaît sous la forme d'un bouton « Se connecter avec {name} », le fournisseur « Par défaut » en premier. En dessous, « ou se connecter par e-mail » précède le formulaire de mot de passe, masqué quand la connexion SSO est exigée. Le bouton renvoie vers votre fournisseur, puis la session s'ouvre au retour.

Limites

La correspondance groupe vers rôle se saisit après la création, dans « Modifier ».
Le rôle se désigne par son identifiant numérique, pas par son nom.
Pour un fournisseur SAML, « Tester » vérifie votre instance, pas votre fournisseur ; la seule vérification réelle est une connexion.
Les métadonnées SAML ne se modifient pas : supprimer puis recréer le fournisseur.
Supprimer un fournisseur ne supprime pas les comptes qu'il a créés : « Les utilisateurs liés à ce fournisseur ne pourront plus se connecter via ce flux. » Ils restent listés dans « Utilisateurs ».
Les connexions et refus SSO sont journalisés côté serveur, mais aucun écran de l'application ne montre ce journal.
Pas de provisionnement SCIM, pas de déconnexion unique (SLO).
Les scopes OIDC ne sont pas universels : Google refuse groups, et d'autres fournisseurs ne renvoient les groupes qu'après configuration de leur côté.