Single Sign-On für UCS 4.1

Um die nahtlose Integration von Apps in das durch UCS bereitgestellte Identity Management noch besser zu gewährleisten, haben wir für die Version 4.1 von Univention Corporate Server ein Single Sign-On für UCS implementiert. Single Sign-On ermöglicht einem Benutzer nach einmaliger Authentifizierung, an einem Identity Provider unterschiedliche Dienste in Anspruch zu nehmen, ohne dass eine weitere Anmeldung an jedem einzelnen dieser Dienste erforderlich ist.

Für ein Single Sign-On stehen verschiedene Web-Techniken zur Verfügung, darunter auch die weit verbreitete Security Assertion Markup Language, kurz SAML genannt. Weitere verbreitete Techniken sind das auf SAML basierende Shiboleth, OAuth, welches u. a. häufig von Facebook und Twitter eingesetzt wird, und das auf OAuth 2.0 aufbauende OpenID Connect.

UCS bietet seit gut zwei Jahren eine SAML Identity Provider App zum Download im Univention App Center an, mit der es beispielsweise sehr einfach möglich ist, Google Apps for Work mit UCS zu verbinden. Der hohe Verbreitungsgrad von SAML im Enterprise Umfeld, die hohe Sicherheit und die positive Erfahrung, die wir mit SAML in den letzten Jahren sammeln konnten, haben den Ausschlag für die Entscheidung gegeben, SAML als erste Single Sign-On Technik in UCS 4.1 fest zu implementieren. Weitere Technologien werden eventuell später folgen.

 

 SAML Single Sign-On

SAML ist ein auf XML basierendes Protokoll, um Authentifizierungsinformationen auszutauschen und ermöglicht dadurch Single Sign-On. SAML stellt mehrere sogenannte „Bindings“ zur Verfügung, die eine Anbindung an weitere Protokolle wie SOAP und HTTP ermöglichen. Dadurch ist es möglich, SAML auch in Desktop-Anwendungen oder über Webdienste zu nutzen. Eine typische SAML-Umgebung beinhaltet mindestens einen Identity Provider, der den Benutzer authentifiziert, sowie einen oder mehrere Service Provider, die die eigentlichen Dienste zur Verfügung stellen. Diese beiden Komponenten tauschen mittels public-private-key Verfahren signierte XML-Daten aus.

Nachdem der Benutzer den entsprechenden Dienst im Browser aufgerufen hat, um einen Single Sign-On durchzuführen, erkennt der Service Provider, ob der Benutzer bereits angemeldet ist und leitet den Benutzer andernfalls zum entsprechenden Identity Provider – im Fall von UCS zum DC Master – mit einer SAML-Anfrage weiter. Dieser stellt eine Login-Maske bereit und leitet den Benutzer nach erfolgreicher Authentifizierung mitsamt einer signierten SAML-Assertion, die Informationen über den Benutzer enthält, zurück zum Service Provider. Der Service Provider kann nun die Signatur der Nachricht überprüfen und dem Benutzer Zugang zu seinem eigentlichen Dienst – z. B. der Univention Management Console – erlauben.

UCS als SAML Identity Provider

Wenn UCS in Zukunft als SAML Identity Provider fungiert, muss natürlich sichergestellt sein, dass die Erreichbarkeit der Dienste im Falle eines Serverausfalls gewährleistet und der Server bestmöglich vor Angriffen geschützt ist.

