Dokumentation DFN-AAI, DFN-PKI und eduroam - de:shibslohttpd

checkerscript

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T10:18:26+00:00

2015/12/09 08:30		aktuell
Zeile 1:		Zeile 1:
	====== Prüfscript ======		====== Prüfscript ======

-	Es handelt sich um eine Implementierung auf Basis von [[https://php.net\|PHP]] und [[http://memcached.org\|memcached]]. Das Skript wird unter [[http://www.gnu.org/licenses/gpl-3.0\|GPLv3]] veröffentlicht. Bitte beachten Sie die [[de:shibslohttpd:limitations#voraussetzungen]].	+	Es handelt sich um eine Implementierung auf Basis von [[https://php.net\|PHP]] und [[http://memcached.org\|memcached]]. Das Skript wird unter [[http://www.gnu.org/licenses/gpl-3.0\|GPLv3]] veröffentlicht. Bitte beachten Sie die [[de:shibslohttpd:limitations#voraussetzungen\|Voraussetzungen]].

	<file php shibchecker.php>		<file php shibchecker.php>

configuration

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T09:48:35+00:00

2015/12/09 10:32		aktuell
Zeile 4:		Zeile 4:
	Für alle Anwendungsszenarien muss die [[de:shibslohttpd:configuration:all\|allgemeine Konfiguration]] durchgeführt werden.		Für alle Anwendungsszenarien muss die [[de:shibslohttpd:configuration:all\|allgemeine Konfiguration]] durchgeführt werden.

-	Man beachte, dass sich die Konfigurationselemente von Apache 2.2 nach Apache 2.4 geändert haben, siehe z.B. [[https://www.switch.ch/aai/support/presentations/techupdate-2014/12_Apache_24_vs_22.pdf]], [[https://www.switch.ch/aai/guides/sp/access-rules/]] und [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig]].	+	Alle Konfigurationen sind für Apache 2.4. Man beachte, dass sich die Konfigurationselemente von Apache 2.2 nach Apache 2.4 geändert haben, siehe z.B. [[https://www.switch.ch/aai/support/presentations/techupdate-2014/12_Apache_24_vs_22.pdf]], [[https://www.switch.ch/aai/guides/sp/access-rules/]] und [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig]].

-	Alle Konfigurationen sind für Apache 2.4.

functioning

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T10:17:56+00:00

2015/12/09 11:17		aktuell
Zeile 27:		Zeile 27:
	- Im Context „lazy“ gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden sind, was eine gültige Anfrage sein muss. Hier wird als Rückgabeparameter „doLogin“ geliefert. Es liegt bei der Administration, auf diesen Zustand mit einer RewriteRule zum Login zu reagieren, falls die Anwendung nicht selbsttätig zum Shibboleth-Login weiter leitet. Erfolgt keine Weiterleitung zum Login, so entsteht hier eine Sicherheitslücke, da dann eine ungewollte Anwendungs-Session eingeschleust werden kann!		- Im Context „lazy“ gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden sind, was eine gültige Anfrage sein muss. Hier wird als Rückgabeparameter „doLogin“ geliefert. Es liegt bei der Administration, auf diesen Zustand mit einer RewriteRule zum Login zu reagieren, falls die Anwendung nicht selbsttätig zum Shibboleth-Login weiter leitet. Erfolgt keine Weiterleitung zum Login, so entsteht hier eine Sicherheitslücke, da dann eine ungewollte Anwendungs-Session eingeschleust werden kann!
	- Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sicher gestellt werden, dass zur Shib-Session-ID die korrekte Anwendungs-Session zugeordnet wird. Hier wird als Rückgabeparameter „doAppSession“ geliefert. \\ Auf diesen Zustand muss die Administration reagieren, sonst besteht die Gefahr, dass ein Cookie einer vorherigen Session der Anwendung eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungs-Session in den Variablen für das Prüfskript zur Verfügung gestellt werden. Hierzu bestehen zwei Möglichkeiten:		- Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sicher gestellt werden, dass zur Shib-Session-ID die korrekte Anwendungs-Session zugeordnet wird. Hier wird als Rückgabeparameter „doAppSession“ geliefert. \\ Auf diesen Zustand muss die Administration reagieren, sonst besteht die Gefahr, dass ein Cookie einer vorherigen Session der Anwendung eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungs-Session in den Variablen für das Prüfskript zur Verfügung gestellt werden. Hierzu bestehen zwei Möglichkeiten:
-	- Es ist möglich, die Session mittels einer Umleitung auf ein zusätzliches Skript zu erzeugen (funktioniert bei PHP), was zu bevorzugen ist, oder falls dies nicht möglich ist	+	- Es ist möglich, die Session mittels einer Umleitung auf ein zusätzliches Skript zu erzeugen (funktioniert bei PHP), was zu bevorzugen ist, oder falls dies nicht möglich ist
-	- am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen, der einmalig für den Reload der Seite sorgt.	+	- am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen, der einmalig für den Reload der Seite sorgt.

	Siehe auch: [[de:shibslohttpd:configuration\|Konfigurationsbeispiele]]		Siehe auch: [[de:shibslohttpd:configuration\|Konfigurationsbeispiele]]

helperscripts

Anonymous (anonymous@undisclosed.example.com) — 2019-02-28T11:25:02+00:00

2015/12/09 11:37		aktuell
Zeile 102:		Zeile 102:
	// See function LogoutNotification below		// See function LogoutNotification below

-	elseif (!empty($HTTP_RAW_POST_DATA)) {	+	elseif (!empty(file_get_contents("php://input"))) {
	// Set SOAP header		// Set SOAP header
	$server = new SoapServer('https://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'].'/LogoutNotification.wsdl');		$server = new SoapServer('https://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'].'/LogoutNotification.wsdl');

introduction

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T11:01:46+00:00

2015/12/09 12:00		aktuell
Zeile 32:		Zeile 32:
	[[de:shibslohttpd:solution#anwendungsszenario_mixedlazy\|mixedLazy:]]\\		[[de:shibslohttpd:solution#anwendungsszenario_mixedlazy\|mixedLazy:]]\\
	Die Authentifizierung erfolgt anwendungsgesteuert nach Erfordernis. Neben der Authentifizierung gegen Shibboleth kann auch gegen andere Mechanismen authentifiziert werden.		Die Authentifizierung erfolgt anwendungsgesteuert nach Erfordernis. Neben der Authentifizierung gegen Shibboleth kann auch gegen andere Mechanismen authentifiziert werden.
-
-	===== Notwendiger Datenspeicher =====
-	Grundsätzlich empfiehlt sich den Einsatz eines persistenten Speichers, am besten einer Datenbank, um dauerhaft den Zusammenhang zwischen Shib-Session-ID und Anwendungs-Session zu speichern. Prinzipiell kann hier auch memcached eingesetzt werden, aber es gehen bei einem Reboot oder Neustart des Dienstes die Beziehung zwischen Shib-Session-ID und der Anwendungs-Session sowie die Ids der Anwendungs-Session zur Duplikatsprüfung bei „mixedLazy“ verloren.
-
-	Die gespeicherten Einträge sollten nach einer Zeitspanne, die in Abhängigkeit der Bereinigung von inaktiven Anwendungs-Sessions und der Session-Lifetime der Shibboleth-Session gewählt sein muss, entfernt werden, was bei memcached direkt über einen Parameter und an einer Datenbank z.B. direkt in der Datenbank über Events geregelt werden kann. Auch der Einsatz von zeitgesteuert aufgerufenen Skripten ist denkbar.
-
-	Das [[de:shibslohttpd:checkerscript\|Prüfskript]] ist mit memcached implementiert, das der Aufwand für Anwendungsbetreuer gegenüber einer Datenbank wesentlich geringer ist.

	Weiter zu [[de:shibslohttpd:solution\|Lösung]]		Weiter zu [[de:shibslohttpd:solution\|Lösung]]

limitations

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T09:48:00+00:00

2015/12/09 08:31		aktuell
Zeile 12:		Zeile 12:
	* php5-memcache nicht php5-memcached!!!\\		* php5-memcache nicht php5-memcached!!!\\
	* shibd Version >= 2.5\\		* shibd Version >= 2.5\\
-	* Apache-Webserver Version >= 2.2, empfohlen 2.4 \\	+	* Apache-Webserver Version >= 2.2, empfohlen 2.4 \\ mit mod_rewrite und mod_headers aktiviert

	===== Todo =====		===== Todo =====

removallogout

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T08:14:46+00:00

2015/12/09 09:14		aktuell
Zeile 7:		Zeile 7:
	<code xml shibboleth2.xml>		<code xml shibboleth2.xml>
	…		…
-	<Errors supportContact="foobar@domain.org"	+	<Errors supportContact="foobar@beispiel-uni.de"
	logoLocation="/shibboleth-sp/logo.jpg"		logoLocation="/shibboleth-sp/logo.jpg"
	styleSheet="/shibboleth-sp/main.css"/>		styleSheet="/shibboleth-sp/main.css"/>

solution

Anonymous (anonymous@undisclosed.example.com) — 2015-12-09T10:13:44+00:00

2015/12/09 11:12		aktuell
Zeile 28:		Zeile 28:
	Erfolgt die Authentifizierung jedoch über Shibboleth, so ist es zwar nicht möglich, eine Anmeldung mit einer bestehenden Session von vorn herein zu unterbinden, aber es kann eine Duplikatsprüfung vorgenommen werden. Das Prüfskript schaltet danach in den Modus „lazy“.		Erfolgt die Authentifizierung jedoch über Shibboleth, so ist es zwar nicht möglich, eine Anmeldung mit einer bestehenden Session von vorn herein zu unterbinden, aber es kann eine Duplikatsprüfung vorgenommen werden. Das Prüfskript schaltet danach in den Modus „lazy“.

-	In der Duplikatsprüfung wird untersucht, ob die ID der gelieferten Anwendungs-Session schon einmal an Hand der vorhanden Datensätze Verwendung fand, was bei entsprechender Konfiguration der Bereinigung quasi den gleichen Schutz bietet, wie das grundsätzliche Verbot, sich mit einer bestehenden Anwendungs-Session anzumelden. Der Mechanismus zur Vorabprüfung mittels sessionHook auf eine bestehende Anwendungs-Session kann und darf hier nicht durchgeführt werden.	+	In der Duplikatsprüfung wird untersucht, ob der Identifiert der gelieferten Anwendungs-Session schon einmal an Hand der vorhanden Datensätze Verwendung fand, was bei entsprechender Konfiguration der Bereinigung quasi den gleichen Schutz bietet, wie das grundsätzliche Verbot, sich mit einer bestehenden Anwendungs-Session anzumelden. Der Mechanismus zur Vorabprüfung mittels sessionHook auf eine bestehende Anwendungs-Session kann und darf hier nicht durchgeführt werden.

	Weiter zu [[de:shibslohttpd:functioning\|Wirkungsweise]]		Weiter zu [[de:shibslohttpd:functioning\|Wirkungsweise]]