Dies ist eine alte Version des Dokuments!


Shibboleth SP

Siehe hierzu die betreffenden Seiten

Vorbemerkung: In den folgenden Beispielen wird davon ausgegangen, dass zur Einrichtungsauswahl der Shibboleth Embedded Discovery Service (EDS) zum Einsatz kommt (siehe unten). Ein solcher SP-seitiger Discovery Service ist in den meisten Fällen das Mittel der Wahl, da er die „User-Experience“ verbessert - insbesondere in Szenarien, in denen ein SP-Betreiber die Liste für die IdP-Auswahl über bestimmte Filter modifizieren/einschränken möchte. Da dieser sehr einfach zu konfigurierenden EDS quasi als Zubehör zum Shibboleth SP mitgeliefert wird, sei er an dieser Stelle besonders empfohlen.
Sollten Sie aus bestimmten Gründen doch bevorzugt den zentralen, vom DFN betriebenen DS/WAYF verwenden wollen, finden Sie einige Konfigurationsbeispiele hier.

Editieren Sie die Haupt-Configdatei des SP an folgenden Stellen:

/etc/shibboleth/shibboleth2.xml
<SPConfig ... >
  ...
  <!-- "sp.example.org" durch den SP-Vhost-Namen ersetzen -->
  <ApplicationDefaults entityID="https://myvhost.mydomain.de/shibboleth" ... >
  ...
   <!-- handerSSL auf "true" und cookieProps auf "https" -->
   <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
             checkAddress="false" consistentAddress="true"  
             handlerSSL="true" cookieProps="https" redirectLimit="host">
      ...
      <!-- "sp.example.org" durch den SP-Vhost-Namen ersetzen -->
      <SSO discoveryProtocol="SAMLDS" discoveryURL="https://myvhost.mydomain.de/shibboleth-ds/index.html">
         SAML2
      </SSO>
      ...
   </Sessions>       
   ...
   <!-- valide (Admin-/Hotline-) eMail-Adresse und korrekte URLs/Pfade einfügen-->
   <Errors supportContact="helpdesk@example.org"
           helpLocation="/about.html"
           styleSheet="/shibboleth-sp/main.css"/>
   ...
   <!-- Metadaten der Test-Föderation aktivieren -->
   <!-- den Pfad zum Zertifikat zur Signaturüberprüfung den lokalen Gegebenheiten anpassen! -->
   <MetadataProvider type="XML" url="http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-test-metadata.xml"
         validate="true" backingFilePath="dfn-aai-test-metadata.xml" reloadInterval="3600">
       <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai.pem"/>
   </MetadataProvider>
   ...
   <!-- Pfadangaben zu den Zertifikat-Dateien -->
   <CredentialResolver type="File" key="/etc/ssl/private/myvhost.mydomain.de.key.pem" 
          certificate="/etc/ssl/localcerts/myvhost.mydomain.de.crt.pem"/>
   ...
  </ApplicationDefaults>
  ...
</SPConfig>

Filtermechanismen

Wenn der vom SP geschützte Dienst nur von Angehörigen bestimmter Einrichtungen genutzt werden soll, können anhand bestimmter Kriterien sogenannte Metadata Filter im SP konfiguriert werden. Dies hat zwei Vorteile:

  1. Der SP arbeitet intern nur mit dem gefilterten, in der Regel deutlich reduzierten Metadatensatz
  2. Ist im SP der entsprechende Discovery Feed Handler konfiguriert (<Handler type=„DiscoveryFeed“ Location=„/DiscoFeed“/>) sorgt der Embedded Discovery Service (s.u.) dafür, dass nur die IdPs bzw. Einrichtungen angezeigt werden, die in diesen gefilterten Metadaten enthalten sind. Der entsprechende Parameter in idpselect_config.js muss hierfür folgendermaßen belegt werden:
    this.dataSource = '/Shibboleth.sso/DiscoFeed'

Im folgenden ein Beispiel für eine Whitelist:

/etc/shibboleth/shibboleth2.xml
...
   <MetadataProvider type="XML" 
         url="http://www.aai.dfn.de/fileadmin/metadata/dfn-aai-basic-metadata.xml"
         validate="true" backingFilePath="dfn-aai-basic-metadata.xml" reloadInterval="3600">
      <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai.pem" />
      <MetadataFilter type="Whitelist">
         <Include>https://idp.uni-beispiel1.de/idp/shibboleth</Include>
         <Include>https://idp.uni-beispiel2.de/idp/shibboleth</Include>
         <Include>https://idp.uni-beispiel3.de/idp/shibboleth</Include>
      </MetadataFilter>
   </MetadataProvider>
   ...

Für ein Beispiel eines Metadata Filters anhand einer Entity Category siehe die Dokumentation des bwIDM-Projekts unter https://www.bwidm.de/teilnahme/dienstanbieter/ (Abschnitt 1.2 - Technische Voraussetzungen)

