| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| de:shibslohttpd:solution [2015/12/09 08:24] – Schreiterer, Frank | de:shibslohttpd:solution [2015/12/09 11:13] (aktuell) – [Anwendungsszenario mixedLazy] Schreiterer, Frank |
|---|
| ===== 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 - Skript siehe [[de:shibslohttpd:helperscripts#checkerphp|checker.php]]. | 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]]. |
| 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. | 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 Parametern erzeugt vier Rückgabewerte | Der Aufruf der RewriteMap mit den erforderlichen [[de:shibslohttpd:functioning|Parametern]] erzeugt vier Rückgabewerte |
| - doLogout, wenn versucht wurde, \\ | - doLogout, wenn versucht wurde, \\ |
| - mit einer einer Anwendungs-Session ohne Shibboleth-Session zuzugreifen | - mit einer einer Anwendungs-Session ohne Shibboleth-Session zuzugreifen |
| - zusätzlich eine weitere Anwendungs-Session und / oder Shibboleth-Cookie einzuschleusen | - zusätzlich eine weitere Anwendungs-Session und / oder Shibboleth-Cookie einzuschleusen |
| - die Shibboleth-Session während der Sitzung zu verändern | - die Shibboleth-Session während der Sitzung zu verändern |
| - doLogin – nur bei Anwendungsszenario „lazy“ \\ muss am Webserver mit einer RewriteRule auf das Login beim Anwendungsszenario „lazy“ umgeleitet werden, sonst ist das Einschleusen eine 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]] | - 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 \\ muss am Webserver mit einer RewriteRule die Initialisierung der Anwendungs-Session sicher stellen. 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]] | - 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. | - 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 ===== |
| 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]] |
| |
| |
| |