Vorbereitung

  1. Vergewissern Sie sich vor dem Anlegen eines neuen Shibboleth Service Providers, dass die zu schützenden Webseiten oder die zu schützende Webanwendung mit einem Shibboleth Service Provider überhaupt geschützt werden kann. Fragen Sie im Zweifelsfall bei den Entwicklern der Webseiten oder der Webanwendung nach.

  2. Informieren Sie sich über das verteilte und föderative Authentisierungs- und Autorisierungssystem Shibboleth. Machen Sie sich klar, was eine Föderation ist, wie ein Shibboleth Identity Provider und ein Shibboleth Service Provider die Authentisierung und Autorisierung von Benutzern realisieren und wie ein Shibboleth Service Provider den Zugriff auf  Webseiten und Webanwendungen schützt (siehe https://www.aai.dfn.de/) .

  3. Informieren Sie sich über die verschiedenen Föderationen der DFN-AAI und die Teilnahmebedingungen für Ihren Service Provider (siehe https://www.aai.dfn.de).

  4. Beachten Sie, dass der Shibboleth Service Provider ausschließlich mit einem Apache-Webserver zusammenarbeitet. Für alternative SAML-Implementierungen (z.B. OpenAthens,  OpenAM, SimpleSAMLPhp, usw.) können wir keinen Support geben.

  5. Erweitern Sie Ihre Firewall-Einstellungen für die beiden Netzwerkadresse der DFN-AAI:

    • Metadatenverwaltung: 194.95.245.77 / 2001:638:d:c104::77,
    • WAYF-Server: 194.95.245.78 / 2001:638:d:c104::78 (nur wenn Ihr SP den WAFY-Server verwenden soll).
  6. Vergewissern Sie sich ob zum Schutz der Webseiten oder der Webanwendung Autorisierungsattribute verwendet werden müssen. Fragen Sie im Zweifelsfall bei den Entwicklern der Webseiten oder der Webanwendung nach, welche Autorisierungsattribute benötigt werden.

  7. Überlegen Sie sich den Benutzerkreis,  welcher Zugriff auf die mit Ihrem Service Provider geschützten Webseiten oder Webanwendungen bekommen soll.

  8. Beachten Sie, dass Sie für Ihren Service Provider ein Testsystem und ein Produktionssystem benötigen. Der Paralellbetrieb beider Systeme ist wichtig, um zukünftige Änderungen in der Kommunikation zwischen ihrem Service Provider und dem Identity Provider der Universität  zeitnah und zuverlässig umsetzen zu können.

Anbindung Ihres Test-SP

  1. Installieren Sie den Test-SP auf ihrem Testsystem und kümmern Sie sich um einen geeigneten DNS-Namen (z.B. https://dienst-test.uni-konstanz.de).

  2. Beantragen Sie für diesen DNS-Namen ein Serverzertifikat bei der CA der Uni Konstanz. Achten Sie darauf, dass Sie den Wert "Shibboleth IdP SP" für das Zertifkatsprofil auswählen.

  3. Überlegen Sie sich eine passende und eindeutige Provider-ID für Ihren Test-SP (z.B. https://dienst-test.uni-konstanz.de/shibboleth-sp ) .

  4. Beantragen Sie die Integration Ihres Test-SP in die lokale Föderation der Uni bzw. in die Testföderation der DFN-AAI. Die weitere Anbindung Ihres Test-SP erfolgt in Zusammenarbeit mit unserem Shibboleth-Team, welches sich bei Ihnen während  der Bearbeitung Ihres Antrags melden wird.

Inbetriebnahme Ihres Test-SP

  1. Verwenden Sie die folgenden Templatedateien, um ihren Test-SP zu konfigurieren:

  2. Verwenden Sie die Metadaten der DFN-AAI-Testföderation:

  3. Verwenden Sie das DFN-AAI-Zertifikat im PEM-Format zur Überprüfung der Signatur der DFN-AAI Metadaten:

  4. Verwenden Sie die folgende Templatedatei, um ihren Apache-Webserver zu konfigurieren:

  5. Verwenden Sie zum Test ihrer Konfiguration eines der beiden Testskripte:

  6. Mit diesen Testskripten können Sie testen, ob die vom Test-IDP versendeten Autorisierungsattribute bei ihrem Test-SP angekommen sind.  Benutzen Sie dazu die folgenden drei Testaccounts aus dem IDM-Testsystem:

    • shibboleth.s (Studentenaccount),
    • shibboleth.b (Bedienstetenaccount),
    • shibboleth.g (Gastaccount)
    Das Passwort für den jeweiligen Testaccount bekommen Sie vom Shibboleth-Team, ggf. muss der Testaccount noch an Ihre Anforderungen angepasst werden.

  7. Erstellen Sie die Autorisierungsregeln um den Zugriff auf das Testskript zu testen.

  8. Ändern Sie die Konfiguration Ihres Apache-Webservers und testen Sie, ob ihr Test-SP nun den Zugriff auf ihre zu schützenden Webseiten oder die zu schützende Webanwendung erfolgreich übernimmt.

  9. Testen Sie, ob ihre zu schützenden Webseiten oder Webanwendung die vom Test-IDP empfangenen Autorisierungsdaten verarbeitet.

Anbindung Ihres produktiven SP

  1. Setzen Sie nach dem Vorbild ihres Test-SP Ihren produktivem SP auf, kümmern Sie sich um einen geeigneten DNS-Namen (z.B. https://dienst.uni-konstanz.de) .

  2. Beantragen Sie für diesen DNS-Namen ein Serverzertifikat bei der CA der Uni Konstanz. Achten Sie darauf, dass Sie den Wert "Shibboleth IdP SP" für das Zertifkatsprofil auswählen.

  3. Überlegen Sie sich eine passende und eindeutige Provider-ID für Ihren produktiven SP (z.B. https://dienst.uni-konstanz.de/shibboleth-sp) .

  4. Beantragen Sie die Integration Ihres produktiven SP in die lokale Föderation der Uni bzw. in die produktiven Föderationen der DFN-AAI. Die weitere Anbindung Ihres produktiven SP erfolgt in Zusammenarbeit mit unserem Shibboleth-Team, welches sich bei Ihnen während  der Bearbeitung Ihres Antrags melden wird.

Inbetriebnahme Ihres produktiven SP

  1. Verwenden Sie die Konfigurationsdateien von ihrem Test-SP  und passen Sie diese an ihr Produktionssystem an.

  2. Verwenden Sie die Metadaten der DFN-AAI-Testföderation:

  3. Verwenden Sie das DFN-AAI-Zertifikat im PEM-Format zur Überprüfung der Signatur der DFN-AAI Metadaten:

  4. Verwenden Sie die Konfigurationsdatei für den Apache-Webserver von Ihrem Test-SP und passen Sie diese an ihr Produktionsystem an.

  5. Testen Sie den Zugriff  auf die zu schützenden Webseiten oder die zu schützende Webanwendung. Benutzen Sie dazu die folgenden drei Testaccounts aus dem IDM-Produktionsystem:

    • shibboleth.s (Studentenaccount),
    • shibboleth.b (Bedienstetenaccount),
    • shibboleth.g (Gastaccount)
    oder Ihren eigenen Account. Das Passwort für den jeweiligen Testaccount bekommen Sie vom Shibboleth-Team, ggf. muss der Testaccount noch an Ihre Anforderungen angepasst werden.

  6. Testen Sie, ob ihre zu schützenden Webseiten oder die zu schützende Webanwendung die Autorisierungsdaten verarbeitet.