Schaubild Übersicht SAML

Kann webbasiertes Arbeiten mit zahlreichen Programmen sicherer und komfortabler gestaltet werden? Ja, dafür gibt es SAML, die Security Assertion Markup Language. Ein sicheres, XML-basiertes Datenformat zum Austausch von Authentifizierungs- und Autorisierungsinformationen, um die Datensicherheit eines Unternehmens trotz webbasierenden Arbeitens nicht zu gefährden.

Gleichzeitig verschafft SAML jedem Anwender ein Höchstmaß an Komfort, denn durch das zunehmend webbasierte, ortsunabhängige Arbeiten muss sich jeder Anwender leider auch immer mehr Zugangsdaten für die einzelnen Programme merken. Nicht zu vergessen, die Zeit und Mühe, die jeden Tag für das Ein- und Ausloggen pro Programm aufgewendet werden muss.

Wie nun mithilfe von SAML das webbasierte Arbeiten erleichtert werden kann, erklären wir im Folgenden. Aber zuerst einmal:

Was genau ist SAML?

SAML bietet ein webbasiertes Single Sign-On zum Zugriff auf mehrere, autonome Services, ohne zu einer mehrmaligen Eingabe der Zugangsdaten gezwungen zu sein. Der SSO-Mechanismus übernimmt dabei die Authentifizierung transparent im Hintergrund. Dazu wird in SAML ein verschlüsselter Session-Cookie verwendet. Diesen Session-Cookie, der mit einem Ablaufdatum versehen ist, erhält der Anwender im Browser von einem Authentifizierungsdienst (Identity Provider – IdP). Damit kann der Anwender anschließend im Browser alle angebundenen Services (Service Provider – SP) nutzen.

SAML Komponenten

SAML setzt sich aus den folgenden Komponenten zusammen:

Principal – Anwender

Principal ist der Anwender. Er muss sich über den User Agent des Browsers authentifizieren.

Identity Provider – IdP

Der Identity Provider ist der Authentifizierungsdienst, der eine Anmeldemaske für den Anwender bereitstellt und anschließend den Browser zum Service Provider weiterleitet.

Artefakte

Im Bereich des Identity Providers gibt es obendrein folgende Artefakte:

* SingleSignOnService Link
Diese URL dient der Anmeldung am Identity Provider. Der Identity Provider bietet hier in aller Regel eine Anmeldemaske zur Authentifizierung von Anwendern an. Die Methode ist dabei nicht genauer spezifiziert. Es kann Benutzername 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 der Abmeldung am Identity Provider. Wenn sich ein Anwender an einem Service abmeldet, sollte er an diesen Endpoint des Identity Providers weitergeleitet werden, damit auch dieser den Anwender abmelden kann. Dieser 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 samlp:authnRequest von den Service Providern verwendet. Dieses Zertifikat muss allen angebundenen Services zur Verfügung gestellt werden.

* Metadatendatei
Eine XML-Datei, die meist unter einer speziellen URL vom Identity Provider zur Verfügung gestellt wird. Diese Datei enthält die oben genannten Artefakte (SingleSignOnService Link, SingleLogoutService Link, Öffentliches Zertifikat). Diese Datei kann allen angebundenen Services zur Verfügung gestellt werden.

Service Provider – SP

Der Service Provider bietet Services, die eine Authentifizierung erfordern. Diese Authentifizierung übernimmt er jedoch nicht selbst, sondern leitet diese transparent an den Identity Provider weiter.

Artefakte

Im Bereich des Service Providers gibt es obendrein folgende Artefakte:

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

* SingleLogoutService Link
Diese URL dient der Abmeldung an weiteren Services, wenn sich an einem Service abgemeldet wurde. Das bedeutet, der Identity Provider schickt einen Logout-Request an Service A, sobald sich der Anwender an Service B abgemeldet hat. Voraussetzung dafür ist, dass dieser SingleLogoutService Link vorab beim Identity Provider für Service A eingetragen wurde.

Komponenten SAML

Anbindung von Services durch SAML

Die Anbindung von Services findet durch den Austausch der oben beschriebenen Artefakte zwischen dem Identity Provider und dem Service statt. Nach diesem Austausch kann der Authentifizierungsablauf durch den Aufruf einer Ressource eines angeschlossenen Services durchgeführt werden. Dazu werden sogenannte SAML AuthnRequests, SAML Assertions und SAML Responses von einer XML-Syntax [1] definiert und von den Komponenten bei der Authentifizierung erstellt und ausgetauscht.

Benutzerverwaltung

Viele Services bieten beim erstmaligen Login die Möglichkeit, einen Benutzer direkt neu anzulegen. Dieses Verfahren wird „Just-in-Time Provisioning“ genannt. Wenn ein Service dies nicht unterstützt, müssen die Benutzer zunächst manuell angelegt werden, oder es wird über einen anderen Weg ein Provisioning durchgeführt.

