Bereit für die Enterprise-SSO-Anfrage: Eine Identitäts-Checkliste für wachsende SaaS-Teams

Der erste Unternehmenskunde, der Ihr Produkt liebt, wird irgendwann eine schwierigere Frage stellen als die nach dem Preis.

Sein Sicherheitsteam wird Single Sign-on über den eigenen Identity Provider, die automatische Deaktivierung beim Ausscheiden von Mitarbeitern und Belege dafür verlangen, wer wann Zugriff hatte.

Wenn Ihre Antworten noch immer „das planen wir“ lauten, gerät der Abschluss oft um ein Quartal ins Hintertreffen, während Sie hektisch nachbessern.

Ich habe auf beiden Seiten solcher Prüfungen gesessen. Die folgende Liste ist die Identitäts-Checkliste, die wachsende B2B-SaaS-Teams brauchen, bevor der Fragebogen eintrifft – ausgerichtet an offenen Standards.

Fragen, die Sicherheitsteams von Unternehmen tatsächlich stellen

Rechnen Sie mit mehr als „Unterstützen Sie SSO?“ Ein typischer Fragebogen deckt Folgendes ab:

• Können sich Mitarbeiter über unseren unternehmenseigenen Identity Provider per SAML 2.0 oder OpenID Connect (OIDC) anmelden?
• Können wir MFA an unserem IdP erzwingen, und wird Ihre Anwendung dieses Signal berücksichtigen, ohne einen zweiten MFA-Weg einzuführen?
• Wie stellen Sie Benutzer bereit und deaktivieren sie? Unterstützen Sie SCIM?
• Wie lange bleiben Sitzungen gültig, welche Richtlinien gelten für Refresh-Tokens und welche Inaktivitäts-Timeouts verwenden Sie?
• Können wir Authentifizierungs- und Admin-Ereignisprotokolle exportieren oder an unser SIEM streamen?
• Wie isolieren Sie die Daten, Konfigurationen und Identitätsverbindungen unseres Mandanten von denen aller anderen Kunden?
• Wie benachrichtigen Sie uns, rotieren Zugangsdaten und weisen nach, welche Konten betroffen waren, wenn es in Ihrem Stack zu einem Identitätsvorfall kommt?

Beantworten Sie jede Frage mit einem konkreten Mechanismus. „Wir nehmen Sicherheit ernst“ hält einem Folgegespräch mit dem IAM-Architekten des Kunden nicht stand.

Grundlagen von SAML und OIDC

Die meisten Käufer aus dem Enterprise-Bereich kommen mit einem bereits in ihren Workforce-IdP integrierten SAML 2.0. OIDC findet sich häufiger bei modernen Cloud-IdPs, API-lastigen Produkten und mobilen Clients. Viele SaaS-Produkte unterstützen beides und lassen jeden Mandanten wählen.

Die Einrichtung erfolgt über einen Austausch von Metadaten.

• SAML: Sie und der Kunde tauschen Entity-IDs, URLs des Assertion Consumer Service, Single-Logout-Endpunkte und Signaturzertifikate aus.
• OIDC: Sie tauschen Issuer-URLs, Client-IDs und Secrets (oder Einstellungen für öffentliche Clients), Redirect-URIs und die Speicherorte der Discovery-Dokumente aus.

Planen Sie die Rotation von Zertifikaten und Signaturschlüsseln, bevor die erste Verbindung produktiv geht. Abgelaufene IdP-Zertifikate sind eine häufige Ursache für Produktionsausfälle.

Kennen Sie den Unterschied zwischen SP-initiierten und IdP-initiierten Abläufen.

• SP-initiiert: Beginnt in Ihrer Anwendung und leitet zum IdP weiter; dies ist der übliche Weg für Deep Links und Einladungen.
• IdP-initiiert: Beginnt im App-Portal des Kunden und führt mit einer nicht angeforderten Assertion oder Anmeldung zu Ihrer Anwendung.

Unterstützen Sie beides, wenn das Portalteam des Käufers eine Kachel in seinem App-Katalog erwartet.

