Nachdem Stefan uns in seinem TechUp über SSO mit KeyCloak und Angular bereits ein praktisches Beispiel zum Thema Single Sign-on mit dem Identity Provider KeyCloak gezeigt hat, wollen wir heute einen Schritt zurück begeben und uns sämtliche Theorie rund um das Thema IdP anschauen. Hierbei wollen wir die Theorie und Geschichte hinter dem Konzept des IdP, sowie seiner wohl bekanntesten Möglichkeit, SAML, beleuchten.

Identification vs. Authentication vs. Authorization

Zu Beginn wollen wir einige wichtige Begrifflichkeiten rund um das Thema IdP oder generell Benutzeranmeldung im Web erklären.

• Identification: Wer bist du?

  • Identification (dt. Identifikation) besagt, um wen oder was es sich handelt
  • Dies geschieht klassischerweise über einen Benutzernamen, eine ID oder ein anderes, eindeutiges Benutzermerkmal wie z.B. eine E-Mail-Adresse

• Authentication: Beweise, wer du bist!

  • Authentication (dt. Authentifizierung) beweist, dass die vorgegebene Identität korrekt ist
  • Dies geschieht meist über eine Kombination aus Username / Password, über ein One Time Password (OTP), eine PIN oder ein anderes Sicherheitsmerkmal

• Authorization: Was darfst du?

  • Authorization (dt. Autorisierung) besagt, welche Rechte auf welche Ressource man besitzt
  • Dies geschieht klassischerweise über eine Role Based Access Control (RBAC) oder ein anderes System zur Berechtigungsverwaltung

Wichtig zu erwähnen ist, dass diese Schritte in dieser Reihenfolge aufeinander aufbauen.

IdP?

Ein Identity Provider (IdP, dt. Identitätsanbieter) ist ein heutzutage oft cloudbasierter Dienst, welcher die Identität eines “Principal” (dt. Prinzipal) verifiziert. Ein Principal ist eine Entität, welche durch ein System wie dem IdP authentifiziert werden kann. Dieser kann nicht nur ein normaler User sein, sondern sich auch auf einen technischen Benutzer, ein System, einen Dienst oder eine Netzwerkkomponente beziehen. Grundlegend kann jede Einheit ein Principal sein, welche sich identifizieren und authentifizieren lässt. Anschliessend können dem Principal dann Berechtigungen zugewiesen werden (Authorization).

Oft beinhaltet ein IdP einen Service zur Benutzerauthentifizierung. Die sogenannte Relying Party (oder auch im SAML Kontext: Service Provider), beispielweise eine Web-Applikation, lagert die Benutzerauthentifizierung zu einem trusted Identity Provider aus. Im IdP liegen dann auch sämtliche Flows, Templates für die Eingabemasken etc. Die Relying Party bekommt dann einen vollständig authentifizierten Principal vom IdP zurück, der Benutzer ist somit eingeloggt. Die eigentlichen Benutzerdaten liegen meist nicht direkt im IdP, sondern in einem Directory wie z.B. eine LDAP.

Diesen Prozess nennt man auch Federation. Der IdP wurde zuvor mit einem (oder mehreren) Relying Parties verbunden, beide vertrauen sich. So gibt es einen Single Control Point for Authentication, alle Systeme verlassen sich auf den IdP und müssen selbst keine Authentication durchführen.

Wichtige Keywords:

• Realm: Eine logische Gruppierung von Sicherheitsrichtlinien, Flows, Usern und weiteren für den Authentication / Authorization Prozess benötigten Items. Oft stellt eine Top-Level-Domain einen Realm als isolierter Mandant auf dem IdP dar.
• Level of Assurance (LOA): Der Grad des Vertrauens der Korrektheit der Identität des Users
• Zero Trust: Verschiedene Konzepte und Prinzipien, wie Policies im IAM Bereich angewandt werden sollten. Zu Zero Trust haben wir bereits dieses TechUp veröffentlicht, schau rein!