Nach allen Änderungen in shibboleth2.xml muss der shibd Service neu gestartet werden:

Funktioniert die überarbeitete Konfiguration?

root@host:~# shibd -t

Dann ab dafür:

root@host:~# systemctl restart shibd

Fallweise kann es passieren, dass der Webserver aus dem Tritt kommt, z.B. nach mehreren shibd-Restarts. In solchen Fällen muss auch dieser neu gestartet werden:

root@host:~# systemctl restart apache2

Installation

Siehe hierzu die betreffende Seite im Shibboleth Wiki.

  • CentOS/RedHat/SuSE

Für RPM-basierte Linux-Varianten bieten die Shibboleth-Entwickler ein RPM-Paket an.

  • Debian/Ubuntu/etc.

Laden Sie das aktuelle tar-File herunter, packen Sie es aus und installieren Sie es:

root@server:~# wget https://shibboleth.net/downloads/embedded-discovery-service/latest/shibboleth-embedded-ds-1.2.2.tar.gz
root@server:~# tar -xzf shibboleth-embedded-ds-1.2.2.tar.gz
root@server:~# cd shibboleth-embedded-ds-1.2.2 ; make install


Konfiguration

Damit der EDS die Arbeit aus Sicherheitsgründen nicht verweigert, muss der eigene Vhost-Namen in die „Return White List“ eingetragen werden:

/etc/shibboleth-ds/idpselect_config.js
  ...
  this.returnWhiteList = [ "^https:\/\/meinvhost\.meinedomain\.de\/Shibboleth\.sso\/Login.*$" ];
  ...

Achten Sie auf die korrekte Syntax, der Eintrag muss in Form einer Regular Expression gemacht werden!


Damit ist der EDS grundsätzlich einsatzbereit. Weitere Hinweise und Informationen (z.B. zur Anpassung des Layouts) finden sich in den Kommentaren der Konfigurationsdatei(en) sowie im Shibboleth-Wiki.

Konfiguration für den Produktivbetrieb

  • das Layout des EDS muss in /etc/shibboleth-ds/index.html angepasst werden, in der die JavaScript-Aufrufe eingebettet werden, siehe hierzu die Kommentare in dieser Datei.
  • Für das <noscript>-Element empfiehlt sich der Link auf einen zentralen WAYF/DS, z.B.
https://wayf.aai.dfn.de/DFN-AAI-Basic/wayf?entityID=https%3A%2F%2Fmyvhost.mydomain.de%2Fshibboleth&return=https%3A%2F%2Fmyvhost.mydpmain.de%2FShibboleth.sso%2FLogin%3FSAMLDS%3D1
/etc/apache2/sites-enabled/myvhost.mydomain.de.conf
<VirtualHost SP-IP-ADRESSE:443 [SP-IPv6-ADRESSE]:443>
  ServerName              myvhost.mydomain.de
  SSLEngine on
  SSLCertificateFile      /etc/ssl/localcerts/myvhost.mydomain.de.crt.pem
  SSLCertificateKeyFile   /etc/ssl/private/myvhost.mydomain.de.key.pem
 
  # siehe https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
  UseCanonicalName On
  # EDS einbinden
  Include /etc/shibboleth-ds/shibboleth-ds.conf
 
  # einige SAML/AAI-Conventionen befolgen:
  Redirect seeother /shibboleth https://myvhost.mydomain.de/Shibboleth.sso/Metadata
  RedirectMatch /start-session$ /Shibboleth.sso/Login
 
  #######################################################
  # Dieser Block kann unter Debian/Ubuntu weggelassen
  # werden, da die Anweisungen automatisch beim Laden
  # des Moduls aktiv werden.
  #
  # Bei anderen Linuxen sind diese aber vielleicht nötig!
  #
  <Location /Shibboleth.sso>
    AuthType None
    Require all granted
  </Location>
  <Location /shibboleth-sp>
    AuthType None
    Require all granted
  </Location>
  Alias /shibboleth-sp/main.css /usr/share/shibboleth/main.css
  #######################################################
  #
  # Vom SP zu schützende Location
  #
  <Location /secure>
    AuthType shibboleth
    ShibRequestSetting requireSession true
    Require valid-user
  </Location>  
</VirtualHost>
root@host:~# systemctl reload apache2

Um sicherzustellen, dass die Webserver-Konfiguration den aktuellen Sicherheitsstandards entspricht, informieren Sie sich bitte z.B. bei Mozilla, dem DFN-CERT, der DFN-PKI oder SSL LABS. Das letztgenannte Portal bietet auch einen Online-Test der Webserver-Konfiguration an.

Ergänzende Hinweise

  • Zuletzt geändert: vor 4 Jahren