Die NetMan Knowledgebase


Tags HAN.V5

Einbindung von Shibboleth in HAN 5

Hinweise zur Einbindung des Shibboleth SP in HAN
Grundlagen und Änderungen ab der Version 5.2.2

Voraussetzungen:

HAN benutzt für die Bereitstellung von HTTPS basierten Webseiten ein Wildcard SSL Zertifikat. Dies hat zur Konsequenz, dass alle Webseiten, die über HTTPS bereitgestellt werden, im DNS Namen ein DNS-Präfix benötigen, damit das Zertifikat gültig ist. Für alle Anmeldeseiten ist fest hinterlegt, dass dieses Präfix "login" ist. Für die Integration von Shibboleth wurde deshalb festgelegt, dass der Service Provider über das Präfix "sp" erreicht wird. Der SP muss dementsprechend als sp. registriert werden.
Für den HAN Demoserver mit dem FQDN demo.hh-han.com wäre dies dann sp.demo.hh-han.com.

Die in HAN verwendeten Konfigurationsdateien gehen von dieser Voraussetzung aus!

Integration des SP in HAN

Die Integration des SP in HAN erfolgt als eigener „Named Virtual Host“ im HAN Webservice (Apache). Dies ist notwendig, da für den SP ein eigenes Zertifikat benötigt wird, wenn das vorhandene Wildcard Zertifikat z.B. von der DFN-AAI nicht akzeptiert wird.

Dazu wurden die Standardkonfigurationsdateien von HAN angepasst. Dies war notwendig, da mit HAN alle Login-Komponenten nur noch über SSL erreichbar waren. Technisch wurden diese Konfigurationen alle im Kontext des vorhandenen „Virtual Host“ für SSL geladen.
Die Module werden aus der o.g. Konfiguration geladen. Da der SP jedoch selber in einem virtuellen Host konfiguriert werden muss und eine Verschachtelung von Virtual Hosts nicht zulässig ist, musste die Reihenfolge zum Laden der einzelnen Konfigurationen angepasst werden.
Zusätzlich ist es notwendig, bei der Verwendung von Shibboleth zusammen mit alternativen Anmeldemechanismen (ab Version 2.4 des Apache im Root des Webservers) die Variable „ShibCompatValidUser On“ zu setzen.

Aufbau der hanshibbolth.conf

Wenn Shibboleth verwendet wird (dies wird über die Variable USESHIBBOLETH on in der Datei variables.conf gesteuert), wird ein „Named Virtual Host“ auf den Namen sp.${SERVERNAME} erstellt, wobei ${SERVERNAME} der FQDN des HAN Servers ist.
Über die Variable ServerName sp.${SERVERNAME} wird der Name an diesen virtuellen Host gebunden. Dies sorgt dafür, dass alle Anfragen an sp. an diese Konfiguration gesendet werden und nicht an den Standard SSL Virtual Host.
Innerhalb des Virtual Hosts ist das eigene, abweichende Zertifikat hinterlegt.
Weiterhin wird innerhalb dieses Virtual Hosts das Shibboleth Modul geladen und alle virtuellen Verzeichnisse werden ebenfalls definiert.

Dieser Aufbau der Konfiguration sorgt dafür, dass alle Konfigurationsdateien immer geladen werden können und auch in Zukunft keinerlei manuelle Nacharbeiten nach Update notwendig sind. 
Bei der Erstinstallation muss lediglich die Datei hanshibbolth.conf angepasst werden, die aber auch bei Updates nicht überschrieben wird.

HAN unterstützt auch die Einbindung eines SP, der nicht der o.g. Namenskonvention entspricht.

In der Datei variables-user.conf wird über die Direktive:
define USESHIBBOLETHSTANDARD on
geregelt, ob es sich um o.g. Namensstandards handelt. Wenn der SP einen abweichenden Namen hat, dann muss diese Direktive gelöscht werden!

Hinweis:

Ist diese Variable nicht gesetzt, so wird die Standard hanshibboleth.conf nicht geladen.

Abweichende Konfigurationen müssen dann über die Datei user.conf hinterlegt werden. So ist sichergestellt, dass bei Updates manuelle Anpassungen nicht überschrieben werden.

Weiterhin muss die URL für die Weiterleitung auf die Shibboleth Anmeldung angepasst werden. Der Standard ist hier:
define HANLoginURL https://sp.${SERVERNAME}/hanshibboleth/login.html
Bei Abweichungen muss diese Direktive ebenfalls in der Datei variables-user.conf definiert sein.

Der Servernamen in der o.g. URL muss dem Servername des SP entsprechen, sonst kann die Shibbolethkonfiguration nicht funktioneiren.


Artikel #3756 | 19.10.22 | Markus Libiseller