Shibboleth SP

Siehe hierzu die betreffenden Seiten

• im Shibboleth Wiki und
• bei SWITCH; dort auch viele Konfigurationsbeispiele für Autorisierung und Zugriffskontrolle (Access Rules)

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/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" verifyBackup="false"/>
   </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>

Zur MetadataProvider-Konfiguration für die Produktivumgebung der DFN-AAI siehe unter Produktivbetrieb.

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. der Embedded Discovery Service zeigt nur diejenigen IdPs bzw. Einrichtungen an, welche in diesen gefilterten Metadaten enthalten sind. In shibboleth2.xml muss <Handler type=„DiscoveryFeed“ Location=„/DiscoFeed“/> aktiv sein, bitte überprüfen sie das zur Sicherheit!).

Die Whitelist wird dann folgendermaßen konfiguriert:

/etc/shibboleth/shibboleth2.xml

...
   <MetadataProvider type="XML" 
         url="http://www.aai.dfn.de/metadata/dfn-aai-idp-metadata.xml"
         validate="true" backingFilePath="dfn-aai-idp-metadata.xml" reloadInterval="3600">
      <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai.pem" verifyBackup="false" />
      <MetadataFilter type="Include">
         <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).

Weiter Beispiele für Include- und Exclude-Filter anhand von Entity Attributen siehe unter Entity Attributes.

Im folgenden zwei Beispiele für Metadata Filter, die anhand der Registration Authority (also der jeweiligen Heimatföderation) auf die eduGAIN-Metadaten angewandt werden:

Nur Identity Provider aus der SWITCHaai (CH) und ACOnet Identity Federation (AT) zulassen:

/etc/shibboleth/shibboleth2.xml

...
   <MetadataProvider type="XML" 
         url="http://www.aai.dfn.de/metadata/dfn-aai-edugain+idp-metadata.xml"
         validate="true" backingFilePath="dfn-aai-edugain+idp-metadata.xml" reloadInterval="3600">
      <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai.pem" verifyBackup="false" />
      <MetadataFilter type="Include" matcher="RegistrationAuthority">
         <registrationAuthority>http://rr.aai.switch.ch/</registrationAuthority>
         <registrationAuthority>http://eduid.at</registrationAuthority>
      </MetadataFilter>
   </MetadataProvider>
   ...

Identity Provider aus zwei fiktiven Föderationen ausschließen:

/etc/shibboleth/shibboleth2.xml

...
   <MetadataProvider type="XML" 
         url="http://www.aai.dfn.de/metadata/dfn-aai-edugain+idp-metadata.xml"
         validate="true" backingFilePath="dfn-aai-edugain+idp-metadata.xml" reloadInterval="3600">
      <MetadataFilter type="Signature" certificate="/etc/ssl/aai/dfn-aai.pem" verifyBackup="false" />
      <MetadataFilter type="Exclude" matcher="RegistrationAuthority">
         <registrationAuthority>http://xyz.qq</registrationAuthority>
         <registrationAuthority>http://zyx.ww</registrationAuthority>
      </MetadataFilter>
   </MetadataProvider>
   ...

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

(Im Folgenden eine Kurzanleitung zur Installation, eine ausführlichere finden Sie auf den Seiten 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

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!

Verifizieren Sie in der gleichen Datei, daß der Parameter this.dataSource den Wert '/Shibboleth.sso/DiscoFeed' hat damit das Zusammenspiel zwischen SP und EDS funktioniert.

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.

• 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.