## Hintergrund Ich begann mit dem Aufbau von Logto, weil ich bemerkte, dass Identitäts- und Zugriffsmanagement (IAM) mit der Zeit immer komplexer und umfangreicher geworden ist. Das Konzept von IAM ist sogar groß genug, um neue Konzepte wie WIAM (Workforce IAM) und CIAM (Customer IAM) hervorzubringen. Während WIAM und CIAM die gleiche Grundlage teilen, haben sie unterschiedliche Anwendungsfälle: WIAM wird typischerweise für interne Benutzer verwendet, während CIAM für externe Kunden eingesetzt wird. Einige Beispiele: - **WIAM** Dein Unternehmen hat ein einheitliches Identitätssystem für Mitarbeiter, sodass jeder dasselbe Konto nutzen kann, um auf Unternehmensressourcen zuzugreifen, wie Software-Abonnements, Cloud-Computing-Dienste usw. - **CIAM** Dein Online-Buchladen benötigt ein Benutzeridentitätssystem für Kunden und Verkäufer. Die Anmeldeerfahrung ist ein entscheidender Teil der Einführung, da sie an der Spitze des Conversion-Funnels steht. Logto begann aus verschiedenen Gründen mit CIAM (wir werden einen weiteren Artikel darüber schreiben). Während der Entwicklung erkannten wir, dass es vorteilhaft wäre, ein einheitliches Verständnis im Team zu schaffen, bevor wir unser Produkt auf die nächste Ebene bringen. Wir hoffen, dass dies auch dir hilft, einen besseren Überblick über die IAM-Landschaft zu gewinnen. Lasst uns anfangen! ## Die Grundlagen von CIAM Unabhängig von ihren Unterschieden haben WIAM und CIAM die gleiche Grundlage: Authentifizierung und Autorisierung. Diese beiden Konzepte stehen im Kern ihrer Funktionen. In diesem Artikel konzentrieren wir uns auf die grundlegenden Konzepte von CIAM und Probleme, denen wir während oder nach dem Authentifizierungsablauf begegnen können. Wir werden auch über Single Sign-On (SSO) und seine damit verbundenen Szenarien sprechen. ### Authentifizierung und Autorisierung - Authentifizierung (AuthN) beantwortet die Frage „Welche Identität besitzt du?“ - Autorisierung (AuthZ) beantwortet die Frage „Was kannst du tun?“ > 💡 Authentifizierung wird anfänglich als "Wer bist du?" definiert. Wenn wir jedoch über digitale Identitäten sprechen, ist es genauer, Authentifizierung als "Nachweis des Besitzes der Identität" darzustellen. (Dank an [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) Wenn du etwas entdeckst, das in keine dieser beiden Kategorien passt, ist es wahrscheinlich nicht essenziell für das Identitätsgeschäft. - **Beispiele für Authentifizierung** - Passwort-Anmeldung, passwortlose Anmeldung, soziale Anmeldung usw. - Machine-to-Machine-Authentifizierung - **Beispiele für Autorisierung** - Rollenbasierte Zugriffskontrolle - Attributbasierte Zugriffskontrolle - **Beispiele für Ausnahmen** - Nicht-Identitätsdaten - Webhooks ### Identität und Mandant Eine Identität stellt typischerweise entweder einen Benutzer oder eine Maschine dar. Bei erfolgreicher Authentifizierung wird ein ID-Token als Identität ausgestellt. Mit anderen Worten, das Hauptziel der Authentifizierung ist es, eine Identität zu erhalten. Ein Mandant ist eine Gruppe von Identitäten: ```mermaid graph TD Tenant --- A[Identity: User 1] Tenant --- B[Identity: User 2] Tenant --- C[Identity: Machine 1] ``` Wenn wir von "Multi-Tenant" sprechen, beziehen wir uns auf mehrere Logto-Instanzen, die identitätsmäßig voneinander isoliert sind. Mit anderen Worten, auf mehrere Logto-Instanzen. ```mermaid graph TD T1[Tenant 1] --- A[Identity: User 1] T2[Tenant 2] --- B[Identity: User 1] T2[Tenant 2] --- C[Identity: Machine 1] subgraph IS2[Identity system 2] T2 B C end subgraph IS1[Identity system 1] T1 A end ``` Beachte, dass es zwei **isolierte** Identitätssysteme gibt, d.h. du kannst die Identität von Mandant 1 nicht in Mandant 2 verwenden, selbst wenn es derselbe Identifikator (E-Mail, Telefon usw.) ist. Es ist wie deine Costco-Mitgliedschaft, die bei Whole Foods nicht gültig ist. 🧱 Kurz gesagt, es gibt “physische Wände” zwischen Mandanten. Die Definition von "Mandant" variiert zwischen CIAM-Produkten. Einige beziehen sich auf den Begriff "Organisation" in Logto, der später vorgestellt wird. ### App und Mandant Genau wie eine Identität gehört auch eine App zu einem Mandanten. Einige Dinge, die zu beachten sind: - Es gibt normalerweise keine direkte Beziehung zwischen einer App und einer Identität. - Eine Identität kann eine App darstellen, aber es gibt keine direkte Verbindung zwischen ihnen. - Genau wie Benutzer sind auch Apps mandantenübergreifend. - Apps sind Code, während Benutzer Menschen sind. - Der alleinige Zweck von Apps besteht darin, Authentifizierung durchzuführen, d.h. eine Identität zu erhalten. ### Identitätsanbieter (IdP) und Dienstanbieter (SP) Der Unterschied zwischen diesen beiden Anbietern ist knifflig, aber wichtig. - **Identitätsanbieter** ist ein Dienst, der Authentifizierung (AuthN) anbietet und Identitäten ausstellt. Du kannst verschiedene Erklärungen zu Dienstanbietern von Google finden, obwohl sie möglicherweise nicht zufriedenstellend sind. In meinen Augen ist der Dienstanbieter ein relatives Konzept: - **Dienstanbieter (oder Reliance Party in [OIDC](https://openid.net/specs/openid-connect-core-1_0.html))** ist ein Dienst oder Client, der die Authentifizierung (AuthN) initiiert und das Ergebnis von Identitätsanbietern anfordert. #### Quiz Betrachte ein typisches Szenario bei sozialer Anmeldung: ```mermaid graph LR A[iOS App] --> |Log-in aufrufen| Logto --> |Weiterleitung| GitHub GitHub --> |Gibt GitHub-ID zurück| Logto --> |Gibt Logto-ID zurück| A ``` **❓ Wie viele Dienstanbieter und Identitätsanbieter gibt es in diesem Diagramm?**

