Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
de:shibslohttpd:solution [2015/12/08 14:54] – angelegt Schreiterer, Frank | de:shibslohttpd:solution [2015/12/09 11:12] – Schreiterer, Frank | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Lösung ====== | ====== Lösung ====== | ||
- | ===== Anwendungsszenarien | + | ===== Anwendungsszenarien normal und lazy ===== |
- | Am Apache-Webserver selbst wird eine RewriteMap konfiguriert, | + | Am Apache-Webserver selbst wird eine RewriteMap konfiguriert, |
- | Zusätzlich muss die ab dem Shibboleth-Service-Provider 2.5 verfügbare Technologie des sessionHook [[https:// | + | Zusätzlich muss die ab dem Shibboleth-Service-Provider 2.5 verfügbare Technologie des sessionHook [[https:// |
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:// | 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:// | ||
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 [[de: | ||
+ | - 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: | ||
+ | - 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: | ||
+ | - 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, | ||
+ | |||
+ | ===== 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, | ||
+ | |||
+ | 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 | ||
+ | |||
+ | Weiter zu [[de: | ||
+ | |||