SAML Authentication – Praktische Anwen­dung und etwas theore­tischer Hinter­grund

Seit 2001 hat man im OASIS Konsortium versucht einen Standard für Authentisierungen und -Authorisierung zu entwickeln. Hauptaugenmerk waren Single Sign On für Webanwendungen und verteilte Transaktionen auf Basis von Webservices.

Nach dem ersten Versuch wurde dann 2008 mit der Version SAML 2.0 (Security Assertion Markup Language) ein Standard verabschiedet, der heute vielfältig zum Einsatz kommt. Dazu findet man vielerlei Informationen im Netz, also will ich mich hier auf die praktische Anwendung beschränken und ein paar Hinweise zum Troubleshooting geben.

Generell brauchen wir eine Instanz, die den User authentifiziert und den SAML Token (SAML Assertion) ausstellt. Man kann das als Badge oder Passierschein verstehen. Der Identity Provider (IdP) muss also die User eindeutig identifizieren und generiert den Passierschein basierend auf den Regeln und den vorhandenen Daten dieses ominösen Tokens. Damit hat der Pförtner / Einlass schon seine Schuldigkeit getan.

Dieser Token wird dann für den Zugriff auf den Service Provider (SP) genutzt. Wenn der Badge korrekt ist, dürfen wir bestimmte Türen damit öffnen und andere vielleicht nicht.

Damit müssen auf der SP Seite keine User-Directories angebunden und keine Credentials verwaltet werden.

Ein Beispiel: Der User benutzt kerberos based Authentication (WIA) gegenüber dem internen ADFS Service (IdP) und bekommt sein SAML Assertion, welcher nur für eine definierte Zeit gültig und digital signiert ist. Damit ist dieser auch nicht mehr veränderbar. Mit diesem Token oder Ticket kann man sich nun gegenüber dem SP Web-Services (z.B. Zscaler ) oder Web-Server (z.B. Salesforce) ausweisen.

Das ist für den User dann auch eine deutliche Verbesserung, da er sich nicht zusätzliche Credentials merken muss und es in diesem Falle sehr transparent für ihn abläuft. Wenn nun noch weitere Service Provider angebunden sind, wird das durch die SSO Möglichkeiten zusätzlich verbessert.

Oder er authentifiziert sich mit seiner Smart Card an der Pulse Secure (IdP), um damit das VPN und den Zugriff auf Web-Services O365 zu erhalten. In diesem Falle ist der Pulse Secure Client mittels embedded Browser SAML fähig.

Zur Unterscheidung folgende Schritte:

IdP initiated Sign On

1. 1. User authentication (UserID, password; certificate based; OTP; …)
   2. Abrufen der notwendigen Informationen von einem ldap, SQL, …
   3. Erstellen des SAML Assertion und Signierung des Tokens
   4. Client erhält Token (als Cookie)
   5. Client benutzt das Cookie für den Zugriff auf Ressourcen am Services Provider

Das sind Zugriffe als IdP initiated Sign On. Im Gegensatz dazu – und das ist viel häufiger – gibt es das SP initiated Sign On. Ich möchte eine Ressource nutzen und werden erste mal zum IdP geschickt, um mich zu authentisieren.

SP initiated Sign ON

1. 1. Benutzer versucht zu surfen
      (als Proxy ist Zscaler definiert und damit landet der User bei Zscaler und muss sich authentisieren)
   2. Zscaler sieht kein SAML Assertion und schickt den Client (Browser) zum IdP
   3. Der IdP (hier Microsoft Azure) identifiziert den User und erstellt das SAML Assertion
      siehe oben 1. bis 4.
   4. Der User weisst am SP das SAML Assertion vor und darf nun den Service nutzen, also in diesem Falle surfen.

Eine Analogie: Im IdP initiated SignOn Verfahren gehe ich erst zum Pförtner und weise mich aus und erhalte mein Badge. Seltener ist es so, dass ich in einen Raum oder ein Gebäude will, dieses verschlossen ist und ich dann erst zum Einlass zurückgehe, um die Zutrittserlaubnis zu erhalten. In der IT-Welt sind die Wege in Millisekunden überwunden und da ist es dann ganz normal.

Aus meiner Sicht ist diese Aufspaltung wichtig, um die einzelnen Schritte separat zu betrachten und den Ablauf zu verstehen. Der Benutzername und die Gruppennamen im Directory Service können dabei unterschiedlich zu dem sein, was dann beim Service Provider vorgewiesen/vorgezeigt wird. Ich melde mich am IdP mit samAccountName oder userPricipalName an, aber als NameID wir die E-Mail-Adresse übergeben, was eine public Information ist. Wir haben aber auch schon IDs (z.B. die SID) übergeben, um Klar-Namen zu vermeiden. Auch die Gruppen könnten dabei «übersetzt werden». Wenn der User in Gruppe «GG-Department-Internet-Access» ist, wird als Gruppen Information Zscaler#n übergeben, damit man keine Rückschlüsse auf die Rolle des Users im Unternehmen ziehen kann. Das SAML Assertion ist ja am Endpunkt lesbar, aber dank digitaler Signatur nicht änderbar.

