Installation und Basiskonfiguration des Shibboleth Identity Providers 2.0 unter SuSE Linux Enterprise Server 10 (SLES10SP1)



Version dieses Dokuments: 0.2 (letzte Änderung: 28.04.2008)
Wolfgang Hommel, Leibniz-Rechenzentrum
Kontakt-E-Mail-Adresse: hommel [at] lrz [punkt] de



Dieses Dokument beschreibt die Installation und die grundlegende Konfiguration eines Shibboleth Identity Providers (Version 2.0.0) unter SuSE Linux Enterprise Server 10 (SLES10 mit Service Pack 1). Das beschriebene Vorgehen orientiert sich stark an der Installationsanleitung im Internet2 Shibboleth-Wiki und weist primär auf Besonderheiten beim Betrieb unter SLES10SP1 hin. Darüber hinaus werden folgende Aspekte berücksichtigt:
Hinweise auf Fehler, Unklarheiten und fehlende Zwischenschritte, die zur Verbesserung dieser Anleitung beitragen, werden sehr gerne entgegen genommen!

Inhalt:
Eine komplementäre Anleitung zur Installation des Shibboleth Service Providers 2.0 findet sich hier.

Installationsanleitung IDP 2.0


Die Reihenfolge der nachfolgenden Schritte muss nicht immer streng eingehalten werden; sie stellt jedoch sicher, dass die Funktionalität der bis dahin installierten und konfigurierten Komponenten immer sofort überprüft werden kann.

Schritt 0: Vorbereitungen

Im Folgenden wird davon ausgegangen, dass eine dedizierte (ggf. virtuelle) Maschine für den Betrieb des Shibboleth Identity Providers zur Verfügung steht, so dass von einer SLES10SP1-Standardkonfiguration ausgegangen werden kann. Als DNS-Name wird idp.example.com verwendet; zur Teilnahme an einer (organisationsübergreifenden) Föderation muss die Maschine eine im Internet geroutete IP-Adresse haben. Führen Sie zur Vorbereitung folgende Schritte durch:

Schritt 1: Java-Installation und -Konfiguration

Die Shibboleth-Entwickler empfehlen den Einsatz der Java-Umgebung von Sun (Sun JDK 1.5 oder neuer), die von Novell/SuSE jedoch nicht für SLES10SP1 bereitgestellt wird:
Die folgenden Konfigurationsschritte sind Shibboleth-spezifisch und somit auch durchzuführen, wenn ein geeignetes JDK bereits eingerichtet war:

Schritt 2: Apache2-Konfiguration

Der Apache2-Webserver dient als Schnittstelle zu den Benutzern auf Port 443. Prinzipiell kann auf Apache2 verzichtet werden, so dass auch Endnutzer direkt auf Tomcat (Port 8443) zugreifen (sog. Tomcat-only-Deployment). In Version 2.0.0 des Shibboleth IDP treten dabei jedoch bekannte Probleme auf, wenn ein Benutzer über seinen Browser ein Client-Zertifikat mitschickt. Mindestens bis dieser Fehler behoben ist empfiehlt sich der ergänzende Einsatz von Apache2.
Die erzeugte Konfiguration sollte auf syntaktische Fehler und grundlegende Funktionalität überprüft werden:

Schritt 3: Tomcat5-Konfiguration

Beim Editieren der Tomcat5-Konfigurationsdateien ist generell darauf zu achten, dass dieselben Pfade zur Shibboleth-IDP-Installation wie im nächsten Schritt verwendet werden (im Beispiel: /srv/idp). Es sind folgende Teilschritte notwendig:

Schritt 4: Deployment des Shibboleth Identity Providers

Wechseln Sie in das Verzeichnis, in das Sie die Quelldistribution entpackt haben, machen Sie die Datei ant.sh ausführbar, und führen Sie sie aus:
Sie werden u.a. nach einem Installationspfad (hier: /srv/idp), dem Hostnamen (hier: idp.example.com) und einem Passwort für den Java Keystore (hier: changeit) gefragt. Diese Angaben sollten identisch zu den im vorhergehenden Schritt bei der Tomcat-Konfiguration verwendeten sein.

