Singe Sign On Schaubild

Die zunehmende Anzahl an Programmen, mit denen Angestellte in Unternehmen tagein tagaus zu tun haben, macht das Arbeiten nicht nur einfacher, sondern gleichzeitig in manchen Belangen auch komplexer. Außerdem birgt ein Mehr an Applikationen auch ein steigendes Sicherheitsrisiko für die Daten im Unternehmensnetzwerk.

Wir möchten Ihnen heute erklären, wie Sie mittels der Single Sign-on Technologie das Arbeiten für Ihre Mitarbeiter einerseits einfacher gestalten, Ihre Daten gleichzeitig aber auch sicherer vor Zugriff von außen halten können.

Was verbirgt sich hinter SSO?

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 anzumelden.

Das heißt, ein Anwender meldet sich beispielweise am Desktoprechner in der Domäne an und kann dadurch direkt auch auf Datei- und Druckserver zugreifen. Der Anwender muss sich also 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.

Nicht verwechseln sollte man „Single Sign-on“ mit „Same User Same Password“ (SUSP). 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.

Vorteile von SSO

  • Für die Anwender liegt der Vorteil bei einem Produktivitätsgewinn. Sie müssen nur einmal ihr Passwort eingeben und können ihre Dienste anschließend sofort 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 auch in dem Fall 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, wo er hinterlegt ist.

Nachteile von SSO

  • Die Verfügbarkeit des Dienstes hängt zusätzlich von der Verfügbarkeit des Single Sign-on Systems ab.
  • Ein Diebstahl des Zugangsschlüssel ermöglicht Angreifern den Zugang zu allen Systemen.

Single Sign-out als zusätzliche Option

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. Dies kann je nach Konfiguration 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.

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 vorstellen, die häufiger benutzt werden.

Security Assertion Markup Language (SAML)

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 unterstützen sehr viele Cloud-Dienste. 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:

  1. Wenn der Anwender Zugriff auf einen externen Dienst im Internet (z. B. auf die Projektmanagementsoftware Redmine) erhalten möchte,
  2. 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.
  3. Am Authentifizierungsdienst erhält der Browser der Anwenderin anschließend einen Session-Cookie, mit dem er sich an dem ursprünglichen Dienst, hier Redmine, anmelden kann.
  4. Mit diesem Session-Cookie kann sich dann die Anwenderin an weiteren internen und
  5. externen Diensten anmelden.

SAML Schaubild

Shibboleth

Shibboleth ist eine Erweiterung des SAML Standards. Es enthält zusätzlich die Möglichkeit, ü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 Vertrauenstellung (Förderation) zueinander:

  1. Wenn nun eine Studentin aus Universität A auf Dienste aus Universität B (z. B. deren MediaWiki) zugreifen möchte,
  2. wird sie zuerst zu einem Discovery Service der Universität B weitergeleitet.
  3. Dieser Discovery Service entscheidet nun, an welchem Authentifizierungsdienst sich die Studentin authentifizieren muss.
  4. Anschließend leitet er die Studentin an den Service Provider (SP) weiter
  5. und der wiederum an den Authentifizierungsdienst (Identity Provider – IdP).
  6. Nach erfolgreicher Authentifizierung
  7. wird die Studentin nun transparent an dem Dienst angemeldet.

shibboleth

OpenID

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

1. bei einem Webservice (feedly) anmelden und

2. wird daraufhin direkt an den OpenID Provider von Google weitergeleitet. Dort authentifiziert sich die Anwenderin

3. und wird anschließend wieder zurück an den Webservice zurückgeleitet.

Schaubild Open ID

Kerberos

Kerbos wiederum ist ein netzwerkbasiertes Single Sign-on Protokoll. Ein Client authentifiziert sich beim Kerberos-Server und erhält ein Ticket (TGT). Mit diesem Ticket können anschließend weitere Tickets für verschiedene Dienste abgerufen werden.

Beispiel:

  1. Wenn eine Anwenderin Zugriff auf einen Dienst in der Domäne erhalten möchte,
  2. lässt sie sich zunächst ein Ticket Granting Ticket vom Authentifizierungsserver des Key Distribution Centers (KDC) ausstellen.
  3. Anschließend kann sich die Anwenderin ein Service-Ticket für jeden angeschlossenen Dienst am Ticket Granting Server in der Domäne ausstellen lassen.
  4. Mit diesem Service-Ticket kann sich die Anwenderin nun an den Diensten der Domäne anmelden.

Schaubild kerberos

Integrationen der Protokolle in UCS

UCS integriert verschiedene Single Sign-on Lösungen, und zwar:

Shibboleth und OpenID haben wir noch nicht integriert, da unsere Nutzer uns bisher von keinen Szenarien berichtet haben, wo sie diese bräuchten.

Näheres 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 (siehe externe Anleitung).

Näheres zu SAML in UCS

SAML 2.0 ist für UCS ebenfalls verfügbar. Es kann sowohl zur Anmeldung an der UMC als auch über die entsprechenden Univention Apps zur Integration mit Office 365 oder Google Apps for Works genutzt werden.

Screenshot Univention Management Console - Single Sign-OnDer UCS-Server fungiert in diesem Fall als Authentifizierungsstelle (SAML Identity Provider) und das Webinterface ist der Dienst (SAML Service Provider).

Für die UMC können Sie es auf Ihrem Server testen, wenn Sie oben in Ihrer Anmeldemaske den Link „Single Sign-On“ auswählen.

An den SAML Identity Provider können selbstverständlich ebenfalls weitere Web-Dienste angeschlossen werden. Mehr dazu finden Sie in meinem nächsten Artikel, der nächste Woche erscheint.

Grundanforderungen an die Einführung von Single Sign-on

In diesem Abschnitt möchte ich 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 nichts im Wege.

Fazit

Das Konzept Single Sign-on war immer schon ein großes Thema in vielen Organisationen. Früher waren es eher native Windows Anwendungen und heute geht es zunehmend um Webanwendungen. Insbesondere da verstärkt Dienste und Services aus der Cloud bezogen werden. 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 und das scheint für die Mitarbeiter komfortabel genug zu sein. Treiber von Single Sign-on sind eher IT-Abteilungen, die aus Sicherheitsgründen und Aufwandsabwägungen Single Sign-on einführen.

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. Und schauen Sie doch gern nächste Woche wieder rein, wenn ich ausführlicher über SAML berichte.

Michel arbeitet seit Januar 2014 bei Univention im Team des Professional Services. Hier ist er sowohl in größeren als auch kleineren UCS Projekten involviert, viele davon im Schulträger-Umfeld. Außerdem hält er gerne Workshops. Seine persönlichen Interessen sind agiles Projektmanagement und Python Programmierung. Derzeit ist Michel als IT-Consultant tätig.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.