Deutsch
  • service provider
  • sso
  • b2b
  • identität
  • auth
  • authentifizierung
  • single sign-on

Erfahre mehr über SP-initiiertes SSO für B2B-Apps

Erfahre, was service provider-initiiertes (SP-initiiertes) Single Sign-On (SSO) ist und wie es deinem Business-to-Business (B2B) Produkt helfen kann.

Ran
Ran
Product & Design

Wenn es um Identitätsmodelle geht, sind B2B-Produkte in einer eigenen Liga. Sie müssen die Komplexität der Multi-Tenancy meistern und gleichzeitig die Forderungen von Unternehmenskunden nach einem einheitlichen Identitäts- und Zugriffsmanagement für Mitarbeiter über eine Vielzahl von Diensten und Anwendungen erfüllen. Auch Logto hat diese Anforderungen von Kunden erlebt. In diesem Artikel werden wir einen produktorientierten Ansatz zur Verständigung von SP-initiiertem SSO verfolgen und erklären, wie es die Bedürfnisse deiner Kunden erfüllt.

Konzept

Beginnen wir mit der Einführung einiger Schlüsselelemente, die du verstehen musst:

  • Service Provider (SP): Deine Anwendungen oder Dienste, die eine einzige oder mehrere Apps sein könnten, die ein Identitätssystem teilen.
  • Enterprise Identity Provider (IdP): Der Identitätsanbieter, auf den sich deine Unternehmenskunden verlassen, um Mitarbeiteridentitäten und Anwendungsberechtigungen zu verwalten. Sie könnten verschiedene Anbieter nutzen, wie Okta, Azure AD, Google Workspace oder sogar maßgeschneiderte IdPs.
  • Organisation des Service Providers (SP Org): B2B-Apps unterstützen häufig Multi-Tenancy für verschiedene Kundenorganisationen.
  • Organisation des Identity Providers (IdP Org): IdPs unterstützen ebenfalls Multi-Tenancy für verschiedene Kundenorganisationen. Idealerweise sollte ein Unternehmen in der Lage sein, seine IdP Org mit einer SP Org zu verknüpfen, um Mitarbeiteridentitäten zu replizieren, aber die Realität kann komplexer sein.
  • Benutzerkonto des Unternehmens: Normalerweise identifiziert durch die Verwendung einer Unternehmens-E-Mail-Domain für den Login. Dieses Unternehmens-E-Mail-Konto gehört letztlich dem Unternehmen.

Kommen wir nun zu SSO und zwei wichtigen Protokollen:

  • Single Sign-On (SSO): SSO ermöglicht es Benutzern, auf mehrere Dienste oder Anwendungen mit einem einzigen Satz von Anmeldeinformationen zuzugreifen. Es vereinfacht das Zugriffsmanagement und verbessert die Sicherheit.
  • SAML- und OIDC-Protokolle: SSO basiert auf diesen Protokollen für Authentifizierung und Autorisierung, wobei jedes seine eigenen Vor- und Nachteile hat.

Es gibt zwei Hauptmechanismen zur Auslösung von SSO, die du berücksichtigen solltest:

  • IdP-initiiertes SSO: Beim IdP-initiierten SSO steuert der Identity Provider (IdP) hauptsächlich den Single-Sign-On-Prozess. Benutzer beginnen die Authentifizierung über die Oberfläche des IdP.
  • SP-initiiertes SSO: Beim SP-initiierten SSO übernimmt der Service Provider (SP) die Führung bei der Initiierung und Verwaltung des Single-Sign-On-Prozesses, der in B2B-Szenarien oft bevorzugt wird.

Nun lass uns SP-initiiertes SSO im Detail erkunden.

Oberflächenebene: Benutzererfahrung

Im Gegensatz zu B2C-Produkten, die eine Handvoll fester Social-IdP-Login-Buttons anbieten können, können B2B-Produkte nicht diktieren, welchen spezifischen Enterprise IdP jeder Kunde verwendet. Daher müssen Benutzer zuerst ihre Identität deklarieren. Nachdem bestätigt wurde, dass sie Mitglied eines Unternehmens sind, das für SSO aktiviert ist, werden sie zu ihrem entsprechenden Enterprise IdP zur Anmeldung weitergeleitet.