(Optional) Zum parallelen Betrieb mehrerer IDP-Instanzen ist dieser Prozess entsprechend oft mit unterschiedlichen Pfaden und Hostnamen zu wiederholen. Dabei empfiehlt sich, pro Instanz auch ein eigenes Installationsverzeichnis zu verwenden, da die Einstellungen dort abgespeichert werden, so dass nach Veränderungen, z.B. bzgl. des Corporate Design der IDP-Webseiten, ein einfaches Re-Deployment ermöglicht wird.

Das ausgeführte Shibboleth-Installationsskript legt das Verzeichnis /srv/idp an und hinterlegt in /srv/idp/war die Datei idp.war, die von Tomcat verwendet werden soll:
(Optional) Beim parallelen Betrieb mehrerer IDP-Instanzen kopieren Sie die Datei in das jeweilige appBase-Verzeichnis (vgl. Schritt 3).

Sofern die Installation bislang als Benutzer root durchgeführt wurde, ist sicherzustellen, dass der Benutzer tomcat Schreibberechtigung auf das Shibboleth-Logfile-Verzeichnis bekommt:
Mittels rctomcat5 restart sollte Tomcat nun gestartet werden. Überprüfen Sie die Protokolldateien im Verzeichnis /var/log/tomcat5/base auf eventuell vorhandene Fehlermeldungen: Der Start muss fehlerfrei, d.h. ohne Auftreten von Java-Exceptions ablaufen. Gehen Sie allen Fehlermeldungen nach und beseitigen Sie deren Ursachen; häufige Probleme umfassen:
Sobald keine Fehler mehr auftreten, lassen Sie Tomcat beim Booten automatisch starten: chkconfig -a tomcat5

(Optional) Insbesondere im Hinblick auf ein mögliches Tomcat-only-Deployment kann es erwünscht sein, den vom Shibboleth-Installationsskript erzeugten Java Keystore, der ein selbstsigniertes Zertifikat enthält, durch einen Java Keystore mit Ihrem DFN-PKI-Zertifikat zu ersetzen. Ersetzen Sie hierzu die Datei /srv/idp/credentials/idp.jks durch einen Java-Keystore, der Ihr DFN-PKI-Zertifikat, den zugehörigen Private Key und die DFN-PKI CA Chain enthält. Um den Private Key in den Keystore zu importieren, können Sie z.B. dieses Tool verwenden. Die übrigen Zertifikate können mit dem im JDK enthaltenen Werkzeug keytool importiert werden.


Schritt 5: Konfiguration des Shibboleth Identity Providers: Metadaten

Zur Teilnahme an einer oder mehreren Föderationen ist das Einbinden der jeweiligen Metadaten erforderlich:

Schritt 6: Konfiguration des Shibboleth Identity Providers: Benutzer-Authentifizierung

Im Unterschied zu früheren Versionen ist der Shibboleth IDP 2.0 nicht mehr auf externe Komponenten zur Benutzerauthentifizierung angewiesen. Für Einrichtungen, die nicht bereits ein anderes Web Single Sign-On Verfahren einsetzen, bietet es sich deshalb an, der Einfachheit halber auf dieses neue Shibboleth-Bordmittel zurückzugreifen. Im Folgenden wird exemplarisch gezeigt, wie eine LDAP-basierte Authentifizierung der Benutzer eingerichtet werden kann:

Schritt 7: Konfiguration des Shibboleth Identity Providers: Erster Funktionstest

Ihr Shibboleth Identity Provider sollte nun bereits dazu in der Lage sein, Benutzer zu authentifizieren und damit ein organisationsübergreifendes Web Single Sign-On zu ermöglichen. Um dies auszuprobieren, können Sie Ihren IDP selbst bei TestShib2 registrieren:
Das Sicherstellen dieser Funktionalität ist die Basis für alle weiteren Konfigurationsmaßnahmen. Gehen Sie eventuell auftretenden Fehlern auf jeden Fall nach! Einige Beispiele:

Schritt 8: Konfiguration des Shibboleth Identity Providers: Corporate Design

