Single Sign-on (SSO) in Unternehmen bedeutet für Anwender eine einmalige Anmeldung (Authentifikation) und die anschließende Nutzung verschiedener Programme, Dienste und Services, ohne sich noch einmal persönlich anmelden zu müssen. Damit verhilft Single Sign-on zu einem effizienteren und sichereren Arbeiten. Vorbei sind die Zeiten, in denen Mitarbeiter sich zahlreiche Passwörter ausdenken und merken mussten.
Doch Single Sign-on dient nicht nur der Nutzerfreundlichkeit, sondern auch der Sicherheit Ihrer Daten. Arbeitet Ihr Unternehmen mit einer komplexen IT Infrastruktur, steigt das Sicherheitsrisiko stark.
Aus diesem Grund erklären wir Ihnen in diesem Beitrag, wie Sie Ihr Arbeiten mithilfe der Single Sign-on Technologie einfacher gestalten und Ihre Daten zugleich sicherer vor Zugriffen von außen halten können.
Die Vorgehensweise bei Single Sign-on
Der Single Sign-on funktioniert wie folgt: Der Anwender meldet sich beispielsweise am Desktoprechner in seiner Domäne an und kann dadurch direkt auch auf Datei- und Druckserver zugreifen. Das heißt, der Anwender muss sich nur einmalig physisch gegenüber einer Entität (Server) authentifizieren (z. B. durch Passworteingabe oder andere Faktoren) und der SSO-Mechanismus übernimmt anschließend transparent im Hintergrund die Authentifizierung gegenüber weiteren Diensten.
Der SSO-Mechanismus kann dabei unterschiedlich implementiert werden. In der Regel bekommt der Anwender nach der erfolgten Authentifizierung ein als Ticket, Token oder Cookie bezeichnetes Datenpaket, das als Zugangsschlüssel für die Authentifizierung an den weiteren Diensten dient. Der SSO-Mechanismus speichert dann den Zugangsschlüssel und stellt sicher, dass der Schlüssel zum richtigen Zeitpunkt vorgelegt wird.
Aber aufgepasst: Single Sign-on sollte keinesfalls mit „Same User Same Password“ (SUSP) verwechselt werden. Bei SUSP verwenden Anwender dieselben Anmeldedaten für verschiedene Dienste. Diese Anmeldedaten werden jedoch entweder synchronisiert oder der Dienst kann die Authentifizierung weiterreichen. Jedoch muss sich der Anwender hier jedes Mal physisch anmelden – sprich: die Anmeldedaten erneut eingeben.
Welche Vorteile bringt SSO?
- Für die Anwender liegt der Vorteil bei einem Produktivitätsgewinn. Sie müssen ihr Passwort nur einmal eingeben und können anschließend alle Dienste direkt verwenden.
- Für die Unternehmens-IT liegen die Vorteile in einem Sicherheitsgewinn und in der weniger aufwändigen Administration. Sicherheitsgewinne werden durch das nur einmalige Übertragen der Anmeldedaten und einer zentralen Authentifizierungs-Datenbank erzielt. Der Administrationsaufwand ist z.B. deutlich niedriger, wenn beispielsweise Anmeldedaten für einen Anwender zurückgesetzt werden müssen. Mit SSO werden die Anwenderdaten zentral einmalig zurückgesetzt und nicht einzeln für jede Datenbank, in der sie hinterlegt sind.
Welche Nachteile birgt SSO?
- Die Verfügbarkeit des Dienstes hängt zusätzlich von der Verfügbarkeit des Single Sign-on Systems ab.
- Ein Diebstahl des Zugangsschlüssels ermöglicht Angreifern den direkten Zugang zu allen Systemen.
Eine zusätzliche Option: Der Single Sign-out
Zusätzlich zum Single Sign-on gibt es noch den Single Sign-out. Hiermit bezeichnet man die Abmeldung an einem Service A und die daraufhin automatisch einsetzende Abmeldung an allen weiteren Services, die während der Session des Anwenders verwendet wurden.
Meist wird der Single Sign-out über ein Schlüsselablaufdatum realisiert. Die Session des Anwenders läuft dann irgendwann aus. Das ist in den meisten Fällen kein Problem. Je nach Konfiguration kann dies jedoch sehr lang dauern, auch wenn der Anwender die Dienste vielleicht schon längst nicht mehr benötigt. Falls das ein Problem darstellen sollte, bieten die gängigen Single Sign-on Protokolle in aller Regel auch eine Single Sign-out Lösung.
Einführung in die Single Sign-on Dienste und Protokolle
Damit Single Sign-on Dienste funktionieren, müssen sie auf bestimmte Protokolle zugreifen, von denen es diverse gibt.
Im Folgenden möchten wir Ihnen einige häufig genutzte Single Sign-on Dienste vorstellen.
Security Assertion Markup Language (SAML): Ein webbasiertes Single Sign-on Protokoll
SAML ist ein webbasiertes Single Sign-on Protokoll. Der Browser des Anwenders erhält via SAML einen verschlüsselten Session-Cookie, der ein Ablaufdatum enthält und mit dem sich der Anwender transparent an Diensten authentifiziert. Diese Dienste können sich im internen Netz oder in der Cloud bzw. im Internet befinden.
Vorteil des Einsatzes von SAML
SAML wird von sehr vielen Cloud Diensten unterstützt. Ein weiterer Vorteil ist, dass der Authentifizierungsdienst intern im Netz stehen kann und nicht aus dem öffentlichen Netz erreichbar sein muss.
Das folgende Beispiel zeigt eine vereinfachte Authentifizierung mittels SAML:
- Wenn der Anwender Zugriff auf einen externen Dienst im Internet (z. B. auf die Projektmanagementsoftware Redmine) erhalten möchte,
- wird er zunächst an den internen Authentifizierungsdienst (Identity Provider – IdP) weitergeleitet. Dazu muss der externe Dienst keinerlei Zugriff oder Verbindung zum internen Authentifizierungsdienst haben. Es reicht, dass der Browser des Anwenders Zugriff erhalten kann.
- Am Authentifizierungsdienst erhält der Browser des Anwenders anschließend einen Session-Cookie, mit dem er sich an dem ursprünglichen Dienst, hier Redmine, anmelden kann.
- Mit diesem Session-Cookie kann sich der Anwender dann an weiteren internen und externen Diensten anmelden.
Shibboleth – Eine Erweiterung des SAML Standards
Shibboleth ist eine Erweiterung des SAML Standards. Es enthält zusätzlich die Option, über Sicherheitsdomänen hinweg einen Single Sign-on zu ermöglichen. Dabei wird durch den Austausch von Zertifikaten eine Vertrauensstellung zwischen den teilnehmenden Entitäten hergestellt.
Im Folgenden vereinfachten Beispiel unterhalten zwei Universitäten (A und B) jeweils eine eigene Sicherheitsdomäne. Jedoch befinden sich beide in einer Vertrauensstellung (Föderation) zueinander:
- Wenn nun eine Studentin aus Universität A auf Dienste aus Universität B (z. B. deren MediaWiki) zugreifen möchte,
- wird sie zuerst zu einem Discovery Service der Universität B weitergeleitet.
- Dieser Discovery Service entscheidet nun, an welchem Authentifizierungsdienst sich die Studentin authentifizieren muss.
- Anschließend leitet er die Studentin an den Service Provider (SP) weiter
- und der wiederum an den Authentifizierungsdienst (Identity Provider – IdP).
- Nach erfolgreicher Authentifizierung
- wird die Studentin nun transparent an dem Dienst angemeldet.
OpenID – Beispiel für ein dezentrales und webbasiertes Single Sign-on System
OpenID dagegen ist ein dezentrales, webbasiertes Single Sign-on System, das mit einer URL und ohne Passwort als Anmeldedaten arbeitet. Hier muss sich der Anwender vorher bei einem OpenID-Provider authentifiziert haben, um sich anschließend bei unterstützenden Websites anmelden zu können.
Im folgenden, einfachen Beispiel möchte sich die Anwenderin
- bei einem Webservice (feedly) anmelden und
- wird daraufhin direkt an den OpenID Provider von Google weitergeleitet. Dort authentifiziert sich die Anwenderin
- und wird anschließend wieder zurück an den Webservice zurückgeleitet.
Kerberos – Beispiel für ein netzwerkbasiertes Single Sign-on Protokoll
Kerberos wiederum ist ein netzwerkbasiertes Single Sign-on Protokoll. Ein Client authentifiziert sich beim Kerberos-Server und erhält ein Ticket (TGT – Ticket Granting Ticket). Mit diesem Ticket können anschließend weitere Tickets für verschiedene Dienste abgerufen werden.
Beispiel:
- Wenn eine Anwenderin Zugriff auf einen Dienst in der Domäne erhalten möchte,
- lässt sie sich zunächst ein Ticket Granting Ticket vom Authentifizierungsserver des Key Distribution Centers (KDC) ausstellen.
- Anschließend kann sich die Anwenderin ein Service-Ticket für jeden angeschlossenen Dienst am Ticket Granting Server in der Domäne ausstellen lassen.
- Mit diesem Service-Ticket kann sich die Anwenderin nun an den Diensten der Domäne anmelden.
Integrationen der Protokolle in UCS
UCS integriert verschiedene Single Sign-on Lösungen, und zwar:
An einer OpenID Connect Integration arbeitet die Entwicklung derzeit. Ein genaues Veröffentlichungsdatum steht jedoch noch nicht fest. Eine Shibboleth Integration – also die Teilnahme an einer IdP-Föderation – ist ohne weiteres möglich. Ein Beispiel wäre die Teilnahme an der Authentifikations- und Autorisierungs-Infrastruktur (AAI) des deutschen Forschungsnetzes (DFN).
Weitere Informationen zu Kerberos in UCS
Kerberos Services werden automatisch vorkonfiguriert und von vielen Diensten im Hintergrund zur Prüfung des Passworts genutzt. Werden die Active Directory Services basierend auf Samba 4 genutzt, findet echtes SSO zwischen den Arbeitsplätzen in der Domäne und z. B. den File- und Printservices statt.
Kerberos ist ebenso für den Zugriff per SSH oder auf den LDAP-Verzeichnisdienst vorkonfiguriert. Mit wenigen Schritten lässt sich Single Sign-on für weitere Dienste aktivieren, zum Beispiel für den Zugriff auf geschützte Webseiten.
Weiteres zu SAML in UCS
SAML 2.0 ist für UCS ebenfalls verfügbar und für den sofortigen Einsatz vorkonfiguriert. Es kann sowohl zur Anmeldung an der UMC, über die entsprechenden Univention Apps zur Integration mit Office 365 oder Google Apps for Works, als auch für alle Drittlösungen, die SAML unterstützen, genutzt werden.
Der UCS-Server fungiert in diesem Fall als Authentifizierungsstelle (SAMLIdentity Provider) und das Webinterface ist der Dienst (SAML ServiceProvider).
Praktisch für Administratoren und Benutzer: Die Verbindung von SAML und Kerberos in UCS
Wenn sich Benutzer auf ihrem Windows- oder Linux-PC, Laptop oder mobilen Endgerät bei UCS anmelden, haben sie sofortigen Zugriff auf Webanwendungen wie Office 365 oder ownCloud / Nextcloud. Sie müssen sich nicht erneut anmelden. Dies wird durch die Verknüpfung der Security Assertion Markup Language (SAML) mit der eingeführten Kerberos-Authentifizierung ermöglicht. Dies ist praktisch für Benutzer und Administratoren. Sie müssen sich beispielsweise nicht erneut an der Univention Management Console (UMC) anmelden.
Grundanforderungen an die Einführung von Single Sign-on
In diesem Abschnitt möchten wir noch einmal auf die Grundanforderungen bei der Einführung von Single Sign-on eingehen.
Folgende Grundvoraussetzungen müssen berücksichtigt werden:
- Die Wahl eines SSO-Mechanismus (beispielsweise Kerberos oder SAML)
- eine Authentifizierungsstelle
- Fähigkeit der Dienste, die Authentifizierung über den SSO-Mechanismus durchzuführen. Viele zentrale Enterprise-Dienste (On-Premises und Off-Premises) unterstützen Single Sign-on. Um ein paar Beispiele zu nennen: Office 365, MediaWiki, OX, owncloud, Google Apps for Business, Redmine, WordPress, Salesforce, SAP NetWeaver, Slack, Moodle, DokuWiki und MailChimp.
Sind diese Voraussetzungen erfüllt, steht der schrittweisen Einführung von Single Sign-on nichts im Wege.
Zu guter Letzt
Das Konzept Single Sign-on war immer schon ein großes Thema in vielen Organisationen. Früher waren es eher native Windows Anwendungen, heute geht es, insbesondere durch die verstärkte Nutzung von Services und Diensten aus der Cloud, zunehmend um Webanwendungen. Gerade bei Web-Services sehen wir aber häufig noch nicht den großen Leidensdruck bei den Mitarbeitern unserer Kunden. Hier werden vielfach Browser-Passwort-Manager verwendet, die für die Mitarbeiter komfortabel genug zu sein scheinen. Treiber von Single Sign-on sind IT-Abteilungen, die aus Sicherheitsgründen und Aufwandsabwägungen Single Sign-on einführen möchten.
Wir hoffen, Ihnen mit diesem Artikel einen guten Überblick über die Möglichkeiten des Single Sign-on gegeben zu haben. Gern können Sie uns bei weiteren Fragen kontaktieren oder unten kommentieren. Haben Sie weitere Fragen zum Thema oder möchten einen Kommentar hinterlassen? Dann nutzen Sie unser Kontaktformular oder das Kommentarfeld.
Außerdem möchten wir Ihnen folgende weitere Artikel empfehlen:
Univention: Single Sign-on für Ubuntu-Clients leicht gemacht
