Publiziert: Zuletzt aktualisiert:

Identity und Single Sign-on

Eine zentrale Identität öffnet und schliesst jeden Zugriff

Identity und Access Management bündelt jede Anmeldung auf eine einzige, zentral verwaltete Identität. Single Sign-on macht daraus den einen Login, der alle angebundenen Anwendungen öffnet, und einen einzigen Punkt, an dem sich Zugriff erteilen und wieder entziehen lässt.

Wer Identität nicht zentral steuert, verteilt sie unkontrolliert: jedes System führt eigene Konten, jede Person merkt sich eigene Passwörter, und beim Austritt bleibt unklar, welche Zugänge noch offen sind. Diese Seite ordnet das Feld von der zentralen Identität über die Protokolle, die sie tragen, bis zur Entscheidung, ob der Identity-Provider im eigenen Haus oder als externer Dienst läuft. Die einzelnen Provider sind je auf einer eigenen Katalogseite beschrieben und an Ort und Stelle verlinkt.

Anti-Patterns: Verstreute Identität als Angriffsfläche

  • Passwort-Wildwuchs: Jede Anwendung verlangt ein eigenes Passwort. Was folgt, ist die Wiederverwendung schwacher Passwörter über Systemgrenzen hinweg und damit die grösste Einzelschwäche im Zugriff.
  • Konto pro Anwendung: Jedes System pflegt seinen eigenen Nutzerbestand. Eine Person existiert dutzendfach, und keine Stelle kennt die Summe ihrer Zugänge.
  • Kein zentrales Offboarding: Beim Austritt werden Konten einzeln und von Hand deaktiviert. Vergessene Zugänge bleiben aktiv und sind ein klassisches Einfallstor.
  • Geteilte Logins: Ein gemeinsames Konto für ein Team macht jede Handlung anonym. Wer was getan hat, lässt sich nicht mehr nachvollziehen.

Eine Identität als gemeinsame Grundlage aller Zugriffe

Identity und Access Management trennt zwei Fragen, die ohne Zentralisierung untrennbar verwoben bleiben: Wer ist die Person (Authentifizierung) und was darf sie (Autorisierung). Die Antwort auf beide liegt an einer Stelle, dem Identity-Provider. Er hält die Identitäten, prüft die Anmeldung, setzt einen zweiten Faktor durch und entscheidet, welche Anwendung eine Person erreichen darf.

Single Sign-on ist die sichtbare Seite dieser Bündelung. Statt sich an jeder Anwendung neu anzumelden, authentifiziert sich eine Person einmal am Identity-Provider; die angebundenen Anwendungen vertrauen dessen Urteil und gewähren Zugang, ohne das Passwort je selbst zu sehen. Der Gewinn ist dreifach: weniger Passwörter und damit weniger Angriffsfläche, ein einziger Ort für starke Authentifizierung, und ein einziger Schalter, der beim Austritt alle Zugänge zugleich schliesst. Das sofortige Offboarding ist der am meisten unterschätzte Vorteil: Eine deaktivierte Identität sperrt in einem Schritt jede angebundene Anwendung.

Vier Protokolle tragen die zentrale Identität

Die Bündelung funktioniert nur, weil Anwendungen und Identity-Provider über herstellerunabhängige Protokolle dieselbe Sprache sprechen. Vier davon decken den grössten Teil der Praxis ab.

  1. OIDC. OpenID Connect ist das moderne Protokoll für Web- und Mobile-Anwendungen. Es setzt auf dem Autorisierungs-Standard OAuth 2.0 auf und ergänzt ihn um die Identitätsschicht. Für neue Anbindungen ist OIDC die Voreinstellung.
  2. SAML. Der ältere, XML-basierte Standard ist im Umfeld klassischer Unternehmens- und SaaS-Anwendungen weit verbreitet. Viele etablierte Dienste sprechen SAML, weshalb es trotz seines Alters relevant bleibt.
  3. LDAP. Das Verzeichnisprotokoll ist das Rückgrat für Authentifizierung gegen einen zentralen Benutzerbestand, besonders bei Altsystemen und internen Diensten. Es liefert die Identitäten, auf denen OIDC und SAML aufsetzen.
  4. SCIM. Wo OIDC und SAML die Anmeldung regeln, automatisiert SCIM die Bereitstellung: Es legt Konten in den angebundenen Anwendungen automatisch an, hält sie aktuell und entfernt sie beim Austritt. Erst SCIM macht das zentrale Offboarding über Systemgrenzen hinweg vollständig.

Selbst betreiben gegen extern beziehen als zentrale Entscheidung

Der Identity-Provider ist das Herzstück, und seine Wahl ist dieselbe Grundsatzentscheidung wie bei jeder kritischen Komponente: ins eigene Haus holen oder als Dienst beziehen.

Ein selbst gehosteter Identity-Provider läuft auf eigener Infrastruktur. Authentik und Keycloak sind die etablierten Open-Source-Vertreter. Die Identitäten und jede Anmeldung bleiben im eigenen Netz, die Konfiguration ist vollständig in eigener Hand, und es entsteht keine laufende Abhängigkeit von einem externen Anbieter. Der Preis ist die eigene Betriebsdisziplin: Verfügbarkeit, Aktualisierung und Absicherung des Identity-Providers liegen im eigenen Verantwortungsbereich, und ein Ausfall sperrt den Login zu allen angebundenen Anwendungen zugleich.

