IAM: AccessManagement und SSO.
Access Management entscheidet beim Zugriff, welche Identität welche Anwendung unter welchen Bedingungen nutzen darf. Es verbindet Verzeichnisse, Anwendungen und Zugriffsrichtlinien; MFA und IGA sind wichtige Nachbardisziplinen, aber keine Synonyme. Diese Seite fasst Access Management und Single Sign-on (SSO) zusammen, weil SSO eine Kernfunktion der Access-Management-Plattformen ist.
Der Policy Point vor der Anwendung.
Die Klasse authentifiziert, föderiert und erzwingt kontextbezogene Zugriffsregeln. Sie ist besonders relevant, wenn SaaS, interne Anwendungen, externe Partner und mehrere Verzeichnisse zusammenkommen.
SSO erleichtert die Anmeldung. MFA stärkt den Nachweis der Identität. IGA klärt, wer eine Berechtigung erhalten oder behalten darf. Access Management setzt diese Entscheidung an der Anwendung oder API durch.
Was zu IAM
gehört.
Identity and Access Management (IAM) ist der Oberbegriff für alles, was Identitäten verwaltet und ihren Zugriff steuert. Auf STOP.LI ist IAM auf mehrere Werkzeugklassen verteilt, weil die Produkte unterschiedliche Aufgaben lösen. Diese Seite deckt den Kern ab: Anmeldung, Föderation, Single Sign-on und die Zugriffsentscheidung zur Laufzeit.
Hervorgehoben: die Bausteine, die Access-Management-Plattformen liefern.
Ablauf einer Zugriffsentscheidung
Die Begriffe Policy Decision Point und Policy Enforcement Point stammen aus der Zero-Trust-Architektur nach NIST SP 800-207. Zero Trust heisst hier: Jeder Zugriff wird einzeln entschieden, nicht einmal pro Netzwerkzugang.
Protokolle, die man kennen muss
| Protokoll | Wofür | Hinweis |
|---|---|---|
| SAML 2.0 | Web-SSO und Föderation mit Unternehmensanwendungen | Weit verbreitet bei etablierten SaaS- und On-Premises-Anwendungen |
| OpenID Connect | Anmeldung für Web- und Mobile-Anwendungen | Baut auf OAuth 2.0 auf und liefert ein ID-Token |
| OAuth 2.0 | Delegierte Berechtigung für APIs | Regelt Zugriff auf Ressourcen, ist allein kein Anmeldeprotokoll |
| SCIM 2.0 | Konten in SaaS-Anwendungen automatisch anlegen, ändern, entfernen | Schliesst die Lücke zwischen Identitätsquelle und Anwendung |
| Kerberos und LDAP | Anmeldung und Verzeichnisabfragen im Windows- und On-Premises-Umfeld | Häufiges Angriffsziel, siehe ITDR |
| RADIUS | Anmeldung an VPN, WLAN und Netzwerkgeräten | Oft der Weg, MFA vor ältere Systeme zu setzen |
Elf Werkzeuge im Vergleich.
Die meisten geprüften Anbieter liefern Workforce-Access-Management als Clouddienst (Microsoft Entra ID, Okta, Ping Identity, JumpCloud, Cisco Duo, Thales); daneben bestehen selbst betriebene Software (PingFederate, IBM Verify Access, Airlock IAM) und Open-Source-Identity-Provider (Keycloak, authentik, ZITADEL). Ping Identity wurde von Thoma Bravo mit ForgeRock zusammengeführt (Abschluss 23.08.2023). SAML und OIDC sind bei den meisten geprüften Produkten belegt; Unterschiede zeigen sich bei bedingtem Zugriff, Passkeys und der Anbindung lokaler Verzeichnisse und Altanwendungen. Mit Airlock IAM (Ergon Informatik, Schweiz, SaaS-Betrieb in der Schweiz) und ZITADEL (in der Schweiz gegründet) sind Anbieter mit Schweizer Bezug vertreten.
SAML/OIDC: SSO über SAML und OIDC · Passkeys: FIDO2 oder Passkeys · Risikobasiert: risikobasierter oder bedingter Zugriff · Federation: Federation und Verzeichnisanbindung (AD/LDAP) · MFA: MFA integriert · SaaS: als SaaS · On-Prem: On-Premises oder Self-Hosted möglich. ● = auf offizieller Hersteller- oder Projektseite beschrieben, – = nicht belegt (nicht zwingend nicht vorhanden). Auswahl nicht abschliessend, keine Rangliste. Stand: Oktober 2026.
Microsoft Entra ID
Microsoft
Cloud-basierter Identitäts- und Zugriffsdienst für Mitarbeitende, Partner, Workloads und KI-Agenten; SSO über SAML 2.0, OpenID Connect und weitere Verfahren.
Risikobasierte Conditional-Access-Richtlinien, die z. B. bei mittlerem oder hohem Anmelderisiko MFA verlangen; Authentication Strength kann Passkeys (FIDO2) erzwingen.
Federation-basiertes SSO für Cloud- und lokale Anwendungen; Microsoft Entra Domain Services stellt LDAP und Kerberos/NTLM für ältere Anwendungen bereit.
Ausschliesslich als Microsoft-Clouddienst; Funktionsumfang hängt von der Lizenzstufe (P1, P2) ab.
Bedingter Zugriff, Passkeys und SSO sind eng mit Microsoft 365 und Azure verbunden.
Kein Eigenbetrieb; risikobasierte Richtlinien setzen höhere Lizenzstufen voraus, Altanwendungen brauchen zusätzliche Komponenten.
Okta Workforce Identity (Single Sign-On, Adaptive MFA)
Okta
SSO für SaaS- und lokale Anwendungen über das Okta Integration Network und Okta Access Gateway; eigene Integrationen über SAML, OIDC, SWA oder SCIM.
Adaptive MFA mit phishing-resistenten Faktoren wie Okta FastPass, FIDO2-WebAuthn-Authenticators und Smartcards (PIV/CAC).
Bestehende Verzeichnisse (AD, LDAP, HR) werden in einer zentralen Steuerungsebene zusammengeführt.
Clouddienst; lokale Anwendungen werden über Okta Access Gateway eingebunden.
Breites Integrationsnetz für heterogene SaaS-Landschaften mit adaptiver MFA im selben Dienst.
Kein Eigenbetrieb des Identity Providers; Altanwendungen erfordern das zusätzliche Access Gateway.
PingOne und PingFederate
Ping Identity
SSO über OAuth, OpenID Connect, SAML und WS-Federation für Mitarbeitende, Partner und Kunden; Federation und OIDC/SAML-Brokering.
Adaptive Zugriffsrichtlinien nach Authentisierungsquelle sowie Benutzer- und Gerätekontext; FIDO2 in PingOne.
Vertrauensbeziehungen zwischen Benutzern, Mandanten, Domänen und Anwendungen über standardbasierte Federation; Anbindung von SaaS-, Cloud- und On-Premises-Anwendungen.
PingFederate kann in einer Cloud nach Wahl betrieben oder als private SaaS (Ping Cloud) bezogen werden; PingOne ist ein Clouddienst.
Wahl zwischen Eigenbetrieb und Clouddienst bei breiter Protokollunterstützung für hybride Landschaften.
Funktionen verteilen sich auf mehrere Produkte (PingOne, PingFederate, PingAM); Architektur- und Lizenzzuschnitt sind vorab zu klären.
JumpCloud Platform (SSO, Conditional Access, Cloud LDAP)
JumpCloud
SSO und MFA für SAML- und OIDC-basierte Anwendungen; Zugriff auf Cloud-Anwendungen, lokale Server und interne Ressourcen.
Conditional-Access-Richtlinien beschränken den Zugriff auf vertrauenswürdige Geräte und Netzwerke und verlangen MFA bei Bedarf.
Cloud LDAP verbindet Benutzer mit LDAP-basierten Anwendungen und Infrastruktur; Geräte- und Verzeichnisverwaltung in derselben Plattform.
Clouddienst mit Benutzerportal für den Anwendungszugriff.
Verzeichnis, Gerätesteuerung und SSO in einer Plattform für Cloud-orientierte mittelgrosse Organisationen.
Passkey-Unterstützung war auf den abgerufenen Seiten nicht belegt; komplexe Enterprise- und Legacy-Szenarien sind im Pilot zu prüfen.
Cisco Duo (Duo SSO)
Cisco
SSO mit vorgefertigten Integrationen sowie generischen SAML-2.0- und OIDC-Integrationen für eigene Anwendungen.
Kombination mit Duo-MFA und adaptiven Zugriffsrichtlinien.
Anbindung an Active Directory, Okta oder PingFederate als Identitätsquelle; Zusammenspiel mit bestehenden IdPs in Cloud oder On-Premises.
Clouddienst von Cisco Duo.
SSO als Erweiterung einer bestehenden Duo-MFA-Einführung, ohne neuen Identity-Stack.
SSO ist ein Baustein der Duo-Plattform mit Schwerpunkt MFA; Passkey-Unterstützung war auf der SSO-Seite nicht ausdrücklich belegt.
SafeNet Trusted Access
Thales
Smart Single Sign-On für Cloud-Anwendungen mit einer Identität und Ausweitung der MFA-Abdeckung.
Kontextbezogene bzw. adaptive Authentisierung; Unterstützung hochsicherer FIDO-Geräte.
Verbindung mit dem Hardware- und PKI-Portfolio von Thales (Token, FIDO-Schlüssel, On-Prem-Managementplattformen als separate Produkte).
Laut Hersteller als SaaS bereitgestellt.
SSO und MFA zusammen mit dem Token- und FIDO-Portfolio eines Herstellers.
SAML/OIDC-Details und Verzeichnisanbindung sind auf der Produktseite nicht ausgeführt; der Schwerpunkt liegt auf Authentisierung statt umfassendem Access Management.
Keycloak
Keycloak (CNCF-Projekt)
Identity Provider und Identity Broker mit OpenID Connect, OAuth 2.0 und SAML 2.0; Anmeldung auch über externe OIDC- oder SAML-Provider.
Konfigurierbare Authentisierungsflüsse mit OTP, X.509-Zertifikaten, WebAuthn und passwortloser WebAuthn-Anmeldung sowie Step-up-Authentisierung.
Eingebaute User Federation mit bestehenden LDAP- oder Active-Directory-Servern.
Lizenz Apache 2.0, Projekt unter dem Dach der Cloud Native Computing Foundation; Betrieb vollständig in eigener Verantwortung.
Offene Standards, volle Datenhoheit und Erweiterbarkeit ohne Lizenzkosten.
Risikobasierter Zugriff ist nicht als Standardfunktion beschrieben; Hochverfügbarkeit, Updates und Support liegen beim Betreiber.
authentik
authentik
Identity Provider mit OAuth2/OIDC, SAML2, SCIM, LDAP, RADIUS und Kerberos; Application Proxy und Remote Access (RDP, VNC, SSH).
MFA, WebAuthn (Passkeys), Conditional Access und GeoIP-/Impossible-Travel-Prüfungen.
LDAP- und Kerberos-Quellen sowie externe OAuth-/SAML-Quellen; Einsatz für B2B- und B2C-Fälle.
Selbst betrieben mit Container-Lösung, Kubernetes oder AWS-CloudFormation-Vorlage; eine gehostete Version wird laut Preisseite derzeit nicht angeboten.
Moderner, selbst betriebener Identity Provider mit breitem Protokollumfang und Conditional Access.
Kein verwalteter Clouddienst; Enterprise-Funktionen und Support nur mit Enterprise-Lizenz, Betrieb und Patchen liegen beim Kunden.
ZITADEL
ZITADEL
Single Sign-on über OIDC, SAML und OAuth2; Multi-Faktor mit OTP, U2F und Passkeys.
MFA mit OTP, U2F und Passkeys; passwortlose Anmeldung mit WebAuthn-fähigen Geräten; eingebauter Audit-Trail.
Mandantenfähigkeit mit Self-Service für die Federation-Einrichtung von Geschäftskunden (Enterprise IDs) und Delegation von Rollen.
Wahl zwischen ZITADEL Cloud und Eigenbetrieb; das Unternehmen wurde laut eigener Angabe in der Schweiz gegründet.
Moderne Protokolle mit Passkeys, wahlweise als Clouddienst oder selbst betrieben.
Ausrichtung eher auf Entwickler- und B2B-Szenarien; Anbindung lokaler AD/LDAP-Verzeichnisse und risikobasierter Zugriff sind auf den geprüften Seiten nicht belegt.
Airlock IAM
Ergon Informatik AG
Authentisierung und SSO für Kunden, Partner und Mitarbeitende mit SAML 2.0, Kerberos, OAuth 2.0, OpenID Connect und weiteren Formaten.
Step-up- und Step-down-Authentisierung, adaptive bzw. risikobasierte Authentisierung, FIDO, WebAuthn und Passkeys sowie eigene 2FA-Lösung.
Teil des Airlock Secure Access Hub zusammen mit Airlock Gateway (WAF) und Microgateway; Identitätsweitergabe an nachgelagerte Dienste.
SaaS und On-Premises basieren auf demselben Softwarekern; der Dienst wird in der Schweiz betrieben und gehostet.
Schweizer Anbieter mit Betrieb wahlweise lokal oder als in der Schweiz gehosteter Dienst.
Schwerpunkt der Kommunikation liegt auf Kunden- und Partneridentitäten; Anbindung lokaler AD/LDAP-Verzeichnisse war auf den geprüften Seiten nicht beschrieben.
IBM Verify (Verify Access)
IBM
Access Management mit SSO und MFA, Interoperabilität mit OpenID; Einsatz in Cloud- und On-Premises-Umgebungen.
Adaptive Risikobewertung und risikobasierte Authentisierung mit Verhaltens- und biometrischen Signalen; passwortlose Verfahren inklusive FIDO2.
Teil der IBM-Verify-Familie mit Verify Directory (containerisiert), Verify Trust und Identity Orchestration.
Laut Produktseite in Cloud- und On-Premises-Umgebungen einsetzbar; Bezug auch über AWS Marketplace.
Risikobasierte Authentisierung für hybride Enterprise-Landschaften mit Eigenbetrieb.
SAML, Verzeichnisanbindung und SaaS-Variante sind auf der Produktseite nicht klar beschrieben; Modulzuschnitt der Verify-Familie vorab klären.
Weitere Anbieter
Kurz eingeordnet, ausserhalb der Vergleichsmatrix.
- OneLogin (One Identity): Workforce-SSO mit MFA und kontextbezogenem Zugriff
- Google Cloud Identity: Verzeichnis und Federation für Google-Umgebungen
- Oracle Cloud Infrastructure IAM (Identity Domains): Workforce- und Kunden-IAM in Oracle Cloud Infrastructure
- Red Hat build of Keycloak: unterstützte Keycloak-Distribution von Red Hat; als Variante von Keycloak behandelt
- Thales OneWelcome: Identity-Plattform von Thales mit Schwerpunkt Kunden- und Partneridentitäten; gehört zur Klasse Customer Identity
- Cloudflare Access, Zscaler Private Access: Zugriffsvermittlung auf Anwendungen (ZTNA), kein Identity Provider; Klasse Netzwerk/Zero Trust
Anwendung
für Anwendung.
- Anwendungen nach Kritikalität und Protokoll inventarisieren (SAML, OIDC, Altanwendungen mit Header- oder Formularanmeldung) und die Reihenfolge der Anbindung danach festlegen.
- Zugriffsrichtlinien als wenige wiederverwendbare Stufen definieren (z. B. Standard, sensibel, administrativ), statt je Anwendung eigene Regeln zu bauen.
- Lokale Anmeldungen in angebundenen Anwendungen abschalten, sobald die Föderation stabil läuft; sonst bleibt ein Umgehungsweg offen.
- Sitzungsdauer und Token-Lebenszeit je Stufe festlegen und den Widerruf aktiver Sitzungen bei Austritt oder Kompromittierung testen.
- Anteil Anwendungen mit Föderation und abgeschalteter lokaler Anmeldung
- Zeit vom Sperrentscheid bis zur Beendigung aller aktiven Sitzungen
- Anteil Zugriffe auf sensible Anwendungen, die über eine kontextbezogene Richtlinie laufen
Das IAM-Team betreibt Plattform und Richtlinienstufen, die Applikations-Owner verantworten Anbindung und Einstufung ihrer Anwendung. Security legt Mindestanforderungen je Stufe fest und prüft Ausnahmen.
ISO/IEC 27001:2022 Annex A 5.15 (Zugangssteuerung), 5.17 (Authentisierungsinformationen) und 8.5 (sichere Authentisierung); NIS2 Art. 21 Abs. 2 lit. i und j nennen Konzepte für die Zugriffskontrolle sowie Multi-Faktor- oder kontinuierliche Authentisierung.
DORA Art. 9 Abs. 4 lit. c und d verlangen, den logischen Zugang auf das Erforderliche zu beschränken und starke Authentifizierungsmechanismen zu implementieren; Access Management liefert dafür durchgesetzte Regeln und Protokolle als Nachweis.
Zentrales Access Management ist nicht automatisch Zero Trust. Solange angebundene Anwendungen lokale Konten, lange Sitzungen oder statische API-Schlüssel zulassen, entscheidet die Richtlinie nur über einen Teil der Zugriffe.
Was im Pilot sichtbar werden muss.
- Föderation und Provisionierung für reale Kernanwendungen.
- Kontextregeln für Gerät, Standort, Risiko und externe Partner.
- Verhalten bei Ausfall des Identity Providers und bei Notzugriffen.
- Auditierbare Ereignisse bis in SIEM und Incident Response.
Diese Werkzeugklasse ist die Durchsetzungsschicht der Identitätsarchitektur. Für privilegierte Zugriffe gehören PAM und Endpoint Privilege Management daneben, nicht darunter.
Security Tool Navigator · Gebiet 03
Im Gebiet Identity Security einordnen.
Diese Werkzeugklasse gehört zum Gebiet Identity Security. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.