SSO erklärt: Unternehmensidentität und passwortloses WiFi

Bis 2021 verfügte die britische Regierung über rund 121 separate Single Sign-On Lösungen - was zeigt, warum SSO mehr als nur eine Komfortfunktion ist. SSO ist föderierte Identitätskonsolidierung: Es zentralisiert die Authentifizierung über einen vertrauenswürdigen Identitätsanbieter, während jede Anwendung die Kontrolle darüber behält, wozu ein authentifizierter Benutzer autorisiert ist.

Sie kennen das Problem vielleicht aus dem normalen Arbeitsalltag. Ein Mitarbeiter benötigt E-Mail, eine Cloud-Anwendung, ein Immobilienverwaltungssystem, internes WiFi und ein Administrationsportal. Jeder Dienst hat ein eigenes Login, eigene Passwortrichtlinien und eigene Kontoinhaber. Wenn jemand neu hinzukommt, die Rolle wechselt oder das Unternehmen verlässt, müssen Administratoren mehrere Systeme aktualisieren, und die Benutzer müssen sich merken, welche Anmeldeinformationen zu welchem Dienst gehören.

Das ist der praktische Grund, warum Unternehmen nach einer Erklärung für SSO suchen. Die Frage ist nicht nur, wie man die Anzahl der Anmeldebildschirme reduziert. Es geht darum, wie man eine zuverlässige Identitäts-Steuerungsebene schafft, ohne die Berechtigungen auf Anwendungsebene zu schwächen oder ein gefährlicheres zentrales Angriffsziel zu schaffen.

Warum eine fragmentierte Identität reale Zugriffsprobleme verursacht

Die Erfahrung der britischen Regierung bietet einen nützlichen Ausgangspunkt. Eine Überprüfung der GOV.UK-Servicestandards aus dem Jahr 2021 schätzte, dass die Zentralregierung etwa 121 verschiedene SSO-Lösungen nutzte, weil Serviceteams separate Authentifizierungssysteme aufgebaut hatten, anstatt eine gemeinsame regierungsweite Identitätsplattform zu verwenden. Personen, die mehrere öffentliche Dienste nutzten, konnten daher mehrere Anmeldedaten besitzen und wussten möglicherweise nicht, welches Konto für eine bestimmte Transaktion erforderlich war. (UK Government authentication and digital identity review)

Die Erkenntnis ist nicht, dass Regierungssysteme einzigartig kompliziert sind. Große Unternehmen, Organisationen im Gesundheitswesen, Hotelgruppen, Immobilienbetreiber und Netzwerke des öffentlichen Sektors stehen vor demselben Muster. Jede Anwendung kann ein Identitätssilo erstellen, und jedes Silo kann eigene Passwortregeln, Wiederherstellungsprozesse, Gruppenmodelle und Offboarding-Workflows entwickeln.

Authentifizierung und Autorisierung sind unterschiedliche Aufgaben

Authentifizierung beantwortet die Frage: „Wer bist du?“ Autorisierung beantwortet die Frage: „Worauf darfst du hier zugreifen?“ SSO konsolidiert die erste Frage über einen vertrauenswürdigen Identity Provider. Die Zielanwendung entscheidet weiterhin, ob diese Identität Datensätze anzeigen, ein System verwalten, einem Netzwerksegment beitreten oder eine bestimmte Funktion nutzen kann.

Ein nützliches gedankliches Modell sieht folgendermaßen aus:

Benutzer
  |
  | authentifiziert sich einmal
  v
Identity Provider
  |
  | sendet vertrauenswürdige Identitätsinformationen
  v
Anwendung oder Netzwerk
  |
  | wendet lokale Berechtigungen an
  v
Autorisierte Sitzung

Diese Unterscheidung ist bei Joiner-, Mover- und Leaver-Prozessen von Bedeutung. Eine zentrale Identität kann deaktiviert werden, wenn eine Person das Unternehmen verlässt, während jeder verbundene Dienst weiterhin ein klares Autorisierungsmodell und eine zuverlässige Möglichkeit benötigt, Berechtigungen zu entziehen.