Ein SaaS-Identity-Provider wie Okta liefert dieselbe Funktion als verwalteten Dienst. Er ist schnell verfügbar, der Betrieb liegt beim Anbieter, und Verfügbarkeit wird vertraglich zugesichert. Im Gegenzug verlassen die Identitäten das eigene Haus, die Kontrolle über das Herzstück des Zugriffs liegt bei einem externen Anbieter, und es entsteht genau die Abhängigkeit, die eine souveräne IT andernorts zu vermeiden sucht. Die Abwägung folgt damit der allgemeinen Make-or-Buy-Frage, zugespitzt auf die sensibelste Komponente der Zugriffskontrolle.

flowchart TD
    SSO["Single Sign-on einführen"]
    SSO --> P{"Welches Protokoll für welche Anwendung"}
    P --> OIDC["OIDC<br/>Web und Mobile, neue Anbindungen"]
    P --> SAML["SAML<br/>klassische Unternehmens- und SaaS-Anwendungen"]
    P --> LDAP["LDAP<br/>Verzeichnis und Altsysteme"]
    P --> SCIM["SCIM<br/>Konten automatisch bereitstellen und entziehen"]
    SSO --> H{"Identity-Provider betreiben"}
    H --> SELF["Selbst gehostet<br/>Authentik, Keycloak"]
    H --> SAAS["SaaS<br/>Okta"]
    SELF --> CTRL["Datenhoheit und volle Kontrolle<br/>eigener Betrieb"]
    SAAS --> MAN["schnell verfügbar und verwaltet<br/>externe Abhängigkeit"]

Das Diagramm zeigt die zwei Entscheidungen, die jede Anbindung prägen: nach dem passenden Protokoll für die jeweilige Anwendung und nach dem Betriebsmodell des Identity-Providers. Beide Wege führen zur selben zentralen Identität; sie unterscheiden sich darin, wer den Provider betreibt und wo die Identitäten liegen.

Identität als das tragende Element von Zero Trust

Wenn der Netzwerk-Perimeter als Schutzlinie ausgedient hat, wird die Identität zur neuen Grenze. Genau diesen Grundsatz macht Zero Trust zum Architekturprinzip: Jeder Zugriff wird einzeln geprüft, unabhängig vom Standort, und die Grundlage jeder Prüfung ist eine verlässliche, zentral verwaltete Identität. Ohne Single Sign-on und einen Identity-Provider gibt es keinen Punkt, an dem sich diese Prüfung durchsetzen lässt. Identity und Access Management ist damit kein isoliertes Thema, sondern die Steuerungsebene, auf der eine Security-Strategie ihre Zugriffsentscheidungen verankert.

Praxis-Beispiel: Der Austritt an einem Tag

Eine Mitarbeiterin verlässt das Unternehmen. Ohne zentrale Identität müsste jede Stelle daran denken, ihr Konto in jedem System einzeln zu deaktivieren, vom E-Mail-Dienst über das Projektwerkzeug bis zum Code-Repository. In der Praxis bleibt dabei regelmässig ein Zugang offen. Mit einem Identity-Provider genügt ein Schritt: Die zentrale Identität wird deaktiviert, und über OIDC und SAML verlieren alle angebundenen Anwendungen sofort das Vertrauen, während SCIM die zugehörigen Konten in den Zielsystemen entfernt. Aus einer fehleranfälligen Checkliste wird eine einzige, nachvollziehbare Handlung.

FAQ

Ist ein einziger Login nicht ein einziger Schwachpunkt?

Die Sorge ist berechtigt, aber sie kehrt sich um. Ein zentraler Login bedeutet, dass starke Authentifizierung nur an einer Stelle durchgesetzt werden muss, statt sich auf die schwächste von dutzenden App-Anmeldungen zu verlassen. Der Identity-Provider ist der richtige Ort, um einen zweiten Faktor verbindlich zu machen. Verstreute Konten mit wiederverwendeten Passwörtern sind die deutlich grössere Angriffsfläche.

Brauchen wir alle vier Protokolle?

Nein. Welche Protokolle zum Einsatz kommen, bestimmen die anzubindenden Anwendungen. Neue Web-Anwendungen sprechen meist OIDC, etablierte Unternehmensdienste oft SAML, interne Altsysteme LDAP. SCIM kommt dazu, sobald die automatische Bereitstellung und das automatische Entziehen von Konten gefordert sind. Ein guter Identity-Provider beherrscht alle vier und vermittelt zwischen ihnen.

Schliessen sich selbst gehostet und SaaS aus?

Nicht zwingend. Eine Organisation kann sensible interne Anwendungen über einen selbst gehosteten Provider absichern und unkritische Dienste an einen SaaS-Provider anbinden. Entscheidend ist, dass die Wahl bewusst entlang der Sensibilität der jeweiligen Identitäten fällt und nicht aus Bequemlichkeit auf eine externe Abhängigkeit hinausläuft.

Referenzen

Verwandte Themen

  • Zero Trust, die Architektur, in der die Identität zur neuen Grenze wird.
  • Security-Strategie, der übergeordnete Rahmen, in dem die Zugriffskontrolle verankert ist.
  • Authentik, ein selbst betreibbarer Open-Source-Identity-Provider.
  • Keycloak, ein etablierter Open-Source-Identity-Provider.
  • Okta, ein Identity-Provider als verwalteter SaaS-Dienst.
  • Public Code, die strategische Grundlage der Make-or-Buy-Entscheidung beim Identity-Provider.

KI fragen

Diese Links öffnen externe KI-Dienste, die Unterhaltung und deren Inhalt werden dabei an den jeweiligen Anbieter übertragen.