Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:shibslohttpd:solution [2015/12/09 11:11] – Schreiterer, Frankde:shibslohttpd:solution [2015/12/09 11:13] (aktuell) – [Anwendungsszenario mixedLazy] Schreiterer, Frank
Zeile 20: Zeile 20:
   - good \\ wenn keine Aktion notwendig ist.   - 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 den Nutzer kaum wahrnehmbar sein dürfte.+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 ===== ===== Anwendungsszenario mixedLazy =====
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]]
  • Zuletzt geändert: vor 9 Jahren