Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibslohttpd:solution [2015/12/08 14:54] – angelegt Schreiterer, Frank
+++ de:shibslohttpd:solution [2015/12/09 11:13] (aktuell) – [Anwendungsszenario mixedLazy] Schreiterer, Frank
@@ Zeile 1: / Zeile 1: @@
 ====== Lösung ======
-===== Anwendungsszenarien „normal“ und „lazy“ =====
+===== Anwendungsszenarien normal und lazy =====
-Am Apache-Webserver selbst wird eine RewriteMap konfiguriert, die ein externes Programm aufruft. Alle Randbedingungen im Apache-Webserver direkt abzubilden, ist nahezu unmöglich, weshalb auf eine Implementierung außerhalb der Apache-Webserver-Umgebung ausgewichen wurde. Die Referenzimplementierung zum [[de:shibslohttpd:checkerscript|Prüfskript]] wurde in PHP mit memcached durchgeführt.
+Am Apache-Webserver selbst wird eine RewriteMap konfiguriert, die ein externes Programm aufruft. Alle Randbedingungen im Apache-Webserver direkt abzubilden, ist nahezu unmöglich, weshalb auf eine [[de:shibslohttpd:checkerscript|Implementierung]] außerhalb der Apache-Webserver-Umgebung ausgewichen wurde.
-Zusätzlich muss die ab dem Shibboleth-Service-Provider 2.5 verfügbare Technologie des sessionHook [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPInterestingFeatures#NativeSPInterestingFeatures-Post-LoginHooksandAttributeChecking]] verwendet werden. Damit kann beim Login ein zusätzlicher Request erzeugt werden, der benötigt wird, um zu erkennen, ob bereits eine Anwendungs-Session vorhanden ist.
+Zusätzlich muss die ab dem Shibboleth-Service-Provider 2.5 verfügbare Technologie des sessionHook [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPInterestingFeatures#NativeSPInterestingFeatures-Post-LoginHooksandAttributeChecking]] verwendet werden. Damit kann beim Login ein zusätzlicher Request erzeugt werden, der benötigt wird, um zu erkennen, ob bereits eine Anwendungs-Session vorhanden ist - Skript siehe [[de:shibslohttpd:helperscripts#checkerphp|checker.php]].
 Die RewriteMap wird mit Parametern vom Shibboleth-Deamon und auch vom Webserver aufgerufen. Parameter des Shibboleth-Deamons stehen allerdings nicht zu jeder Zeit über Environment-Variablen zur Verfügung, weshalb eine Konfiguration mit ShibUseHeaders on erfolgen muss. Mögliche Probleme werden unter https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSpoofChecking
 erörtert, jedoch wird vom Shibboleth-Deamon ein HeaderSpoofing mit dem Leeren der Shibboleth-Session quittiert, sodass die Gefahr als eher gering eingestuft werden kann. Es wird jedoch dringend empfohlen, in den Shibboleth nachgelagerten Anwendungen auf Environment-Variablen zuzugreifen.
+Der Aufruf der RewriteMap mit den erforderlichen [[de:shibslohttpd:functioning|Parametern]] erzeugt vier Rückgabewerte
+  - doLogout, wenn versucht wurde, \\
+    - mit einer einer Anwendungs-Session ohne Shibboleth-Session zuzugreifen
+    - die Anwendungs-Session während der Sitzung zu verändern
+    - zusätzlich eine weitere Anwendungs-Session und / oder Shibboleth-Cookie einzuschleusen
+    - die Shibboleth-Session während der Sitzung zu verändern
+  - doLogin – nur bei Anwendungsszenario „lazy“ \\ Am Webserver muss mit einer RewriteRule auf das Login umgeleitet werden, sonst ist das Einschleusen einer vorhanden Anwendungs-Session möglich! Beim Login muss die Anwendungs-Session erzeugt werden! [[de:shibslohttpd:functioning#sonderzustaende|Siehe auch Wirkungsweise Prüfskript – Sonderzustände Punkt 1]]
+  - doAppSession \\ Am Webserver muss mit einer RewriteRule die Initialisierung der Anwendungs-Session sicher gestellt werden. Da beim Login noch keine Anwendungs-Session vorhanden sein darf ist es möglich, dass unmittelbar nach dem erfolgreichen Shibboleth-Login noch keine Anwendungs-Session für die RewriteRule existiert, aber das Cookie schon existiert und somit verändert werden könnte, [[de:shibslohttpd:functioning#sonderzustaende|siehe auch Wirkungsweise Prüfskript – Sonderzustände Punkt 2]]
+  - good \\ wenn keine Aktion notwendig ist.
+Mit Hilfe der RewriteMap wird das Prüfskript bei jeder Anfrage an den Webserver ausgeführt. Beim Login beträgt die durch das Prüfskript zusätzlich verursachte Ausführungszeit bis zu 20 Millisekunden, danach benötigen die Prüfungen i.d.R. im Bereich von unter 0,5 Millisekunden, was in der Praxis für die Nutzer kaum wahrnehmbar sein dürfte.
+===== Anwendungsszenario mixedLazy =====
+Das Anwendungsszenario „mixedLazy“ lässt neben Shibboleth die Verwendung von weiteren Authentifizierungsmethoden zu. Damit ist es mit diesem Mechanismus nicht möglich, die Anwendung bei nicht-Shibboleth-Authentifizierung gegen die Verwendung einer vorhanden oder manipulierten Anwendungs-Session zu schützen. Hier muss man sich, wie bisher auch, auf die Schutzmechanismen der Anwendung verlassen.
+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 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]]