Praktische Regel: Betrachten Sie SSO als eine Möglichkeit, Identitäten zentral zu steuern, und nicht als Ersatz für Anwendungsberechtigungen.

Das gleiche Prinzip gilt bei der Planung von kabelgebundenen und drahtlosen Bereitstellungen. Der Netzwerkzugriff ist Teil der Identitätsumgebung. Daher sollten Teams festlegen, welche Verzeichnisgruppen welche Netzwerkrollen erreichen können, anstatt den Zugriff an ein gemeinsam genutztes Passwort zu binden.

Für Mitarbeiter WiFi und identitätsbasierten Zugriff zeigt Purples identitätsbasiertes Networking, wie Netzwerkrichtlinien mit einer individuellen Identität statt mit gemeinsamen Anmeldedaten verknüpft werden können. Das Ergebnis ist eine klarere Beziehung zwischen einer Person, ihrem Directory Status und dem Zugriff, den sie erhält.

Wie Single Sign-On in Enterprise-Föderationen funktioniert

In einer Enterprise-Föderation übernehmen ein Identity Provider, eine Relying Party und eine signierte Identitätsnachricht jeweils eigene Aufgaben. Der Identity Provider authentifiziert den Benutzer, während die Relying Party - etwa eine Anwendung oder ein Netzwerkdienst - die resultierenden Identitätsinformationen überprüft.

Die Authentifizierung kann ein Passwort, Multi-Faktor-Authentifizierung, Gerätebedingungen oder eine andere genehmigte Methode nutzen. Der Provider stellt dann eine signierte Assertion oder ein Token für den angeforderten Dienst aus. Der Dienst validiert diese Nachricht und erstellt eine eigene Sitzung, sodass die Anmeldedaten beim Identity Provider verbleiben.

Der Föderationsablauf

1. Der Benutzer fordert einen Dienst an. Er öffnet eine Anwendung, ein Administrationsportal oder einen geschützten Netzwerkdienst.
2. Der Dienst prüft, ob eine aktive Sitzung vorliegt. Wenn nicht, leitet er den Benutzer zum Identity Provider weiter.
3. Der Identity Provider authentifiziert den Benutzer. Er wendet konfigurierte Kontrollen an, wie MFA oder bedingten Zugriff.
4. Der Identity Provider stellt eine signierte Nachricht aus. Die Integration nutzt üblicherweise eine SAML-Assertion oder ein OpenID Connect Token.
5. Der Dienst validiert die Nachricht. Er überprüft Aussteller, Signatur, Zielgruppe, Ablaufdatum und relevante Claims.
6. Die Anwendung erstellt eine eigene Sitzung. Sie weist die verifizierte Identität lokalen Berechtigungen zu und protokolliert das Authentifizierungsereignis.

Die Validierung schützt das Vertrauensverhältnis. Das UK National Cyber Security Centre rät, dass SAML-Zusicherungen, die über nicht vertrauenswürdige Netzwerke empfangen werden, gegen die erwartete Zertifizierungsstelle geprüft werden müssen. Eine nicht verifizierte Zusicherung kann einen Pfad zur Kontoübernahme über eine vertrauenswürdige Verbindung des Identitätsanbieters bieten. (NCSC-Leitfaden zu Identitäts- und Zugriffsmanagement)

Eine gültige Identitätsprüfung gewährt eine authentifizierte Identität, nicht automatisch jede Berechtigung im Zieldienst. Die Anwendung sollte nur die für die Autorisierung erforderlichen Claims verarbeiten und dann ihre eigenen Rollen- und Ressourcenregeln anwenden. Diese Trennung ermöglicht es demselben Föderationsmuster auch, Mitarbeiteranwendungen, Administrationsportale und identitätsbasierte Netzwerkdienste zu unterstützen.

SAML, OIDC und OAuth im Enterprise-Kontext

Sobald das Föderationsmodell klar ist, fällt die Protokollauswahl leichter. SAML und OpenID Connect sind gängige Standards für Enterprise SSO, während OAuth in erster Linie ein Autorisierungs Framework für den delegierten Zugriff auf APIs ist. Wird OAuth mit Authentifizierung verwechselt, kann dies dazu führen, dass Teams einen Identitätsfluss aufbauen, der ihre Sicherheitsanforderungen nicht erfüllt.