Antwort

Beide haben zwei. Die iOS-App ist ein Dienstanbieter für Logto, während Logto ein Identitätsanbieter ist. Logto ist auch ein Dienstanbieter für GitHub, während GitHub ein Identitätsanbieter ist. Somit ist Logto sowohl ein Dienstanbieter als auch ein Identitätsanbieter.

## Fallstudie: Ein Tech-Lösungsunternehmen Du bist ein CTO eines Tech-Lösungsunternehmens, du hast über 100 Geschäftspartner und du hast über 300 Projekte geliefert. - Jedes Projekt ist entweder eine Web-App oder eine mobile App mit einem Backend-Service. - Für jeden Geschäftspartner möchtest du das Benutzersystem umstrukturieren, um SSO über seine Projekte hinweg bereitzustellen. **❓ Wie kann Logto (oder ein CIAM-Produkt) helfen?**

Antwort

Erstelle eine Logto-Instanz für jeden Geschäftspartner. Jeder Partner hält einen Mandanten. Projekte werden in Logto „Apps“ zugeordnet. ```mermaid graph TD T1[Tenant 1] --- A[App 1] T1 --- B[App 2] T1 --- C[App 3] T1 --- U1[User 1] T1 --- U2[User 2] T2[Tenant 2] --- D[App 1] T2 --- E[App 2] T2 --- U21[User 1] T2 --- U22[User 2] ``` Logto bietet eine universelle Anmeldeerfahrung (d.h. SSO) innerhalb eines Mandanten, sodass Benutzer sich nicht erneut anmelden müssen, wenn sie auf eine andere App im gleichen Mandanten zugreifen, nachdem sie sich bereits angemeldet haben.

