saml-2.0 Tutorial
Erste Schritte mit Saml-2.0
Suche…
Bemerkungen
SAML2.0 ist ein offener Standard für die Übertragung von Authentifizierungs- und Autorisierungsdaten zwischen Service Providern und Identity Providern.
Die häufigste Verwendung ist webbasiertes SSO, wobei SAML einem Benutzer ermöglicht, sich mit Anmeldeinformationen von einem anderen System aus bei einer Anwendung anzumelden, ohne dass die beiden Systeme während der Authentifizierung direkt miteinander verbunden werden müssen.
Der SAML2.0-Authentifizierungsablauf
SAML gibt drei Schlüsselrollen an:
Der Identitätsanbieter (IdP)
Die Partei, die die Identität der Benutzer bereitstellt und aufrechterhält. Dies kann ein Verzeichnisdienst wie ADFS oder eine benutzerdefinierte Datenbanklösung sein.
Der Dienstleister (SP)
Der Dienstanbieter ist der tatsächliche Dienst, bei dem der Benutzer versucht, sich anzumelden. Dies kann eine Website, eine Anwendung oder ein Dienst sein, bei dem sich ein Benutzer anmelden muss.
Der Auftraggeber / der Benutzer
Der tatsächliche Benutzer, der die Anforderung initiiert oder versucht, auf eine Ressource vom Service Provider (SP) zuzugreifen.
Der Hauptanwendungsfall von SAML ist Web Based SSO , bei dem der SAML-Prozess durch eine Reihe von Weiterleitungen im Browser des Benutzers ausgeführt wird, wobei der Benutzer als Token-Träger zwischen IdP und SP fungiert.
Es gibt zwei Flüsse für webbasiertes SSO mit SAML:
Identity Provider (IdP) initiiert
Der Benutzer meldet sich beim IdP an und wird dann an den gewünschten SP weitergeleitet. Ein Benutzer meldet sich beispielsweise in einem Unternehmens-Intranet an und erhält alle verfügbaren Anwendungen.
Dienstanbieter (SP) initiiert
Der Benutzer versucht, sich bei einer Anwendung anzumelden, wird jedoch an den IDP weitergeleitet, um die eigentliche Authentifizierung durchzuführen. Ein Benutzer versucht beispielsweise, sich bei einer Remote- SaaS- Anwendung anzumelden , wird jedoch an einen Unternehmens-IDP weitergeleitet, sodass sich der Benutzer mit seinen Unternehmensanmeldeinformationen bei der Remote-Anwendung anmelden kann.
Der durch den SP initiierte Fluss wird im Folgenden durch den Workflow deutlich visualisiert:
Quelle: Wikipedia
- Ein Benutzer versucht, auf eine Ressource in einer bestimmten Anwendung oder Webseite zuzugreifen
- Ein Benutzer gibt an, dass er versucht, sich mit einem externen IdP anzumelden. Der SP generiert eine SAML-Assertion und leitet diese weiter (in der Regel über POST- oder GET-Variablen), während Sie zum IdP weitergeleitet werden
- Der Benutzer authentifiziert sich beim IdP
- Die signierte Zusicherung und das Token werden vom IdP generiert
- Die signierte Assertion und das Token werden (wieder unter Verwendung von POST- oder GET-Variablen) an den SP zurückgeleitet, und bei Erfolg wird eine Sitzung auf dem SP initiiert
- Außerdem kann der Benutzer weitere Ressourcen vom SP anfordern, während er eine aktive Sitzung mit dem SP hat (z. B. durch Cookies), so dass er sich nicht bei jeder Anforderung beim IdP authentifizieren muss.
SAML-Debugging-Tools
Da alle Anforderungen und Zusicherungen hin und her gehen, kann es mühsam sein, Probleme mit Ihren SAML-Ansprüchen und -Absicherungen zu debuggen.
Da in SAML ein Kernprinzip keine direkte Verbindung zwischen dem IdP und dem SP erfordert, fungiert der Browser des Benutzers als Nachrichtenträger zwischen den beiden. Daher erfolgt die gesamte Kommunikation - wenn auch verschlüsselt - über Ihren eigenen Browser.
Mithilfe verschiedener Debugging-Tools können Sie die genaue Kommunikation und Anforderungen sehen und zwischen IdP und SP weiterleiten.
Hier finden Sie einige Tools für verschiedene Browser, mit denen Sie beginnen können:
Chrom
Feuerfuchs
Zum Beispiel können Sie mit SAML Tracer dekodierte SAML-Assertions und -Anforderungen während des Testens und Debuggens in Echtzeit sehen