Bei der Zuordnung von Attributen und Claims verbergen sich die unauffälligen Fehler. Gruppennamen sowie E-Mail- und Abteilungsattribute unterscheiden sich je nach IdP. Ordnen Sie sie für jeden Mandanten explizit zu.

Wenn ein erforderlicher Claim fehlt, muss der Zugriff standardmäßig verweigert werden. Weichen Sie nicht auf eine standardmäßige Administrator- oder Mitgliederrolle aus, nur weil ein Gruppenattribut vorgelagert umbenannt wurde.

Mandantentrennung

Enterprise-SSO ist naturgemäß mandantenfähig. Jeder Kunde braucht seine eigene IdP-Verbindung, seine eigene Domänenliste und seine eigenen Attributzuordnungen.

Die Domänenverifizierung (oder Home-Realm-Erkennung) leitet user@customer.com an den IdP dieses Kunden weiter statt auf eine gemeinsame Anmeldeseite.

Fügen Sie jedem Token und jeder Sitzung eine stabile Mandantenkennung hinzu und prüfen Sie sie bei jeder Anfrage zusammen mit der Audience. Ein für Mandant A ausgestelltes Token darf niemals die Daten von Mandant B öffnen, selbst wenn die E-Mail-Adresse des Benutzers übereinstimmt.

Kombinieren Sie dies mit Audience-Werten pro API (siehe RFC 8707 zu Resource Indicators, sofern Sie diese verwenden), damit ein für die Abrechnung bestimmtes Token Ihre Admin-API nicht aufrufen kann.

Vermeiden Sie gemeinsame „Catch-all“-IdP-Verbindungen für voneinander unabhängige Kunden. Gemeinsame Verbindungen machen die Attributzuordnung mehrdeutig und verwandeln eine einzige Fehlkonfiguration in einen mandantenübergreifenden Vorfall.

Deaktivierung und SCIM

SSO allein verhindert, dass sich ein ausgeschiedener Mitarbeiter erneut anmeldet. Das Konto, das bereits in Ihrem Produkt existiert, entfernt es ebenso wenig wie die API-Schlüssel, persönlichen Zugriffstoken, Refresh-Tokens oder langlebigen Sitzungen, über die dieses Konto noch verfügt.

SCIM 2.0 (RFC 7643 für das Schema, RFC 7644 für das Protokoll) ermöglicht es dem Verzeichnis des Kunden, Benutzer in Ihrer Anwendung automatisch anzulegen, zu aktualisieren und zu deaktivieren.

Wenn die Personalabteilung jemanden als ausgeschieden markiert, sendet der IdP eine Deaktivierung. Ihre Anwendung sollte den Benutzer deaktivieren, Refresh-Tokens und Sitzungen widerrufen und im selben Ablauf die an diese Identität gebundenen API-Zugangsdaten ungültig machen.

Just-in-time-(JIT-)Provisioning legt beim ersten SSO-Login ein Konto an. Für erste Mandanten und Demos ist das in Ordnung. Das allein löst weder die Deaktivierung noch Rollenänderungen oder die Bereinigung von Sitzen.

Bevorzugen Sie SCIM (oder eine gleichwertige Verzeichnissynchronisierung), sobald ein Kunde über eine echte IT-Funktion verfügt. Wenn Sie nur JIT anbieten, dokumentieren Sie die Lücke ehrlich: Der Käufer wird danach fragen.

Befolgen Sie für Token-Laufzeiten und den Widerruf die OAuth-Sicherheitsbest Practices (RFC 9700). Kurzlebige Zugriffstoken plus widerrufbare Refresh-Tokens verschaffen Ihnen einen echten Notausschalter, wenn SCIM „deaktiviert“ meldet.

Audit-Nachweise

Sicherheitsfragebögen und Prüfungen nach SOC 2 oder ISO 27001 fragen, wer sich authentifiziert, wer Rollen geändert, wer einen IdP verbunden und wer Daten exportiert hat.

Sie benötigen Login-, Admin- und Provisioning-Ereignisse mit Zeitstempel, Akteur, Ziel, Mandant, IP- oder Gerätekontext, sofern verfügbar, sowie Ergebnis.