## Worüber wir sprechen, wenn wir über SSO sprechen Wir haben festgestellt, dass der Begriff “SSO” oft Verwirrung stiftet. Wir betrachten Single Sign-On (SSO) als ein Verhalten, nicht als ein Geschäftskonzept. Daher ist SSO nicht gleich „SSO im WIAM“. Wenn wir sagen „es benötigt SSO“, kann es sich auf einen der folgenden Fälle beziehen: ### SSO-Fall 1 > 👉🏽 In einem großen Unternehmen verwenden Mitarbeiter dieselben Anmeldeinformationen, um sich bei allen firmenlizenzierten Ressourcen (z.B. E-Mail, Instant Messaging, Clouddienste) anzumelden. Es ist das typische WIAM-Szenario. In diesem Fall ist nur ein Identitätsanbieter beteiligt. Darauf gehen wir jetzt nicht ein. ### SSO-Fall 2 > 👉🏽 Endbenutzer verwenden dieselben Anmeldeinformationen, um sich bei allen von derselben Firma entwickelten Diensten anzumelden (Beispiel: GSuite). Logto konzentriert sich derzeit auf den oben skizzierten Ansatz. Mehrere externe Identitätsanbieter, wie beispielsweise ein Drittanbieter für soziale Anmeldung, können unabhängig und ohne Verbindung existieren. Trotzdem bleibt Logto die einzige Quelle der Wahrheit für Identitäten und "leiht“ sie sich einfach von anderen Anbietern. In diesem Fall agiert Logto sowohl als Identitätsanbieter (für GSuite-Apps) als auch als Dienstanbieter (für externe Identitätsanbieter). ### SSO-Fall 3 > 👉🏽 Endbenutzer können nur den spezifischen Identitätsanbieter innerhalb der entsprechenden E-Mail-Domain verwenden, um die Authentifizierung abzuschließen. Zum Beispiel die Anmeldung bei Figma mit Google Workspace. Dies ist der häufigste Anwendungsfall für SSO im CIAM. Lassen Sie uns einen genaueren Blick darauf werfen. Wenn wir uns bei Figma mit unserer @silverhand.io E-Mail anmelden möchten, können wir entweder die soziale Anmeldung oder SSO verwenden. Die folgenden Abbildungen veranschaulichen den Unterschied zwischen den beiden:

