SSO mit Authentik - Was ist das?

Ahoi,

Single-Sign On ist eine tolle und vor allem bequeme Funktion, welche die meisten Internet-Nutzer bereits verwendet haben. Meist sogar, ohne es zu wissen. SSO wird überall da benutzt, wo es nötig ist, jemanden anhand zentral abgelegter Daten gegenüber einem Dritten zu authentifizieren.

Dieser Dritte kann alles Mögliche sein, häufig handelt es sich aber um Webseiten und Computer / Remote Desktop.

Was ist Single-Sign On?

Draw.io: Diagram anzeigen

Im Alltag begegnet man SSO bei YouTube, Google Drive, Gmail uvm. wo ein einziger Account für die Authentifizierung gegenüber mehreren Diensten verwendet wird. In dem Beispiel respektive ein Google-Account, um sich gegenüber YouTube, Google Drive oder Gmail zu verifizieren. Es bietet dadurch den Vorteil, dass nur ein Passwort für mehrere Dienste gleichzeitig genutzt werden kann ohne, dass es ein Risiko darstellt (dazu, später mehr).

Im Unternehmensumfeld wird SSO gerne für die Authentifizierung von Mitarbeitern gegenüber internen Diensten wie einem Wiki oder Remote Desktop verwendet.

Wie funktioniert Single-Sign On?

Für die Umsetzung haben sich in den letzten Jahrzehnten verschiedene Protokolle entwickelt

• SAML

• OAuth (2.0)

• OpenID Connect

• JWT

• LDAP / Active Directory

Jedes einzelne Protokoll zu erklären, würde den Beitrag unendlich aufblasen. Ich überlasse das dem Marktführer für SSO-as-a-Service auth0.com - Single-Sign On: Protocols.

Grundsätzlich funktioniert es so:
Der Dienst gegenüber wem sich der Nutzer authentifizieren möchte, fragt beim Identity Provider (IdP) an, ob der Nutzer authentifiziert ist.

Falls nein, wird der Nutzer vom IdP aufgefordert, sich zu authentifizieren und leitet den Nutzer daraufhin zurück zum angefragten Dienst.

Falls ja, übersendet der Nutzer meist eigenständig bereits ein Token (JWT, HTTP-Header, Cookie, POST/GET Parameter) beim Aufruf des Dienstes. Dieser fragt anschließend beim IdP an, ob das Token korrekt ist und dieser antwortet daraufhin mit einem OK und Metadaten, zu dem Nutzer.

Die Metadaten können beispielsweise Benutzername, Vorname, Nachname und die E-Mail Adresse enthalten, ganz wichtig aber: Kein Passwort! Das Token vom IdP hat seinen Platz eingenommen. Der angefragte Dienst kann dann anhand dieser Informationen einen lokalen Nutzer erstellen und mit den Metadaten vom IdP “verknüpfen”, falls der Nutzer neu ist.

Und sonst noch?

Auch wenn es den Anschein macht, wird nicht das Token vom IdP zur Bestimmung der Eindeutigkeit eines Nutzers verwendet. Einige der oben genannten Protokolle erlauben es, einen beliebigen Wert aus den Metadaten als Schlüssel (UID) zu verwenden. In der Regel gibt aber der Dienst selber vor, welchen Wert aus den Metadaten er als Schlüssel verwendet.

Wie du vielleicht ahnst, kann man auch pro Dienst verschiedene Werte aus den Metadaten als UID verwenden und so auch bereits existierende lokale Accounts in einem Dienst mit einem Benutzer aus dem SSO Benutzerverzeichnis verknüpfen.

@xtrc - Anmerkung

Abhängig von dem Dienst, welchen man schützen möchte, kann es nötig/möglich sein, zusätzliche Einstellungen über die Metadaten vorzunehmen. WordPress zum Beispiel fragt auch die Gruppen eines Nutzers ab. Lautet eine davon “admin”, wird der WordPress-Benutzer ebenfalls in die WordPress-Gruppe “admin” hinzugefügt.

Änderungen an den Metadaten werden also oft erst dann wirksam, wenn sich der Nutzer gegenüber einem Dienst neu authentifiziert und dieser so eine neue Kopie der Metadaten erhält.