Shibboleth - DFN-AAI

Shibboleth ist die im Hochschul- und Forschungsumfeld weit verbreitete Technik, die als Authentifikations- und Autorisierungs-Infrastruktur (AAI) für Webanwendungen dient. Dabei kann ein Benutzer mit seiner lokalen Kennung auch Dienste anderer Hochschulen und Anbieter (z.B. Bibliotheken, Softwarehändler) nutzen.

Die Software Shibboleth bildet die technische Basis, die Besitzern von aktiven LRZ-, TUM- und LMU-Kennungen ein ständig wachsendes Dienstangebot im Web eröffnet, siehe Verzeichnis der Service Provider in der DFN-AAI

Merkmale und Eigenschaften von Shibboleth

  • Verteilte Authentifikation und Autorisierung: Die lokale Kennung kann zum Login sowohl für lokale Dienste als auch für Angebote anderer Einrichtungen verwendet werden (Föderiertes Identitätsmanagement, FIM).
  • Webanwendungen: Shibboleth ist ausschließlich für Webanwendungen einsetzbar (nicht z.B. zur Anmeldung an CIP-Pools). Neben Hochschulangeboten (Portale, Wikis, Learning-Systeme etc.) nutzen auch kommerzielle Anbieter Shibboleth (z.B. Online-Verlagsangebote, Softwarevertrieb)
  • Single-Sign-On: Mit einer einzigen Anmeldung sind verschiedene Dienste und Anwendungen nutzbar, auch bei anderen Einrichtungen.
  • Datenschutz: Der Benutzer kann seine persönlichen Daten, die an einen Dienstanbieter geschickt werden, vorab einsehen und die Übermittlung und Dienstnutzung ggf. abbrechen.
  • Föderation: Verteilte Authentifikation erfordert ein noch höheres Maß an Sicherheit, Vertraulichkeit und Verlässlichkeit der Systeme als eine einrichtungslokale Lösung. In Deutschland sind deshalb Hochschulen und Forschungseinrichtungen in der DFN-AAI-Föderation zusammengeschlossen. Der DFN organisiert und überwacht die technischen wie auch die vertragsrechtlichen Voraussetzungen der Partner.

Technik von Shibboleth

Shibboleth umfasst sogenannte Identity Provider (IdP) und Service Provider (SP). Identity Provider sorgen für die Authentifikation von Benutzern der lokalen Einrichtung. Mitteilungen über die erfolgte Authentifikation (Identitiätskontrolle, Login) und relevante Informationen für die Autorisierung (Zugangsberechtigung) gelangen über das SAML (Security Assertion Markup Language) zum Service Provider, auf dessen Seite die Webanwendung läuft. Möchte ein Benutzer eine solche Anwendung betreten, wird er i.d.R. zu einem WAYF-Service ("where are you from") geleitet, wo er seine Heimatorganisation auswählt und zu dieser weitergeleitet wird. Das Login erfolgt also ausschließlich an der Login-Maske der Heimatorganisation (des lokalen IdP), was gegenüber herkömmlichen Logins an jeder einzelnen Webanwendung einen großer Sicherheitsfortschritt darstellt: Passwörter gelangen nicht mehr zu den Webanwendungen und den dahinter laufenden fremden Systemen. Eine gründliche Einführung in Konzept und Technik von Shibboleth bietet das Shibboleth-Wiki https://wiki.shibboleth.net/confluence/display/CONCEPT/Home.

Identity Provider im Münchner Wissenschaftsnetz (LMU und TUM)

Das LRZ betreibt die Identity Provider der TUM und der LMU. Identitäten sind alle aktiven Kennungen aus dem TUM- bzw. dem LMU-Verzeichnisdienst. Um den vollen Berechtigungsumfang (Autorisierung als immatrikulierter Student, aktiver Mitarbeiter etc.) in den Anwendungen zu erhalten, sollten TUM- bzw. LMU-Angehörige im WAYF-Service deshalb immer ihre Universität auswählen (und nicht "Leibniz-Rechenzentrum"). DFN-AAI WAYF

Shibboleth-Authentifizierung in eigenen Webanwendungen (LMU und TUM)

Um in einer eigenen Webanwendung Shibboleth-Authentifizierung zu nutzen, muss zusätzlich eine Shibboleth-Software installiert werden, die den sog. shibd (Shibboleth Daemon) enthält, außer die Anwendung unterstützt nativ Shibboleth/SAML-Authentifizierung. Siehe hierzu die Anleitung der DFN-AAI in
https://www.aai.dfn.de/dokumentation/service-provider.

