Wie funktioniert Single Sign-on?

Single Sign-on (SSO) ist eine Authentifizierungsmethode, die es Benutzern ermöglicht, sich auf sichere Weise bei mehreren Anwendungen und Webseiten zu authentifizieren und dabei nur einmal ihre Anmeldeinformationen einzugeben.

SSO basiert auf einer Vertrauensstellung zwischen einer Anwendung, die als Serviceanbieter fungiert, und einem Identitätsanbieter wie OneLogin. Grundlage für diese Vertrauensstellung ist häufig ein Zertifikat, das zwischen dem Identitätsanbieter und dem Serviceanbieter ausgetauscht wird. Mithilfe des Zertifikats können die vom Identitätsanbieter an den Serviceanbieter gesendeten Identitätsdaten signiert werden. So erkennt der Serviceanbieter, dass die Daten aus einer vertrauenswürdigen Quelle stammen. Beim SSO liegen diese Identitätsdaten in Form von Token vor, die Informationen zur Identifizierung des Benutzers enthalten, wie z. B. eine E-Mail-Adresse des Benutzers oder ein Benutzername.

Der Anmeldeablauf sieht in der Regel so aus:

1. Ein Benutzer navigiert zu der Anwendung oder Webseite, auf die er zugreifen möchte, d. h. dem Serviceanbieter.
2. Der Serviceanbieter sendet ein Token mit Informationen über einen Benutzer, wie z. B. seiner E-Mail-Adresse, an das SSO-System (d. h. den Identitätsanbieter) und fordert die Authentifizierung des Benutzers an.
3. Der Identitätsanbieter prüft zunächst, ob der Benutzer bereits authentifiziert wurde. In diesem Fall gewährt er dem Benutzer Zugriff auf die Anwendung des Serviceanbieters und fährt mit Schritt 5 fort.
4. Wenn sich der Benutzer noch nicht angemeldet hat, wird er vom Identitätsanbieter aufgefordert, die erforderlichen Anmeldeinformationen einzugeben. Dabei könnte es sich einfach um einen Benutzernamen und ein Kennwort handeln. Es könnte auch eine andere Form der Authentifizierung erforderlich sein, wie z. B. ein Einmalkennwort (One-Time Password, OTP).
5. Wenn der Identitätsanbieter die angegebenen Anmeldeinformationen validiert hat, sendet er ein Token zum Serviceanbieter zurück, um die erfolgreiche Authentifizierung zu bestätigen.
6. Dieses Token wird über den Browser des Benutzers an den Serviceanbieter weitergegeben.
7. Das vom Serviceanbieter empfangene Token wird gemäß der Vertrauensstellung validiert, die zwischen dem Serviceanbieter und dem Identitätsanbieter während der Erstkonfiguration eingerichtet wurde.
8. Dem Benutzer wird Zugriff auf den Serviceanbieter gewährt.

Wenn der Benutzer versucht, auf eine andere Webseite zuzugreifen, erfolgt der gleiche Authentifizierungsablauf, sofern für die neue Webseite eine ähnliche Vertrauensstellung mit der SSO-Lösung konfiguriert wurde.

Ein SSO-Token ist eine Sammlung von Daten oder Informationen, die während des SSO-Verfahrens von einem System zu einem anderen weitergegeben wird. Bei den Daten kann es sich einfach um die E-Mail-Adresse eines Benutzers und Informationen zu dem System handeln, von dem das Token gesendet wird. Die Token müssen digital signiert sein, damit der Empfänger des Tokens prüfen kann, ob das Token von einer vertrauenswürdigen Quelle stammt. Das für diese digitale Signatur verwendete Zertifikat wird während der Erstkonfiguration ausgetauscht.

Die Antwort auf diese Frage lautet: „Es kommt darauf an.“

SSO kann auf verschiedene Weise zur Verbesserung der Sicherheit beitragen. Eine Single-Sign-on-Lösung kann die Verwaltung von Benutzernamen und Kennwörtern für Benutzer wie auch Administratoren vereinfachen. Benutzer müssen sich nicht mehr verschiedene Anmeldeinformationen merken und benötigen nur noch ein einziges Kennwort, dass dafür komplexer sein kann. SSO ermöglicht Benutzern häufig, viel schneller auf ihre Anwendungen zuzugreifen.

