OpenID Connect, kurz OIDC, und Security Assertion Markup Language, SAML, sind in unterschiedliche Kontexten Voraussetzung für Single Sign-On. Dieser Beitrag wirft einen Blick auf die Bedeutung von SSO im Allgemeinen und SAML im Besonderen.
In der Public-Cloud ist häufig von Anwendungen und Diensten die Rede, die eine so genannte moderne Authentifizierung über HTTP-fähige Protokolle und Verfahren unterstützen. Die Beiträge dieser Workshop-Reihe widmen sich der Security Assertion Markup Language (SAML), OpenID Connect (OIDC), der Microsoft Identity Platform und dem Feature Azure AD Business to Customer.
Zwar sind SAML und OIDC seit Jahren etablierte und gut funktionierende Verfahren. Entsprechende Erläuterungen in den einschlägigen Kanälen (einschließlich dieser Seite) fokussieren sich aber entweder auf die Code-technische Umsetzung oder die Vogelperspektive im Hinblick auf die grobe Funktionalität.
Dieser Beitrag schließt die Lücke zwischen beiden Polen und widmet sich der Implementation am Beispiel Azure als IdP und Zoom als eine exemplarische SAML-fähige Anwendung. Entwickler und Entwicklerinnen können darauf aufbauend eigene Anwendungen SSO-fähig machen.
Was ist Single Sign-On?
Die Frage ist zweifelsohne schon häufig aus verschiedenen Blickweisen beantwortet worden. Nutzer melden sich exakt einmal an einem unternehmenseigenen Gerät oder einer unternehmenseigenen App an und habe dann mit den verwendeten Zugangsdaten (Credentials) Zugriff auf weitere für sie freigegeben Apps oder Dienste, ohne diese noch einmal eingeben zu müssen. So weit, so gut. Was bedeutet das aber konkret?
Meldet sich ein User zum Beispiel mit seinem Benutzernamen und dem zugehörigen Passwort an, beweist er dem darunter liegenden System, dass er derjenige ist, der er zu sein vorgibt. Zwar ist dabei heute – insbesondere in der Cloud – meist noch ein zweiter Faktor beteiligt, doch nach erfolgreicher Anmeldung /Authentifizierung kann der oder die Anwender den Dienst nutzen. wozu Dieser eine eigene Session bereitstellt, über welche dann die weitere Kommunikation erfolgt.
Die entscheidende Frage im Hinblick auf Single Sign-On in der Cloud ist, wie das Ganze funktioniert, wenn Identity sowie Service Provider (bei SAML werden „Parteien“ als SAML-Provider bezeichnet) auf unterschiedlichen Systemen laufen. Außerdem soll der Service Provider selbst nie das Passwort des Benutzers kennen. Damit das Ganze funktioniert, muss es also eine Vertrauensstellung zwischen den Diensten (Service Provider) und dem Single Point of Authentication (Identity Provider, IdP) geben.
Daraus folgt, dass irgendwann/irgendwo im Verlauf des Anmeldeprozesses ein „Beweis“ über die erfolgreiche Anmeldung beim IdP an den jeweiligen externen Dienst (Service Provider) weitergegeben werden muss. Dazu bedarf es eines Frameworks oder entsprechen konfigurierte Protokollen, um solche Nachrichten sicher auszutauschen. Generell gibt es zwar unterschiedliche SSO-Mechanismen und -Protokolle, wir reden im Folgenden aber nur von webbasiertem Single Sign-On; in diesem Szenario erfolgt die Anmeldung z. B. am webbasierten myapplications-Portal von Office365, was den Zugriff auf Apps und Dienste in der Umgebung gewährleistet.
Was ist SAML
Generell ist SAML (Security Assertion Markup Language) ein quelloffenes XML-Framework, das den Austausch von Authentifizierungs- und Autorisierungsinformationen ermöglich. Damit vereinfacht es verknüpfte Authentifizierungs- und Autorisierungsprozesse für Benutzer, Identitätsprovider und Dienstanbieter und stellt sicher, dass Identitätsprovider und Dienstanbieter getrennt voneinander geführt werden können. Das wiederrum zentralisiert die Benutzerverwaltung z. B. für den Zugriff auf SaaS-Lösungen, was der Zweck von Single Sign-On ist.
Meldet sich also ein User bei einer SAML-fähigen Anwendung an, fordert der Dienstanbieter eine Autorisierung vom entsprechenden Identitätsprovider an. Der Identitätsprovider authentifiziert die Anmeldeinformationen des Benutzers und gibt die Berechtigung für den Benutzer an den Dienstanbieter zurück, sodass Dieser den Dienst nutzen kann. Also ist die SAML-Authentifizierung exakt der Prozess, der die Identität und die Anmeldeinformationen des Benutzers (Passwort + ggf. MFA) überprüft.
Die SAML-Autorisierung teilt dann dem Dienstanbieter mit, welchen Zugriff er dem authentifizierten Benutzer gewähren soll. Bei SAML spricht man allgemein von SAML-Providern. Letzter ist ein System, das dem Benutzer dabei unterstützt, auf den gewünschten Dienst zuzugreifen. Es gibt zwei Typen von SAML-Providern, nämlich Dienstanbieter (Service Provider) und Identitätsanbieter (Identity Provider), wobei der Dienstanbieter auf die Authentifizierung durch den Identitätsprovider angewiesen ist, um dem Benutzer eine Berechtigung erteilen zu können.
Der Identitätsanbieter überprüft bei der Authentifizierung, ob der Endbenutzer derjenige ist, der er zu sein vorgibt und sendet diese Daten zusammen mit den Zugriffsrechten des Benutzers für den Dienst an den Dienstanbieter. Ein bekannter Identity Provider ist z. B. das Azure AD. Populäre Dienstanbieter sind Salesforce oder Zoom. Eine SAML Assertion ist ein XML-Dokument mit vermerkten Benutzerberechtigungen, das der Identitätsanbieter an den Dienstanbieter sendet. Dabei gibt es derzeit exakt drei Arten von Assertions:
- 1. Die Authentifizierungs-Assertion gilt als Nachweis für die Identifizierung des Users und enthält die Zeit, in der sich der User angemeldet und welche Art der Authentifizierung er verwendet hat.
- 2. Die Attributs-Assertion übergibt SAML-Attribute an den Dienstanbieter, wobei SAML-Attribute spezifische Daten mit den Informationen über den User enthalten.
- 3. Die Autorisierungsentscheidungs-Assertion sagt aus, ob der Benutzer berechtigt ist, den Dienst zu verwenden, oder ob der Identitätsprovider die Anfrage abgelehnt hat, z. B. wegen falschen Passworts oder fehlender Berechtigung für den Dienst.
Single Sign-On mit SAML
Das Vertrauen zwischen Identity Provider und Service Provider wird durch Austausch von Zertifikaten gewährleistet. Analog zur Webserver-Kommunikation gibt es also zwei Zertifikate (public und private). Das öffentliche Zertifikat, z. B. des Azure Active Directory (AD) IdP, muss bei der Einrichtung des Dienstanbieters (z. B. Zoom) hinterlegt werden. Nur so kann der Dienst, an dem sich der User anmeldet, die Beglaubigung des Azure AD Identity Providers überprüfen.
Dazu sind die verschiedenen SAML-Endpunkte von Bedeutung. Hierbei handelt es sich um HTTPS-URLs, an welche die XML-Nachrichten gesendet werden. Allerdings ist bei SAML (im Gegensatz z. B. zu OICC) keine direkte Verbindung zwischen Service Provider und Identity Provider notwendig. Der Webbrowser des Nutzers muss allerdings beide Seiten erreichen können.
Im Azure AD lassen sich Unternehmens-Anwendungen die SAML unterstützen im Abschnitt „Unternehmensanwendungen“ aus unzähligen mitgelieferten Konfigurationsvorlagen recht einfach zur Zusammenarbeit mit Azure AD bewegen. Klicken Sie dazu einfach auf „Neue Anwendung“ und suchen dann im Dialog „Azure AD-Katalog durchsuchen“ nach der gewünschten App, z. B. „Zoom“.
Schon bei der Auswahl ist zu erkennen, dass in diesem Fall Zoom mehrere SSO-Modi unterstützt, wie die Kennwort-, Link- oder SAML-basierte Anmeldung. Klicken Sie dann auf Erstellen. Danach taucht Zoom in der Liste konfigurierter Unternehmensanwendungen auf.
Klicken Sie dann auf Zoom landen Sie zunächst auf der Übersichtsseite mit dem Anwendungsnamen, der Anwendungs-ID und der Objekt-ID. Im Abschnitt „Verwalten / Einmaliges Anmelden“ finden Sie dann die verschiedenen Optionen zur SSO-Konfiguration.
Wenn Sie jetzt auf „SAML“ klicken, haben Sie die Möglichkeit, die verschiedenen SAML-Endpunkte und Metadaten zu konfigurieren. In Azure gelingt das sogar derart komfortabel, dass Sie den angezeigten Konfigurationsassistenten numerisch arbeiten und gleichzeitig oder vorab dem Link zum Konfigurationsleitfaden folgen können:
Im Schritt 1 steht an erster Stelle der Bezeichner (Identitäts-ID). Er identifiziert den SAML Identity Provider für die jeweiligen Dienste gefolgt von der Antwort-URL (Assertionsverbraucherdienst-URL). Außerdem richten Sie hier die Anmelde-URL ein, wenn Sie vom Dienstanbieter initiiertes SSO nutzen. Hierbei handelt es sich um die URL der Anmeldeseite für Ihre Anwendung (wie z. B. https://zoom.us/web/sso/login). Das Feld ist obsolet, wenn Sie vom Identitätsanbieter initiiertes SSO nutzen. Fehlt noch die entsprechende Abmelde-URL.
Es folgen im Schritt 2 die Attribute und Ansprüche (Claims). Das SAML-Signaturzertifikat können Sie im Schritt 3 einrichten und herunterladen. Das sind die Schritte, die in Azure zu erledigen sind. Schritt 5 widmet sich der SSO/SAML-Konfiguration in Zoom unter https://zoom.us/account/sso. Leider benötigen Sie dazu einen kostenpflichtigen Pro- oder Enterprise Account.
Die Zoom-seitige SSO-Konfiguration ist in der Schnellstartanleitung für SSO in Zoom gut erklärt. Dazu brauchen Sie eine genehmigte Vanity-URL, also eine speziell für Ihr Unternehmen erstellte URL wie z. B. <organzation>.zoom.us. Hierbei handelt es sich schlicht um eine Zoom-Sub-Domain, die zur Konfiguration für SSO-Funktion (Single-Sign-On) erforderlich ist. Nutzer können eine Vanity-URL festlegen oder eine vorgeschlagene Vanity-URL von Zoom nutzen. In Zoom (Schritt 5 im Azure-Leitfaden) geben Sie diese Meta-Daten unter https://zoom.us/account/sso ein:
- URL der Anmeldeseite: <SingleSign-OnService>
- URL der Abmeldeseite: <SingleLogoutService>
- Zertifikat: <X509Certificate> ohne “Begin Certificate” und “End Certificate”.
- Aussteller: <ID of EntityDescriptor>
- Bindung: Wählen Sie http-post oder http-redirect
Das Zertifikat wiederrum können Sie wie oben beschrieben von der Azure-AD-Unternehmensanwendungs-Konfiguration herunterladen.
Um abschließend besser zu verstehen, wie genau eine Anmeldung bei einem SAML-fähigen Dienst funktioniert, werfen Sie nun einen Blick auf den Ablauf für SAML.
- 1. Der Browser des Benutzers ruft die Login-Seite des Dienstes oder z. B. den Zoom-Login auf.
- 2. Der Browser erhält als Antwort den Authentication Redirect Request …
- 3. … und wird damit zur Azure-AD Sign-In-Seite weitergeleitet.
- 4. Diese sendet eine Aufforderung zum Eingeben der Credentials an den Benutzer.
- 5. Der Benutzer meldet sich mit seinem Azure-AD Benutzernamen und Passwort und ggf. MFA an.
- 6. Bei Erfolg erhält der der Benutzer eine SAML Assertion in Form einer eine XML-Datei, die eine Signatur mit dem Zertifikat vom Identity Provider enthält.
- 7. Mit dieser (XML) Nachricht wendet sich der Benutzer (in Form des Browsers) wieder an den Dienst und übermittelt die XML-Datei.
- 8. Der Dienst entscheidet dann, ob die Anmeldung gültig ist: Wurde die Nachricht korrekt mit dem privaten Schlüssel des Azure-AD-Zertifikats signiert, beglaubigt der Dienst die Anmeldung und gewährt dem Benutzer Zugriff.
Die Vorgänge laufen alle mehr oder weniger automatisch als URL-Redirection ab. Beobachten Sie dazu ggf. die zugehörigen Umleitungen in Ihren Browser. Wie der jeweilige Dienst zur SMAL-Zusammenarbeit konfiguriert wird, ist zwar immer etwas unterschiedlich (siehe Beispiel Zoom). Meist ist aber das Eintragen der benötigten Metadaten mehr oder weniger selbsterklärend. In den nächsten Teilen schauen wir uns den Prozess für Open ID Connect (OIDC) und OAuth an und anschließend, wie Sie beides in Ihren eigenen Anwendungen implementieren.