Vereinfachte SAML-Authentifizierungsintegration für Entwickler

Single Sign-On (SSO) ist für moderne Anwendungen entscheidend, und SAML ermöglicht sichere, benutzerfreundliche Authentifizierung über verschiedene Unternehmensidentitätssysteme hinweg. Dieser Leitfaden vereinfacht SAML für Entwickler und Designer mit klaren Schritten und praktischen Beispielen, um dir bei einer effizienten Implementierung zu helfen.

Was sind SAML-Authentifizierung und SAML-Apps?#

Security Assertion Markup Language (SAML) ist ein XML-basierter Standard, der für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen zwei Hauptakteuren verwendet wird: dem Identity Provider (IdP) und dem Service Provider (SP). Es ist eine gängige Lösung für Single Sign-On (SSO) in Organisationen und vereinfacht das Leben von Unternehmensanwendern, indem sie sich einmal anmelden und auf mehrere Anwendungen zugreifen können.

Identity Provider (IdP) ist für das Verwalten und Überprüfen von Benutzeranmeldeinformationen wie Benutzernamen und Passwörtern verantwortlich. Wenn ein Benutzer versucht, auf einen geschützten Dienst zuzugreifen, bestätigt der IdP dessen Identität und sendet diese Bestätigung an den Dienst.

• Beispiel: Stell dir vor, du arbeitest in einem großen Unternehmen, das Microsoft Azure AD zur Verwaltung von Mitarbeiterkonten verwendet. Wenn du dich bei Salesforce anmelden möchtest, fungiert Azure AD als IdP. Es überprüft deine Anmeldedaten und informiert Salesforce darüber, dass du zur Nutzung berechtigt bist.

Service Provider (SP) ist die Anwendung oder der Dienst, auf den Benutzer eigentlich zugreifen möchten. Er verlässt sich darauf, dass der IdP die aufwändige Authentifizierung übernimmt.

• Beispiel: Im obigen Szenario ist Salesforce der SP. Es verlässt sich auf Microsoft Azure AD (den IdP), um deine Identität zu bestätigen. Sobald Azure AD für dich bürgt, lässt dich Salesforce rein.

Wenn von einer “SAML-App” die Rede ist, ist damit meistens der SP gemeint.

Mit dem SAML-Protokoll kannst du deinen Dienst als IdP einrichten, um Anwendungsintegrationen zu ermöglichen (wie Azure AD / Google Workspace); oder als SP (wie Salesforce / Slack), um SSO für Benutzer anzubieten.

Eine SAML Assertion ist das Herzstück des SAML-Protokolls. Sie ist eine digitale „Notiz“, die vom IdP erstellt und an einen SP gesendet wird, die besagt: „Ich habe die Identität dieses Benutzers bestätigt.“ Als Nächstes erklären wir, wie der Prozess sowohl für IdP als auch SP funktioniert.

Als SAML Identity Provider agieren#

Wenn dein Dienst als IdP funktioniert, ermöglichst du SAML-Authentifizierung über mehrere Anwendungen hinweg. Das erlaubt Benutzern, auf verschiedene Dienste über eine einzige Unternehmensidentität zuzugreifen.

Hier ist ein typischer SAML-SSO-Workflow für einen IdP:

1. Der Benutzer versucht, auf eine Anwendung (SP) zuzugreifen, zum Beispiel Salesforce.
2. Die Anwendung leitet den Benutzer an deinen IdP zur Authentifizierung weiter.
3. Der Benutzer gibt seine Anmeldedaten auf der Anmeldeseite deines IdP ein.
4. Der IdP überprüft die Anmeldedaten.
5. Wenn die Anmeldedaten korrekt sind, schickt der IdP eine SAML-Assertion an den SP zurück.
6. Der SP verarbeitet die Assertion, bestätigt deren Gültigkeit und gewährt dem Benutzer Zugriff.

Als SAML Service Provider agieren#

Wenn dein Dienst der SP ist, integrierst du dich mit verschiedenen Identity Providern, um deinen Benutzern SSO-Fähigkeit zu bieten. Das ermöglicht es Unternehmensbenutzern aus unterschiedlichen Organisationen oder Mandanten, deine Anwendung sicher und effizient zu nutzen.

