Lange Zeit war es üblich, dass jede Anwendung ihre eigene Benutzerdatenbank hatte. Dies stellte die Benutzer*innen vor die Herausforderung, sich eine Vielzahl von Zugangsdaten merken zu müssen. Post-its mit Benutzernamen und Passwörtern unter der Tastatur oder im Korpus waren daher keine Seltenheit. Durch die Delegation der Authentifizierung an zentrale Systeme, so genannte IdP’s, haben die Benutzer*innen nun die Möglichkeit, sich mit einem Account in mehreren Anwendungen anzumelden.
Federated Authentication, Identity Provider, Service Provider, Relying Party, SAML, OpenID Connect, Claims, … Wer mit diesen Begriffen nichts anfangen kann, ist hier genau richtig. In den folgenden Zeilen versuche ich ein wenig Ordnung in das Begriffswirrwarr zu bringen.
Federated Authentication
Wäre es nicht praktisch, wenn wir uns bei allen Webseiten und Anwendungen, den sogenannten Service Providern (SP), mit den gleichen Zugangsdaten authentifizieren könnten? Gerade im geschäftlichen Umfeld ist die Idee nicht neu. Anwendungen wurden an den zentralen Verzeichnisdienst angebunden, so dass sich die Mitarbeitenden mit ihrem normalen Windows-Account anmelden konnten. Dieser Ansatz hat jedoch zwei entscheidende Nachteile.
- Die Anwendungen benötigen direkten Zugriff auf den Verzeichnisdienst. Beim Einsatz von Anwendungen ausserhalb des Firmennetzwerkes ist dies jedoch nicht möglich.
- Die Applikationen kommen in den Besitz von Benutzernamen und Passwörtern.
Federated Authentication geht daher noch einen Schritt weiter. Anstatt die Anmeldedaten gegen ein zentrales System zu prüfen, wird der gesamte Anmeldevorgang an einen so genannten Identity Provider (IdP) delegiert. Die Benutzer*innen werden dazu auf eine Anmeldeseite des IdP weitergeleitet.
Zum besseren Verständnis hier ein einfaches Beispiel einer Authentifizierung an einer Web-Applikation mit dem SAML-Protokoll:
- Der*die Benutzer*in ruft im Browser eine Web-Applikation auf, die durch Federated Authentication geschützt ist.
- Die Web-Applikation erkennt, dass der*die Benutzer*in nicht angemeldet ist und leitet ihn*sie an den für die Authentifizierung zuständigen IdP weiter.
- Der*die Benutzer*in meldet sich beim IdP an. Bei Multi-Faktor-Anmeldungen wird an dieser Stelle auch der zweite Faktor geprüft.
- Nach erfolgreicher Anmeldung leitet der IdP den*die Benutzer*in zurück zur Web-Applikation. Dabei wird ein sogenanntes Security Token (Assertion) mit Informationen über den*die Benutzer*in mitgeschickt.
- Die Web-Applikation validiert das Security Token und prüft anhand der Informationen im Token, ob der*die Benutzer*in Zugriff auf die Applikation hat.
- Der*die Benutzer*in erhält Zugriff auf die Web-Applikation.
SAML und OpenID Connect
Die Kommunikation zwischen Service Provider und IdP erfolgt über definierte Protokolle:
- SAML ist ein etwas in die Jahre gekommenes Protokoll. Es ist für den Einsatz in klassischen Webanwendungen konzipiert, bei denen die Anmeldung über das Backend angestoßen wird. Zudem muss die Anmeldung zwingend in einem Browser oder Browser-Widget erfolgen. Moderne Konzepte wie Refresh-Token und On-Behalf-Of werden nicht unterstützt.
- OpenID Connect ist der Newcomer unter den SSO-Protokollen, auch wenn es mittlerweile schon einige Jahre alt ist. Durch seinen modularen Aufbau unterstützt es verschiedene moderne Anwendungsfälle wie Single Page Application, Mobile Apps, Geräteautorisierung. Dies führt aber auch dazu, dass die Verwendung des Protokolls im Vergleich zu SAML wesentlich komplexer ist.
Assertion, Security Token, Claims
Nach erfolgreicher Anmeldung erstellt der IdP ein sogenanntes Security Token (Assertion) mit Informationen über den*die Benutzer*in und signiert dieses. Dadurch kann der Service Provider sicher sein, dass das Token vom gewünschten IdP ausgestellt und nicht verändert wurde. Die Informationen im Token werden als Claims bezeichnet. Ein Claim ist ein Schlüssel-Wert-Paar, das aus einem Claim-Type und einem Wert besteht. Der Claim-Type ist nicht eindeutig. D.h. ein Security Token kann mehrere Claims desselben Typs enthalten. Dies ist z.B. wichtig, wenn AD-Gruppen in das Security Token gepackt werden.
Fazit
Federated Authentication bietet viele Vorteile. Nicht nur Anwendende profitieren von einer verbesserten Benutzererfahrung. Die zentrale Verwaltung von Identitäten reduziert daneben den Administrationsaufwand und erhöht die Sicherheit.