SSO

Ein wichtiges Keyword, welches rund um das Thema IdP oft zu hören ist: SSO. 🤔

Mit dem single sign-on (SSO) Authentication Konzept kann man einen Principal über mehrere Systeme hinweg erkennen und nutzen. Der Benutzer muss sich hierfür nur einmalig anmelden und ist in allen verbundenen aber trotzdem unabhängigen Systemen angemeldet. Ein gutes Beispiel hierfür ist die Google Suite. Ist man bei Gmail angemeldet, wird man automatisch via SSO bei allen anderen Google Diensten wie z.B. dem Google Kalender angemeldet. Wichtig ist, dass nicht nur das Anmelden, sondern auch das Abmelden einheitlich funktioniert.

SAML

Nun wollen wir uns das erste Sicherheitsprotokoll, welches die meisten IdP’s unterstützen, genauer anschauen.

Die Security Assertion Markup Language (SAML) ist ein offener Standard, ein XML-Namespace und ein Protokoll, welches erlaubt, Authentifizierungs- und Autorisierungsdaten von einem IdP zu einen Service Provider (SP) zu übergeben. Konkret stellt SAML Funktionen zur Verfügung, um sicherheitsbezogene Informationen zu beschreiben und korrekt und sicher zu übertragen. Oft wird es für single sign-on Use Cases verwendet.

SAML wurde 2001 (!) von dem sogenannten OASIS-Konsortium entwickelt, dazu gehörten unter anderem Microsystems, IBM, Nokia und SAP. Nach SAML 1.1 wurde 2005 dann der heute immer noch genutzte Standard SAML 2.0 veröffentlicht, welcher nicht zu SAML 1.1 rückwärtskompatibel ist. SAML selbst funktioniert nur mit HTTP-basierten Systemen wie einem Browser.

Wichtige Keywords

• Identity Provider (IdP): Überprüft, ob der Benutzer derjenige ist, für den er sich ausgibt. Sendet Daten und Zugriffsrechte an den SP zurück (siehe oben).
• Service Provider (SP): Die Zielanwendung, Webapplikation oder generell ein Service, benötigt die Authentifizierung des Benutzers durch den Identity Provider, da dem Benutzer Berechtigungen erteilt werden sollen (auch Relying Party genannt).
• Assertion: Ein XML-Dokument, welches der IdP an den SP sendet, enthält Informationen über den Benutzer, dessen Rechte und die genutzte Authentifizierung. Das Dokument wird mit einem X.509-Zertifikat signiert, um die Echtheit zu gewährleisten. Ausserdem enthält es Metadaten wie Conditions (wie lange ist diese gültig usw.) und eine Issuer ID.
• Metadata File: Ein XML-File, welches die SAML-Konfigurationen, Zertifikate und weitere Informationen für IdP und SP beinhaltet und ausgetauscht werden muss. Auf beiden Seiten muss die korrekte Config bestehen, damit der SAML Flow funktioniert. Mit dem Metadata Exchange wird der Trust zwischen SP und IdP hergestellt.
• Bindings: Definiert, wie Assertions und Messages zwischen IdP und SP gesendet werden. Klassischerweise via HTTP Redirect Binding oder via HTTP Post Binding.
• SAML Context Classes: Zeigt, welche Authentifizierungsmethode genutzt wurde. Wird in der Assertion an den SP gesendet, SP kann dies akzeptieren oder ablehnen und nach einer stärkeren Authentifizierungsmethode fragen. Kann spezifisch mit eigenen Methoden erweitert werden. Beispielsweise: “urn:oasis:names:tc:SAML:2.0:ac:classes:Password” für die Password Auth Method.

Technisch gesehen nutzt SAML im Hintergrund ein Session-Cookie. Dieses Cookie wird bei allen Requests an den Service-Provider gesendet. Dadurch ist keine direkte Verbindung zwischen SP und IdP nötig.