UCS bietet das für Office 365 und Google Apps for Work. Beim Editieren der Benutzereigenschaften bieten sich SAML Attribute oder das Provisioning über andere Schnittstellen an. Beides kann auch kombiniert werden. Beim Löschen von Benutzern stellen sich ähnliche Fragen. Manche Services bieten hier die Möglichkeit, diese nach einer Weile der Inaktivität zu 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 für Office 365 und Google Apps for Work möglich.

 Ablauf einer Authentifizierung mittels SAML

Die folgenden Schritte zeigen ein Authentifizierungsbeispiel mittels SAML:

  1. Wenn die Anwenderin Zugriff auf eine Ressource eines Service erhalten möchte – egal, ob intern oder extern – stellt sie einen GET-Request an den Service. In diesem Beispiel die Login-URL wiki.univent.intern/login.
  2. Von dem Service erhält sie einen Redirect an den SingleSignOnService Link des Identity Providers. Dieser Redirect enthält die samlp:authnRequest, die vom Identity Provider unterzeichnet werden soll.
  3. Der Browser der Anwenderin ruft also den SingleSignOnService Link des Identity Providers auf und reicht die samlp:authnRequest ein.
  4. Anschließend muss sich die Anwenderin authentifizieren und erhält dann
  5. eine samlp:response in Form eines XHTML Formulars zurück. Dieses XHTML Formular enthält unter anderem den AssertionConsumerService Link, den der User Agent des Browsers verwenden kann, um
  6. einen POST-Request an den Service Provider des Services zu stellen.
  7. Der Service Provider erstellt nun einen Security Context und
  8. leitet die Anwenderin per Redirect weiter an die ursprüngliche Login-URL und, da ein Security Context existiert, auch an weitere Ressourcen des Services.

Prozess SAML Schaubild

Da alle Schritte über den User Agent des Browsers gehen, ist hier auch schön zu sehen, dass ein externer Service keinen direkten Zugriff oder keine Verbindung zum internen Authentifizierungsdienst haben muss. Es reicht, dass der Browser der Anwenderin Zugriff erhalten kann. Außerdem wichtig ist dann eine saubere Konfiguration des DNS.

Attribut-basierte Autorisierung

Neben der Authentifizierung ist auch eine Attribut-basierte Autorisierung konfigurierbar. Hier sieht die XML-Syntax Möglichkeiten vor, Attribute zwischen Identity Provider und Service Provider auszutauschen. Anhand dieser Attribute kann der Service Provider anschließend über Ressourcenzugriffe detailliert entscheiden.

Vorteile

  • Single Sign-On für alle Anwender
  • Viele Dienste unterstützen SAML nativ oder über Plugins; insbesondere auch viele Clouddienste
  • Einsparung in der Administration. Bei der Accountverwaltung ist nur eine Datenbank zu administrieren.
  • Sicherheitsgewinn, da:
    • nur eine interne Nutzerdatenbank zu schützen ist. Die kann auch nur intern im Netz erreichbar sein und muss nicht von außen (Internet) zugänglich sein.
    • Passwörter nicht mehr in anderen Diensten benötigt werden.

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.

Integration in UCS

Eine SAML-Integration in UCS besteht schon seit UCS 4.1. Die Anmeldemaske befindet sich unter https://ucs-sso.domainname/univention-management-console/saml/.

Die Metadaten jeweils unter https://ucs-sso.domainname/simplesamlphp/saml2/idp/metadata.php.

Wie man Services hinzufügt, beschreibt das UCS Handbuch.

Für das Provisioning von Office 365 und Google Apps for Work gibt es extra Konnektoren, die Benutzer anlegen, modifizieren und löschen. Hiermit bietet UCS eine noch tiefere Integration der Services.

Grundanforderungen an die Einführung von SAML

Bevor Sie sich für eine (Teil-)Einführung von SAML entscheiden, sollten Sie mindestens die folgenden Fragen für sich beantworten:

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

Wir hoffen, Ihnen einen guten Einstieg in die Technologie des SAML Protokolls vermittelt zu haben. Sollten Sie weitere Fragen haben, können Sie gerne mit uns Kontakt aufnehmen.

Quellen:
[1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
[2] https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
[3] http://docs.software-univention.de/handbuch-4.1.html#domain:saml:additionalserviceprovider
[4] https://www.univention.de/produkte/univention-app-center/app-katalog/office365/
[5] https://www.univention.de/produkte/univention-app-center/app-katalog/google-apps/

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!

Kommentare

  1. Gute Informationen, sehr hilfreich. Danke.

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