Für Windows- und Microsoft-Umgebungen ist Microsoft Entra ID meist der naheliegende Ausgangspunkt, während Okta und Ping Identity bei heterogenen Anwendungslandschaften sowie komplexeren Identitätsarchitekturen stärker in den Vordergrund rücken. Cisco Duo eignet sich vor allem, wenn eine überschaubare SSO-Einführung eng mit Mehr-Faktor-Authentifizierung verbunden werden soll. Keycloak ist die flexible, selbst betriebene Alternative für Unternehmen mit eigener Entwicklungs- und Betriebskompetenz. AD FS bleibt vor allem für bestehende lokale Verbundstrukturen relevant, ist aber selten die erste Wahl für eine neue Cloud-SSO-Plattform.
Die passende Entscheidung hängt nicht allein davon ab, welche Lösung eine Anmeldeseite bereitstellt. Ausschlaggebend sind die vorhandenen Benutzerverzeichnisse, die zu integrierenden Anwendungen, unterstützte Protokolle, Geräteverwaltung, Bereitstellungsaufwand und die Frage, wer den laufenden Betrieb verantwortet. Auch Benutzeranlage und -entzug gehören in die Auswahl: SSO vereinfacht die Anmeldung, ersetzt aber nicht automatisch den vollständigen Identitätslebenszyklus.
Welche Aufgaben eine Unternehmenslösung tatsächlich abdecken muss
Single Sign-on bedeutet, dass ein zentraler Identitätsanbieter die Anmeldung für mehrere verbundene Anwendungen übernimmt. Nach erfolgreicher Authentifizierung stellt er der jeweiligen Anwendung eine signierte Identitätsinformation oder ein Zugriffstoken bereit. Das Kennwort muss dadurch nicht bei jedem angebundenen Dienst erneut eingegeben werden.
In Microsoft-orientierten Unternehmen beginnt die Anforderung häufig bei Windows, Microsoft 365 und Active Directory. Hinzu kommen Fachanwendungen, VPN-Zugänge, Software-as-a-Service-Dienste und intern entwickelte Webanwendungen. Eine geeignete Plattform sollte diese Bereiche nicht nur anmelden, sondern Zugriffe bei Bedarf an Bedingungen knüpfen können.
- Authentifizierung: Prüfung der Identität durch Kennwort, Sicherheitsschlüssel, Zertifikat, Authenticator-App oder andere zugelassene Verfahren.
- Föderation: Vertrauensbeziehung zwischen dem Identitätsanbieter und einer Anwendung, meist über SAML 2.0 oder OpenID Connect.
- Autorisierung: Entscheidung darüber, welche Anwendung, Rolle oder Ressource ein angemeldeter Benutzer verwenden darf.
- Provisionierung: Anlegen, Aktualisieren und Sperren von Konten in Zielanwendungen, häufig über SCIM oder anbieterspezifische Schnittstellen.
- Zugriffsrichtlinien: Zusätzliche Anforderungen anhand von Benutzergruppe, Gerät, Standortsignal, Risiko oder Anwendung.
Diese Aufgaben sollten im Auswahlverfahren getrennt bewertet werden. Eine Anwendung kann beispielsweise SAML-Anmeldung unterstützen, aber keine automatisierte Deprovisionierung anbieten. Ein ausgeschiedener Mitarbeiter verliert dann möglicherweise den zentralen Login, während ein lokales Anwendungskonto oder eine aktive Sitzung bestehen bleibt. Ein belastbares Offboarding benötigt deshalb mehr als eine funktionierende SSO-Verbindung.
Sechs etablierte Wege für zentrale Anmeldung und Zugriffsverwaltung
Die folgenden Lösungen gehören zu unterschiedlichen Produktklassen. Sie werden deshalb nach demselben Raster eingeordnet: Integration in Microsoft- und Windows-Strukturen, Eignung für gemischte Anwendungslandschaften, Betriebsmodell, Möglichkeiten zur Kontenbereitstellung sowie wesentliche Grenze.
| Lösung | Microsoft- und Windows-Bezug | Gemischte Anwendungen | Betriebsmodell | Typische Grenze |
|---|---|---|---|---|
| Microsoft Entra ID | Sehr eng mit Microsoft 365, Windows und Microsoft-Diensten verzahnt | Galerieanwendungen sowie SAML- und OpenID-Connect-Integrationen | Cloud-Dienst, optional mit hybrider Verzeichnisanbindung | Erweiterte Richtlinien und Identitätsfunktionen hängen von Lizenz und Produktumfang ab |
| Okta Workforce Identity | Anbindung an Microsoft-Verzeichnisse und Microsoft-Anwendungen möglich | Stark auf herstellerübergreifende SaaS- und Unternehmenslandschaften ausgerichtet | Cloud-Dienst mit Agenten und Konnektoren für lokale Systeme | Zusätzliche Plattform neben dem vorhandenen Microsoft-Ökosystem |
| Ping Identity | Für Microsoft-Verzeichnisse und hybride Unternehmensstrukturen geeignet | Breite Ausrichtung auf Föderation, komplexe Richtlinien und hybride Architekturen | Je nach Produkt und Architektur Cloud, lokal oder hybrid | Planung und Betrieb können anspruchsvoller als bei einer einfachen Standardumgebung sein |
| Cisco Duo SSO | Mit Active Directory und Microsoft-Anwendungen kombinierbar | SSO für angebundene Cloud-Anwendungen, Schwerpunkt auf sicherer Authentifizierung | Cloud-Dienst mit erforderlichen Integrationen zur Umgebung | Für umfassendes Identity Governance oder komplexe Lebenszyklusprozesse oft nicht allein ausreichend |
| Keycloak | Verzeichnisanbindung ist möglich, aber keine native Microsoft-Gesamtplattform | Gut für standardbasierte und selbst entwickelte Anwendungen | Selbst betrieben oder über einen Dienstleister verwaltet | Unternehmen tragen Verantwortung für Hochverfügbarkeit, Updates, Absicherung und Monitoring |
| AD FS | Eng an lokale Active-Directory-Strukturen angebunden | Föderation mit kompatiblen Anwendungen und Partnern | Lokaler Windows-Server-Betrieb | Hoher Eigenbetrieb; für neue Cloud-zentrierte Vorhaben meist weniger attraktiv |
Microsoft Entra ID für Microsoft 365 und verwaltete Windows-Geräte
Microsoft Entra ID ist besonders schlüssig, wenn Benutzerkonten, Microsoft 365, Windows-Geräte und Sicherheitsrichtlinien bereits überwiegend im Microsoft-Ökosystem verwaltet werden. Der Dienst kann als Identitätsanbieter für Microsoft-Anwendungen und zahlreiche externe SaaS-Dienste dienen. Lokale Active-Directory-Strukturen lassen sich in eine hybride Identitätsarchitektur einbinden, ohne dass jede Anwendung unmittelbar gegen den lokalen Domänencontroller authentifizieren muss.
Ein wichtiger Auswahlpunkt ist die gewünschte Tiefe. Einfache Anmeldung, bedingte Zugriffsentscheidungen, Identitätsschutz, privilegierte Rollen und Governance-Funktionen sind nicht automatisch in jedem Lizenzpaket in gleichem Umfang enthalten. Vor der Beschaffung sollten Administratoren im Microsoft-Produktvergleich und im Entra Admin Center prüfen, welche Funktionen für den vorhandenen Mandanten freigeschaltet sind. Entscheidend ist die tatsächlich benötigte Kombination, nicht allein der Produktname.
Entra ID ist meist die erste Prüfoption, wenn Windows 11, Microsoft 365 und gegebenenfalls Microsoft Intune den Arbeitsplatz prägen. Besteht die Anwendungslandschaft überwiegend aus Produkten anderer Hersteller und soll die Identitätsplattform bewusst unabhängig von Microsoft geführt werden, verdient eine neutrale Alternative einen gleichwertigen Pilotversuch.
Okta Workforce Identity für eine herstellerübergreifende Anwendungslandschaft
Okta Workforce Identity richtet sich an Mitarbeiteridentitäten und wird häufig als unabhängige Schicht zwischen Benutzerverzeichnissen und vielen Cloud-Anwendungen eingesetzt. Die Plattform ist interessant, wenn Microsoft-Dienste nur einen Teil der Umgebung bilden und zahlreiche weitere SaaS-Produkte über einen zentralen Anwendungskatalog angebunden werden sollen.
Der Vorteil der Neutralität bringt einen Architekturentscheid mit sich: Rollen, Gruppen, Richtlinien und Lebenszyklusprozesse müssen zwischen Okta, Active Directory, Personalverwaltung und Zielanwendungen klar verteilt werden. Ohne ein festgelegtes führendes System entstehen doppelte Gruppenstrukturen oder widersprüchliche Zuständigkeiten. Vor einer Entscheidung sollte für jede wichtige Anwendung geprüft werden, ob nur SSO, zusätzlich SCIM oder ein anbieterspezifischer Provisionierungsweg verfügbar ist.
Okta passt besonders gut, wenn die IT eine zentrale, herstellerübergreifende Identitätsebene aufbauen möchte. Bei einer fast vollständig auf Microsoft ausgerichteten Umgebung sollte der zusätzliche Nutzen gegen die Kosten und den administrativen Parallelbetrieb abgewogen werden.
Ping Identity für hybride und komplexe Zugriffsmodelle
Ping Identity ist eine Option für größere oder technisch vielfältige Umgebungen, in denen Cloud-Dienste, lokale Anwendungen, Partnerzugänge und eigene Schnittstellen gemeinsam abgesichert werden müssen. Die Produktfamilie deckt unterschiedliche Bereiche rund um Authentifizierung, Föderation und Zugriffssteuerung ab. Welche Komponenten erforderlich sind, hängt stark von der Architektur ab.
Die Stärke liegt weniger in einer möglichst kleinen Standardinstallation als in der Anpassbarkeit an anspruchsvolle Identitätsflüsse. Das kann bei mehreren Benutzergruppen, Geschäftspartnern, älteren Anwendungen oder besonderen Bereitstellungsanforderungen wichtig sein. Gleichzeitig steigen Planungsbedarf und Anforderungen an das Betriebsteam. Ein Proof of Concept sollte deshalb nicht nur eine moderne SaaS-Anwendung, sondern auch die schwierigste lokale oder partnerspezifische Integration enthalten.
Cisco Duo SSO mit Schwerpunkt auf Mehr-Faktor-Authentifizierung
Cisco Duo verbindet SSO mit einer starken Ausrichtung auf Mehr-Faktor-Authentifizierung und Zugriffsprüfung. Die Lösung kann sinnvoll sein, wenn Duo bereits zur Absicherung von VPN, Serverzugängen oder Anwendungen eingesetzt wird und der Betrieb die Zahl separater Anmeldungen reduzieren möchte.
Für eine überschaubare Einführung mit klaren Anwendungen ist dieser Ansatz oft leichter zu erfassen als eine umfangreiche Identity-Governance-Plattform. Die Grenze zeigt sich, sobald komplexe Genehmigungsabläufe, detaillierte Rollenmodelle oder ein weitreichender automatisierter Kontenlebenszyklus verlangt werden. Dann muss geprüft werden, ob Duo mit einem führenden Verzeichnis und weiteren Verwaltungswerkzeugen kombiniert wird. Unterstützte Integrationen und enthaltene Funktionen sollten in der Duo-Dokumentation für die geplante Edition einzeln bestätigt werden.
Keycloak für selbst betriebene und eigene Anwendungen
Keycloak ist eine quelloffene Identitäts- und Zugriffsplattform, die unter anderem OpenID Connect, OAuth 2.0 und SAML unterstützt. Sie eignet sich besonders für Unternehmen, die eigene Webanwendungen entwickeln, standardisierte Protokolle benötigen und die Plattform in der eigenen Infrastruktur oder einer selbst kontrollierten Cloud-Umgebung betreiben wollen.
Die Software vermeidet zwar die Bindung an einen ausschließlich als Cloud-Dienst angebotenen Identitätsanbieter, macht den Betrieb aber nicht kostenlos. Hochverfügbarkeit, Datenbank, Zertifikate, Schlüsselverwaltung, Protokollierung, Sicherheitsupdates, Sicherungen und Wiederherstellung müssen geplant und getestet werden. Auch eine sichere Vorkonfiguration entsteht nicht automatisch durch die Installation.
Keycloak ist eine gute Wahl für ein kompetentes Plattformteam mit klaren Anforderungen an Anpassung und Datenhaltung. Unternehmen ohne dauerhaft zuständige Linux-, Container- oder Identitätsspezialisten sollten einen verwalteten Betrieb oder einen SaaS-Anbieter eher bevorzugen.
AD FS für bestehende lokale Föderationsstrukturen
Active Directory Federation Services ist eine Windows-Server-Rolle für föderierte Anmeldungen. AD FS kann in etablierten lokalen Umgebungen weiterhin eine wichtige Funktion erfüllen, etwa wenn Anwendungen oder Partnerbeziehungen ausdrücklich daran gebunden sind. Es ist jedoch keine vollständige Cloud-Identitätsplattform und verlangt eigene Server, Zertifikatsverwaltung, Überwachung, Absicherung sowie eine hochverfügbare Auslegung.
Für ein neues Projekt sollte zunächst geklärt werden, ob die betreffenden Anwendungen direkt mit einem modernen Cloud-Identitätsanbieter verbunden werden können. Bleibt AD FS wegen einer Altanwendung notwendig, ist eine begrenzte Übergangs- oder Sonderrolle meist leichter zu beherrschen als der Aufbau weiterer Abhängigkeiten. Eine vorhandene Installation sollte nicht allein aus Gewohnheit zum Standard für jede neue Anwendung werden.
Die Auswahl beginnt beim führenden Benutzerverzeichnis
Vor einem Produktvergleich muss feststehen, wo eine digitale Identität entsteht und endet. Das kann ein lokales Active Directory, ein Cloud-Verzeichnis oder ein Personalverwaltungssystem mit nachgeschaltetem Identitätsmanagement sein. Ohne diese Festlegung bleibt unklar, welche Plattform Namen, Abteilung, Gruppen und Austrittsdatum verbindlich vorgibt.
- Erfasse alle Benutzergruppen: Beschäftigte, externe Dienstleister, Administratoren, Partner und technische Konten benötigen oft unterschiedliche Verfahren.
- Ordne jede wichtige Anwendung einem Protokoll zu. SAML 2.0 und OpenID Connect sind für moderne SSO-Verbindungen üblich; ältere Anwendungen benötigen eventuell einen Proxy, ein Gateway oder eine Übergangslösung.
- Prüfe getrennt, wie Konten angelegt und gesperrt werden. Eine erfolgreiche Anmeldung sagt nichts darüber aus, ob SCIM, eine API oder nur manuelle Verwaltung verfügbar ist.
- Lege fest, welche Signale eine Zugriffsentscheidung beeinflussen dürfen. Dazu können Mehr-Faktor-Authentifizierung, Gerätezustand, Netzwerk, Benutzerrolle und Anmelderisiko gehören.
- Plane zwei Notfallzugänge, die nicht vom normalen Föderationsweg abhängen. Ihre Verwendung muss streng kontrolliert und regelmäßig getestet werden.
Für Windows-Arbeitsplätze ist zusätzlich zu unterscheiden, ob lediglich Webanwendungen per SSO geöffnet werden sollen oder ob auch Geräteanmeldung, Geräteverwaltung und passwortlose Verfahren Teil des Projekts sind. Ein Browser-Login über SAML ersetzt weder die Windows-Anmeldung noch die Verwaltung des Gerätezustands. Diese Unterscheidung verhindert, dass eine gute SaaS-Anbindung fälschlich als vollständige Arbeitsplatzlösung bewertet wird.
Ein Pilot muss Abmeldung, Ausfall und Offboarding einschließen
Eine Demonstration mit einem aktiven Benutzer und einer einzelnen Anwendung belegt nur den einfachsten Teil. Ein aussagekräftiger Pilot umfasst mindestens eine Microsoft-Anwendung, eine wichtige Drittanbieteranwendung und – sofern vorhanden – eine technisch schwierige lokale Anwendung. Getestet werden reguläre Anmeldung, Mehr-Faktor-Anforderung, Gruppenänderung, Kontensperre und der Ausfall einer beteiligten Komponente.
| Beobachtung im Pilot | Bedeutung | Nächste Entscheidung |
|---|---|---|
| SSO funktioniert, das Zielkonto bleibt nach einer zentralen Sperre aber aktiv | Authentifizierung und Provisionierung sind nicht vollständig gekoppelt | SCIM, API-Anbindung oder verbindlichen manuellen Entzugsprozess ergänzen |
| Verwaltete Windows-Geräte werden erkannt, private Geräte jedoch gleichbehandelt | Gerätesignale fehlen oder werden in der Richtlinie nicht ausgewertet | Geräteverwaltung und Zugriffsregeln vor der Freigabe abstimmen |
| Eine ältere Anwendung versteht weder SAML noch OpenID Connect | Direkte moderne Föderation ist nicht möglich | Modernisierung, Zugriffsproxy oder begrenzte Sonderlösung bewerten |
| Beim Ausfall des Identitätsanbieters sind auch Administrationszugänge blockiert | Der Notfallzugang ist unzureichend | Unabhängige Notfallkonten und Wiederanlaufverfahren einrichten |
| Gruppen werden aus mehreren Systemen überschrieben | Die Datenhoheit ist nicht eindeutig | Für jedes Attribut ein führendes System festlegen |
Auch die Abmeldung benötigt Aufmerksamkeit. SSO führt nicht automatisch dazu, dass das Abmelden aus einer Anwendung alle anderen Sitzungen beendet. Sitzungslaufzeiten, Token-Widerruf und globale Abmeldefunktionen unterscheiden sich nach Protokoll und Anwendung. Für besonders schützenswerte Dienste kann eine kurze oder erneut bestätigte Sitzung sinnvoller sein als maximaler Komfort.
Welche Lösung passt zu welcher Unternehmenslage?
In einem Unternehmen mit Microsoft 365, verwalteten Windows-Geräten und einer bereits etablierten Microsoft-Identität sollte Microsoft Entra ID zuerst geprüft werden. Der wesentliche Vorteil liegt in der Verzahnung der vorhandenen Dienste. Vor der Freigabe müssen Lizenzumfang, Drittanbieterintegrationen und automatisiertes Offboarding bestätigt werden.
Bei einer großen, herstellerübergreifenden SaaS-Landschaft sind Okta Workforce Identity und Ping Identity die naheliegenden Vergleichskandidaten. Okta spricht häufig Unternehmen an, die eine unabhängige zentrale Plattform für viele Standardanwendungen suchen. Ping Identity kommt stärker in Betracht, wenn hybride Bereitstellung, Partneridentitäten oder angepasste Föderationsabläufe den Ausschlag geben. Die endgültige Wahl sollte anhand derselben eigenen Anwendungsliste getestet werden.
Cisco Duo SSO passt zu einem klar begrenzten SSO-Projekt, bei dem sichere Mehr-Faktor-Authentifizierung im Mittelpunkt steht und Duo bereits eingesetzt wird. Keycloak empfiehlt sich für standardbasierte Eigenentwicklungen und Organisationen, die den technischen Betrieb bewusst selbst übernehmen. AD FS ist vor allem dann vertretbar, wenn bestehende lokale Abhängigkeiten einen Weiterbetrieb verlangen; für eine neue Cloud-zentrierte Umgebung sollte es nicht ungeprüft als Ausgangspunkt gesetzt werden.
Eine belastbare Entscheidung entsteht somit nicht durch die längste Funktionsliste. Sie entsteht, wenn der Kandidat die wichtigsten Anwendungen integriert, ausgeschiedene Benutzer zuverlässig entzieht, Windows- und Gerätesignale passend verarbeitet und auch bei Störungen administrierbar bleibt. Genau diese vier Ergebnisse sollten vor einem unternehmensweiten Rollout nachweisbar sein.
