Kurz erklärt: SAML für sichere, komfortable Webzugänge

Was ist SAML?

Das SAML-Format basiert auf XML; es dient zum Authentisieren und Autorisieren von Benutzern. Mehrere SAML-Komponenten arbeiten dafür Hand in Hand:

• der Identity Provider (IdP) ist ein Authentifizierungdienst, stellt eine Anmeldemaske bereit, leitet Anwender zum Service Provider (SP) weiter und kann durch UCS abgebildet werden
• der Service Provider (SP) verlangt eine Authentifizierung, vertraut IdP und ist im Kontext von UCS ein beliebig anderer Dienst wie z.B. die Private Cloud Lösungen ownCloud oder 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.

• Single-Sign-on-Service-Link: Dient zur Anmeldung am Identity Provider. Der IdP bietet in der Regel eine Anmeldemaske, über die sich Anwender authentifizieren. Das kann über eine Kombination aus Benutzernamen und Passwort sein oder eine Authentifizierung inklusive Mehrfaktor-Authentifizierung. Der Link muss bei allen angebundenen Services eingetragen werden.
  Mehr zum Thema Single-Sign-on erfahren Sie hier!
• Öffentliches Zertifikat: Der Identity Provider bietet ein öffentliches Zertifikat an, das für das Signieren der Anfragen zur Authentifizierung von den Service Providern verwendet wird. Das Zertifikat muss allen angebundenen Services zur Verfügung gestellt werden.
• Assertion-Consumer-Service-Link: 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.
• Single-Logout-Service-Link: Dient zum Abmelden von weiteren Diensten, wenn ein Benutzer sich von einem Service oder vom IdP abgemeldet hat. Der Identity Provider schickt einen Logout-Request an Service A, sobald sich der Anwender von Service B abgemeldet hat. Voraussetzung dafür ist, dass der Single-Logout-Service-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. Die Angabe des Links ist optional.

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.

Tipp: Die Verwaltung von Benutzeraccounts läuft nicht selten über einen LDAP-Verzeichnisdienst.  In einem eigenen Artikel zeigen wir Ihnen, wie Sie durch LDAP-Replikation Server-Ausfälle verhindern und die Performance verbessern können.

UCS unterstützt 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 bietet sich Folgendes an:

• Nutzen der SAML-Attribute
• Verteilen über andere Schnittstellen
• eine Kombination aus beidem

Beim Löschen von Benutzeraccounts gibt es ebenfalls mehrere Wege:

• automatisches Löschen nach einer bestimmten Dauer von Inaktivität
• Löschen durch Nutzung 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 ein*e Anwender*in Zugriff auf eine Ressource eines Dienstes benötigt – egal, ob intern oder extern –, öffnet er oder sie eine Login-URL (technisch ein GET-Request) des Services, z. B. die Adresse wiki.univent.intern/login.
2. Der Dienst stellt einen Redirect an den SingleSignOnService Link des Identity Providers bereit. 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 der oder die Anwender*in 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 den oder die Anwender*in nun als authentifiziert.
8. Per Redirect erfolgt eine Weiterleitung an die ursprüngliche Login-URL. Von dort wird die Anfrage 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

Integration in UCS

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

Weitere Artikel zum Thema SAML:

• SAML Single Sign-on in die ownCloud App integrieren
• Datensicherheit durch Mehr-Faktor-Authentisierung in UCS mit privacyIDEA + SAML
• Benutzer registrieren sich selbst – neuer Self Service für SUSE und UCS
• Sicher in der Cloud: Zwei-Faktor-Authentifizierung für Single Sign-On