Flow

Grundlegend ist der Flow im SAML Context einfach zu erklären, trotzdem sollte man zwischen zwei Arten unterscheiden. Hier ist noch anzumerken, dass sich die Datenübertragung, ob ein POST oder ein Redirect gemacht wird je nach Binding unterscheiden kann.

IdP-Initiated Flow

Bei IdP Initiated Flow fragt der User direkt den IdP an. Dort wird, wenn noch nicht vorhanden, eine IdP-Session für den User erstellt. Der User wird authentifiziert und die SAML Assertion wird dann zum Client und anschliessend an den SP gesendet.

1. Benutzer ruft direkt den IdP auf
2. Benutzer gibt seine Anmeldedaten auf dem IdP ein
3. Der IdP authentifiziert den Benutzer, stellt eine SAML Assertion aus und schick diese dem Benutzer
4. Über einen POST Request (je nach Binding) sendet der User Agent die Assertion dann an den SP

Anschliessend wir eine Session zwischen User Agent und SP gestartet und der Benutzer wird im SP korrekt erkannt.

SP-Initiated Flow

Beim SP-initiated Flow geht der erste Call direkt an den SP. Dieser erkennt, dass noch keine Session besteht und sendet ein “Request for Authentication Message” via Redirect an den IdP. Dieser sorgt dann für die Authentifizierung, erstellt eine Session und die SAML Assertion wird via User Agent zum SP gesendet.

1. Benutzer ruft den SP aus
2. Da der Benutzer nicht authentifiziert ist, sendet der SP einen Redirect an den IdP, genannt “request for authentication”
3. Via Redirect gelang der Benutzer zum IdP
4. Nach der Eingabe der Anmeldedaten wird dieser authentifiziert
5. Die SAML Assertion wird vom IdP erstellt und über den User Agent…
6. … an den SP gesendet

Anschliessend wir eine Session zwischen User Agent und SP gestartet und der Benutzer wird im SP korrekt erkannt.

Dies ist meist der klassische Weg, da der Benutzer direkt zur Applikation will und die Applikation dann den Redirect zum IdP mit allen Parametern usw. macht.

Vorteile

• Erhöhte Sicherheit
• Idealerweise nur noch eine Username / Passwort Kombination
• Kostenreduzierung, da User Management zentral gemacht wird
• User Experience wird dank SSO erhöht
• SAML Unterstützung ist weiter verbreitet

Nachteile

• Single Point of Failure = IdP
• Diebstahl des Session-Cookies ermöglicht Missbrauch der Session

Kurz zusammengefasst

Nehmen wir an, wir wollen an einem Strassenfest eine Portion Pommes kaufen. An der Pommesbude erfahren wir aber, dass man einen personalisierten Bon für die Pommes benötigt. Also gehen wir zur Kasse, nennen unseren Namen, das Codewort und, ob wir Ketchup oder Mayo möchten und bezahlen die Pommes. Nachdem unsere Angaben geprüft wurden, laufen wir mit unserem Bon in der Hand zur Pommesbude und erhalten dort nun unsere Pommes! 🍟

In diesem Beispiel fungiert die Pommesbude als Service Provider (SP). Man kann sich seine Pommes nur mit einem Bon, der SAML Assertion holen. Diesen Bon bekommt man an der Kasse, nachdem man sich dort persönlich angemeldet hat. Die Kasse fungiert hier als Identity Provider (IdP). Das Codewort (Metadaten & Zertifikat) zwischen SP und IdP fungiert hier als Federation, ein Vertrauen (Trust) besteht zwischen beiden Einheiten.

Je nachdem, ob ich direkt zur Kasse oder erst zur Pommesbude laufe, habe ich entweder einen IdP oder einen SP initiated Flow.

Ausblick

In der Identity & Access Management (IAM) Serie wollen wir uns im nächsten Teil OAuth und OIDC genauer anschauen! Stay tuned! 🚀