--- title: "SAML für einen Enterprise-Kunden an einem Nachmittag" summary: "Ein Firmenkunde will das Login über Entra ID oder Okta. Was das mit EAuth braucht, was seine IT tut und was noch fehlt." author: "Samuel Krauss" author_title: "Founder" publisher: "Elchi Studios" published: 2026-10-03 updated: 2026-10-09 url: https://elchi.dev/de/journal/saml-fuer-einen-enterprise-kunden-an-einem-nachmittag language: de translation_of: https://elchi.dev/en/journal/saml-for-one-enterprise-customer-in-an-afternoon tags: ["eauth","saml","sso","organisations"] words: 1300 --- # SAML für einen Enterprise-Kunden an einem Nachmittag *Von Samuel Krauss, Founder. Veröffentlicht am 3. Oktober 2026.* > Ein Firmenkunde will das Login über Entra ID oder Okta. Was das mit EAuth braucht, was seine IT tut und was noch fehlt. Der erste Firmenkunde, der sagt „Unsere Leute melden sich über Entra ID an“, ist meist der Moment, in dem ein kleines Produkt merkt, was Enterprise-Software in der Entwicklung kostet. SAML ist alt, wortreich und voller Möglichkeiten, es falsch zu machen, und die IT-Abteilung des Kunden testet es gegen genau einen Provider, ihren eigenen. Mit EAuth ist das Ganze eine Seite in der Konsole. Dieser Beitrag geht es durch, auch die Teile, die wir nicht beschleunigen können. ## Zuerst Organisationen Single Sign-on gehört in EAuth zu einer Organisation, nicht zu Ihrer Anwendung als Ganzes. Eine Organisation ist ein Kunde: eine Gruppe von Konten Ihrer Anwendung mit je einer Rolle, eine E-Mail-Domain, die der Kunde verifiziert hat, und, falls er will, eine Verbindung zu seinem Identity Provider. Vor SAML kommen deshalb zwei Dinge. Setzen Sie in den Einstellungen der Anwendung das Häkchen bei **Enable organisations**, legen Sie dann die Organisation des Kunden an und verifizieren Sie seine Domain mit dem TXT-Record, den die Konsole anzeigt. Die Domain entscheidet, wer zum Provider geschickt wird, und sie verhindert, dass der Provider eines Kunden für die Adressen eines anderen Kunden bürgt. Ohne verifizierte Domain lässt sich Single Sign-on nicht einschalten. ## Was Sie tun Öffnen Sie die Organisation, wählen Sie **Set up single sign-on**, und die Konsole zeigt die Seite von EAuth: eine Entity-ID, eine Reply-URL und Metadaten zum Herunterladen, die beides und das Zertifikat für diese Verbindung enthalten. Jede Verbindung hat ihr eigenes RSA-Schlüsselpaar mit 3072 Bit, sodass die Einrichtung eines Kunden nie die eines anderen berührt. Der Administrator des Kunden legt dafür bei seinem Provider eine Anwendung mit diesen beiden Werten an oder liest die Metadaten ein und schickt Ihnen seine Federation-Metadaten zurück. Fügen Sie sie in die Konsole ein, oder tippen Sie Entity-ID, Login-URL und Signaturzertifikat von Hand ein. Entscheiden Sie zwei Dinge: ob Leute bei ihrem ersten Login Mitglied werden und ob sich Mitglieder nur über den Provider bei der Organisation anmelden dürfen. Dann schalten Sie es ein. Das ist Ihr ganzer Teil. Rechnen Sie mit einem Nachmittag, und davon geht das meiste an den Mailwechsel in der Mitte und daran, dass der Administrator des Kunden die richtigen Attributeinstellungen findet. Der Provider muss Login-Anfragen per HTTP-Redirect annehmen, wie es Entra ID, Okta und Google Workspace tun, und die Adresse als NameID oder als E-Mail-Attribut schicken. Die Standardnamen der Attribute sind die, die Entra ID und Okta schicken; weicht ein Provider ab, setzen Sie die Namen in der Konsole. Ein Provider, der nur IdP-initiiertes Login kann, bei dem er eine Antwort postet, nach der niemand gefragt hat, wird absichtlich nicht unterstützt. Warum, steht im Abschnitt über die Prüfungen. ## Was die Leute des Kunden sehen Nennt Ihre Anwendung die Organisation in der Authorization-Anfrage, mit dem Parameter `organization` und deren ID oder Slug, geht eine nicht angemeldete Person direkt zu ihrem Provider, ohne etwas einzutippen. So funktioniert ein Button „Sign in with SSO“ in Ihrem Produkt. Nennt sie sie nicht, hat die Login-Seite von EAuth einen Button **Use single sign-on**: Die Person tippt ihre Geschäftsadresse ein und wird zum Provider ihrer Organisation geschickt. Das Formular mit einer Adresse in der Domain und ohne Passwort abzuschicken, bewirkt dasselbe. Auch eine Registrierung mit einer solchen Adresse geht zum Provider, denn der Provider legt das Konto an. Das erste Login über den Provider legt das Konto bei Ihrer Anwendung an, bereits bestätigt und ohne Passwort. Das ist wichtig seit dem 3. Oktober, seit EAuth keiner Anwendung mehr ein Konto gibt, dessen Adresse niemand bestätigt hat: Bei diesen Konten ist das Wort des Providers die Bestätigung. Ist die Mitgliedschaft beim ersten Login eingeschaltet, tritt das Konto ausserdem mit der Standardrolle der Organisation bei. Ist sie ausgeschaltet, tritt es nirgends bei, bis jemand es einlädt, und Ihre Anwendung bekommt für die Organisation `access_denied`. Ein Konto, das es mit dieser Adresse schon gab, behält seine ID und seine Mitgliedschaften. Hatte sein Besitzer die Adresse bestätigt, wird es so verknüpft, wie es ist. Hatte niemand sie bestätigt, hat es womöglich jemand anderes als die Person registriert, also übernimmt das Wort des Providers das Konto: Passwort, Passkeys und zweiter Faktor fallen weg, die Sessions enden, und Ihr Webhook erfährt `session.revoked` mit dem Grund. Ist **nur über den Provider** eingeschaltet, zählen Passwörter und Passkeys für die Organisation nicht mehr. Ein Passwort, das für eine Adresse in der Domain eingetippt wird, wird nicht einmal angeschaut, die Refresh Tokens der Organisation enden, sobald die Einstellung greift, und ein Token aus einer anderen Art von Login wird bei der Verwendung abgewiesen. ## Was wir bei jeder Antwort prüfen Das ist der Teil, dessen Bau Zeit kostet, und der Grund, ihn von jemandem zu übernehmen, der ihn gebaut hat. Das Prüfen von XML-Signaturen ist Sache einer gepflegten Library: Signature-Wrapping-Angriffe haben Implementierungen bei grossen Herstellern gebrochen, weil die Kanonisierung von XML auf eine Art subtil ist, die jeden Test besteht, den ein Entwickler schreibt. Die Library prüft die Signatur gegen das Zertifikat, das Sie eingefügt haben, nie gegen eines, das in der Antwort mitkam, und sie prüft Destination, Issuer, Zeiten und Recipient. Dazu bindet EAuth jede Anfrage an den Browser, der sie gestartet hat, mit einem Cookie, das nur dieser Browser hat. Eine Antwort, die jemand anderswo beschafft und aus einem anderen Browser postet, meldet also niemanden an. Eine Anfrage bleibt zehn Minuten offen und wird einmal beantwortet, und jede Assertion-ID wird länger gespeichert, als die Assertion akzeptiert werden könnte. Eine abgefangene Antwort, die ein zweites Mal gepostet wird, wird abgewiesen. Die Audience muss die Entity-ID dieser Verbindung sein, und die bestätigte Adresse muss in der verifizierten Domain der Organisation liegen. Wird eine Antwort abgewiesen, sieht die Person das, und die Seite der Organisation in der Konsole zeigt den Grund: eine Signatur, die nicht passt, eine Audience oder Reply-URL, die der Provider falsch hat, eine Adresse ausserhalb der Domain, ein Provider, der die Person auf Anfrage nicht erneut authentifiziert hat. Dort schauen Sie nach, während die IT des Kunden alles einrichtet, und das spart die Runde, in der jede Seite der anderen schreibt „Es funktioniert nicht“. ## Leute entfernen, und frische Logins Entfernt der Kunde jemanden bei seinem Provider, kann sich diese Person nicht mehr darüber anmelden. EAuth erfährt von der Entfernung allerdings nichts. Refresh Tokens, die Ihre Anwendung für die Person schon hat, funktionieren weiter, bis sie ablaufen, also bis zu 30 Tage, ausser das Mitglied wird in der Konsole entfernt oder gesperrt oder die Organisation wird gesperrt. Das beendet die Refresh Tokens der Organisation sofort, und bereits ausgestellte Access Tokens laufen innerhalb von 15 Minuten ab. Eine Anwendung, die ein frisches Login will, kann das sagen. Mit `prompt=login` wird der Provider gebeten, die Person erneut zu authentifizieren (ForceAuthn), und eine Antwort mit einem früheren Login wird abgewiesen. Mit `max_age` zählt die eigene Session des Providers, wenn sie jung genug ist, und wenn nicht, wird der Provider erneut gefragt. Das `auth_time` im ID-Token ist der Zeitpunkt, zu dem sich die Person laut Provider authentifiziert hat, und die Session von EAuth endet spätestens dann, wenn der Provider es sagt. ## Was es nicht tut Es gibt kein SCIM-Provisioning: Konten entstehen beim ersten Login und werden weder vorher angelegt noch entfernt, nachdem der Provider jemanden gestrichen hat. Das ist die Lücke aus dem vorigen Abschnitt und der Grund, warum der Entfernen-Button in der Konsole wichtig ist. Gruppen-Claims des Providers werden nicht auf Rollen abgebildet; Rollen in der Organisation werden in der Konsole gesetzt. Das Artifact Binding wird nicht unterstützt. Ein Wort zum Testen. Unsere End-to-End-Tests laufen gegen einen Identity Provider, der auf derselben SAML-Library aufbaut und seine Antworten so signiert, wie es Entra ID und Okta tun. Das prüft das Protokoll und unsere Abweisungen. Es ist nicht dasselbe wie eine Session in der Admin-Konsole jedes Herstellers, und die erste Verbindung zu einem bestimmten Provider ist die Stelle, an der seine besonderen Einstellungen zum Vorschein kommen. Für diesen Nachmittag steht der Abweisungsgrund auf der Seite der Organisation. ## Quellen 1. [Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf), OASIS, gelesen am 2026-10-03 2. [SAML Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html), OWASP, gelesen am 2026-10-03 3. [On Breaking SAML: Be Whoever You Want to Be](https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/somorovsky), USENIX Security 2012, gelesen am 2026-10-03 4. [Single sign-on SAML protocol](https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol), Microsoft, gelesen am 2026-10-03 5. [Enterprise SSO with SAML, EAuth documentation](https://docs.elchi.dev/enterprise-sso), Elchi Studios, gelesen am 2026-10-03