Durch SSO wird auch der Helpdesk entlastet, der weniger Zeit mit der Unterstützung von Benutzern verbringen muss, die ihr Kennwort vergessen haben. Administratoren können Anforderungen wie die Komplexität von Kennwörtern und die Multi-Faktor-Authentifizierung (MFA) zentral steuern. Zudem können sie einem Benutzer schneller sämtliche Anmelderechte entziehen, wenn dieser das Unternehmen verlässt.

Single Sign-on hat jedoch auch Nachteile. Beispielsweise könnte es sein, dass Sie manche Anwendungen besonders absichern möchten. Aus diesem Grund wäre eine SSO-Lösung zu empfehlen, die es Ihnen zum Beispiel ermöglicht, bei Zugriffsversuchen auf eine bestimmte Anwendung einen zusätzlichen Authentifizierungsfaktor zu verlangen oder die Anmeldung bei bestimmten Anwendungen nur über ein sicheres Netzwerk zuzulassen.

Die Details der Implementierung einer SSO-Lösung hängen von Ihrer konkreten SSO-Lösung ab. Doch unabhängig von den spezifischen Schritten müssen Sie sich darüber im Klaren sein, was genau Sie mit der Implementierung erreichen möchten. Beantworten Sie dazu die folgenden Fragen:

• Welche verschiedenen Arten von Benutzern unterstützen Sie und welche unterschiedlichen Anforderungen haben diese?
• Suchen Sie nach einer On-Premises- oder einer cloudbasierten Lösung?
• Kann diese Lösung mit Ihrem Unternehmen und Ihren Anforderungen mitwachsen?
• Auf welche Weise möchten Sie sicherstellen, dass sich nur vertrauenswürdige Benutzer anmelden? Mithilfe von MFA, adaptiver Authentifizierung, Gerätevertrauen, Whitelisting von IP-Adressen oder einer anderen Lösung?
• In welche Systeme müssen Sie die Lösung integrieren?
• Benötigen Sie API-Zugriff?

Es ist wichtig, den Unterschied zwischen Single Sign-on und Kennworttresoren oder Password Managern zu verstehen, die manchmal als „SSO“ bezeichnet werden, was in diesem Fall allerdings „Same Sign-On“ und nicht „Single Sign-on“ bedeutet. Wenn Sie einen Kennwort-Vault nutzen, können Sie zwar denselben Benutzernamen und dasselbe Kennwort haben, müssen diese aber bei jedem Wechsel zu einer anderen Anwendung oder Webseite neu eingeben. Bei diesem System speichern Sie einfach die Anmeldeinformationen für die verschiedenen Anwendungen und geben diese bei Bedarf ein. Zwischen den Anwendungen und dem Kennworttresorsystem wird keine Vertrauensstellung eingerichtet.

Bei SSO im Sinne von „Single Sign-on“ können Sie nach der Anmeldung über die SSO-Lösung auf alle vom Unternehmen genehmigten Anwendungen und Webseiten zugreifen, ohne sich erneut anmelden zu müssen. Dies gilt für cloudbasierte wie auch On-Premises-Anwendungen, die häufig über ein SSO-Portal (auch als „Anmeldeportal“ bezeichnet) zugänglich sind.

Bei der Untersuchung der verfügbaren SSO-Optionen stoßen Sie möglicherweise auf unterschiedliche Begriffe: SSO-Software, SSO-Lösung und SSO-Anbieter. In vielen Fällen kann sich der Unterschied einfach daraus ergeben, wie sich das Unternehmen selbst kategorisiert. Wenn von Software die Rede ist, wird vermutlich ein Programm lokal installiert. Dieses Programm erledigt normalerweise nur ganz bestimmte Aufgaben. Bei einer Lösung ist davon auszugehen, dass die Funktionen des Kernprodukts erweitert oder angepasst werden können. Bei einem Anbieter handelt es sich um ein Unternehmen, das die Lösung entwickelt oder hostet. OneLogin ist beispielsweise als ein SSO-Lösungsanbieter bekannt.

Im Zusammenhang mit Single Sign-on (SSO) werden zahlreiche Begriffe verwendet.

• Federated Identity Management (FIM)
• OAuth (heute insbesondere OAuth 2.0)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Same Sign-On (SSO)