Dazu wird standardmäßig der auf simplesamlphp basierende SAML Identity Provider auf jedem DC Master und DC Backup System installiert. Jeder SAML Identity Provider wird dann in einem DNS-Eintrag z. B. ucs-sso.example.com eingetragen, die SSL-Zertifikate dafür werden auf die jeweiligen Rechner repliziert. Falls einer der Server ausfällt, versucht ein Browser typischerweise eine Verbindung zur nächsten IP-Adresse aufzubauen. Das erfordert natürlich eine Replizierung der simplesamlphp-Sessions zwischen den einzelnen Identity-Provider-Kopien. Dazu stellt simplesamlphp die Möglichkeit bereit, Sitzungsdaten mittels memcached an mehrere Server zu replizieren. Da nicht garantiert ist, dass die DC Backup Systeme in Kundenumgebungen standardmäßig abgeschottet sind, ist eine Verteidigung gegen mögliche Man-In-The-Middle-Attacken notwendig. Da memcached ein unverschlüsseltes Protokoll ist, sorgen ein SSL-Tunnel, der memcached mittels stunnel kapselt, sowie bestimmte Firewall-Regeln und UNIX-Sockets dafür, dass der Memcached-Dienst nur verschlüsselt und authentifiziert von außen angesprochen werden kann.

Weiterhin besitzt der Identity Provider den privaten Schlüssel, mit dem die SAML-Nachrichten signiert werden. Damit dieser effektiv geschützt wird, läuft simplesamlphp mit den Berechtigungen eines explizit für SAML angelegten Benutzers und hat sehr eingeschränkte LDAP Leseberechtigungen. Das verhindert, dass beispielsweise durch Apps mitgelieferte, angreifbare Web-Skripte ausgenutzt werden können, um an den privaten Schlüssel, Sitzungs-Daten oder das Passwort für den verwendeten LDAP-Benutzer zu gelangen.

UMC als SAML Service Provider

Die Implementierung des SAML Service Providers hat natürlich auch Auswirkungen auf die Univention Management Console (UMC). Weil die Authentifizierung zum Identity Provider delegiert wird, hat der Dienst keine Kenntnis mehr vom Benutzerpasswort. Der UMC-Server und der UMC-Webserver sind zwei voneinander unabhängige Dienste. Der UMC-Server erfordert eine Authentifizierung und spricht kein HTTP – kann somit keine SAML-Anbindung machen. Der SAML Service Provider ist Teil des UMC-Webservers, der bisher einfach das Passwort zum UMC-Server durchgereicht hat. Auch einige UMC-Module benötigen das Passwort um z.B. Verbindungen zum LDAP aufzubauen, das domänenweite Univention App Center zu benutzen oder eine Klassenarbeit in UCS@school zu starten. Als Lösung dafür benutzt UCS 4.1 ein PAM-Modul pam-saml für die Authentifizierung am UMC-Server sowie das SASL-Plugin cy2saml für den LDAP-Zugriff. Diese beiden Module ermöglichen die Authentifizierung anhand der signierten SAML-Nachricht. Für alle weiteren Szenarien, in denen ein Passwort benötigt wird, wird Univention Management Console vorerst nicht vermeiden können, erneute Passwortabfragen zu machen.

Auch für die Integration in der UMC-Benutzeroberfläche gibt es Änderungen: Da SAML-Nachrichten zeitlich begrenzt sind und diese zur Authentifizierung an LDAP verwendet werden, müssen diese im Hintergrund erneuert werden. SAML bietet zur Überprüfung, ob eine Session noch gültig ist, eine passive Authentifizierungsmethode an, in der der Browser unsichtbar zum Identity Provider geleitet wird, der entweder eine neue SAML-Nachricht ausstellt oder einen Status-Fehler berichtet und anschließend zum Service Provider zurückleitet. UMC kann dieses Verfahren allerdings nur eingeschränkt benutzen, da bei einer Browser-Weiterleitung alle geöffneten Module und Zustände verlorengehen würden. Deswegen wird dies jetzt durch eine Mischung aus Ajax- und Iframe-Requests im Hintergrund gelöst.

Aussicht

Pünktlich zu UCS 4.1 wird die Firma Netknights mit der Lösung privacyIDEA eine Integration der App in SAML veröffentlichen, um Mehr-Faktor-Authentisierung in UCS zu ermöglichen. Wir glauben, dass in Zukunft immer mehr Univention Apps die SAML Infrastruktur nutzen, um Anwendern mehr Sicherheit und Komfort bieten zu können und das Zusammenspiel mit UCS noch weiter zu vereinfachen.