Page tree
Skip to end of metadata
Go to start of metadata

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 auf Dienste anderer Hochschulen und Anbieter zugreifen, z.B. E-Learning-Angebote, Bibliotheken oder Softwareanbieter.

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 in erster Linie 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). Mit dem ECP-Protokoll ist jedoch die Anmeldung an eigenständigen APPs (z.B. beim LRZ Sync+Share) möglich.
  • 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.

Am LRZ betriebene Identity Provider für TUM, LMU und BAdW

Das LRZ betreibt die Identity Provider der TUM, der LMU und der BAdW. Identitäten sind alle aktiven Kennungen aus dem TUM- , dem LMU- bzw. dem LRZ-Verzeichnisdienst.

Um den vollen Berechtigungsumfang (Autorisierung als immatrikulierter Student, aktiver Mitarbeiter etc.) in den Anwendungen zu erhalten, sollten Benutzer von TUM- bzw. LMU beachten:

In der Anwendung "Login mit TUM-Kennung" oder "Login mit LMU-Kennung" wählen (sofern vorhanden):In einem Auswahlfeld (evtl. nach Klick auf "Shibboleth Login" oder "Institutional Login") ihre Universität auswählen (und nicht "Leibniz-Rechenzentrum"):


Der Anmeldebildschirm des LMU Moodle

(Quelle: https://moodle.lmu.de/local/login)


Der Where-Are-You-From Dialog des DFN-AAI
(Quelle: https://wayf.aai.dfn.de/DFN-AAI/wayf)



Ein allgemeiner Where-Are-You-From Dialog eines Web-Dienstes
(Quelle: https://link.springer.com)

Shibbolethisierung eigener Webanwendungen

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://wiki.aai.dfn.de/de:shibsp.

Shibboleth für Anwendungen der LMU, TUM und BAdW

Aufnahme in die AAI-Föderation

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 Authentisierung")  folgende Informationen:

  1. Organisatorisches
    • Shibboleth EntityID wie im SP konfiguriert (z.B. https://abstimmung.semesterticket-muenchen.de/shibboleth)
    • Anzeigename des Webdiensts (z.B. "Abstimmung über das Semesterticket in München",  "TUM Mathematischer Kalender", "LMUcast für iTunesU"), deutsch und englisch
    • Kurzbeschreibung des Webdienstes (1-2 Zeilen), deutsch und englisch
    • URL zur Informationsseite mit Beschreibung Ihres Webdienstes, deutsch und englisch
    • URL zur Datenschutzerklärung (Privacy Statement) für Ihren Webdienst, deutsch und englisch
    • Helpdesk-URL- und Mailadresse (z.B. "TUM IT-Support", "LMU IT-Servicedesk")
    • Name und Mailadresse je einer Kontaktperson für die technische Administration des SPs und für den Support des Webdienstes

  2. Technik
    • URL, von dem die Shibboleth-Metadaten des SPs abgerufen werden können.
      Dieser URL hat typischerweise die Form
      https://abstimmung.semesterticket-muenchen.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://abstimmung.semesterticket-muenchen.de/Shibboleth.sso/SAML2/POST

  3. Datenschutz
    • Mitteilung, dass der Webdienst auf einem TUM/LMU/BAdW-System betrieben wird und nur anonyme Daten zum Login und zur Zuordnung evtl. vorhandener Profile verwendet (die sog. eduPersonTargetedID).
      - ODER -
    • Die Liste der Attribute (personenbezogene Daten), die der Webdienst vom IdP anfordert und die im  TUM/LMU/BAdW-IdP für ihren Webdienst freigeben werden sollen,
      (personenbezogen sind u.a. Benutzerkennung/LRZ-Kennung, Name, Mail-Adresse, Einrichtungszugehörigkeit/Affiliation, Geschlecht);
      sowie die Mitteilung, dass für den Webdienst ein Eintrag im Verzeichnis der Verarbeitungstätigkeiten gemäß § 30 Datenschutz-Grundverordnung (DSGVO) Ihrer Organisationseinheit existiert und dieser Eintrag die Verarbeitung dieser Attribute abdeckt. 

Serverzertifikat

Verwenden Sie kein selbst signiertes Server-Zertifikat! Lassen Sie für Ihren Server ein Zertifikat von Ihrer lokalen PKI/Registration Authority (RA) ausstellen (https://doku.tid.dfn.de/de:certificates).

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:

Shibboleth für Anwendungen anderer Einrichtungen

Für die Shibboleth-Anbindung von Webdiensten, die an anderen Einrichtungen als an TUM, LMU oder BAdW 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.


  • No labels