In Worten: - Nach der sozialen Anmeldung können Benutzer ein Passwort festlegen oder die E-Mail-Adresse in Figma ändern. - Nach SSO können Benutzer kein Passwort festlegen oder persönliche Informationen einschließlich ihrer E-Mail-Adresse ändern, da ihre Identitäten von Google Workspace verwaltet werden. In diesem Fall ist Logto sowohl ein Identitätsanbieter als auch ein Dienstanbieter. Es scheint, dass SSO komplexer ist als ein normaler Anmeldevorgang. Was sind die Vorteile für den Identitätsinhaber? - **Zentrale Steuerung:** Halte Identitätsinformationen und Authentifizierungsprozesse an einem Ort und stelle sicher, dass Benutzerinformationen immer auf dem neuesten Stand sind. Es ist nicht erforderlich, Lizenzen über verschiedene Anwendungen hinweg für Änderungen hinzuzufügen und zu entfernen. - **Verbesserte Benutzererfahrung:** Identitätsinhaber, die SSO benötigen, sind normalerweise Unternehmen. Ihre Mitarbeiter können dieselben Anmeldeinformationen und gemeinsame Sitzungen für unternehmensübergreifende Anwendungen wie Figma, Zoom, Slack usw. verwenden. - **Erhöhte Sicherheit:** Möglicherweise hast du bemerkt, dass einige Unternehmen bestimmte Anmeldemethoden verlangen, wie z. B. dynamische Verifizierungscodes. Die Verwendung von SSO kann sicherstellen, dass jeder Mitarbeiter dieselbe Kombination von Anmeldemethoden für den Zugriff auf alle Ressourcen verwendet. > 🤔 Wahrscheinlich hast du erkannt, dass dies tatsächlich **SSO-Fall 1** aus der SaaS-Perspektive ist. Es ist an der Zeit, über das "X" im SSO-Diagramm zu sprechen. Dies stellt den Prozess dar, in dem Figma die E-Mail-Domain mit einem bestimmten Identitätsanbieter verbindet. Aber wie funktioniert das? ## SSO-Mapping Da die Anfrage häufig von Unternehmenskunden kommt, bezeichnen wir den Prozess von "SSO-Fall 3" aus dem vorherigen Abschnitt der Klarheit halber als "Enterprise SSO". Wir können leicht eine naive Lösung entwickeln: Erstellen Sie eine Zuordnung zwischen E-Mail-Domains und SSO-Methoden und aktualisieren Sie sie manuell. Die Aktion des Prozesses “X“ ist nun klar: > 🔍 **Finden Sie die zugeordnete Unternehmens-SSO-Methode der angegebenen E-Mail-Domain** Wenn du silverhand.io als gültige E-Mail-Domain konfigurierst, die mit einer Google Workspace-SSO-URL verbunden ist, werden Benutzer, die versuchen, sich mit einer @silverhand.io E-Mail anzumelden, zur entsprechenden Google Workspace-Anmeldeseite umgeleitet, anstatt vor Ort verarbeitet zu werden. Wenn du nur ein paar Dutzend Kunden hast, die Enterprise SSO benötigen, ist die manuelle Verwaltung der Zuordnung in Ordnung. Es gibt jedoch noch weitere Überlegungen: 1. _Was wenn es Hunderte oder Tausende von Enterprise SSO-Kunden gibt?_ 2. _Was ist das Verhältnis zwischen „normalen Benutzern“ und „Enterprise SSO-Benutzern“?_ 3. _Sollten Daten zwischen verschiedenen Enterprise SSO-Kunden isoliert werden?_ 4. _Besteht die Notwendigkeit, ein Dashboard für die Enterprise SSO-Administratoren bereitzustellen, um aktive Benutzer, Prüfungsprotokolle usw. anzuzeigen?_ 5. _Wie können Konten automatisch deaktiviert werden, wenn ein Benutzer aus dem Enterprise SSO-Identitätsanbieter entfernt wird?_ Und vieles mehr. Da fast alle Enterprise SSO E-Mail-Domain-basiert sind, können wir schnell eine bessere Lösung finden: - Wenn der Benutzer den Besitz dieser Domain nachweisen kann, kann er das Enterprise SSO dieser Domain in Eigenregie einrichten. Diese Lösung adressiert die ersten beiden Fragen: > _1. Was wenn es Hunderte oder Tausende von Enterprise SSO-Kunden gibt?_ - Sie können das Enterprise SSO eigenständig einrichten. > _2. Was ist das Verhältnis zwischen „normalen Benutzern“ und „Enterprise SSO-Benutzern“?_ - Wir öffnen alle möglichen Anmeldemethoden für normale Benutzer, außer Enterprise SSO; Während wir die Anmeldemethode auf Enterprise SSO nur für Benutzer beschränken, die versuchen, sich mit den konfigurierten Domains anzumelden. Zur dritten Frage: > _3. Soll ich Daten zwischen verschiedenen Enterprise SSO-Kunden isolieren?_ - Ja und nein. Es ist Zeit, Organisation vorzustellen. ## Organisation Wir erwähnten, dass E-Mail-Domains verwendet werden, um die spezifische Enterprise SSO-Methode zu erkennen; mit anderen Worten, spezifische Behandlungen für eine bestimmte Gruppe von Benutzern anzuwenden. Die Anforderungen der Kunden sind jedoch häufig mehr als nur Enterprise SSO; beispielsweise die Fragen 4 und 5 im vorherigen Abschnitt. Im Laufe der Jahre hat sich durch herausragende SaaS-Unternehmen ein ausgereiftes Modell entwickelt, um diese Probleme zu adressieren: Organisationen. **Regeln der Organisationen** 1. Eine Organisation ist eine Gruppe von Identitäten, typischerweise kleiner als ein Mandant. 2. Alle Organisationen sind mit einem Mandanten verbunden. Du kannst auf andere Begriffe stoßen, wie "Workspace", „Team“ oder sogar "Mandant" in der Software. Um festzustellen, ob es sich um das Konzept handelt, das wir diskutieren, überprüfe einfach, ob es „eine Gruppe von Identitäten“ darstellt. In diesem Artikel verwenden wir aus Konsistenzgründen den Begriff "Organisation". 🤹🏽‍♀️ In den meisten Fällen ist "eine Gruppe von Identitäten" gleichbedeutend mit "einer Gruppe von Benutzern". Jedoch kann **dieselbe Identität in mehreren Organisationen existieren**. In Notion kannst du mit derselben E-Mail-Adresse mehrere Arbeitsbereiche (d.h. Organisationen) erstellen und ihnen beitreten und problemlos zwischen ihnen wechseln. Für Slack scheint es das Gleiche zu sein, aber wir vermuten, dass unterschiedliche Identitäten im Hintergrund verwendet werden, da wir für jeden Arbeitsbereich ein neues Konto erstellen müssen.

