SAML verstehen

SAML in 3 Minuten

Mit SAML melden Sie sich mit dem Konto Ihrer Organisation bei einer Anwendung an, ohne dass die Anwendung je das Passwort sieht.

Siehe auch: die Zeitleiste der SAML-Geschichte · die von OAuth und OpenID Connect

Ein Bild zum Verstehen

Stellen Sie sich ein Konzert vor. Die Anwendung ist die Halle: Sie will wissen, wer hereinkommt, prüft aber Ihre Papiere nicht selbst. Der Identitätsprovider ist der Akkreditierungsschalter Ihres Unternehmens: Er kennt Ihre Identität wirklich. Am Eingang schickt Sie die Halle zum Schalter, der Ihnen einen versiegelten Ausweis mit Ihrem Namen aushändigt. Die Halle vertraut nur dem Siegel, das sie zu erkennen weiß.

Dieser versiegelte Ausweis ist die SAML-Assertion. Das Siegel ist die Signatur.

Die drei Akteure

Sie

Der Benutzer mit seinem Browser. Er trägt die Nachrichten von einer Seite zur anderen.

Die Anwendung

Der Dienst, auf den Sie zugreifen wollen. Im Fachjargon „SP“, für Service Provider.

Der Identitätsprovider

Der, der Sie authentifiziert: Microsoft Entra ID, Okta, Keycloak, Google Workspace… Im Fachjargon heißt er „IdP“.

Eine Anmeldung in fünf Schritten

Siein Ihrem BrowserApplicationder Dienst (SP)IdentitätsproviderIhre Organisation (IdP) 1 Ich öffne die Anwendung und ich bin noch nicht angemeldet 2 „Können Sie diese Person identifizieren?“ Anfrage (AuthnRequest), vom Browser übermittelt Authentifizierung: Passwort, MFA… 3 „Hier ist ihre Identität, signiert“ Antwort (Response + Assertion), über den Browser 4 Ich bin angemeldet die Anwendung hat die Signatur geprüft (5)
  1. Sie öffnen die Anwendung. Sie sieht, dass Sie nicht angemeldet sind.
  2. Es schickt Sie zu Ihrem Identitätsprovider mit einer Anfrage: „Identifiziere diese Person und schick sie an diese Adresse zu mir zurück.“
  3. Der Identitätsprovider authentifiziert Sie (Passwort, Freigabe auf dem Telefon…). Dieser Schritt findet nur auf seiner Seite statt.
  4. Es schickt Sie mit einer signierten Nachricht zur Anwendung zurück: der Assertion (wer Sie sind, für welche Anwendung, bis wann).
  5. Die Anwendung prüft die Signatur und die Bedingungen und öffnet dann eine Sitzung für Sie.

Was die Assertion enthält

  • Wer: der Bezeichner der Person (die NameID, oft ihre E-Mail).
  • Für wen: die Empfängeranwendung (die Audience) und die genaue Empfangsadresse (der ACS).
  • Bis wann: ein sehr kurzer Gültigkeitszeitraum, einige Minuten.
  • Was sonst: Informationen über die Person (Name, Gruppen…), Attribute genannt.
  • Das Siegel: die Signatur, die beweist, dass die Nachricht wirklich vom Identitätsprovider stammt und nicht verändert wurde.

Warum die Anwendung der Nachricht vertraut

Vor dem ersten Test tauschen die Anwendung und der Identitätsprovider eine Art technischen Personalausweis aus: die Metadaten. Sie enthalten ihre Namen (Entity ID), ihre Adressen und vor allem das Zertifikat, mit dem das Siegel erkannt wird. Das ist der „Konfigurations“-Teil, und dort liegen fast alle Probleme.

Was auf jeder Seite zu konfigurieren ist

Seite des IdentitätsprovidersAnwendungsseite
Der Name der Anwendung (Entity ID)Der Name des Identitätsproviders (Entity ID)
Die Adresse, an die die Person zurückgeschickt wird (ACS-URL)Die Adresse, an die man sie zur Identifizierung schickt (SSO-URL)
Optional das Zertifikat der AnwendungDas Zertifikat des Identitätsproviders

Ein Ein-Zeichen-Fehler (ein Schrägstrich am Ende, http statt https) genügt, um alles zu blockieren. ID-Kit sagt Ihnen genau, welcher Wert nicht passt.

Und wo passt ID-Kit hinein?

  • Haben Sie eine Anwendung zu testen? ID-Kit spielt den Identitätsprovider.
  • Haben Sie einen Identitätsprovider zu testen? ID-Kit spielt die Anwendung.

Zum Weiterlesen: die technischen Details oder häufige Fehler.

Möchten Sie es live sehen? ID-Kit übernimmt die Rolle, die Ihnen fehlt, und zeigt Ihnen jeden Schritt.

Meinen Bereich öffnenEine SAML-Antwort dekodieren