Hier ein Workflow für SP-initiiertes SSO:

1. Der Benutzer versucht, sich bei deiner Anwendung anzumelden.
2. Deine Anwendung generiert eine SAML-Anfrage und leitet den Benutzer zur Anmeldeseite des IdP weiter.
3. Der Benutzer meldet sich beim IdP an (oder überspringt diesen Schritt, falls bereits angemeldet).
4. Der IdP verifiziert die Identität des Benutzers und packt nach der Bestätigung die Benutzerdaten in eine SAML-Assertion.
5. Der IdP sendet die Assertion an deine Anwendung zurück.
6. Dein Dienst überprüft die Assertion. Wenn sie gültig ist, erhält der Benutzer Zugriff auf deine Anwendung.

Wichtige Parameter beim SAML-SSO#

Für eine erfolgreiche SAML-SSO-Integration müssen IdP und SP bestimmte Parameter austauschen. Hier ein Überblick über die wichtigsten:

Parameter vom IdP#

1. IdP Entity ID: Eine eindeutige Kennung für den IdP in SAML-Kommunikationen, wie ein digitaler Namensschild.
2. SSO-URL: Die Login-Endpunkt-URL, zu der der SP Nutzer zur Authentifizierung umleitet.
3. X.509-Zertifikat: Ein öffentlicher Schlüssel zum Signieren der SAML-Assertion, der für Sicherheit sorgt. Das ist das „Siegel“ zur Überprüfung der Echtheit.

Tipp: Wenn dein IdP eine SAML Metadata URL bietet, wird alles einfacher. Diese URL enthält alle wichtigen Infos (wie Zertifikate, SSO-URLs und IdP Entity ID) an einem Ort. Sie minimiert Kopierfehler und erspart das manuelle Aktualisieren von Zertifikatsdateien.

Parameter vom SP#

1. SP Entity ID: Die eindeutige Kennung des SP, ähnlich wie die IdP Entity ID.
2. Assertion Consumer Service (ACS) URL: Dies ist der Endpunkt, an dem der SP die SAML-Assertion vom IdP erwartet.
3. RelayState (Optional): Wird verwendet, um Daten während des SAML-Prozesses zu übergeben, zum Beispiel die URL, die der Nutzer ursprünglich besuchen wollte.

SAML-Attributabbildung und Verschlüsselung#

1. NameID-Format: Definiert das Benutzeridentifikationsformat (z.B. E-Mail-Adresse oder Benutzername).
2. SAML-Attribute: Zusätzliche Benutzerdetails wie Rolle, E-Mail oder Abteilung, die der IdP an den SP sendet.
   • Beispiel: Wenn die vom IdP signierte SAML-Assertion email ([email protected]), role (admin) und department (engineering) enthält. Der SP kann role verwenden, um Adminrechte zuweisen oder department, um den Benutzer dem richtigen Team zuzuordnen. Damit diese Daten ankommen, müssen IdP und SP die Attributabbildung festlegen. Beispielsweise definiert der IdP „department“ als team, während der SP es als group erwartet. Nur durch passendes Mapping klappt die Kommunikation reibungslos.
3. Verschlüsselte Assertions (Optional): Zum Schutz sensibler Authentifizierungsdaten können SAML-Assertions verschlüsselt werden.
   • Rolle des IdP: Verschlüsselt die Assertion mit dem öffentlichen Schlüssel des SP.
   • Rolle des SP: Entschlüsselt die Assertion mit seinem privaten Schlüssel, um die Benutzerdaten zu lesen.

Nun solltest du alle nötigen Infos haben, um eine SAML-Verbindung einzurichten. Um Salesforce (Service Provider) mit Azure AD (Identity Provider) zu integrieren, befolge diese Schritte:

• Beschaffe dir IdP Entity ID, SSO-URL und Zertifikat von Azure AD und konfiguriere diese in Salesforce.
• Teile Salesforce’s SP Entity ID und ACS URL an Azure AD mit.