![Slack-Arbeitsbereiche](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _Slack-Arbeitsbereiche_ ![Notion-Arbeitsbereiche](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _Notion-Arbeitsbereiche_

Notion bietet einen “Personal Plan” an, der normalerweise im Hintergrund eine Organisation darstellt, mit dem alleinigen Benutzer (dir) darin. Wir kennen die genaue Implementierung von Notion nicht, aber diese Erklärung ist vernünftig und für unser Modell archivierbar. Jede Organisation hat auch einen Identifikator, der normalerweise als „Organisationsdomain“ bezeichnet wird. Eine "Organisationsdomain" ist ein interner Identifikator, der verwendet wird, um Organisationen zu unterscheiden. Sie kann sich von der "E-Mail-Domain" unterscheiden, da die erstere vom Dienstanbieter verwaltet wird, während die letztere normalerweise von einem externen Identitätsanbieter bereitgestellt wird. Zum Beispiel kannst du `foo` als Organisationsdomain in Slack verwenden, aber `@bar.io` als E-Mail-Domain für diese Organisation verwenden. ### Quiz **❓ Kann eine App einer Organisation zugeordnet werden?**

Antwort

Ja. Wie wir zu Beginn besprochen haben, kann eine App eine Identität haben. Kannst du ein Geschäfts szenario dafür ausarbeiten?

## Noch offene Fragen > _3. Sollten Daten zwischen verschiedenen Enterprise SSO-Kunden isoliert werden?_ - **Ja:** Isoliere Geschäftsdaten, wie Nachrichten und Dokumente, auf Organisationsebene. - **Nein:** Halte Identitäten unabhängig, da sie nicht mit einer Organisation verbunden sein müssen. - Beachte, dass hier drei unterschiedliche Entitäten beteiligt sind: Identitäten, Organisationen und Enterprise SSO-Konfigurationen; was die Komplexität erheblich erhöht hat. Die Frage selbst ist nicht spezifisch genug. > _4. Besteht die Notwendigkeit, ein Dashboard für die Enterprise SSO-Administratoren bereitzustellen, um aktive Benutzer, Prüfungsprotokolle usw. anzuzeigen?_ > > _5. Wie kann ein Konto automatisch deaktiviert werden, wenn ein Benutzer aus dem Enterprise SSO-Identitätsanbieter entfernt wird?_ - Diese Anforderungen sind eher geschäftsorientiert und können auf Organisationsebene umgesetzt werden. Wir lassen sie hier offen. ## Abschließende Anmerkungen Wir haben mehrere Konzepte eingeführt: Authentifizierung (AuthN), Autorisierung (AuthZ), Identität, Mandant, Anwendung, Identitätsanbieter (IdP), Dienstanbieter (SP), Single Sign-On (SSO) und Enterprise SSO (Organisation). Es kann eine Weile dauern, bis du sie alle verstanden hast. Als ich diesen Artikel schrieb, bemerkte ich, dass interessanterweise die teuersten Pläne von Online-Diensten oft exklusive Funktionen im Zusammenhang mit Autorisierung enthalten, die in diesem Artikel völlig unerwähnt geblieben sind. Möglicherweise hast du bereits einige Fragen zur Autorisierung, wie zum Beispiel: - Wie können wir einem Benutzer Berechtigungen zuweisen und diese überprüfen? - Welches Berechtigungsmodell sollte ich verwenden? - Was ist die Best Practice für die Anwendung eines Berechtigungsmodells? 🔥 Mach eine Pause und wir sehen uns in CIAM 102!