Standard	Praktische Rolle	Typischer Einsatzbereich
SAML	Tauscht signierte Identitätsbehauptungen aus	Etablierte Enterprise- und browserbasierte Anwendungen
OpenID Connect	Fügt eine Identitätsebene mithilfe von Tokens hinzu	Moderne SaaS-, Web- und mobile Orientierungsdienste
OAuth	Delegiert den Zugriff auf geschützte Ressourcen	API-Zugriff im Namen eines Benutzers oder Dienstes

SAML wird häufig in ausgereifter Enterprise-Software verwendet, da es ein etabliertes Browser-Föderationsmodell nutzt. OIDC ist in der Regel natürlicher für moderne Dienste, die auf JSON, REST und tokenbasierten Interaktionen aufbauen. Die richtige Wahl hängt davon ab, was die Anwendung unterstützt und wie der Dienst Identitätsinformationen validiert.

Was der Dienst überprüfen muss

Unabhängig vom Standard muss die Relying Party das empfangene Identitätsmaterial validieren, bevor sie eine Sitzung erstellt. Zu den grundlegenden Prüfungen gehören:

• Aussteller: Bestätigen Sie, dass die Nachricht vom erwarteten Identitätsanbieter stammt.
• Signatur: Überprüfen Sie, ob die Nachricht mit dem vertrauenswürdigen Schlüssel oder Zertifikat signiert wurde.
• Zielgruppe (Audience): Überprüfen Sie, ob die Nachricht für diesen Dienst bestimmt war.
• Ablauf: Veraltete Zusicherungen oder Tokens ablehnen.
• Claims: Verwenden Sie nur relevante, validierte Identitäts- und Gruppeninformationen.

Der Identity Provider kann Richtlinien wie MFA, bedingten Zugriff, Passwortsperren und Gruppenmitgliedschaften zentralisieren. Die Anwendung erhält dann die für ihre eigene Autorisierungsentscheidung erforderlichen Claims, anstatt eine vollständige Kopie des Authentifizierungsprozesses des Benutzers zu verwalten.

Diese Trennung ist nützlich bei der Integration von Plattformen wie Microsoft Entra ID, Okta oder Google Workspace. Der Anbieter verwaltet die Authentifizierungsrichtlinie, während die verbundene Anwendung für ihr Zugriffsmodell und ihre Sitzungssteuerungen verantwortlich bleibt. Für Netzwerkbetreiber, die eine Okta-Integration für RADIUS-basierten Zugriff evaluieren, gilt dasselbe Prinzip: Identitätsvalidierung und Netzwerkautorisierung müssen zusammenarbeiten, sind aber nicht dieselbe Steuerung.

Das Konzentrationsrisiko, das SSO mit sich bringt

Ein einziges kompromittiertes Konto beim Identity Provider kann Zugriff auf mehrere verknüpfte Dienste gleichzeitig gewähren. SSO reduziert die Wildwuchs von Passwörtern, konzentriert jedoch das Vertrauen auf den Identity Provider und macht ihn zu einer hochwertigen Steuerungsebene (Control Plane). Organisationen müssen daher bewerten, wie sich die Föderation auf ihren Schadensradius und ihre Wiederherstellungsoptionen auswirkt. Die NCSC-Richtlinie zur Auswahl von Authentifizierungsmethoden hebt diese Vertrauenskonzentration als ein Risiko hervor, das eine gezielte Bewertung erfordert.

SSO konsolidiert Anmeldeereignisse. Phishing-Resistenz, Gerätevertrauen und der Zugriff nach dem Prinzip der minimalen Rechtevergabe müssen über die Kontrollen bereitgestellt werden, die die Föderationsarchitektur umgeben. Ein starkes Konzept schützt den Provider, die von ihm erstellten Sitzungen und die Wiederherstellungsprozesse, die den Zugriff wiederherstellen können.

Schichten um den Provider herum aufbauen

Die Kontrollen sollten sowohl die routinemäßige Anmeldung als auch die weniger sichtbaren Pfade abdecken, die bei der Kontowiederherstellung genutzt werden:

