- Shibboleth - Single Sign On (SSO) - Dokumentation
Einleitung
Zweck und Ziel dieser Dokumentation
Diese Dokumentation richtet sich an Anwendungsbetreuer:innen, die eine zentrale Authentifizierung an der Technischen Universität Dresden realisieren wollen. Ziel dieser Dokumentation ist, zu beschreiben, wie diese Authentifizierung über den Shibboleth IdP der Technischen Universität Dresden vorgenommen und dabei von dessen Vorteilen profitiert werden kann.
Vorteile von Shibboleth
- Nutzer:innen
- Single Sign On (SSO) - einmalig am IdP angemeldet, kann die IdP-Sitzung für alle weiteren SP wiederverwendet werden, ohne dass man sein Passwort/Token erneut eingeben muss
- Multi Faktor Authentifizierung (MFA) - gemäß der Empfehlung des BSI Grundschutzkataloges bietet der Shibboleth IdP der Technischen Universität Dresden einen zweiten Faktor per TOTP oder Indexed Secret Verfahren an
- Eingabemaske bei der Heimateinrichtung - gewährt Nutzer:innen während der Authentifizierung eine sichere und vertraute Anmeldeumgebung. Die Anmeldedaten werden immer bei der Heimateinrichtung (IdP) eingegeben, nicht beim Anbieter (SP).
- Datenschutz - Überblick und Zustimmung übermittelter Daten
- Einrichtung (IdP)
- Zentrale Authentifizierung - simple Anbindung an IDM-System (geringer Aufwand und Komplexität)
- Zentrale Eingabemaske - Konsolidierung und Skalierung der Benutzerverwaltung
- Zentrale Updates/Informationen - Erhöhung der Sicherheit
- Anbieter (SP)
- keine eigene Benutzerverwaltung
- Kontrolle über die Nutzung (Autorisierung)
- breites Spektrum an Nutzern durch Mitgliedschaft in der DFN-AAI
- Richtigkeit der Daten (Fehleingaben werden vermieden)
Grundlagen
Was ist Shibboleth?
Shibboleth ist eine OpenSource-Software für Webanwendungen, die vom Shibboleth Konsortium weiterentwickelt wird. Diese Software, bestehend aus mehreren Komponenten, bietet ein Verfahren zur verteilten Zugriffssteuerung an. Shibboleth ist an der Technischen Universität Dresden die empfohlene Art & Weise der Authentifizierung, da hier mehrere Sicherheitsaspekte bereits berücksichtigt werden (siehe Vorteile), die bei anderen Authentifizierungsverfahren aufwendig selbst realisiert werden müssten oder gar nicht möglich sind.
Der Shibboleth IdP an der Technischen Universität Dresden basiert auf dem SAML2.0 Protokoll. Eine Realisierung des OIDC Protokoll ist in Planung.
Was ist SAML (Security Assertion Markup Language)
Die Security Assertion Markup Language stellt ein XML-Framework dar, mit dem der Shibboleth-IdP die Authentifizierung vornimmt und Daten zur Autorisierung bereitstellt. Weitere Informationen zu SAML findet man z. B. in der Wikipedia.
Was ist OIDC (OpenID Connect)
Das OpenID Connect bildet eine Authentifizierungsschicht, die auf dem OAuth-2.0-Protokoll aufbaut. OAuth-2.0 dient der Autorisierung. Das OAuth-2.0-Protokoll bietet Anwendungen den Zugriff auf Nutzerdaten, die von einem IdP bereitgestellt werden.
Der Shibboleth IdP der Technischen Universität Dresden unterstützt noch kein OIDC. Es ist in Planung das OIDC-Plugin am IdP der Technischen Universität Dresden einzuführen. Alternativen bilden derzeit Keycloak oder ein OpenID Connect Proxy des DFN-AAI Vereins. Der OpenID Connect Proxy bietet nur ausgewählte Attribute an. Keycloak dagegen kann als OIDC Proxy mit einem eigenen Mapping betrieben werden. Somit ist es möglich viel mehr Informationen von seinem IdP zu beziehen, als es der DFN-AAI Verein mit dem OpenID Connect Proxy vorsieht.
Komponenten & Funktionsweise
Identity Provider (IdP, bei der Heimateinrichtung tu-dresden.de)
- Multi Faktor Authentifizierung (frei wählbar, Username + Password + TOTP)
- Identity Management, SSO (frei wählbar, OpenLDAP bzw. IDM)
- Lieferung von Benutzerdaten als OID Mapping (Attribute wie z.B.: E-Mail, Name. Siehe auch Attribute)
- siehe auch Identity Provider
Service Provider (SP, beim Anbieter)
- Zugriffskontrolle (benötigt erfolgreiche Authentifizierung und optional Attribute zur Diensterbringung)
- kein Zugriff auf sensitive Daten während der Authentifizierung
- siehe auch Service Provider
Discovery Service
- optionaler Lokalisierungsdienst
- Liste mit Heimateinrichtungen und Anbietern, die IdPs betreiben
- als selbstständiger Dienst oder beim Anbieter (siehe auch Discovery Services des DFN-Vereines)
DFN-AAI-Föderation
- Vertrauensstellung zwischen IdPs und SPs
- Einhaltung technischer und rechtlicher Rahmenbedingungen
- siehe auch DFN-AAI-Föderation
Funktionsweise
Die hier abgebildete Grafik zeigt die Shibboleth SAML-Kommunikation der einzelnen Komponenten:
|
||
|
||
|
|
Die Vertrauensstellung zwischen Resource (SP) und Users's Home Org (IdP) wird durch die DFN-AAI-Föderation sichergestellt. Die Vertrauensstellung zwischen SP und IdP kann auch direkt hergestellt werden, indem der IdP die Metadaten der SPs lokal speichert. Nachteil dabei sind höhere Aufwände bei Aktualisierungen von z.B. Zertifikaten, Endpoints, Kontakten u.a.
Ohne Vertrauensstellung zwischen IdP und SP wird die technische Kommunikation abgelehnt und die Nutzer:innen erhalten eine Fehlernachricht.
Mit nur einem Identity Provider
| Vorgang | Beschreibung |
|---|---|
| 1 | Nutzer:in wählt die gewünschte URL Resource (SP) in seinem Browser aus |
| 5 | Der SP stellt nun eine Authentifizierungs-Anfrage an den ausgewählten IdP |
| - bereits eingeloggte Nutzer:innen werden am IdP wieder an den SP zurückgeleitet (keine weiteren Schritte am IdP) | |
| - existiert keine gültige Session für den/die Nutzer:in, fragt der IdP nach den Zugangsdaten (in Form einer Login-Seite) | |
| 6 | Nutzer:in gibt seine Zugangsdaten am IdP ein |
| 7 | Mit erfolgreicher Authentifizierung wird der /die Nutzer:in vom IdP wieder zurück an den SP geschickt |
| - der IdP teilt dem SP unter anderem mit, dass sich dieser erfolgreich authentifiziert hat | |
| - darüber hinaus werden, wenn von den Nutzer:innen akzeptiert, weitere Informationen (Attribute) an den SP weitergegeben | |
| - die Datenübertragung der Informationen (Attribute) erfolgt über den Webbrowser der Nutzer:innen | |
| - der SP wertet die Attribute aus und leitet eventuelle Zugriffsberechtigungen (Autorisierung) davon ab | |
| - der Zugriff auf den SP wird gestattet oder verweigert |
Mit mehreren Identity Provider
Die Resource (SP) kann eine Koniguration besitzen, mit der mehreren Users's Home Org (IdP) der Zugriff gewährt wird. In diesem Fall müssen Nutzer:innen entscheiden, über welchen IdP Sie Zugriff zum SP erlangen. Dieses Verfahren wird auch Discovery Service genannt. Bei mehreren IdP werden der Funktionsweise: Mit nur einem Identity Provider folgende Vorgänge eingereiht.
| Vorgang | Beschreibung |
|---|---|
| 2 | SP prüft, ob Nutzer:in bereits eingeloggt ist |
| - bei Erfolg liefert der SP die angeforderte Seite aus (der weitere Ablauf wird gestoppt) | |
| - bei Misserfolg leitet der SP alle Nutzer:innen an einen Discovery Service weiter (via Redirect) | |
| 3 | Nutzer:in wählt aus einer Liste die entsprechende Heimateinrichtung aus |
| 4 | Der Discovery Service leitet nach Auswahl der Nutzer:innen den gewählten IdP (via Redirect) an den ursprünglichen SP zurück |
Schlüsselwörter
Metadaten
Die Metadaten werden beim SP und IdP verwendet, um gegenseitig die Vertrauensstellung zu gewährleisten. Der SP benötigt dabei die Metadaten des IdP und umgekehrt.
Die Metadaten werden im XML-Format vorgehalten und sollten mindestens folgende Merkmale für den IdP der Technischen Universität Dresden beinhalten:
- entityId
- SAML Zertifikat für Verschlüsslung und Signierung
- Assertion Consumer Endpoint
In der Regel erzeugen SP Anwendungen die Metadaten mittels Metadatengenerator. Über das DFN-AAI-MDV können mit Angabe der oben genannten Informationen die Metadaten vorgeneriert und verwaltet werden.
Weitere Informationen zu den Metadaten finden Sie hier
Deutsches Forschungsnetz (DFN) - Authentication and Authorization Infrastructure (AAI)
Die Technische Universität Dresden ist Mitglied der DFN-AAI. Die DFN-AAI stellt die technische Grundlage, mit der eine Infrastruktur von Vertrauensstellungen aller AAI teilnehmenden Heimateinrichtungen realisiert werden kann. Durch die Mitgliedschaft in der DFN-AAI besitzen IdP- und SP-Betreiber Zugriff auf eine Vielzahl vertrauenswürdiger Metadaten, mit denen der Datenaustausch gewährleistet wird.
Vorteile der DFN-AAI (aus Sicht von SP):
- Einhaltung und Prüfung von Richtlinien (z.B. Zertifikate)
- Zentrale Verwaltung von Metadaten
- Bereitstellung eines Lokalisierungsdienstes (siehe Discovery Service)
DFN-AAI Metadatenverwaltung (MDV)
Die DFN-AAI Metadatenverwaltung ist eine online Verwaltungsoberfläche zur Pflege der Metadaten von IdP- und SP-Betreibenden. Die MDV validiert Eingaben und stellt diese zentral für alle IdPs/SPs zum Download bereit.
Hinweis: Änderungen in der DFN-AAI Metadatenverwaltung besitzen Wartezeiten. Bitte beachten Sie diese Wartezeiten bei Änderungen z.B. am SAML Zertifikat oder SP Endpoints, um eine Störung Ihres Dienstes zu vermeiden.
entityId
Die entityId ist eine weltweit eindeutige ID in Form eines URL z.B. https://meine-domain.de/shibboleth. Der URL kann frei gewählt werden und muss mit keiner Ressource verknüpft sein. Um die Eindeutigkeit sicherzustellen ist ein DNS-Eintrag der Domain des SP ratsam.
Empfehlung: Verwenden Sie als entityId den Pfad für den Zugriff auf die Metadaten des SP.
Bitte beachten: Die entityId wird am IdP zur Freigabe- bzw. Filterkonfiguration verwendet. Zur Vermeidung von Störungen und nachträglichen Anpassungen bei unterschiedlichen Heimateinrichtungen (IdPs), sollte dieser Wert als statisch angesehen werden, sobald er einem IdP veröffentlicht wurde.
Identity Provider (IdP)
Der Identity Provider ist ein System, das für Identitäten bestimmter Heimateinrichtung betrieben wird. Er bietet diesen Identitäten die Möglichkeit der digitalen Authentifizierung nur im Kontext der Heimateinrichtung an.
Die Technische Universität Dresden betreibt zwei IdPs:
- https://idp3-test.tu-dresden.de/idp/shibboleth (Testsystem mit anonymen Testdaten)
- https://idp.tu-dresden.de/idp/shibboleth (Produktionssystem)
Service Provider (SP)
Der Service Provider ist im Kontext Shibboleth eine Anwendung / ein System das Zugriff auf Identitätsdaten benötigt.
Discovery Service
Der Discovery Service ist ein Verfahren zum Ermitteln des IdPs der Heimateinrichtung. Dem Nutzer werden über den SP Heimateinrichtungen angeboten, bei denen er seine Herkunft bestimmen kann: WAYF - Where are you from
Single Sign On (SSO)
Bezeichnung des Verfahrens, bei denen Nutzer:innen Zugriff zu mehreren SPs bekommen, sich aber nur einmalig beim ersten SP über Ihre Heimateinrichtung (IdP) anmelden müssen. Der Webbrowser hält die Session der Heimateinrichtung für weitere SP Anmeldungen offen. Eine Anmeldung bei weiteren SPs ist ohne erneute Dateneingabe von Nutzer:innen möglich, solange die Session der Heimateinrichtung gültig ist.
Single Logout (SLO)
Bezeichnung des Verfahrens, bei dem sich Nutzer:innen einmalig bei der Heimateinrichtung (IdP) abmelden und gleichzeitig alle offenen SP-Sessions schließen können.
SAML Zertifikat
Das SAML Zertifikat dient der Signierung und Ver-/Entschlüsselung während der Kommunikation zwischen SP und IdP. Neben dem HTTPS Zertifikat des Webservers, welcher eine verschlüsselte Datenübertragung gewährleitet, wird das SAML Zertifikat zur Verschlüsselung der Daten selbst verwendet. Der Transfer der IdP-Daten verläuft über den Webbrowser der Nutzer:innen. Eine zusätzliche Verschlüsselung der IdP-Daten erhöht die Datensicherheit, sofern der Webbrowser der Nutzer:innen kompromittiert ist. Nur der SP ist in der Lage die Daten zu entschlüsseln.
Das SAML Zertifikat kann, muss aber nicht das Webserverzertifikat sein! Webserverzertifikat können eine kurze Gültigkeit besitzen. Es wird empfohlen ein selbstsigniertes Zertifikat mit folgenden Vorgaben zu verwenden.
SAML Zertifikate müssen in regelmäßigen Abständen ersetzt werden (maximal 1170 Tage). Dafür muss der SP einen geeigneten Prozess besitzen (z.B. Zertifikatsrollover), um während des Austausches mit allen IdPs keinen Ausfall der Authentifizierung hervorzurufen.
Hinweis: Ebenso wie der SP besitzt der IdP ein SAML Zertifikat, das im regelmäßigen Abstand ersetzt werden muss. Der SP muss einen geeigneten Prozess besitzen, der das SAML Zertifikat des IdP aktualisiert (z.B. über DFN-AAI). Ohne Aktualisierung des IdP SAML Zertifikates am SP, wird eine Änderung dessen in einen Ausfall der SP Authentifizierung laufen.
Zertifikatsrollover
Der Zertifikatsrollover ist ein Prozess mit dem Ziel, ein altes Zertifikat gegen ein neues Zertifikat auszutauschen. Der Zertifikatsrollover ist darauf ausgelegt, dass der öffentliche und der private Schlüssel erneuert werden können. Damit die Verschlüsselung zwischen SP und IdP weiterhin gewährleitet wird, müssen diese immer das aktuelle Zertifikat (öffentlicher Schlüssel) des Gegenparts kennen, sowie benötigt der Gegenpart seinen dazugehörigen Zertifikatsschlüssel (privater Schlüssel).
Während des Zertifikatsrollover wird das neue Zertifikat bekanntgegeben, während der Betrieb weiterhin über das alte Zertifikat verläuft. Mit gewisser Wartezeit werden die Zertifikate getauscht ohne einen Ausfall der Authentifizierung zu erzeugen.
Technische Voraussetzungen
Die Voraussetzung für die Shibboleth Authentifizierung ist der Betrieb eines SP Clients. Der Standard sieht vor, dass der SP über einen Webserver betrieben wird. Die Kommunikation verläuft über den Webbrowser des Nutzers (siehe Anbindung per Webserver oder Funktionsweise).
Die Auswahl einer geeigneten SP Anwendung hängt maßgeblich von Ihrem Betriebssystem und der damit eingesetzten Webserver-Anwendung und Ihren individuellen Präferenzen ab. Ob Sie nun eine Open-Source-Lösung wie den Shibboleth SP selbst, eine kommerzielle Alternative oder eine spezialisierte Integration für Ihre Webserver-Plattform bevorzugen – die Entscheidung liegt bei Ihnen. Diese Vielfalt an Optionen gewährleistet, dass Sie den SP finden, der optimal zu Ihrer IT-Infrastruktur und Ihren Sicherheitsrichtlinien passt.
Diese Dokumentation richtet sich vorwiegend auf die Konfiguration des Shibboleth SP und bietet ausgewählte Alternativen an, die bereits am ZIH bewährt im Einsatz sind.
Anbindungsoptionen
Anbindung per Webserver
Anbindungen per Webserver werden im SAML2.0 Protokoll (Standard) oder bedingt per OIDC Protokoll (noch in Entwicklung) angeboten.
SAML2.0 - Atlassian Shibboleth Service Provider 3
Die hier beschriebene Anbindung basiert auf der Vorlage des Atlassian Shibboleth Service Provider 3 Clients. Bitte beachten Sie die technischen Vorraussetzungen und Installation dieses SPs.
Die weitere Konfiguration wird in einem separaten Abschnitt zu SAML2.0 - Atlassian Shibboleth Service Provider 3 angeboten.
OIDC - OpenID Connect Proxy
Der OpenID Connect Proxy wird vom DFN-AAI für Dienste angeboten, die kein SAML Protokoll unterstützen, dafür jedoch auf OIDC ausgelegt sind. Der Proxy verarbeitet das SAML Protokoll der registrierten Heimateinrichtung und bietet dies im OIDC Protokoll als IdP dem SP an.
Mit einem Satz von definierten Attributen bietet der OIDC Proxy eine Alternative, wenn der IdP der Heimateinrichtung kein OIDC unterstützt.
OIDC - Keycloak
Die Anwendung Keycloak kann als Identity Provider mit OIDC Protokoll betrieben werden und ermöglicht die Kommunikation über SAML2.0. Durch die zusätzliche Konfiguration als SP ist es möglich eine Authentifizierung über einen anderen Identity Provider (z.B. SAML2.0 Protokoll) zu realisieren. Keycloak eignet sich somit als Wrapper zwischen SAML2.0 und OIDC ähnlich wie der OpenID Connect Proxy.
Das ZIH bietet hierfür eine containerisierte Lösung an. Eine mögliche Installation und Konfiguration von Keycloak wird in einem separaten Abschnitt angeboten.
Anbindungsprozess
Für die produktive Shibboleth Anbindung am IdP der Technischen Universität Dresden ist vor der Freigabe der Daten ein signierter PDF-Antrag notwendig, den Sie an den Service Desk senden. Eine Test-Anbindung an die Shibboleth Test-Umgebung ist jeder Zeit möglich und ohne großen Beantragungsprozess verbunden. Hier genügt eine formlose E-Mail an den Service Desk.
Zur Reduktion der Bearbeitungsdauer während des Anbindungsprozesses und unabhängig davon, ob Ihre Anbindung als Test oder für die Produktion erfolgen soll, befolgen Sie bitte die nachfolgenden Punkte.
Vorbereitung Seitens Service Providers
- Sind die technischen Voraussetzungen vorhanden?
- Welche Attribute sollen am IdP freigegeben werden (siehe Welche Attribute werden benötigt?)?
- Sind UI Informationen berücksichtigt worden?
- Anzeigename (deutsch/englisch)
- Beschreibung der Anwendung (deutsch/englisch)
- Link zur Datenschutzerklärung (deutsch/englisch)
Technische Voraussetzungen
Diese Checkliste soll Ihnen helfen, um vor der Antragsstellung sicherzugehen, dass der Service Provider alle Voraussetzungen erfüllt.
- entityId nach den Vorgaben definiert
- Service Provider installiert und konfiguriert (siehe Anbindungsoptionen)
- SAML2.0 Zertifikat entspricht den Vorgaben der DFN-AAI? (siehe https://doku.tid.dfn.de/de:certificates). Hinweis: Verwenden Sie keine browserverankerten Zertifikate. Aufgrund der zukünftig geringen Gültigkeit von browserverankerten Zertifikaten müssten sehr häufig aufwendige Zertifikatsrollover durchgeführt werden. Lesen Sie hier zur Generierung von selbstsignierten Zertifikaten.
- Metadaten beinhalten SAML2.0 Zertifikat für Signierung und Verschlüsselung. Ebenfalls empfohlen ist die Angabe der benötigen Attribute in den Metadaten.
- Metadaten liegen für die Beantragung vor bzw. werden manuell im DFN-AAI-MDV erstellt.
Welche Attribute werden benötigt?
Während der Beantragung sollte Ihnen bewusst sein, welche Informationen Ihr SP vom IdP benötigt. Bitte teilen Sie uns die erforderlichen Attribute im Antrag oder in den Metadaten (siehe auch Metadaten) des SPs mit.
Einen Überblick über einen Satz häufig verwendeter Attribute finden Sie auf folgenden Seiten:
Tipps & Tricks
SAML Zertifikat selbstsigniert erstellen
Verwenden Sie folgenden Befehl um Ihr SAML Zertifikat für Ihren SP mit der entityId https://meine-domain.de/shibboleth zu erstellen.
openssl req -x509 -newkey rsa:3072 -keyout shibboleth-sp.key -out shibboleth-sp.pem -days 1170 -nodes -subj "/CN=https:\/\/meine-domain.de\/shibboleth/"
SAML Zertifikatstausch ohne Rollover
Ein SP, der kein Zertifikatsrollover unterstützt, weil nur genau ein Zertifikat gleichzeitig aktiv sein kann, hat die Möglichkeit, sein SAML-Zertifikat (öffentlicher Schlüssel) zu aktualisieren, indem er bei der Ausstellung des neuen Zertifikats den gleichen privaten Schlüssel my-same-saml-key.pem verwendet wie das bisherige Zertifikat. Dadurch funktioniert die Kryptographie auch zwischen altem und neuen Zertifikat.
openssl req -x509 -new -nodes -key my-same-saml-key.pem -sha256 -days 1170 -out my-new-saml-cert.pem
Hinweis: Der Schlüssel my-same-saml-key.pem sollte zu den aktuellen Vorgaben der DFN-AAI passen z.B. 3072 Bits.