SSO-SAML-UCS

SAML (Security Assertion Markup Language) ist ein Standard, der das Single Sign-On (SSO) ermöglicht, also ein zentrales Login. So melden sich Benutzer einmal an und erhalten dann automatisch Zugriff auf andere Programme und Dienste. Auch UCS unterstützt SAML und SSO, um Nutzern nicht nur eine zentrale Identität, sondern auch einen zentralen Login zu bieten und somit das webbasierte Arbeiten sicherer und komfortabler zu gestalten.

Was ist SAML?

Das SAML-Format basiert auf XML; es dient zum Authentisieren und Autorisieren von Benutzern. Mehrere SAML-Komponenten arbeiten Hand in Hand: Der Identity Provider (IdP) ist ein Authentifizierungsdienst, der eine Anmeldemaske bereitstellt und die Anwender zum Service Provider (SP) weiterleitet. Dieser Dienst verlangt eine Authentifizierung und vertraut dem IdP. Im UCS-Kontext ist Univention Corporate Server der IdP, und der SP kann ein beliebiger anderer Dienst sein, wie z. B. Nextcloud.
SAML arbeitet im Hintergrund mit so genannten Session-Cookies, die mit einem Ablaufdatum versehen sind. Den Session-Cookie erhalten die Anwender bei der Authentifizierung am IdP und können sich mit ihm anschließend bei den angebundenen Diensten anmelden. Da der Session-Cookie wie andere Cookies auch im Browser der Anwender gespeichert wird, ist keine direkte Verbindung zwischen IdP und SP notwendig. So kann ein UCS, der als IdP agiert, etwa abgeschottet in einem internen Netz stehen und dennoch die Authentifizierung für einen Cloud-Dienst im Internet übernehmen – ohne, dass dieser je direkt mit dem UCS interagiert hätte.

Anbindung von Services mit SAML

Um Services mit SAML anzubinden, ist das Austauschen von Metadaten erforderlich; diese enthalten so genannte Artefakte.

SSO mit SAML und UCS: Schaubild Austausch Metadaten Service Provider und Identity Provider

Lassen Sie sich von den Begriffen nicht abschrecken – sie klingen kompliziert, sind aber schnell erklärt. IdP und SP stellen beide Metadaten zur Verfügung. In den meisten Fällen (auch bei UCS) handelt es sich um XML-Dateien. Beim IdP enthalten diese Dateien unter anderem folgende wichtige Artefakte:

SingleSignOnService Link

Diese URL dient zur Anmeldung am Identity Provider. Der IdP bietet hier in aller Regel eine Anmeldemaske, über die sich Anwender authentifizieren. Die Methode ist dabei nicht genauer spezifiziert: Es kann eine Kombination aus Benutzernamen und Passwort sein, es kann aber auch eine andere Form der Authentifizierung inklusive Mehrfaktor-Authentifizierung gefordert sein. Dieser Link muss bei allen angebundenen Services eingetragen werden.

SingleLogoutService Link

Diese URL dient zum Abmelden vom Identity Provider. Wenn sich ein Anwender von einem Dienst abmeldet, sollte er zu diesem IdP-Endpoint weitergeleitet werden, damit auch dieser den Benutzer abmelden kann. Der Link kann bei allen angebundenen Services eingetragen werden.

Öffentliches Zertifikat

Der Identity Provider bietet ein öffentliches Zertifikat an. Dieses wird für das Signieren der Anfragen zur Authentifizierung von den Service Providern verwendet. Das Zertifikat muss allen angebundenen Services zur Verfügung gestellt werden.
Im Bereich des Service Providers gibt es darüber hinaus folgende Artefakte:

AssertionConsumerService Link

Diese URL spezifiziert den Ort, an den der Anwender wieder zurückgeleitet werden soll, nachdem er sich authentifiziert hat. Der Link muss beim Identity Provider eingetragen werden.

SingleLogoutService Link

Diese URL dient zum Abmelden von weiteren Diensten, wenn ein Benutzer sich von einem Service abgemeldet hat. Das bedeutet, der Identity Provider schickt einen Logout-Request an Service A, sobald sich der Anwender von Service B abgemeldet hat. Voraussetzung dafür ist, dass dieser SingleLogoutService Link vorab beim Identity Provider für Service A eingetragen wurde.
In der Praxis unterscheidet sich der Austausch der Metadaten von Dienst zu Dienst. Manche Services nehmen die Metadaten des IdP direkt als XML-Datei entgegen, andere erfordern die manuelle Eingabe der Artefakte.

Benutzerverwaltung

Viele Services bieten beim ersten Login die Möglichkeit, automatisch einen neuen Benutzeraccount anzulegen. Dieses Verfahren heißt Just-in-Time-Bereitstellung (Just-in-Time provisioning). Sollte ein Dienst dies nicht unterstützen, müssen die Benutzer zunächst manuell angelegt werden, oder die Daten werden über einen anderen Weg bereitgestellt.
UCS unterstützt wenn benötigt die Just-in-Time-Bereitstellung z.B. für Dienste wie Office 365 und Google G Suite. Viele andere Dienste legen die User von alleine an, wenn Sie sich über SAML einloggen. Beim Bearbeiten der Benutzereigenschaften bieten sich SAML-Attribute oder das Verteilen über andere Schnittstellen an. Beides kann auch kombiniert werden. Beim Löschen von Benutzeraccounts gibt es ebenfalls mehrere Wege: Manche Services können Accounts automatisch nach einer bestimmten Dauer der Inaktivität löschen. Eine andere Möglichkeit für das Löschen von Benutzern wäre das Nutzen einer anderen Schnittstelle. Auch dies ist in UCS beispielsweise für Office 365 (hier authentifiziert sich der UCS Office 365 Connector gegen eine Schnittstelle in der Azure-Cloud und provisioniert dort die User) oder für Google G Suite möglich. Die Art der Schnittstellen kann zwischen einzelnen Diensten sehr verschieden sein.

