Dans une université, une seule personne peut avoir besoin d'accéder au site principal, à un portail des enseignants, au système de la bibliothèque, à une plateforme d'apprentissage et à une dizaine d'autres applications — et personne ne veut se connecter séparément à chacune d'elles. L'authentification unique (SSO) résout ce problème en permettant à un utilisateur de s'authentifier une seule fois, avec un seul ensemble d'identifiants institutionnels, et d'obtenir l'accès à tous les systèmes connectés. Pour un site Drupal qui se trouve au cœur de la présence numérique d'une université, l'intégration avec le SSO de l'établissement est l'un des éléments les plus importants de sa construction.
Ce guide explique comment fonctionne l'intégration SSO de Drupal et, surtout, comment choisir la bonne approche. Nous aborderons les quatre technologies sur lesquelles s'appuient les universités — SAML, Shibboleth, LDAP et CAS — leurs cas d'usage respectifs, le fonctionnement de l'intégration côté Drupal, ainsi que les décisions de gouvernance de l'identité et de sécurité que la plupart des guides étape par étape laissent de côté.
Ce que signifie réellement l'authentification unique
L'authentification unique est un modèle d'authentification dans lequel un utilisateur se connecte une seule fois auprès d'une autorité centrale de confiance, puis est automatiquement reconnu par chaque application qui y est connectée. Le principe clé — et l'avantage en matière de sécurité — est que les applications individuelles ne manipulent jamais le mot de passe de l'utilisateur. Avec le SSO en place, les identifiants sont vérifiés en un seul endroit, selon un seul ensemble de règles, plutôt que d'être stockés et contrôlés séparément par chaque système.
Pour une université, cela est important à plusieurs niveaux à la fois. Les étudiants et le personnel obtiennent une identité unique pour des dizaines de services. L'équipe informatique gère l'authentification de manière centralisée, en appliquant des règles de mot de passe cohérentes et une authentification multifacteur partout. Et lorsque quelqu'un quitte l'établissement, la désactivation d'un seul compte central coupe l'accès à tout, au lieu de laisser des identifiants orphelins dispersés dans différents systèmes. Cette combinaison de confort et de contrôle explique pourquoi le SSO est, en pratique, indispensable pour toute plateforme web institutionnelle sérieuse.
Le socle de base : Fournisseur d'identité et Fournisseur de service
Toute mise en place du SSO implique deux rôles, et les comprendre rend le reste beaucoup plus clair.
Le fournisseur d'identité (IdP) est l'autorité centrale de confiance qui détient les identités des utilisateurs et vérifie les identifiants — le service Shibboleth de l'établissement, son Active Directory ou son serveur CAS. Le fournisseur de service (SP) est l'application que l'utilisateur souhaite atteindre — dans ce cas, le site Drupal. Lorsqu'un utilisateur tente d'accéder au SP Drupal, celui-ci délègue l'authentification à l'IdP ; l'IdP vérifie l'utilisateur et renvoie une confirmation, accompagnée d'attributs tels que le nom, l'e-mail et le rôle ; Drupal accorde alors l'accès en se basant sur cette réponse de confiance. Dans la configuration universitaire standard, Drupal agit comme fournisseur de service, et le système existant de l'établissement est le fournisseur d'identité. Bien établir cette relation est le fondement de toute intégration SSO.
Les quatre approches : SAML, Shibboleth, LDAP et CAS
Les universités s'appuient généralement sur l'une des quatre technologies suivantes pour le SSO. Elles se recoupent dans leur objectif, mais diffèrent par leur origine, leur mécanisme et leur meilleur domaine d'application.
SAML
SAML (Security Assertion Markup Language) est la norme ouverte qui sous-tend la plupart des solutions SSO d'entreprise modernes. Il s'agit d'un protocole basé sur XML permettant d'échanger des données d'authentification et d'autorisation entre un IdP et un SP, et il s'intègre à pratiquement toutes les grandes plateformes d'identité — Microsoft Entra ID, Okta, ADFS, Google Workspace, et bien d'autres. Dans Drupal, SAML est géré via des modules contribués qui permettent au site d'agir comme fournisseur de service, en déléguant l'authentification à tout IdP compatible SAML. C'est le choix le plus largement compatible et le terrain d'entente que la plupart des autres systèmes peuvent comprendre.
Shibboleth
Shibboleth est une implémentation spécifique et largement déployée de SAML, profondément ancrée dans le monde académique. C'est l'épine dorsale de l'accès fédéré dans l'enseignement supérieur et la recherche — la technologie derrière les fédérations académiques nationales et internationales qui permettent à un étudiant de se connecter dans un établissement et d'accéder à des ressources dans un autre. Techniquement, intégrer Drupal avec Shibboleth revient à une intégration SAML : Drupal agit comme fournisseur de service SAML et Shibboleth fait office de fournisseur d'identité. Si votre établissement fait partie d'une fédération d'identité académique, Shibboleth sera très probablement le système auquel vous vous connecterez.
LDAP
LDAP (Lightweight Directory Access Protocol) n'est pas un protocole SSO au même sens que SAML — c'est un protocole permettant d'interroger un annuaire d'utilisateurs, le plus souvent Microsoft Active Directory. Son rôle dans une université est d'être la source sous-jacente de l'identité : il stocke qui existe, les appartenances aux groupes et les attributs des utilisateurs. L'intégration LDAP de Drupal permet aux utilisateurs de se connecter avec leurs identifiants d'annuaire, et peut provisionner automatiquement les comptes Drupal et attribuer des rôles en fonction des groupes de l'annuaire. LDAP est souvent la couche qui se trouve derrière un protocole SSO plutôt qu'un substitut à celui-ci, et il est particulièrement courant lorsque l'établissement fonctionne sur la pile Microsoft.
CAS
CAS (Central Authentication Service) est un protocole SSO open source né à l'université de Yale, encore largement utilisé dans l'enseignement supérieur. Il a été conçu spécifiquement pour résoudre le problème du SSO pour les applications web, et fonctionne aisément aux côtés de magasins d'autorisation comme LDAP. Dans Drupal, l'intégration CAS redirige les utilisateurs vers le serveur CAS central de l'établissement pour s'authentifier, puis les ramène sur le site en tant qu'utilisateurs connectés, avec des rôles attribuables en fonction de la réponse CAS. Pour les universités qui exploitent déjà un déploiement CAS à l'échelle du campus, y connecter Drupal est un choix naturel.
Quel protocole une université devrait-elle choisir ?
En pratique, le choix est généralement dicté par ce que l'établissement utilise déjà — Drupal se connecte à l'IdP existant, et non l'inverse. Le tableau ci-dessous résume les cas d'usage de chaque approche.
| Approche | Ce que c'est | Cas d'usage idéal |
|---|---|---|
| SAML | Norme ouverte pour l'authentification fédérée ; compatibilité la plus large. | Connexion à Entra ID, Okta, ADFS ou tout IdP SAML. |
| Shibboleth | Implémentation académique de SAML ; la norme des fédérations de recherche. | Établissements membres d'une fédération académique nationale ou internationale. |
| LDAP | Protocole d'annuaire ; source sous-jacente de l'identité des utilisateurs. | Environnements Microsoft Active Directory ; provisionnement des rôles. |
| CAS | Protocole SSO open source axé sur le web, courant sur les campus. | Établissements disposant déjà d'un serveur CAS à l'échelle du campus. |
La règle pratique est simple : identifiez le fournisseur d'identité que votre établissement exploite déjà, puis choisissez l'intégration Drupal qui communique avec lui. Une université au sein d'une fédération académique connecte Drupal à Shibboleth ; un établissement standardisé sur Microsoft se connecte via SAML à Entra ID ou via LDAP à Active Directory ; un établissement exploitant un serveur CAS de campus se connecte à CAS. Il s'agit rarement d'un choix fait à partir de zéro — la bonne réponse est généralement déterminée par l'infrastructure d'identité déjà en place.
Comment le SSO fonctionne côté Drupal
Côté Drupal, le SSO est géré via des modules contribués plutôt que par le noyau, et il existe un écosystème mature pour chaque protocole. Quel que soit le module utilisé, l'intégration prend en charge quelques tâches essentielles : elle redirige les utilisateurs non authentifiés vers l'IdP, reçoit et valide la réponse d'authentification, et fait correspondre les attributs renvoyés par l'IdP à un compte Drupal.
Un concept qu'il vaut la peine de comprendre ici est le provisionnement « just-in-time » (JIT). Plutôt que de créer un compte Drupal à l'avance pour chaque utilisateur potentiel, le provisionnement JIT crée le compte automatiquement la première fois qu'une personne s'authentifie avec succès via l'IdP, en le remplissant avec les attributs fournis par l'IdP — nom, e-mail et rôle. C'est ce qui permet au SSO de s'adapter à l'échelle d'une université entière : aucun administrateur n'a besoin de créer manuellement des milliers de comptes, et l'attribution des rôles peut être pilotée automatiquement par les appartenances aux groupes signalées par l'IdP. Pour les établissements évaluant les modules spécifiques, les pages officielles des projets Drupal.org pour SimpleSAMLphp Authentication, LDAP et CAS documentent les options actuelles et prises en charge.
Gouvernance de l'identité : la partie que la plupart des guides omettent
La plupart des tutoriels sur le SSO s'arrêtent dès que la connexion fonctionne. Mais pour une université qui traite des données sensibles concernant les étudiants et le personnel, les questions les plus difficiles et les plus importantes portent sur la gouvernance : qui a accès, comment l'accès est-il retiré, et où l'identité réside-t-elle réellement. C'est là qu'une intégration bien conçue se distingue d'une intégration simplement fonctionnelle.
Le principe central est que Drupal ne devrait pas maintenir son propre pool distinct de comptes utilisateurs à côté du fournisseur d'identité institutionnel. Lorsque des comptes Drupal locaux existent de manière indépendante, ils finissent par se désynchroniser : ils ne sont pas désactivés lorsque quelqu'un part, et accumulent des mots de passe faibles avec le temps. La pratique recommandée consiste à désactiver l'authentification locale par mot de passe pour tout le monde, à l'exception d'un unique compte administrateur d'urgence (« break-glass »), à acheminer toute l'authentification via l'IdP, et à hériter de cette source amont l'authentification multifacteur, la politique de mots de passe et le cycle de vie des comptes de l'établissement. En d'autres termes, le système d'identité de l'établissement — et non Drupal — devient la source unique de vérité quant à qui peut se connecter.
Cette approche apporte un avantage de sécurité concret : la désactivation des accès (« deprovisioning »). Lorsqu'un étudiant obtient son diplôme ou qu'un membre du personnel quitte l'établissement, la désactivation de son compte d'identité central coupe immédiatement son accès à Drupal en même temps que tout le reste, sans laisser derrière lui aucun identifiant local orphelin. Pour un établissement responsable de la protection des données, cet unique interrupteur centralisé est bien plus sûr que d'essayer de retrouver des comptes séparés dans chaque système.
Scénarios universitaires : multisite, cycle de vie et anciens élèves
Le SSO dans un contexte universitaire apporte son lot de scénarios qu'un site d'entreprise unique ne rencontre jamais :
- Authentification unique multisite : Les grandes universités exploitent de nombreux sites — un site principal ainsi que des sites distincts pour les facultés, les départements et les centres de recherche. Le SSO permet à un utilisateur de se connecter une seule fois et de circuler entre tous ces sites en toute transparence, tandis que l'authentification reste centralisée. Cela s'accorde naturellement avec l'architecture multisite de Drupal, où de nombreux sites sont gouvernés depuis un seul endroit.
- Le cycle de vie de l'identité : La relation d'une personne avec une université évolue dans le temps — candidat, étudiant, diplômé, et parfois membre du personnel — et ses besoins d'accès évoluent en conséquence. Faire découler les rôles Drupal des attributs de l'IdP signifie que l'accès peut suivre ce cycle de vie automatiquement, plutôt que d'être ajusté manuellement à chaque transition.
- Des populations distinctes : Étudiants, enseignants, personnel et anciens élèves ont souvent besoin de différents niveaux d'accès à différents systèmes. Comme l'IdP signale l'appartenance aux groupes, Drupal peut associer automatiquement chaque population au rôle approprié, en gardant les permissions alignées sur le statut réel de l'utilisateur.
Ces scénarios expliquent précisément pourquoi l'intégration de l'identité fait partie intégrante de la construction d'une plateforme universitaire, plutôt que d'être une réflexion après coup. Ils rejoignent également l'ensemble plus large des intégrations académiques dont un site Drupal a généralement besoin — parmi elles, une plateforme d'apprentissage, que nous abordons dans notre guide sur l'intégration de Moodle et Drupal.
Erreurs courantes en matière de SSO et comment les éviter
- Faire fonctionner des comptes locaux aux côtés de l'IdP : L'échec de gouvernance le plus courant. Les comptes Drupal indépendants se désynchronisent, ne sont pas désactivés et accumulent des mots de passe faibles. Acheminez l'authentification via l'IdP et ne conservez localement qu'un seul compte administrateur d'urgence.
- Oublier le compte d'urgence : Si chaque connexion dépend de l'IdP et que celui-ci devient inaccessible, plus personne ne peut se connecter — pas même les administrateurs. Un seul compte d'urgence local bien sécurisé évite un blocage total.
- Mapper les rôles à la légère : Accorder automatiquement des rôles Drupal élevés à partir des attributs de l'IdP peut octroyer un accès administratif de manière non intentionnelle. Associez chaque attribut au privilège minimal dont il a besoin, et traitez les rôles administratifs avec une vigilance accrue.
- Négliger la désactivation des accès : Se concentrer uniquement sur le bon fonctionnement de la connexion laisse sans réponse la question la plus importante — comment l'accès est retiré. Concevez pour le moment où quelqu'un part, pas seulement pour celui où il arrive.
- Choisir un protocole de manière isolée : Choisir une technologie SSO sans vérifier ce que l'établissement utilise déjà entraîne une complexité inutile. Partez du fournisseur d'identité existant et connectez-vous à lui.
- Négliger le mapping des attributs : Si les attributs de l'IdP ne sont pas correctement associés aux champs et rôles de Drupal, les utilisateurs peuvent se connecter mais se retrouver avec des permissions erronées. Vérifiez le mapping des attributs avec autant de rigueur que le flux de connexion lui-même.
Bien réalisée, l'intégration SSO fait d'un site Drupal une partie fluide et sécurisée de l'écosystème numérique d'une université — une seule identité, gouvernée de manière centralisée, s'étendant à tous les systèmes connectés. C'est une capacité fondamentale pour tout établissement exploitant Drupal à grande échelle, et cela fait partie de l'ensemble plus large des intégrations académiques exploré dans notre présentation de Drupal dans l'éducation.
Questions fréquentes sur le SSO dans Drupal
Drupal stocke-t-il les mots de passe lorsque le SSO est activé ?
Non — c'est là l'avantage de sécurité fondamental du SSO. Lorsque l'authentification est déléguée à un fournisseur d'identité, les identifiants de l'utilisateur sont vérifiés par l'IdP et ne sont jamais stockés dans Drupal. La configuration recommandée désactive entièrement l'authentification locale par mot de passe, à l'exception d'un unique compte administrateur d'urgence conservé pour les situations exceptionnelles. Cela signifie que les mots de passe, la politique de mots de passe et l'authentification multifacteur résident tous dans le système d'identité central de l'établissement, et Drupal se contente de faire confiance à sa réponse vérifiée.
Drupal peut-il utiliser plusieurs fournisseurs d'identité à la fois ?
Oui, selon les modules utilisés, Drupal peut être configuré pour fonctionner avec plusieurs sources d'authentification. Un exemple courant est un établissement qui authentifie les étudiants via un système et le personnel via un autre, ou qui conserve SAML pour la plupart des utilisateurs tout en gardant une option locale limitée pour un groupe spécifique. La configuration devient plus complexe à chaque source supplémentaire ; le conseil pratique est donc de ne prendre en charge que les fournisseurs d'identité pour lesquels il existe un besoin réel, et de garder la configuration aussi simple que le permettent les besoins réels de l'établissement.
Quelle est la différence entre authentification et provisionnement ?
L'authentification consiste à vérifier qui est un utilisateur — en confirmant ses identifiants auprès du fournisseur d'identité. Le provisionnement consiste à créer et à maintenir le compte et les attributs de l'utilisateur dans Drupal. Le SSO gère l'authentification ; le provisionnement « just-in-time » gère la création de compte qui suit, en générant automatiquement un compte Drupal lors de la première connexion et en le remplissant à partir des attributs de l'IdP. Les deux fonctionnent ensemble : l'authentification prouve l'identité, et le provisionnement donne à cette identité une place et un rôle au sein de Drupal.
SAML ou CAS est-il préférable pour une université ?
Aucun des deux n'est universellement meilleur — cela dépend de ce que votre établissement utilise déjà. SAML, y compris son implémentation académique Shibboleth, est le bon choix pour les établissements appartenant à des fédérations de recherche ou standardisés sur des plateformes d'identité comme Entra ID ou Okta. CAS est un excellent choix pour les universités qui exploitent déjà un serveur CAS à l'échelle du campus. La décision doit suivre l'infrastructure d'identité existante plutôt qu'un classement abstrait : connectez Drupal au système auquel votre établissement fait déjà confiance, et laissez cela déterminer le protocole.