• Starke MFA für privilegierte Benutzer: Nutzen Sie phishing-resistente Methoden, wo die Umgebung dies unterstützt, insbesondere für Administratoren.
• Bedingter Zugriff: Bewerten Sie Gerätestatus, Standort, Sitzungsrisiko und andere verfügbare Signale, bevor Sie Zugriff gewähren.
• Separate Administratoridentitäten: Trennen Sie privilegierte Administration von gewöhnlichen alltäglichen Aktivitäten.
• Überwachung der Authentifizierung: Untersuchen Sie unmögliche Reisebewegungen, Indikatoren für Token-Replay, wiederholte Fehlschläge und unerwartete Privilegienerweiterungen.
• Schutz bei der Wiederherstellung: Behandeln Sie Helpdesk-Zurücksetzungen und Notfallkonten als sensible Identitätsvorgänge mit Genehmigung und Überwachung.

Das NCSC empfiehlt die Kombination von Enterprise SSO mit einer starken Benutzer- und Geräteauthentifizierung, einschließlich MFA oder bedingtem Zugriff. Es empfiehlt auch SSO für SaaS, da zentrale Steuerungen die Benutzer- und Gruppenverwaltung konsistenter gestalten und verhindern, dass Anmeldedaten in jede Anwendung synchronisiert werden. Das Cloud-Sicherheitsprinzip zu Identität und Authentifizierung beschreibt diesen Ansatz.

SSO verringert die Anzahl der Anmeldedaten, die Sie verwalten müssen. Es erfordert jedoch einen starken Schutz für die Anmeldedaten und Sitzungen, die verknüpfte Dienste steuern.

Netzwerkteams sollten die Mitarbeiteridentität von der Gastidentität trennen. Eine Mitarbeiter-Föderation kann das Prinzip der minimalen Rechtevergabe und eine schnelle Widerrufung unterstützen. Die Gastauthentifizierung darf keine Mitarbeiter-Verzeichnisrechte erben, nur weil beide Abläufe ein Captive Portal oder eine WiFi-Infrastruktur nutzen.

Passwortloses WiFi und verzeichnisbasierter Netzwerkzugriff

Mitarbeiter, die sich mit dem WiFi verbinden, sollten kein gemeinsames Passwort benötigen, das nach ihrem Ausscheiden gültig bleibt. Ein verzeichnisgestütztes Konzept beginnt mit der Authentifizierung über den Identitätsanbieter der Organisation und ordnet dann die verifizierte Identität oder Gruppe einer Netzwerkrolle zu. Der Drahtlosdienst wendet daher dieselben Beschäftigungs- und Zugriffsentscheidungen an, die auch an anderer Stelle verwendet werden, anstatt eine separate Liste von WiFi-Passwörtern zu führen.

Purple unterstützt dieses Modell für Enterprise WiFi durch Integrationen mit Microsoft Entra ID, Google Workspace und Okta. Sein passwortloser WiFi-Ansatz vermeidet gemeinsam genutzte Anmeldedaten und die RADIUS-Verwaltung vor Ort. Verzeichnisänderungen können die Bereitstellung oder den Widerruf auslösen. Die Gruppenmitgliedschaft eines Mitarbeiters bestimmt den Netzwerkzugriff, während das Deaktivieren des Verzeichniskontos eines ausscheidenden Mitarbeiters diesen Zugriff entfernen kann, ohne darauf warten zu müssen, dass jemand ein gemeinsames Passwort ändert.

Föderationskontrollen auf das Netzwerk anwenden

Der Identitätsanbieter, die Netzwerkrichtlinie und die Überwachung sollten dieselbe Zugriffsentscheidung treffen. Ordnen Sie Verzeichnisgruppen eindeutigen Netzwerkrollen zu, damit Mitarbeiter, Auftragnehmer und Administratoren standardmäßig nicht denselben Zugriff erhalten. Halten Sie die Lebensdauer von Zusicherungen oder Tokens kurz, um die Nutzbarkeit veralteter Identitätsdaten einzuschränken. Fordern Sie MFA beim Identitätsanbieter an, da drahtloses SSO nicht allein durch die Verwendung von SSO zu MFA wird.