Um dies zu erreichen, musst du auf der Anmeldeseite bestimmen, ob der Benutzer sich über SSO anmelden muss und zu welchem IdP er weitergeleitet werden soll. Gängige Methoden sind:

  1. E-Mail-Domain-Zuordnung: Verknüpfe eine E-Mail-Domain mit einem spezifischen IdP-Connector. Dies betrifft Benutzer mit E-Mail-Adressen unter dieser Domain. Stelle sicher, dass die Domain-Inhaberschaft verifiziert wird, um böswillige Konfigurationen zu verhindern.
  2. Organisationsnamen-Zuordnung: Verknüpfe den Namen der Organisation mit einem IdP-Connector, wobei du dich darauf verlässt, dass sich Benutzer an den Namen ihrer Organisation erinnern.
  3. Persönliche E-Mail-Zuordnung des Benutzers: Dies ermöglicht es, direkt festzustellen, ob ein Benutzerkonto für SSO aktiviert ist, ohne auf E-Mail-Domains oder Org-Namen angewiesen zu sein. Dies kannst du erreichen, indem du Benutzer manuell einlädst, Regeln für erforderliches SSO anpasst oder ihre Konten durch Verzeichnis-Synchronisierung automatisch synchronisierst.

Beim Design der Startseite für die Anmeldung gibt es typischerweise zwei Formen, die du je nach Geschäftsmodell deines Produkts wählen kannst:

  1. B2B-Produkte: Empfehle, direkt SSO-Schaltflächen anzuzeigen, um es den Mitgliedern deiner Unternehmenskunden, die SSO nutzen müssen, intuitiv zu machen.
  2. Produkte, die B2C und B2B unterstützen: Da die meisten Benutzer kein SSO verwenden werden, beurteile die E-Mail-Domains, um festzustellen, ob SSO erforderlich ist. Du kannst die Eingabe der Anmeldedaten verzögern, indem du sie zunächst ausblendest und erst nach Bestätigung der Identität des Benutzers anzeigst.

Unterliegende Komplexität: Benutzeridentitätsmodell

Die Integration von SSO in dein Identitätssystem bringt jedoch viel mehr Komplexität mit sich, als nur eine SSO-Schaltfläche zur Anmeldeseite hinzuzufügen. Du musst weitaus mehr Faktoren berücksichtigen.

Die Beziehungen zwischen den Schlüsselelementen sind selten eins-zu-eins; du musst eins-zu-viele und sogar viele-zu-viele Szenarien berücksichtigen. Um diese Variationen schrittweise zu erkunden:

  • Eine IdP Org mit mehreren E-Mail-Domains: Wenn du dich auf E-Mail-Domains verlässt, um die Identität eines Benutzers zu bestimmen, musst du mehrere Domain-Zuordnungen unterstützen.
  • Eine E-Mail-Domain, die mehreren IdP Orgs zugeordnet ist: Wenn eine Domain mehreren IdP Orgs gehören könnte, müssen Benutzer den IdP wählen, den sie für das Single Sign-On verwenden möchten.
  • Eine IdP Org verknüpft mit mehreren SP Orgs: Erwäge, die Möglichkeit zu bieten, einen IdP schnell mit mehreren SP Orgs zu verbinden.
  • Ein Benutzerkonto in mehreren IdP Orgs und SP Orgs: Verschiedene SP Orgs können eine Verifizierung durch unterschiedliche IdPs erforderlich machen.

Die Aktivierung oder Deaktivierung von SSO innerhalb eines Unternehmens kann die Art und Weise, wie Benutzer sich authentifizieren, ändern, was einen sicheren und reibungslosen Übergang erfordert.

  • Entscheidungen zur SSO-Aktivierung: Es müssen Entscheidungen getroffen werden, ob SSO nur bestimmte Tenant SP Orgs oder alle Tenant SP Orgs betrifft. Ersteres bietet Flexibilität, während letzteres dem Trend zu unternehmensweiter Identitäts- und Zugriffskontrolle entspricht.
  • Überlegungen zur Übergangszeit: Als SP musst du Unsicherheiten beim Einsatz von Drittanbieter-IdP-Diensten berücksichtigen. Enterprise-Administratoren müssen immer Zugriff auf deine App durch SSO oder Anmeldedatenoptionen haben, und auch Unternehmensmitglieder könnten diese während des Übergangs benötigen.

Dies sind nur einige Punkte zur Bewältigung verschiedener Szenarien; viele weitere Fähigkeiten und Details können noch erforscht werden.

Fazit

Wir hoffen, dass dir diese Analyse des SP-initiierten SSO neue Perspektiven für Unternehmensidentitätslösungen bietet. Die gute Nachricht ist, dass Logto fleißig an Lösungen arbeitet, die eine einfache Konfiguration und out-of-the-box SSO-Authentifizierungserfahrungen bieten. Bleibe gespannt auf unsere bevorstehende Veröffentlichung, in der wir tiefer in spezifische SP-initiierte SSO-Lösungen eintauchen werden.