Logto vereinfacht SAML-Integration#

Logto kann sowohl als IdP als auch als SP agieren, um SAML-SSO für deine Anwendungen zu unterstützen.

Logto als SAML IdP verwenden#

Logto ermöglicht es anderen Anwendungen, sich für föderierte Identitätsauthentifizierung darauf zu verlassen, und unterstützt Multi-Faktor-Authentifizierung (MFA) für erhöhte Sicherheit.

1. Erstelle eine Logto App Gehe zu Logto Console > Anwendungen und erstelle eine neue SAML-App.
2. SAML-Parameter konfigurieren Richte die App mit der Assertion Consumer Service URL und der SP Entity ID des Service Providers ein.
3. Metadaten-URL bereitstellen Logto stellt eine IdP-Metadaten-URL bereit, die SPs verwenden können, um alle wichtigen Infos wie SSO-URLs und Zertifikate automatisch zu erhalten.
4. Erweiterte Konfiguration (Optional)
   • Du kannst mehrere neue Zertifikate mit Fingerprints erstellen und Ablaufdaten setzen, aber nur ein Zertifikat kann aktiv sein.
   • Passe das NameID-Format deinen geschäftlichen Anforderungen an.
   • Aktiviere die Verschlüsselung der SAML-Assertion, indem du das x509-Zertifikat deines Service Providers kopierst und damit die Assertions verschlüsselst.
5. Attribute abbilden (Optional) Passe ganz einfach an, wie Benutzerattribute an Service Provider (SPs) weitergegeben werden.

Für ausführliche Anleitungen besuche die offizielle Dokumentation: SAML App

Logto als SAML SP verwenden#

Logto lässt sich auch mit beliebigen Enterprise-IdPs via SAML- oder OIDC-Protokoll integrieren. Egal ob du SP-initiiertes SSO für deine zentralen Anmeldeseiten oder IdP-initiiertes SSO konfigurierst – der Ablauf bleibt einfach.

1. Erstelle einen Enterprise Connector Gehe zu Logto Console > Enterprise SSO und erstelle einen neuen Enterprise Connector. Wähle SAML als Protokollstandard.
2. SAML-Parameter konfigurieren Gib entweder die Metadaten-URL oder die Metadaten-XML-Datei deines IdP an. Falls die Metadaten nicht verfügbar sind, klicke auf manuelle Konfiguration und trage IdP Entity ID, SSO-URL und das Signing-Zertifikat ein.
3. ACS URL und SP Entity ID teilen Gib die ACS URL und SP Entity ID von Logto an deinen IdP weiter, um die Integration abzuschließen.
4. Attribute abbilden (Optional) Konfiguriere die Benutzerdaten-Mappings wie E-Mail oder Namen, damit die Infos korrekt zwischen IdP und Logto übertragen werden.
5. Enterprise-E-Mail-Domains hinzufügen Im Tab „SSO Experience“ des Enterprise Connectors kannst du eine oder mehrere E-Mail-Domains hinzufügen. So wird sichergestellt, dass nur Nutzer mit den angegebenen Domains SSO verwenden können.
6. IdP-initiiertes SSO aktivieren (Optional) IdP-initiiertes SSO solltest du nur aktivieren, falls deine Unternehmenskunden es benötigen. Damit können Benutzer deine Anwendungen direkt vom IdP-Dashboard aus öffnen.

Weitere Anleitungen findest du in der offiziellen Dokumentation: Enterprise SSO Dokumentation.

Fazit#

SAML bietet eine standardisierte und sichere Methode für SSO, die Authentifizierung vereinfachen kann. Logto macht die Einrichtung zum Kinderspiel, egal ob du es als IdP oder SP nutzt. Mit seiner benutzerfreundlichen Oberfläche und den Cloud- und Open-Source-Optionen nimmt Logto der SAML-Integration die Komplexität. Mit nur wenigen Parametern kannst du deine Dienste mit jedem SAML IdP oder SP verbinden und dich darauf konzentrieren, für deine Nutzer großartige Erlebnisse zu schaffen.