1.. User Authentication:
first of all, der User muss identifiziert werden.

Wie wir uns am IdP authentisieren, ist eine Frage der Konfiguration und der Möglichkeiten. Sinnvoll ist es natürlich, dies abhängig davon zu machen, auf welche Ressourcen ich zugreifen möchte. Also eine Policy, um zu unterscheiden.

• • User sitzt intern im Office à kann kerberos verwenden.
  • User ist unterwegs an seinem Laptop à Smart Card.
  • User ist an einem Kiosk-Rechner auf einer Konferenz / Hotel Lobby à dann wohl eher OTP.
  • User Client source IP ist aus einem untypischen Land, wo er sich sonst nicht aufhält à kein Zugriff.

2.   Abrufen der notwendigen Informationen:

Wir müssen organisieren, dass nun die richtigen Informationen in das Assertion / den Token / den Claim kommen. Wie immer nur die notwendigen Informationen und nicht was möglich ist. Gerade die Gruppenmitgliedschaften sollten restriktiv genutzt werden.

• • NameID (SMTP Address)
  • Gruppen, die der SP dann für die Authorisierung verwendet
  • eventuell noch ein Displayname oder Department, wenn das Sinn macht oder so.

Und klar die kommen aus dem ldap, das wir meist eh schon zur Verfügung haben.

3.   Erstellen des SAML Assertion und Signierung des Tokens:
Die Informationen knüpfen wir nun in einer XML-Struktur zusammen und unterschreiben dies noch mit unserem guten Namen (signiert mit den Signing Certificate, das dem SP bekannt ist).

4.   Client erhält Token (als Cookie)

5.   Client benutzt das Cookie für den Zugriff auf Ressourcen am Services Provider

• • SP vertraut den Informationen, da es digital signiert ist und der SP den Public Key hat.

Als kleine Animation:

1. Es ist eine SAML Response
   

Man sieht hier für welchen SP das verwendet wird, spezifische ID. InResponseTo ist natürlich die Request ID
Gleich darunter ist auch der Aussteller (Issuer) zu finden.

Nach dem Digest, der Signatur und dem Zertifikat (based64) und kryptografischen Informationen kommt:

2. Erfolgreiche Anmeldung, das Success ist wichtig

Und jetzt beginnt das Assertion.
mit ID, Issuer, Subject, Time Condition, Attributes…

3. Innerhalb des Subjects die NameID, das wird übergeben und muss dann auch beim SP ausgewertet werden
   dfdf
   
4. Gültigkeit

5. Vergleiche mit Destination
   dfdfdf
6. Last but not least die weiteren Attribute:
   Insbesondere GruppenInformationen für eventuell Authorization am SP. Auf der PulseSecure im Role Mapping und bei Zscaler zum Beispiel für das Policy Assignment.

Hinweis: Das Zertifikat kann man per copy&paste in einen Testdatei speichern und diese auf Windows ins cer umbennen und bekommt dann sehr schön das Zertifikat lesbar angezeigt.

Hier wird also mit einem self signed certificate gearbeitet.

Der SAML Request ist dagegen unspektakulär. Wir sehen wieder woher und wohin die Reise für den Browser gehen soll, eine Reference ID, die wir schon kennen.

Der RelayState ist in diesem http-get aber wirklich von Bedeutung, da sonst die Anfrage eventuell vom IdP abgelehnt wird.

better user experience – lower costs – higher security

Wie oben gezeigt, kann die Benutzererfahrung deutlich verbessert werden, der gesamte Anmeldeprozess geht üblicherweise wirklich schnell. Je nach IdP Fähigkeiten können wir hier die optimale Authentisierung definieren, was sonst nicht auf jedem SP abzubilden wäre. Das spart auch Kosten.

Die Sicherheit wird deutlich erhöht. Es werden keine Hashes übertragen, die Authentisierung erfolgt an einer Stelle, die dafür spezialisiert ist und die Benutzerinformationen müssen nicht an vielen Stellen abgelegt und verwaltet werden. Zudem findet eine Reduzierung der Anzahl der Benutzerdatenbanken statt.

SAML Provisioning und SCIM

Die Informationen im SAML Assertion können auch dafür verwendet werden, um Informationen beim SP zu cachen. Leider fehlt ein sauberer Mechanismus für ein CleanUp. Deshalb wird zum Publizieren der Gruppeninformation dann SCIM eingesetzt, damit man schon mal das Policy Assignment machen kann. Aber je nach Fähigkeiten auf der SP Seite, kann man immer die Zuweisung der Ressourcenzugriffe auf Basis von SAML Attributen machen.

Zu SCIM – System for Cross-domain Identity Management vielleicht ein anderes Mal mehr.