Das Formular zur Eingabe von Benutzername und Passwort kann durch Editieren der Datei login.jsp (im Verzeichnis /srv/www/tomcat5/base/webapps/idp bzw. im Verzeichnis /resources/webpages der Shibboleth IDP Quelltextdistribution an eigene Designvorgaben angepasst werden. Die anderen .jsp-Dateien in diesem Verzeichnis sind nur in Server-Fehlerfällen relevant und sollten zumindest um geeignete Kontaktinformationen angereichert werden.


Schritt 9: Konfiguration des Shibboleth Identity Providers: Attribute-Resolver

Neben der Benutzerauthentifizierung ist das Bereitstellen von Benutzerattributen die zweite wichtige Aufgabe eines Shibboleth Identity Providers. Im Folgenden wird exemplarisch gezeigt, wie Benutzerattribute von einem LDAP-Server übernommen werden können:

Schritt 10: Konfiguration des Shibboleth Identity Providers: Attribute-Filter

Während in attribute-resolver.xml festgelegt wird, welche Attribute prinzipiell über Benutzer bekannt sind, wird über attribute-filter.xml festgelegt, welche Attribute welcher Benutzer an welche Shibboleth Service Provider übermittelt werden dürfen. Es empfiehlt sich, zusammen mit dem zuständigen Datenschutzbeauftragten eine Default-Policy festzulegen, die vorgibt, welche Benutzerattribute an alle Service Provider herausgegeben werden dürfen. Falls dazu beispielsweise die Attribute eduPersonEntitlement und eduPersonAffiliation gehören sollen, könnte folgende AttributeFilterPolicy angelegt werden:
<AttributeFilterPolicy id="DefaultPolicy">
    <PolicyRequirementRule xsi:type="basic:ANY" />
    <AttributeRule attributeID="eduPersonEntitlement"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule>
    <AttributeRule attributeID="eduPersonAffiliation"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule>       
</AttributeFilterPolicy>

Das Zusammenspiel von attribute-resolver.xml und attribute-filter.xml kann mit dem Kommandozeilenwerkzeug AACLI getestet werden. Nach dem Aufruf von
/srv/idp/bin/aacli.sh --configDir=/srv/idp/conf/ --principal=test --requester=https://sp.testshib.org/
wird angezeigt, welche Attribute des Benutzers test an den TestShib2 Service Provider übermittelt werden würden.


Herzlichen Glückwunsch! Damit ist Ihr Shibboleth Identity Provider installiert und grundlegend konfiguriert! Falls Sie Probleme gefunden haben, die hier nicht beschrieben sind, oder Ihnen Schritte gefehlt haben, wenden Sie sich bitte per E-Mail an die ganz oben angegebene Adresse - vielen Dank!

Weitere Anmerkungen zum Betrieb mehrerer IDP-Instanzen auf einer Maschine

Die Verwendung von JAAS hat den Nachteil, dass zur Benutzerauthentifizierung nur eine einzige, gemeinsame Konfiguration für alle IDP-Instanzen einer JVM (hier: der ganze Tomcat-Server) verwendet werden kann. Beim Hosting von IDPs, die Benutzer z.B. gegen verschiedene LDAP-Server authentifizieren sollen, kann deshalb alternativ wie unter Shibboleth 1.3 auf Tomcat-Realms zurückgegriffen werden:

Durch diese Login-Config wird dasselbe Anmeldeformular verwendet, das vorher bereits für JAAS konfiguriert wurde. Die geänderte Konfiguration kann nach einem Tomcat-Neustart getestet werden.

Installationsanleitung ARPViewer 2.0

Das vom SWITCH entwickelte IDP-Plugin ARPViewer kann u.a. dazu verwendet werden, jedem Benutzer
Der Einsatz dieses Werkzeugs unterstützt somit die grundlegende datenschutzrechtliche Anforderung, dass personenbezogene Daten nur mit Zustimmung des Benutzers verarbeitet werden dürfen. Nachfolgend wird die Installation in Ergänzung zur oben beschriebenen IDP-Konfiguration beschrieben.

1. Vorbereitungen

2. MySQL-Datenbank bereitstellen

3. Tomcat5-Konfiguration anpassen

4. Apache-Konfiguration anpassen

5. Deployment

6. Anpassen der ARPViewer-Konfigurationsdateien

7. Anpassen der Shibboleth-IDP-Konfigurationsdateien

8. Testen



Impressum, a2822bj