Mehr zu Identity und Service Providern, SAML und OpenID Connect sowie weiteren technischen Voraussetzungen für die Benutzer-Authentifizierung
Single Sign-on (SSO), also die Einmalanmeldung, macht es möglich: Nutzer*innen melden sich einmal mit ihren Zugangsdaten an und erhalten automatisch Zugriff auf alle Programme und Dienste, die für sie freigegeben sind. Sie authentifizieren sich also einmalig gegenüber einem Server, danach übernimmt der SSO-Mechanismus die Authentifizierung gegenüber weiteren Diensten.
In diesem Artikel möchte ich zunächst die technischen Grundlagen erklären und dann näher auf die beiden Authentifizierungs-Standards OpenID Connect und SAML (Security Assertion Markup Language) eingehen – beide Methoden stehen für Univention Corporate Server (UCS) zur Verfügung. Danach zeige ich Ihnen kurz den Ablauf einer SSO-Authentifizierung für beide Standards, gefolgt von Tipps zur Fehlersuche. Die wichtigsten Begriffe, die ich im Artikel verwende, erklärt das kleine SSO-Glossar.
Inhaltsverzeichnis
Kleines SSO-Glossar
- Identity Provider: der Dienst, der die Benutzer*innen authentifiziert (z. B. Überprüfung von Benutzername und Passwort), um zu beglaubigen, dass eine Person wirklich die ist, die sie vorgibt zu sein
- Service Provider/Relying Party: entfernter Dienst, also die Partei, die sich darauf verlässt, dass jemand erfolgreich authentifiziert wurde
- Entities: eindeutig identifizierbare Objekte oder auch Dienste, die bei der Authentifizierung zusammenspielen
- Web Endpoints: HTTP-/HTTPS-URLs zur Kommunikation und zum Nachrichtenaustausch zwischen den Webdiensten
- Issuer: die ausstellende Stelle, also die Entität, die eine Nachricht verfasst und unterschrieben hat zur Beglaubigung
Was ist Single Sign-on?
Wenn sich ein Benutzer mit dem Benutzernamen und dem zugehörigen Passwort anmeldet, beweist er dem darunter liegenden System, dass er wirklich der ist, der er zu sein behauptet. Manchmal ist noch ein zweiter Faktor mit im Spiel, wie etwa ein YubiKey oder eine SMS – das heißt dann Zwei-Faktor-Authentisierung (2FA). Egal, wie die Anmeldung erfolgt – nach der Authentifizierung kann der oder die Anwender*in den Dienst nutzen, bei dem er oder sie sich gerade angemeldet hat. Dazu öffnet der Dienst eine eigene Session, und darüber läuft dann die weitere Kommunikation.
In Bezug auf Single Sign-on stellt sich die Frage, wie der Prozess funktioniert, wenn Identity Provider und Service Provider auf unterschiedlichen Systemen laufen und der Service Provider nie das Passwort des Benutzers erhalten soll. Damit SSO funktioniert, muss es ein Vertrauen zwischen den Diensten und dem Single Point of Authentication geben. Im Klartext heißt das, dass im Verlauf der Anmeldung ein Beweis über die erfolgreiche Anmeldung an den externen Dienst weitergegeben werden muss. Wenn sich ein Benutzer also beispielsweise am UCS-Portal anmeldet, muss dieses mit den angebundenen externen Diensten kommunizieren. Dazu braucht es ein Framework oder auch ein Protokoll, das entsprechend konfiguriert sein muss, um diese Nachrichten sicher auszutauschen.
Es gibt verschiedene SSO-Mechanismen und -Protokolle. In diesem Artikel spreche ich ausschließlich von Web Single Sign-on, das heißt, Anwender*innen melden sich z. B. am webbasierten UCS-Portal einmalig an und erhalten danach Zugriff auf Apps und Dienste in der Umgebung. UCS unterstützt auch Single Sign-on über Kerberos, was ich nur der Vollständigkeit halber erwähne. In diesem Text geht es um die beiden Standards SAML (Security Assertion Markup Language) und OpenID Connect. Wenn Sie sich dafür interessieren, wie UCS diese beiden Standards miteinander vereint, empfehle ich den Blogartikel Zwei Standards, aber ein gemeinsames Single Sign-on: Integration von SAML und OpenID Connect.
Schauen wir uns nun an, wie Single Sign-on mit OpenID Connect und SAML genau abläuft.
Single Sign-on mit OpenID Connect
Bevor Benutzer*innen sich das erste Mal anmelden, müssen Admins zunächst das Vertrauen zwischen dem Identity Provider (hier: UCS) und den anderen Diensten herstellen. OpenID Connect nutzt dazu ein Shared Secret, was im besten Fall ein sehr langes Passwort ist. Administratoren müssen also in UCS und beim externen Dienst dasselbe geteilte Geheimnis hinterlegen. Die Endpunkte, zwischen denen die Nachrichten ausgetauscht werden, sind bei OpenID Connect viele verschiedene URLs für verschiedene Aktionen. Diese werden beispielsweise für die Anmeldung, das Abrufen von Informationen über den Benutzer und das Abmelden genutzt.
Admins sollten bei der Planung berücksichtigen, dass bei der Verwendung von OIDC alle Server, auf denen Dienste laufen, bei denen Anwender*innen sich per SSO anmelden möchten, eine direkte Verbindung per HTTPS zum Identity Provider brauchen, also zum Beispiel zu UCS. Es ist daher sinnvoll, dies schon im Vorfeld bei den Firewall-Regeln und den Weiterleitungen zu berücksichtigen.
In den hier verwendeten Beispielen ist der UCS IdP unter ucs-sso.mydomain.intranet erreichbar; die URL https://ucs-sso.mydomain.intranet/.well-known/openid-configuration stellt die Metadaten bereit, die Admins unter anderem für die Konfiguration und zum Verbinden des Dienstes mit anderen Services benötigen. Als Erstes wird der issuer definiert, also die ausstellende Stelle. In diesem Beispiel ist das der UCS SSO OpenID Connect Provider. Es folgen verschiedene Endpunkte, gegen die dann Nachrichten ausgetauscht werden. Der erste ist der authorization_endpoint, wo die Authentifizierung ankommt. Am userinfo_endpoint können dann die Benutzerdaten abgerufen werden.
Single Sign-on mit SAML
Bei SAML wird das Vertrauen zwischen Identity Provider und Diensten durch Zertifikatsaustausch sichergestellt. Das heißt, es gibt zwei Zertifikate (public und private), wie sie beispielsweise auch bei Webservern vorkommen. Administratoren müssen das öffentliche Zertifikat des UCS IdP bei der Einrichtung des Dienstes hinterlegen, damit der Dienst, an dem sich Benutzer anmelden, die Beglaubigung des UCS Identity Providers verifizieren kann.
Schauen wir uns die SAML-Endpunkte an. Genau wie bei OpenID Connect funktioniert das über HTTPS-URLs, an die die Nachrichten geschickt werden. Dabei gibt es einen wichtigen Unterschied: Bei SAML ist keine direkte Verbindung zwischen Service Provider und Identity Provider erforderlich. Lediglich der Webbrowser der Nutzer*innen muss beide Seiten erreichen können.
Die SAML-Endpunkte und -Metadaten finden Sie ebenfalls über eine URL (https://ucs-sso.mydomain.intranet/simplesamlphp/saml2/idp/metadata.php). Ganz oben steht die entityID – sie entspricht dem Issuer bei OpenID Connect und identifiziert den SAML Identity Provider für die jeweiligen Dienste. Am Ende der recht komplexen XML-Datei sehen Sie die Endpunkte für den Austausch der Nachrichten.
Wie läuft SSO bei OpenID Connect und bei SAML ab?
Um besser zu verstehen, wie eine Anmeldung bei einem Dienst stattfindet, erkläre ich den Ablauf einmal für OpenID Connect und einmal für SAML – das ist wichtig, um das Gesamtkonzept zu verstehen und um eventuelle Probleme zu identifizieren und zu lösen (Stichwort: Debugging).
Fangen wir an mit OpenID Connect: Ganz links im Bild ist der Enduser bzw. der User Agent, also der Webbrowser, in der Mitte der Dienst, bei dem die Anmeldung erfolgen soll (z. B. bei Kopano Meet). Ganz rechts in der Skizze zu sehen ist der Identity Provider, also UCS.
1. Beim Login besucht ein Benutzer zunächst eine Website mit dem Browser. Sobald er auf einen Login-Button für einen Dienst klickt, passieren diverse Weiterleitungen.
2. Der erste Redirect geht zurück zum Browser.
3. Der nächste Redirect geht von dort aus zum UCS Identity Provider. Hier wird unter anderem auch der Name des Dienstes übertragen, an dem sich der Benutzer anmelden möchte – damit der Benutzer nach der Anmeldung wieder korrekt zurückgeleitet werden kann.
4. Dieser schickt eine Login-Seite zum Benutzer, der bis dahin noch nicht bekannt ist, der also keine Session hat.
5. Der Benutzer gibt seine Credentials (z. B. Benutzername und Passwort) ein.
6. Der Identity Provider kontaktiert den Benutzer noch einmal: „Der Dienst XYZ hat folgende Daten von dir angefordert (z. B. E-Mail-Adresse, Telefonnummer usw.).“ Der Nutzer kann der Übertragung zustimmen. In der Regel überspringen wir in UCS diesen Punkt, weil der Administrator allein durch die Einrichtung des Dienstes für seine Benutzer schon zugestimmt hat, dass die Daten übertragen werden sollen.
7. Der Benutzer bestätigt die Anfrage.
8. Nach erfolgreicher Anmeldung erhält der Webbrowser einen Autorisierungs-Code, ein so genanntes Token.
9. Dieses wird per HTTP-Request zurückgeleitet zum Dienst, bei dem sich der Benutzer anmelden möchte.
10. Jetzt kommt eine Besonderheit bei OpenID Connect im Vergleich zu SAML: Der Dienst fragt bei UCS noch einmal nach: „Hier ist ein Benutzer, der hat mir einen Code übermittelt – bitte liefere weitere Informationen zu dem Benutzer aus.“ Das kann die E-Mail-Adresse, seine Gruppenzugehörigkeit, die Telefonnummer oder etwas anderes sein.
11. Der Identity Provider übermittelt die angeforderten Informationen.
12. Erst wenn das geklappt hat, kann der Dienst eine Session für den Benutzer öffnen, dieser kann sich anmelden und den Service nutzen.
Schauen wir uns als Nächstes den Ablauf für SAML an:
- Der Start sieht ähnlich aus: Der Browser des Benutzers landet auf der Login-Seite (entweder beim Dienst oder im UCS-Portal). Der Anwender klickt den Login-Button.
- Der Browser erhält eine Anfrage, den Authentication Redirect Request.
- Das Ganze wird zur UCS-Single Sign-on-Seite weitergeleitet.
- Eine Aufforderung zur Eingabe der Credentials geht an den Benutzer.
- Dieser meldet sich an, z. B. mit Benutzernamen und Passwort.
- Jetzt kommt eine SAML-Besonderheit: Als Beglaubigung der Anmeldung erhält der Benutzer eine SAML Assertion, eine XML-Datei, die eine Signatur mit dem Zertifikat vom Identity Provider enthält.
- Mit dieser Nachricht wendet sich der Nutzer bzw. der Browser an den Dienst und übermittelt sie.
- Der Dienst entscheidet nun, ob die Anmeldung gültig ist: Nur wenn die Nachricht mit dem korrekten privaten Schlüssel des UCS-Zertifikats signiert ist, beglaubigt der Dienst die Anmeldung und gewährt dem Benutzer Zutritt.
Bitte beachten Sie, dass die Konfiguration der Dienste jeweils anders abläuft: Bei manchen Services ist das Eintragen der Metadaten selbsterklärend, bei anderen ist die Konfiguration etwas komplizierter – daher ist es gut, zunächst das grundlegende Konzept zu verstehen.
Tipps zum Debuggen von Single Sign-on mit SAML
Beide Methoden haben eines gemeinsam: Es werden relativ viele Nachrichten ausgetauscht, und diese kann sich der Admin selbstverständlich auch zu Debugging-Zwecken anschauen. Wenn es irgendwo hakt, gibt es einige Möglichkeiten, eventuelle Probleme aufzuspüren. Wenn wir uns an dieser Stelle nur mit SAML beschäftigen, empfehle ich die Firefox-Erweiterung SAML-tracer zum Anzeigen der Nachrichten, die während der einmaligen Anmeldung und der einmaligen Abmeldung über den Browser gesendet werden. Debugging von OIDC ist komplexer, weil hier auch direkte verschlüsselte Kommunikation zwischen Dienst und IdP mitgeschnitten werden muss – daher gehe ich hier nicht näher darauf ein.
Ich habe noch einen zweiten Tipp für Sie: Verwenden Sie zum Debuggen immer ein privates Fenster (Firefox) oder ein Fenster im Inkognito-Modus (Chrome). Mir ist es schon häufiger passiert, dass ich eine Konfiguration korrigiert habe, aber keine Veränderung bemerken konnte. Eine Session in meinem Browser-Cache hat einfach meinen aktuellen Test verfälscht.
Wie üblich lautet eine Empfehlung, die Logfiles zu analysieren – und zwar sowohl die Protokolle auf UCS-Seite (Identity Provider) als auch die des Dienstes (Service Provider). Gerade bei externen Diensten kann das wichtig sein: Wir schicken eine – unserer Meinung nach – gültige Nachricht an den Dienst, dieser quittiert das aber nur mit einer leider nicht sehr aussagekräftigen Fehlermeldung, und Benutzer können sich nicht anmelden. Sofern der Admin keinen Zugriff auf die Protokolle hat, ist es hilfreich, den Support des externen Dienstes zu fragen, ob eine Information in den dortigen Logs auftaucht.
UCS als Identity Provider verwendet Syslog zum Protokollieren, und jede Anmeldung sollte in der Datei /var/log/syslog auftauchen. Im Zweifelsfall hilft es, den Debuglevel zu erhöhen, sollten die Informationen in den Logfiles nicht aussagekräftig genug sein. Dazu setzen Admins die UCR-Variable saml/idp/log/debug/enabled auf TRUE und die Variable saml/idp/log/level auf DEBUG.
SAML-Debugging mit dem Firefox-Add-on SAML-tracer
Im Folgenden möchte ich noch einmal im Detail zeigen, wie Administratoren mit der Firefox-Erweiterung SAML-tracer die SAML-Nachrichten betrachten und analysieren können. Im UCS-Portal klicke ich den Button ANMELDEN und lande dann im Dialog zur Eingabe von Benutzernamen und Passwort. Gleichzeitig lasse ich das Firefox-Add-on protokollieren, was im Hintergrund passiert:
Auf dem Reiter SAML können Sie die Meldungen betrachten. Auf unserem Screenshot sehen Sie, dass vom Browser der Authentifizierungs-Request (AuthnRequest) an UCS geschickt wurde. Hier stehen ein paar wichtige Details. Zunächst einmal zeigt das Protokoll die AssertionConsumerServiceURL, also die URL, die die Anfrage gestellt hat. Der UCS-Server weiß also nun, dass die Anfrage von portal.internet.domain kommt. Auch das Ziel (Destination) ist klar – so kann UCS sicherstellen, dass wirklich der Empfänger der Nachricht gemeint ist. Außerdem wird ein Identifier (ID) mitgeschickt; dieser steht auch später in der Antwort, nachdem sich der Benutzer erfolgreich angemeldet hat. Ein Zeitstempel verrät, wann das Ganze passiert ist. Der Issuer wird ebenfalls übertragen; das ist in diesem Beispiel das Portal.
Noch eine wichtige Zusatzinfo zu den Zeitstempeln: Sowohl bei OpenID Connect als auch bei SAML ist es unbedingt erforderlich, dass alle Uhren korrekt gehen! Die ausgetauschten Nachrichten sind immer nur eine begrenzte Zeit lang gültig, damit potenzielle Angreifer nicht den Netzwerkverkehr mitschneiden, (mit viel Rechenzeit) dieses Paket entschlüsseln und versuchen, sich selbst anzumelden.
Nachdem die Anmeldung mit Benutzernamen und Passwort erfolgt ist, wird der Browser zum Portal umgeleitet. Was wurde jetzt genau im Hintergrund übertragen, um den Benutzer zu identifizieren? Das ist zunächst einmal eine SAML-Response, die neben einem Zeitstempel als Destination das Portal eingetragen hat. In der Antwort steht wiederum der Identifier und zwar im InResponseTo-Arttribut, das die Session aufgreift, mit der wir eben im Portal gestartet sind. Auch in der Antwort ist die ausstellende Seite als Issuer hinterlegt, hier der UCS Identity Provider. Das hilft dem Portal oder dem externen Dienst bei der Zuordnung. Dabei kommen die Zertifikate zum Einsatz, die der Administrator vorher hinterlegt hat.
Der Issuer taucht gleich mehrmals im Protokoll auf, weil die Nachricht aufgrund ihrer Komplexität in verschiedene Bereiche unterteilt ist, die dann auch von den Diensten unterschiedlich ausgewertet werden können. Im Abschnitt, der mit Subject beginnt, geht es um den Benutzer, der sich angemeldet hat. In der vierten Zeile sehen wir beispielsweise einen langen String: Der Benutzername wird nicht direkt als Subject mitgeschickt, sondern folgt später als Attribut. Das ist für verschiedene SAML-Dienste unterschiedlich zu konfigurieren.
In der SubjectConfirmationData ist explizit noch einmal beschrieben, dass das Portal der Adressat dieser Nachricht ist. Und auch hier wird nochmal die Session-ID übertragen, damit die Zuordnung passt. Am Ende der Nachricht (nicht mehr auf dem Screenshot zu sehen) sind verschiedene Attribute zu sehen, unter anderem der Benutzername. Für das Portal ist das eine wichtige Information, damit die interne Zuordnung gelingt.
Noch Fragen?
Zugegeben, das ganze Thema ist recht komplex. Gerade wenn Sie nachträglich die Konfiguration anpassen wollen, gilt es natürlich zu beachten, dass alle Server in der Domäne entsprechend eingerichtet werden. Auch eventuell neu hinzukommende Systeme gilt es zu berücksichtigen – am besten mit einer entsprechenden UCR-Richtlinie. All diese Informationen und mehr habe ich daher in einem eigenen Artikel zusammengetragen, den Sie in unserer Knowledge Base finden.
Ich hoffe, dass ich Ihnen mit diesem Artikel die Grundlagen zu Single Sign-on, OpenID Connect und SAML näherbringen konnte. Falls es noch offene Fragen gibt, nehmen Sie gerne Kontakt zu uns auf oder diskutieren Sie mit uns im Forum. Sie können auch gerne einen Kommentar hier im Blog hinterlassen.