Damit die Identity Provider dem neuen Service Provider vertrauen, müssen dessen Metadaten

  • in die lokale AAI-Föderation der Heimateinrichtung
  • oder in die deutschlandweite DFN-AAI-Föderation aufgenommen werden.

Die Metadaten enthalten u.a. das Zertifikat des SPs, die URLs für die Service Endpoints als Schnittstellen zwischen IdP und SP, sowie Kontaktinformationen.

Für die Aufnahme Ihres SPs in eine Föderation geben Sie bitte an den LRZ Servicedesk (Service "Benutzerverwaltung und Verzeichnisdiesnste - DFN AAI/Shibboleth")  folgende Informationen:

  1. Organisatorisches
    • Shibboleth EntityID wie im SP konfiguriert (z.B. https://bikesharing.tum.de/shibboleth)
    • Anzeigename des Webdiensts ("TUM Bikesharing", "LMUcast für iTunesU")
    • Kurzbeschreibung des Webdienstes (1-2 Zeilen)
    • URL der Startseite Ihres Webdienstes (z.B. https://bikesharing.tum.de/login.php)
    • Helpdesk-URL- und Mailadresse
    • Name und Mailadresse einer Kontaktperson für die Technik und Administration des SPs

  2. Technik
    • URL, von dem die Shibboleth-Metadaten des SPs abgerufen werden können.
      Dieser URL hat typischerweise die Form
      https://bikesharing.tum.de/Shibboleth.sso/Metadata
      und ist durch die Installation der Shibboleth SP-Software auf Ihrem Webdienst verfügbar.
      - ODER -
    • Server-Zertifikat des Webdienstes und
      Service-Endpoints: Art und URL der vom SP unterstützten Shibboleth NameID- und Assertion-Consumer- und ggf. Single-Logout-Services, z.B.
       urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
       -> https://bikesharing.tum.de/Shibboleth.sso/SAML2/POST

  3. Datenschutz
    • Mitteilung, dass der Webdienst auf einem TUM/LMU-System betrieben wird und nur anonyme Daten zum Login und zur Zuordnung evtl. vorhandener Profile verwendet (die sog. eduPersonTargetedID).
      - ODER -
    • eine Kopie der Freigabe Ihres Datenschutzbeauftragten für Ihren Dienst. Diese ist immer erforderlich, wenn der Webdienst vom IdP auch personenbezogene Daten anfordert und verarbeitet, wie z.B. Name, Mail-Adresse, Einrichtungszugehörigkeit (Affiliation), Geschlecht etc.

Serverzertifikate

Verwenden Sie kein selbst-signiertes Server-Zertifikat! Lassen Sie für Ihren Server ein Zertifikat von Ihrer lokalen PKI/Registration Authority (RA) ausstellen (https://www.aai.dfn.de/der-dienst/zertifikate/).

Dies sind

Außerdem sollte das Zertifikat das Client-Auth-Flag beinhalten, also nicht als Webserver-, sondern als Shibboleth-IdP/SP-Zertifikat beantragt werden, siehe z.B.http://www.lrz.de/services/pki/wieman/

Nach Aufnahme Ihres SPs in die gewünschte Föderation (Nachricht vom Servicedesk) tragen sie in shibboleth2.xml als MetadataProvider im Attribut "uri" ein:

  • für die TUM-lokale Föderation: http://www.aai.dfn.de/fileadmin/metadata/DFN-AAI-Local-8-metadata.xml
  • für die LMU-lokale Föderation: http://www.aai.dfn.de/fileadmin/metadata/DFN-AAI-Local-29-metadata.xml
  • für die DFN-AAI-Testföderation:http://www.aai.dfn.de/fileadmin/metadata/DFN-AAI-Test-metadata.xml

Andere Einrichtungen

Für die Shibboleth-Anbindung von Webdiensten, die an anderen Einrichtungen als an TUM oder LMU betrieben werden, wenden Sie sich bitte an den jeweiligen Ansprechpartner gemäß der Liste
https://www.aai.dfn.de/verzeichnis/teilnehmer/

Sollte Ihre Einrichtung dort nicht aufgeführt sein, muss sie zunächst mit dem DFN-Verein einen Vertrag zur DFN-AAI schließen, ggf. auch einen ersten DFN-Rahmenvertrag. Beachten Sie auch das Angebot des kostenlosen Hostings von Identity Providern in der DFN-AAI
https://www.aai.dfn.de/der-dienst/ausgelagerter-idp/