Ablauf einer Authentifizierung mit SAML

Die folgenden Schritte zeigen beispielhaft, wie eine Authentifizierung mit SAML ablaufen kann:

  1.  Wenn eine Anwenderin Zugriff auf eine Ressource eines Dienstes benötigt – egal, ob intern oder extern –, öffnet sie eine Login-URL (technisch ein GET-Request) des Services, z. B. die Adresse wiki.univent.intern/login.
  2. Von dem Dienst erhält sie einen Redirect an den SingleSignOnService Link des Identity Providers. Diese Weiterleitung enthält eine Anfrage des Services, die vom Identity Provider unterzeichnet werden soll.
  3. Der Browser der Anwenderin ruft also den SingleSignOnService Link des Identity Providers auf und reicht die Anfrage ein.
  4. Anschließend muss sich die Anwenderin authentifizieren.
  5. Die Antwort des Dienstes enthält unter anderem den AssertionConsumerService Link.
  6. Diesen kann der Browser verwenden, um einen POST-Request an den Service Provider des Dienstes zu stellen.
  7. Der Service Provider betrachtet die Anwenderin nun als authentifiziert.
  8. Per Redirect leitet er sie weiter an die ursprüngliche Login-URL. Von dort wird sie aufgrund der erfolgreichen Authentifizierung an die Ressourcen des Dienstes weitergeleitet.

Attribut-basierte Autorisierung

Neben der Authentifizierung der Benutzer selbst ist auch eine detaillierte Autorisierung für Zugriffe auf bestimmte Ressourcen konfigurierbar. Hier erlaubt SAML, Attribute zwischen Identity Provider und Service Provider auszutauschen. Anhand der Attribute kann ein Service Entscheidungen über Ressourcenzugriffe treffen. In UCS können Sie für jeden einzelnen Service Provider definieren, ob er LDAP-Attribute übergeben soll und wenn ja, welche das sind.

Vor- und Nachteile von SAML

Vorteile

  • Single Sign-On steht für alle Anwender zur Verfügung.
  • Viele Dienste unterstützen SAML nativ oder über Plugins; dazu gehören auch viele Cloud-Dienste.
  • Der Administrations-Aufwand verringert sich, denn es gibt nur eine Datenbank für die Accounts zu pflegen.
  • Sicherheitsgewinn:
    Es gibt nur eine interne Nutzerdatenbank, die nicht von außen (Internet) zugänglich sein muss.
    Die Passwörter werden nicht mehr in anderen Diensten benötigt.

Nachteile

  • Die Verfügbarkeit einzelner Dienste hängt von der Verfügbarkeit des Identity Providers ab.
  • Ein Diebstahl des Session-Cookies ermöglicht Angreifern den Zugang zu allen Diensten.

Film-Tutorial: zentrale Maildienste in UCS bereitstellen

Sehen Sie in dem 8-minütigen Film-Tutorial, wie Sie Ihren eigenen E-Mail Server mit UCS aufsetzen, wieso Sie die Komponente UCS Mail Server aus dem Univention App Center auf einem UCS Slave installieren sollten und wie Sie am besten bei der Installation vorgehen. Mehr


Integration in UCS

Eine SAML-Integration in UCS existiert schon seit UCS 4.1. Die Anmeldemaske befindet sich in der Voreinstellung unter https://ucs-sso.domainname/univention/saml/. Zugriff auf die Metadaten bietet die Adresse https://ucs-sso.domainname/simplesamlphp/saml2/idp/metadata.php.
Das UCS-Handbuch beschreibt, wie Sie Services hinzufügen. Für das Bereitstellen von Office 365 und Google G Suite gibt es eigene Connector-Apps in unserem App Center, die Benutzer anlegen, modifizieren und löschen.

Tipp: Sie können die SAML-Anmeldemaske auch unter einer anderen Adresse verfügbar machen und damit z. B. einen Zugriff von außen ermöglichen. Wie das geht, erklärt ein Artikel aus der Univention Knowledge Base.

Ist SAML für mich geeignet?

Bevor Sie sich entscheiden, SAML in Ihrer Umgebung ganz oder teilweise einzusetzen, sollten Sie ein paar Fragen beantworten:

  • Kann der anzubindende Service SAML 2.0?
  • Wie sieht die Benutzer-Synchronisation aus?
  • Kann der anzubindende Service Just-in-Time-Bereitstellung?
  • Wie werden Benutzer gelöscht?
  • Wie kann eine anderweitige Bereitstellung durchgeführt werden?
  • Welche Rollen soll es im anzubindenden Service geben?
  • Gibt es viele verschiedene Benutzerrollen?
  • Gibt es eine Standardrolle für Benutzer?
  • Wie kann diese über SAML-Attribute abgebildet werden?
  • Kann das der Service zuordnen?

Noch Fragen?

Wenn Sie SSO richtig einsetzen, können Sie Nutzern komfortabel Zugriff auf mehrere Dienste, Anwendungen und andere Ressourcen gewähren. SAML als Authentifizierungs- und Autorisierungs-System und UCS als Identity Provider, der die Verifizierung durchführt, leisten hier gute Dienste. Sollten Sie weitere Fragen haben, können Sie gerne mit uns Kontakt aufnehmen.

Junior IT Consultant im Professional Service Team bei Univention.

Was ist Ihre Meinung? Hinterlassen Sie einen Kommentar!

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