Wie funktioniert Single Sign-on ?

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:

1.  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.
2. Der Browser erhält eine Anfrage, den Authentication Redirect Request.
3. Das Ganze wird zur UCS-Single Sign-on-Seite weitergeleitet.
4. Eine Aufforderung zur Eingabe der Credentials geht an den Benutzer.
5. Dieser meldet sich an, z. B. mit Benutzernamen und Passwort.
6. 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.
7. Mit dieser Nachricht wendet sich der Nutzer bzw. der Browser an den Dienst und übermittelt sie.
8. 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.