SSO ist tatsächlich Teil eines größeren Konzepts, das als „Federated Identity Management“ bezeichnet wird. Daher wird SSO manchmal auch „Federated SSO“ genannt. FIM bezieht sich nur auf eine Vertrauensstellung, die zwischen zwei oder mehreren Domänen oder Systemen für Identity Management eingerichtet wird. Single Sign-on steht oft als Funktion innerhalb einer FIM-Architektur zur Verfügung.

OAuth 2.0 ist ein spezifisches Framework, das auch als Bestandteil einer FIM-Architektur betrachtet werden könnte. OAuth konzentriert sich auf die Vertrauensstellung und ermöglicht den Austausch von Benutzeridentitätsinformationen zwischen den Domänen.

OpenID Connect (OIDC) ist eine Authentifizierungsebene über OAuth 2.0, die Single-Sign-on-Funktionalität bereitstellt.

Die oft auch mit „SSO“ bezeichnete Same-Sign-On-Methode ist nicht mit Single Sign-on zu verwechseln, da keine Vertrauensstellung zwischen den an der Authentifizierung beteiligten Entitäten besteht. Stattdessen werden die Anmeldeinformationen auf den jeweiligen Systemen dupliziert und bei Bedarf übermittelt. Same Sign-On ist nicht so sicher wie eine Single-Sign-on-Lösung.

Im Zusammenhang mit Single Sign-on ist häufig von einigen spezifischen Systemen die Rede: Active Directory, Active Directory Federation Services (ADFS) und Lightweight Directory Access Protocol (LDAP).

Active Directory ist der zentrale Verzeichnisdienst von Microsoft, der heute konkret als „Active Directory Domain Services (ADDS)“ bezeichnet wird. Benutzer und Ressourcen werden zwecks zentraler Verwaltung dem Verzeichnisservice hinzugefügt und ADDS verwendet Authentifizierungsprotokolle wie NTLM und Kerberos. Somit können sich von ADDS erfasste Benutzer von ihren Rechnern aus authentifizieren und Zugriff auf andere Systeme erhalten, die mit ADDS integriert sind. Dies ist eine Art von Single Sign-on.

Bei Active Directory Federation Services (ADFS) handelt es sich um ein bestimmtes Federated-Identity-Management-System, das auch Single-Sign-on-Funktionen bietet. Es unterstützt sowohl SAML als auch OIDC. ADFS wird hauptsächlich genutzt, um eine Vertrauensstellung zwischen ADDS und anderen Systemen wie Azure AD oder anderen ADDS-Gesamtstrukturen einzurichten.

Lightweight Directory Access Protocol (LDAP) ist nichts anderes als ein Branchenstandard, der definiert, wie Verzeichnisdaten organisiert und abgefragt werden. LDAP ermöglicht die zentrale Verwaltung von Ressourcen wie Benutzern und Systemen. Der Standard legt allerdings nicht fest, wie die Anmeldung bei diesen Systemen erfolgt, definiert also nicht die tatsächlich zur Authentifizierung genutzten Protokolle. LDAP ist jedoch häufig Teil des Authentifizierungsprozesses und der Zugriffssteuerung. Wenn beispielsweise ein Benutzer auf eine bestimmte Ressource zugreifen möchte, könnte dieser Benutzer und seine Gruppenzugehörigkeit mithilfe von LDAP abgefragt werden, um zu prüfen, ob er Zugriffsrechte für diese Ressource besitzt. LDAP-Lösungen wie OpenLDAP bieten Authentifizierung durch Unterstützung von Authentifizierungsprotokollen wie Simple Authentication and Security Layer (SASL).

So wie viele andere Anwendungen werden heute auch SSO-Funktionen über das Internet ausgeführt. Cloud-basierte Plattformen wie OneLogin lassen sich somit als Software-as-a-Service(SaaS)-SSO-Lösungen kategorisieren.

Und zu guter Letzt: Vielleicht haben Sie schon einmal von App-to-App- oder Anwendung-zu-Anwendungs-SSO gehört. Dies ist noch kein Branchenstandard. Es ist eher ein Begriff, der von SAPCloud verwendet wird, um den Prozess der Weitergabe einer Benutzeridentität von einer Anwendung an eine andere innerhalb des eigenen Ökosystems zu beschreiben. Es ähnelt OAuth 2.0, ist jedoch kein Standardprotokoll oder eine Standardmethode und derzeit eine Besonderheit von SAPCloud.