Zeichnen Sie erfolgreiche und fehlgeschlagene Authentifizierungsereignisse auf und verbinden Sie jede Identitätsentscheidung mit der resultierenden Netzwerkautorisierung. Testen Sie den Zertifikats-Rollover vor dem Ablaufdatum, da Ausfälle des Föderationsvertrauens den ansonsten einwandfreien WiFi-Zugriff unterbrechen können.

Mandantenfähige Standorte erfordern eine getrennte Abgrenzung. Wohnimmobilien, Studentenwohnheime, Hotels und gemischt genutzte Gebäude können Bewohnern oder Gästen einen einfachen Zugang bieten, während der Datenverkehr von Mietern und Personalsystemen isoliert wird. iPSK kann Legacy-Geräte unterstützen, während Mitarbeiter-SSO einen separaten Pfad für die Personalidentität bereitstellt.

Gast WiFi erfordert zudem Entscheidungen über Einwilligung, Speicherung und Kundenprofile. Dieser Leitfaden für Gästedaten in Veranstaltungsorten bietet eine nützliche Referenz parallel zum Netzwerkdesign, während Purple die identitätsbasierte Authentifizierung mit dem WLAN Zugangserlebnis verbindet.

Messbare Ergebnisse für Unternehmen und Veranstaltungsorte im Vereinigten Königreich

Ein praktischer Business Case für SSO beginnt mit den Anmeldedaten, die eine Organisation nicht mehr verwalten muss. Eine Umfrage der Institution of Engineering and Technology unter 2.000 britischen Einwohnern ab 16 Jahren vom April 2024 ergab, dass nur 20% ein sicheres Passwort korrekt identifizieren konnten. Dieselbe Umfrage ergab, dass ein Fünftel ein Passwort über mehrere Websites oder Geräte hinweg wiederverwendete, während 21% ein wichtiges Datum und 20% den Namen eines Haustieres nutzten. Es wurde auch festgestellt, dass 38% glaubten, das Ersetzen von Buchstaben durch Zahlen würde die Passwortsicherheit verbessern, 65% glaubten, dass Passwörter niemals aufgeschrieben werden sollten, und 77% dachten, dass häufige Passwortänderungen die Sicherheit erhöhen. (IET-Umfrage zur Passwortsicherheit)

Diese Ergebnisse zeigen die Grenzen auf, die entstehen, wenn Benutzer für jede Anwendung und jedes Netzwerk separate Anmeldedaten erstellen und sich merken müssen. Eine zentralisierte Identität verändert, wo das Unternehmen Kontrollen anwendet und wie schnell Administratoren handeln können - auch wenn Phishing und Kontoübernahmen weiterhin reale Risiken bleiben.

Für einen Betreiber sind die Ergebnisse praktischer Natur:

• Weniger unverwaltete Anmeldedaten: Benutzer erstellen, merken und wiederverwenden weniger separate Anwendungspasswörter.
• Einheitliche Richtlinie: Der Identity Provider kann MFA, bedingten Zugriff und Passwortbeschränkungen über alle verknüpften Dienste hinweg anwenden.
• Schnellere Entziehung: Das Deaktivieren einer Organisationsidentität kann zur zentralen Maßnahme zur Zugriffsentfernung werden, sofern verknüpfte Dienste Lebenszyklusänderungen korrekt verarbeiten.
• Klarere Audit-Trails: Protokolle können die Identität einer Person mit Authentifizierungs- und Netzwerkautorisierungsentscheidungen verknüpfen.
• Weniger redundante Verwaltung: Teams verwalten Identitätsrichtlinien zentral, anstatt gleichwertige Kontrollen in jedem Dienst neu zu erstellen.

Der Nutzen geht über die Reduzierung von Anmeldeaufforderungen hinaus. Ein Gesundheitsdienstleister kann den Zugriff nach Rollen zuweisen, eine Hotelgruppe kann Personal- und Gästedienste trennen, und ein Immobilienbetreiber kann eine klarere Zuordnung von Mandanten- und Belegschaftsberechtigungen beibehalten. In jedem Fall ist das messbare Ergebnis ein kleinerer Bestand an Anmeldeinformationen, eine zuverlässigere Bearbeitung von Ausscheidenden und ein stäkerer Nachweis darüber, wer Zugriff auf eine Anwendungs- oder Netzwerkrolle erhalten hat.