Die Aufbewahrungsdauer sollte den Erwartungen der Käufer in ihrer Branche entsprechen, und Exporte sollten sich erstellen lassen, ohne eine Woche Entwicklungsarbeit zu erfordern. CSV- oder JSON-Downloads helfen kleineren Käufern; SIEM-Streaming per Webhook oder über einen Log-Transport hilft größeren.

Seien Sie bereit, die Frage „Zeigen Sie mir, wer zwischen diesen beiden Zeitpunkten Zugriff auf diesen Mandanten hatte“ zu beantworten. Wenn dafür ein Datenbankarchäologe erforderlich ist, verbessern Sie die Protokollierung, bevor der Auditor fragt.

Die Rolle von KI-Agenten

KI-Agenten und MCP-ähnliche Tool-Integrationen agieren zunehmend für einen Benutzer innerhalb Ihres Produkts. Behandeln Sie sie als vollwertige Identitäten in Ihrem Zugriffsmodell.

Bevorzugen Sie delegierte OAuth-Token, die auf die APIs beschränkt, kurzlebig und an die Audience der APIs gebunden sind, die der Agent aufrufen darf. Sorgen Sie dafür, dass die Identität des menschlichen Benutzers und die des Agenten in jeder Protokollzeile unterscheidbar bleiben.

Wenn Sie einen Benutzer widerrufen, widerrufen Sie auch jede unter diesem Benutzer ausgestellte Agentenberechtigung, jedes Refresh-Token und jedes Tool-Zugangsdokument. Andernfalls sieht die Deaktivierung in der Benutzeroberfläche vollständig aus, während ein Agent weiterhin ein gültiges Token besitzt.

Dieselbe Audience-Disziplin, die interne APIs schützt, gilt auch hier. Eine weit gefasste Audience, die von jedem Agenten-Tool gemeinsam genutzt wird, wird zu einem Generalschlüssel, sobald eine einzige Integration ein Token preisgibt.

Abschließende Checkliste

Bevor Sie den nächsten Enterprise-Fragebogen beantworten, vergewissern Sie sich, dass Sie jedes Kästchen ankreuzen können:

1. Mandantenspezifische SAML-2.0- und/oder OIDC-Verbindungen mit dokumentiertem Metadatenaustausch und Zertifikatsrotation.
2. SP-initiierte und IdP-initiierte Anmeldewege, die mit mindestens einem echten Kunden-IdP getestet wurden.
3. Explizite Attribut- und Claim-Zuordnungen mit standardmäßiger Zugriffsverweigerung, wenn ein zugeordnetes Claim fehlt.
4. Domänenverifizierung oder Home-Realm-Erkennung, die Benutzer an den richtigen IdP weiterleitet.
5. Stabile Mandanten-IDs in Tokens, die bei jeder Anfrage zusammen mit der Audience geprüft werden.
6. SCIM-2.0-Deprovisioning (oder eine gleichwertige Lösung), das Sitzungen, Refresh-Tokens und API-Zugangsdaten widerruft.
7. Exportierbare Authentifizierungs- und Admin-Ereignisprotokolle mit einer Aufbewahrungsdauer, die Sie in einer SOC-2-ähnlichen Prüfung vertreten können.
8. Der Zugriff von Agenten und Tools wird als delegierte, eingeschränkte und widerrufbare Token mit unterschiedlichen Protokollidentitäten modelliert.

Enterprise-SSO betrifft Login, Autorisierung, Lebenszyklus, Audit und inzwischen auch nichtmenschliche Akteure. Bauen Sie diese Komponenten auf, solange Ihre Käufer noch aus dem gehobenen Mittelstand kommen, und die erste ernsthafte Sicherheitsprüfung wird zu einem Gespräch über Zeitpläne statt zu einem unter Vertragsdruck erforderlichen Neubau.

Mehr erfahren: Entdecken Sie die beste Software für Identity und Access Management zur Verwaltung von Authentifizierung, Zugriff und Identitätslebenszyklen.