An einer Universität muss eine einzelne Person möglicherweise auf die Hauptwebsite, ein Fakultätsportal, das Bibliothekssystem, eine Lernplattform und ein Dutzend weiterer Anwendungen zugreifen — und niemand möchte sich bei jeder einzeln anmelden. Single Sign-On (SSO) löst dieses Problem, indem es einem Benutzer erlaubt, sich einmal mit einem einzigen Satz institutioneller Anmeldedaten zu authentifizieren und Zugriff auf alle verbundenen Systeme zu erhalten. Für eine Drupal-Website, die im Zentrum der digitalen Präsenz einer Universität steht, ist die Integration mit dem SSO der Institution einer der wichtigsten Bausteine des Aufbaus.
Dieser Leitfaden erklärt, wie die Drupal-SSO-Integration funktioniert und, noch wichtiger, wie man den richtigen Ansatz wählt. Wir behandeln die vier Technologien, auf die Universitäten setzen — SAML, Shibboleth, LDAP und CAS — wann jede davon passt, wie die Integration auf der Drupal-Seite funktioniert, sowie die Entscheidungen zu Identitätsverwaltung und Sicherheit, die die meisten Schritt-für-Schritt-Anleitungen auslassen.
Was Single Sign-On tatsächlich bedeutet
Single Sign-On ist ein Authentifizierungsmodell, bei dem sich ein Benutzer einmal bei einer vertrauenswürdigen zentralen Instanz anmeldet und anschließend automatisch von jeder damit verbundenen Anwendung erkannt wird. Das zentrale Prinzip — und der Sicherheitsvorteil — besteht darin, dass die einzelnen Anwendungen niemals mit dem Passwort des Benutzers in Berührung kommen. Mit SSO werden Anmeldedaten an einem einzigen Ort nach einheitlichen Richtlinien überprüft, anstatt von jedem System separat gespeichert und geprüft zu werden.
Für eine Universität ist das auf mehreren Ebenen gleichzeitig relevant. Studierende und Mitarbeiter erhalten eine einzige Identität für Dutzende von Diensten. Das IT-Team verwaltet die Authentifizierung zentral und wendet überall einheitliche Passwortregeln und Multi-Faktor-Authentifizierung an. Und wenn jemand die Institution verlässt, wird durch die Deaktivierung eines zentralen Kontos der Zugriff auf alles unterbrochen, anstatt verwaiste Logins über verschiedene Systeme verstreut zurückzulassen. Diese Kombination aus Komfort und Kontrolle ist der Grund, warum SSO für jede ernsthafte institutionelle Webplattform praktisch eine Voraussetzung ist.
Der Grundbaustein: Identity Provider und Service Provider
Jede SSO-Einrichtung umfasst zwei Rollen, und deren Verständnis macht alles Weitere klarer.
Der Identity Provider (IdP) ist die vertrauenswürdige zentrale Instanz, die Benutzeridentitäten verwaltet und Anmeldedaten überprüft — der Shibboleth-Dienst der Institution, ihr Active Directory oder ihr CAS-Server. Der Service Provider (SP) ist die Anwendung, auf die der Benutzer zugreifen möchte — in diesem Fall die Drupal-Website. Wenn ein Benutzer versucht, auf den Drupal-SP zuzugreifen, übergibt dieser die Authentifizierung an den IdP; der IdP überprüft den Benutzer und sendet eine Bestätigung zurück, zusammen mit Attributen wie Name, E-Mail und Rolle; und Drupal gewährt daraufhin Zugriff basierend auf dieser vertrauenswürdigen Antwort. Im typischen Universitäts-Setup fungiert Drupal als Service Provider, und das bestehende System der Institution ist der Identity Provider. Diese Beziehung richtig zu gestalten, ist die Grundlage jeder SSO-Integration.
Die vier Ansätze: SAML, Shibboleth, LDAP und CAS
Universitäten setzen für SSO typischerweise auf eine von vier Technologien. Sie überschneiden sich im Zweck, unterscheiden sich jedoch in Ursprung, Mechanismus und dem Bereich, in dem sie am besten passen.
SAML
SAML (Security Assertion Markup Language) ist der offene Standard, der den meisten modernen Unternehmens-SSO-Lösungen zugrunde liegt. Es handelt sich um ein XML-basiertes Protokoll für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen einem IdP und einem SP, das mit praktisch jeder größeren Identitätsplattform integriert werden kann — Microsoft Entra ID, Okta, ADFS, Google Workspace und mehr. In Drupal wird SAML über beigesteuerte Module (contributed modules) abgewickelt, die es der Website ermöglichen, als Service Provider zu fungieren und die Authentifizierung an jeden SAML-kompatiblen IdP zu delegieren. Es ist die am breitesten kompatible Option und die gemeinsame Basis, mit der sich die meisten anderen Systeme verständigen können.
Shibboleth
Shibboleth ist eine spezifische, weit verbreitete Implementierung von SAML, die tief in der akademischen Welt verwurzelt ist. Es ist das Rückgrat des föderierten Zugriffs im Hochschul- und Forschungsbereich — die Technologie hinter nationalen und internationalen akademischen Föderationen, die es einem Studierenden ermöglichen, sich an einer Institution anzumelden und auf Ressourcen an einer anderen zuzugreifen. Technisch gesehen ist die Integration von Drupal mit Shibboleth eine SAML-Integration: Drupal fungiert als SAML-Service-Provider, und Shibboleth dient als Identity Provider. Wenn Ihre Institution Teil einer akademischen Identitätsföderation ist, ist Shibboleth sehr wahrscheinlich das System, mit dem Sie sich verbinden werden.
LDAP
LDAP (Lightweight Directory Access Protocol) ist kein SSO-Protokoll im selben Sinne wie SAML — es ist ein Protokoll zur Abfrage eines Benutzerverzeichnisses, meist Microsoft Active Directory. Seine Rolle an einer Universität besteht darin, die zugrunde liegende Identitätsquelle zu sein: Es speichert, wer existiert, welche Gruppenmitgliedschaften vorliegen und welche Attribute zugeordnet sind. Die LDAP-Integration von Drupal ermöglicht es Benutzern, sich mit ihren Verzeichnis-Anmeldedaten anzumelden, und kann Drupal-Konten automatisch anlegen sowie Rollen basierend auf Verzeichnisgruppen zuweisen. LDAP ist oft die Ebene, die hinter einem SSO-Protokoll liegt, anstatt es zu ersetzen, und ist besonders verbreitet, wenn die Institution auf dem Microsoft-Stack läuft.
CAS
CAS (Central Authentication Service) ist ein Open-Source-SSO-Protokoll mit Wurzeln an der Yale University, das im Hochschulbereich weiterhin weit verbreitet ist. Es wurde speziell für das SSO-Problem von Webanwendungen entwickelt und funktioniert problemlos zusammen mit Autorisierungsspeichern wie LDAP. In Drupal leitet die CAS-Integration Benutzer zur zentralen CAS-Server-Authentifizierung der Institution weiter und bringt sie anschließend als angemeldeten Benutzer zur Website zurück, wobei Rollen basierend auf der CAS-Antwort zugewiesen werden können. Für Universitäten, die bereits eine campusweite CAS-Bereitstellung betreiben, ist die Anbindung von Drupal daran eine natürliche Lösung.
Welches Protokoll sollte eine Universität wählen?
In der Praxis wird die Wahl in der Regel durch das bestimmt, was die Institution bereits betreibt — Drupal verbindet sich mit dem bestehenden IdP und nicht umgekehrt. Die folgende Tabelle fasst zusammen, wann welcher Ansatz passt.
| Ansatz | Was es ist | Am besten geeignet für |
|---|---|---|
| SAML | Offener Standard für föderierte Authentifizierung; breiteste Kompatibilität. | Verbindung zu Entra ID, Okta, ADFS oder jedem SAML-IdP. |
| Shibboleth | Akademische SAML-Implementierung; Standard für Forschungsföderationen. | Institutionen in einer nationalen oder internationalen akademischen Föderation. |
| LDAP | Verzeichnisprotokoll; zugrunde liegende Quelle der Benutzeridentität. | Microsoft-Active-Directory-Umgebungen; Rollenbereitstellung. |
| CAS | Webfokussiertes Open-Source-SSO-Protokoll, verbreitet auf Campussen. | Institutionen mit einem bereits bestehenden campusweiten CAS-Server. |
Die praktische Regel ist einfach: Identifizieren Sie den Identity Provider, den Ihre Institution bereits betreibt, und wählen Sie dann die Drupal-Integration, die mit ihm kommuniziert. Eine Universität in einer akademischen Föderation verbindet Drupal mit Shibboleth; eine auf Microsoft standardisierte Institution verbindet sich über SAML mit Entra ID oder über LDAP mit Active Directory; eine mit einem Campus-CAS-Server verbindet sich mit CAS. Es ist selten eine Entscheidung auf der grünen Wiese — die richtige Antwort wird in der Regel durch die bereits vorhandene Identitätsinfrastruktur bestimmt.
Wie SSO auf der Drupal-Seite funktioniert
Auf der Drupal-Seite wird SSO über beigesteuerte Module und nicht über den Core abgewickelt, und für jedes Protokoll gibt es ein ausgereiftes Ökosystem. Unabhängig vom verwendeten Modul übernimmt die Integration einige wesentliche Aufgaben: Sie leitet nicht authentifizierte Benutzer zum IdP weiter, empfängt und validiert die Authentifizierungsantwort und ordnet die vom IdP zurückgegebenen Attribute einem Drupal-Konto zu.
Ein Konzept, das es hier zu verstehen gilt, ist die Just-in-Time-(JIT-)Bereitstellung. Anstatt im Voraus für jeden potenziellen Benutzer ein Drupal-Konto anzulegen, erstellt die JIT-Bereitstellung das Konto automatisch beim ersten erfolgreichen Authentifizieren über den IdP und füllt es mit den vom IdP bereitgestellten Attributen — Name, E-Mail und Rolle. Dies ist es, was SSO für eine ganze Universität skalierbar macht: Kein Administrator muss manuell Tausende von Konten anlegen, und die Rollenzuweisung kann automatisch durch die vom IdP gemeldeten Gruppenmitgliedschaften gesteuert werden. Für Institutionen, die die spezifischen Module evaluieren, dokumentieren die offiziellen Drupal.org-Projektseiten für SimpleSAMLphp Authentication, LDAP und CAS die aktuellen, unterstützten Optionen.
Identitätsverwaltung: Der Teil, den die meisten Leitfäden auslassen
Die meisten SSO-Tutorials enden, sobald die Anmeldung funktioniert. Doch für eine Universität, die sensible Daten von Studierenden und Mitarbeitern verwaltet, sind die schwierigeren und wichtigeren Fragen die zur Governance: Wer hat Zugriff, wie wird der Zugriff entzogen, und wo lebt die Identität tatsächlich. Hier hebt sich eine gut durchdachte Integration von einer lediglich funktionierenden ab.
Das zentrale Prinzip lautet, dass Drupal nicht neben dem institutionellen Identity Provider einen eigenen, separaten Pool von Benutzerkonten führen sollte. Wenn lokale Drupal-Konten unabhängig existieren, geraten sie aus der Synchronisation: Sie werden nicht deaktiviert, wenn jemand geht, und sammeln im Laufe der Zeit schwache Passwörter an. Die empfohlene Vorgehensweise besteht darin, die lokale Passwort-Authentifizierung für alle außer einem einzigen Notfall-Administratorkonto ("Break-Glass") zu deaktivieren, die gesamte Authentifizierung über den IdP zu leiten und die Multi-Faktor-Authentifizierung, Passwortrichtlinie und den Kontolebenszyklus der Institution von dieser übergeordneten Quelle zu übernehmen. Mit anderen Worten: Das Identitätssystem der Institution — nicht Drupal — wird zur einzigen verlässlichen Quelle dafür, wer sich anmelden kann.
Dieser Ansatz bringt einen konkreten Sicherheitsvorteil: die Deprovisionierung. Wenn ein Studierender die Universität abschließt oder ein Mitarbeiter sie verlässt, unterbricht die Deaktivierung seines zentralen Identitätskontos sofort seinen Drupal-Zugriff zusammen mit allem anderen, ohne dass ein verwaister lokaler Login zurückbleibt. Für eine Institution, die für Datenschutz verantwortlich ist, ist dieser einzige, zentrale Ausschalter weitaus sicherer, als versuchte separate Konten über jedes System hinweg aufzuspüren.
Universitätsszenarien: Multisite, Lebenszyklus und Alumni
SSO im universitären Kontext bringt einige Szenarien mit sich, denen eine einzelne Unternehmenswebsite nie begegnet:
- Multisite-Single-Sign-On: Große Universitäten betreiben viele Websites — eine Hauptseite sowie separate Seiten für Fakultäten, Fachbereiche und Forschungszentren. SSO ermöglicht es einem Benutzer, sich einmal anzumelden und sich nahtlos zwischen allen zu bewegen, während die Authentifizierung zentralisiert bleibt. Dies passt natürlich zur Multisite-Architektur von Drupal, bei der viele Websites von einem einzigen Ort aus verwaltet werden.
- Der Identitätslebenszyklus: Die Beziehung einer Person zu einer Universität verändert sich im Laufe der Zeit — Bewerber, Studierender, Absolvent und manchmal Mitarbeiter — und ihre Zugriffsbedürfnisse ändern sich entsprechend. Drupal-Rollen anhand der Attribute des IdP zu steuern bedeutet, dass der Zugriff diesem Lebenszyklus automatisch folgen kann, statt bei jedem Übergang manuell angepasst zu werden.
- Unterschiedliche Nutzergruppen: Studierende, Lehrpersonal, Mitarbeiter und Alumni benötigen oft unterschiedliche Zugriffsebenen auf verschiedene Systeme. Da der IdP die Gruppenmitgliedschaft meldet, kann Drupal jede Nutzergruppe automatisch der entsprechenden Rolle zuordnen und so die Berechtigungen mit dem tatsächlichen Status eines Benutzers abgleichen.
Diese Szenarien sind genau der Grund, warum die Identitätsintegration ein Kernbestandteil beim Aufbau einer Universitätsplattform ist und keine nachträgliche Überlegung. Sie stehen auch im Zusammenhang mit den umfassenderen akademischen Integrationen, die eine Drupal-Website typischerweise benötigt — darunter eine Lernplattform, die wir in unserem Leitfaden zur Moodle-Drupal-Integration behandeln.
Häufige SSO-Fehler und wie man sie vermeidet
- Lokale Konten neben dem IdP betreiben: Der häufigste Governance-Fehler. Unabhängige Drupal-Konten geraten aus der Synchronisation, werden nicht deprovisioniert und sammeln schwache Passwörter an. Leiten Sie die Authentifizierung über den IdP und behalten Sie nur ein lokales Notfall-Administratorkonto.
- Das Notfallkonto vergessen: Wenn jede Anmeldung vom IdP abhängt und der IdP nicht erreichbar wird, kann sich niemand mehr anmelden — auch nicht Administratoren. Ein einziges, gut gesichertes lokales Notfallkonto verhindert eine vollständige Aussperrung.
- Rollen unüberlegt zuordnen: Das automatische Vergeben erhöhter Drupal-Rollen anhand von IdP-Attributen kann unbeabsichtigt administrativen Zugriff gewähren. Ordnen Sie jedes Attribut dem geringstmöglichen Privileg zu, das es benötigt, und behandeln Sie administrative Rollen mit besonderer Sorgfalt.
- Die Deprovisionierung ignorieren: Wer sich nur darauf konzentriert, dass die Anmeldung funktioniert, lässt die wichtigere Frage — wie der Zugriff entzogen wird — unbeantwortet. Planen Sie für den Moment, in dem jemand geht, nicht nur für den Moment, in dem er beitritt.
- Ein Protokoll isoliert auswählen: Die Wahl einer SSO-Technologie, ohne zu prüfen, was die Institution bereits betreibt, führt zu unnötiger Komplexität. Beginnen Sie beim bestehenden Identity Provider und verbinden Sie sich mit ihm.
- Die Attributzuordnung vernachlässigen: Wenn die Attribute des IdP nicht korrekt auf Drupal-Felder und -Rollen abgebildet werden, können sich Benutzer zwar anmelden, landen aber mit falschen Berechtigungen. Überprüfen Sie die Attributzuordnung ebenso sorgfältig wie den Anmeldeprozess selbst.
Richtig umgesetzt, macht die SSO-Integration eine Drupal-Website zu einem nahtlosen, sicheren Teil des digitalen Ökosystems einer Universität — eine Identität, zentral verwaltet, über jedes verbundene System hinweg. Es ist eine grundlegende Fähigkeit für jede Institution, die Drupal in großem Maßstab betreibt, und Teil der breiteren akademischen Integrationen, die in unserem Überblick zu Drupal im Bildungswesen behandelt werden.
Häufig gestellte Fragen zu Drupal-SSO
Speichert Drupal Passwörter, wenn SSO aktiviert ist?
Nein — das ist der zentrale Sicherheitsvorteil von SSO. Wenn die Authentifizierung an einen Identity Provider delegiert wird, werden die Anmeldedaten der Benutzer vom IdP überprüft und niemals in Drupal gespeichert. Die empfohlene Konfiguration deaktiviert die lokale Passwort-Authentifizierung vollständig, mit Ausnahme eines einzigen Notfall-Administratorkontos, das für Notfälle vorgehalten wird. Das bedeutet, dass Passwörter, Passwortrichtlinien und Multi-Faktor-Authentifizierung alle im zentralen Identitätssystem der Institution liegen, und Drupal vertraut lediglich dessen verifizierter Antwort.
Kann Drupal mehr als einen Identity Provider gleichzeitig nutzen?
Ja, je nach verwendeten Modulen kann Drupal so konfiguriert werden, dass es mit mehreren Authentifizierungsquellen arbeitet. Ein häufiges Beispiel ist eine Institution, die Studierende über ein System und Mitarbeiter über ein anderes authentifiziert, oder die SAML für die meisten Benutzer beibehält, während sie eine begrenzte lokale Option für eine bestimmte Gruppe bereithält. Die Konfiguration wird mit jeder zusätzlichen Quelle komplexer, daher lautet der praktische Ratschlag, nur die Identity Provider zu unterstützen, für die ein echter Bedarf besteht, und die Einrichtung so einfach wie möglich entsprechend den tatsächlichen Anforderungen der Institution zu gestalten.
Was ist der Unterschied zwischen Authentifizierung und Bereitstellung?
Authentifizierung bedeutet zu überprüfen, wer ein Benutzer ist — die Bestätigung seiner Anmeldedaten gegenüber dem Identity Provider. Bereitstellung (Provisioning) bedeutet, das Konto und die Attribute des Benutzers in Drupal zu erstellen und zu pflegen. SSO übernimmt die Authentifizierung; die Just-in-Time-Bereitstellung übernimmt die darauffolgende Kontoerstellung, indem bei der ersten Anmeldung automatisch ein Drupal-Konto erzeugt und mit den Attributen des IdP gefüllt wird. Beide arbeiten zusammen: Die Authentifizierung beweist die Identität, und die Bereitstellung gibt dieser Identität einen Platz und eine Rolle innerhalb von Drupal.
Ist SAML oder CAS besser für eine Universität?
Keines ist grundsätzlich besser — es hängt davon ab, was Ihre Institution bereits betreibt. SAML, einschließlich seiner akademischen Implementierung Shibboleth, ist die richtige Wahl für Institutionen in Forschungsföderationen oder solche, die auf Identitätsplattformen wie Entra ID oder Okta standardisiert sind. CAS eignet sich hervorragend für Universitäten, die bereits einen campusweiten CAS-Server betreiben. Die Entscheidung sollte der bestehenden Identitätsinfrastruktur folgen und nicht einer abstrakten Rangfolge: Verbinden Sie Drupal mit dem System, dem Ihre Institution bereits vertraut, und lassen Sie dies das Protokoll bestimmen.