SSO-Implementierung ohne Schaffung neuer Risiken

Einer sicheren Einführung geht das Identitätsmodell voraus, nicht die Anmeldeschaltfläche. Wählen Sie SAML oder OIDC, wo es zur Anwendung passt, anstatt Passwörter in eine Anwendungs- oder Netzwerkplattform zu kopieren. Etablieren Sie den Identitätsanbieter als Authentifizierungsinstanz und lassen Sie dann jeden verbundenen Dienst Aussteller, Signatur, Zielgruppe, Ablauf und Claims überprüfen, bevor eine Sitzung erstellt wird.

Verwendung einer operationalen Checkliste

• Starten Sie mit maßgeblichen Gruppen: Weisen Sie den Zugriff über Verzeichnisgruppen zu, die dem zuständigen Fachbereich oder IT-Team gehören.
• Definieren Sie Regeln für Rollenwechsel: Ein Rollenwechsel sollte alte Berechtigungen sowohl entfernen als auch neue hinzufügen.
• Verwalten Sie Ausscheidende zentral: Deaktivieren Sie die Unternehmensidentität und überprüfen Sie, ob verbundene Anwendungen und Netzwerkrollen korrekt reagieren.
• Schützen Sie Notfallzugriffe: Halten Sie Notfall-Accounts von der normalen Verwaltung getrennt, überwachen Sie diese genau und testen Sie deren Wiederherstellungsprozess.
• Trennen Sie Mitarbeiter und Gäste: Workforce SSO kann Zugriffsrechte nach dem Prinzip der geringsten Rechtevergabe sowie den Widerruf von Rechten unterstützen. Die Authentifizierung von Gästen darf niemals Mitarbeiterberechtigungen erben.
• Testen Sie Vertrauensänderungen: Überprüfen Sie Zertifikatsverlängerungen, Token-Abläufe, Sitzungsbeendigungen und Anbieterausfälle vor dem Einsatz in der Produktion.
• Überprüfen Sie das Monitoring: Stellen Sie sicher, dass Authentifizierungsereignisse, administrative Aktionen und Netzwerkautorisierungsentscheidungen für Untersuchungen zur Verfügung stehen.

Ein Standort muss möglicherweise auch mehrere Netzwerkhersteller unterstützen, anstatt seine bestehende WLAN-Infrastruktur zu ersetzen. Purple ist für die Zusammenarbeit mit Meraki, Aruba, Ruckus, Mist und UniFi konzipiert, und das angegebene Bereitstellungsmodell wird in Wochen statt in Monaten gemessen. Betrachten Sie diese Funktionen als Überlegungen zur Implementierung und nicht als Ersatz für eine Architekturprüfung. Für einen breiteren Überblick darüber, wie Technologieanbieter Sicherheitsvorkehrungen beschreiben, bietet Vertrauen und Kontrollen von AdManage.ai einen nützlichen Vergleichspunkt.

Die zentrale Entscheidung ist, ob die Organisation für jeden verbundenen Dienst erklären kann, wer den Benutzer authentifiziert, welchen Claims vertraut wird, wie Berechtigungen zugewiesen werden und was passiert, wenn sich die Identität ändert. SSO ist eine Ebene innerhalb eines Identitäts- und Zugriffsverwaltungsprogramms. Es ersetzt weder MFA, bedingten Zugriff, Authentifizierungsüberwachung, Wiederherstellungskontrollen noch Lifecycle Governance.

---

Purple verbindet Mitarbeiteridentitäten mit passwortlosem WiFi, verzeichnisbasierten Netzwerkrollen und separiertem Gastzugang und unterstützt Integrationen mit Entra ID, Google Workspace und Okta. Besuchen Sie Purple, um zu prüfen, wie das identitätsbasierte Networking Modell in Ihre bestehende WLAN Umgebung und SSO Einführung passt.