- SAML (Single Assertion Markup Language) ist ein Standard, der Regeln für den Austausch sicherheitsbezogener Nachrichten im XML-Format definiert
- Es wird hauptsächlich für den Nachrichtenaustausch zwischen drei oder mehr unabhängigen Entitäten verwendet
- Ein typisches Szenario ist, dass zwei Softwaresysteme verschiedener Unternehmen und ein Benutzer beteiligt sind
- Die beiden Systeme müssen Informationen über den Benutzer austauschen
- Man könnte auch eine benutzerdefinierte Integration bauen, aber diese ist schwer zu warten
- SAML vereinfacht komplexe Integrationsarbeit, indem es dafür sorgt, dass Systeme denselben Regeln folgen
Format von SAML-Nachrichten
- SAML-Nachrichten bestehen aus XML
- Es definiert die Nachrichtensyntax und erklärt, wie der Nachrichteninhalt sicher verarbeitet werden soll
- Wenn man ein
<Response>-Tag erhält, weiß man zum Beispiel, dass man nach einem <Assertion>-Tag suchen sollte
- Es gibt Anleitungen dazu, wie digitale Signaturen aussehen, und wie Nachrichten verarbeitet werden müssen, um Sicherheitsprobleme zu vermeiden
Die Flexibilität von SAML
- SAML wurde mit starkem Fokus auf Flexibilität entworfen. Grundsätzlich kann man mit SAML vieles tun, aber diese Flexibilität führt auch zu Komplexität
- Die SAML-Spezifikation enthält unzählige Ausnahmen sowie viele ifs und Beispiele, die zusätzliche Edge Cases schaffen
- Da SAML alt ist, nutzen manche Menschen diese Flexibilität aus
- In realen Produktionsumgebungen, besonders in Legacy-Systemen, kann sich SAML manchmal ungewöhnlich verhalten
- Meistens wird das Leben einfacher, wenn man sich nur auf eine kleine Teilmenge von SAML konzentriert
Wofür SAML in der Praxis verwendet wird
- SAML wird hauptsächlich für Single Sign-On (SSO) verwendet
- SAML definiert einige etwas seltsame SSO-Typen, aber normalerweise wird das Web Browser SSO Profile verwendet
- Der Endbenutzer authentifiziert sich zuerst bei einem zentralisierten System und greift dann auf die gewünschte Softwareanwendung zu
- Der Benutzer authentifiziert sich nicht direkt bei der Anwendung
- Wenn Sie zum Beispiel schon einmal Okta verwendet haben, um auf E-Mails zuzugreifen, haben Sie das Web Browser SSO Profile verwendet
An SSO beteiligte Entitäten
- An SSO sind drei Akteure beteiligt:
- Benutzer: die Person, die die Anwendung verwenden möchte
- Service Provider (SP): die Anwendung selbst
- Identity Provider (IdP): der zentrale Dienst, den der Benutzer zur Authentifizierung verwendet
- Der IdP jedes Kunden kann als Datenbank betrachtet werden. Er verwaltet Daten über Personen
- Unternehmen verwenden Identity Provider oft, um Mitarbeiter Abteilungen zuzuordnen und verschiedene Berechtigungen zu vergeben
- Bei jeder Benutzeranmeldung über SAML müssen Informationen vom IdP abgerufen werden. Bei SSO wird der IdP hauptsächlich gebeten, die Benutzeridentität zu bestätigen
- Es ist eine vorab konfigurierte Vertrauensbeziehung mit dem IdP erforderlich
- Jeder Kunde, der SAML SSO verwendet, benötigt eine eigene Konfiguration in der Anwendung
- Allerdings tauscht man nicht direkt Nachrichten mit dem IdP aus. Bei SAML SSO kommunizieren Service Provider und Identity Provider über den Browser des Benutzers
Wie die Entitäten in SAML miteinander interagieren
- Typischer SAML-SSO-Prozess:
- Ein Benutzer versucht in einem Webbrowser auf einen Teil der Anwendung zuzugreifen
- Es wird geprüft, ob der Benutzer einen gültigen Sicherheitskontext hat
- Da der Benutzer keinen gültigen Sicherheitskontext hat, wird eine Anmeldeseite angezeigt
- Der Benutzer gibt einige Informationen ein, zum Beispiel eine E-Mail-Adresse, die verwendet werden, um die passende Anmeldemethode zu bestimmen
- Der Benutzer wird auf die Webadresse des IdP weitergeleitet, und über den Browser des Benutzers wird eine SAML-Nachricht an den IdP übermittelt
- Der IdP zeigt dem Benutzer eine Aufforderung zur Eingabe von Zugangsdaten. Der Benutzer wird erfolgreich authentifiziert
- Der IdP leitet den Benutzer mit einer SAML-Nachricht, die Informationen über die Authentifizierung des Benutzers enthält, zurück zur Anwendung
- Die SAML-Nachricht wird verarbeitet, und es wird entschieden, dass ein Sicherheitskontext für den Benutzer eingerichtet werden soll
- Dem Benutzer wird Zugriff auf den gewünschten Teil der Anwendung gewährt
- Der SAML-SSO-Prozess kann auch vom Identity Provider aus gestartet werden
- In diesem Fall erhält man eine Authentifizierungsantwort, ohne zuvor eine Authentifizierungsanfrage gesendet zu haben
- Bei der Implementierung von Unterstützung für SAML SSO sollte man auf IdP-initiiertes SSO vorbereitet sein
In SAML ausgetauschte Nachrichten
- Bei SAML SSO sind hauptsächlich zwei Nachrichtentypen relevant
- Eine Nachricht vom Service Provider an den IdP wird als SAML-Anfrage (request) bezeichnet
- Eine Nachricht vom IdP zurück an den Service Provider wird als SAML-Antwort (response) bezeichnet
- SAML-Anfragen sind eigentlich nicht besonders komplex. Es reicht, XML per HTTP-Redirect zu senden
- Das
<AuthnRequest>-Tag enthält eine ID, damit der IdP die zugehörige <Response> der ursprünglichen Anfrage zuordnen kann
- Es werden auch Daten gesendet, die in ein
<Issuer>-Tag eingeschlossen sind, um dem IdP mitzuteilen, wer der Absender ist
- SAML-Antworten sind kniffliger. Sie werden normalerweise per POST übertragen
<Response> umschließt konzeptionell mehrere <Assertion>-Tags<Assertion> umschließt Claims über den Benutzer, etwa wer er ist und wie er sich beim IdP authentifiziert hat- Durch die Verarbeitung der Assertion wird entschieden, ob der Benutzer angemeldet werden soll
Hinweise
- Hier wurden viele Details ausgelassen, insbesondere sicherheitskritische Aspekte
- Wenn Sie sich nicht persönlich für SAML interessieren oder beruflich einen Grund haben, sich intensiv damit zu befassen, ist es nicht empfehlenswert, SAML-basiertes Login selbst zu implementieren. Das ist Zeitverschwendung
- Wenn Sie SAML so schnell wie möglich einrichten möchten, stellen wir das Open-Source-Projekt SSOReady bereit, das SAML abstrahiert. Es wird Ihnen viel Zeit und Schmerz ersparen
Noch keine Kommentare.