Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
de:shibslohttpd:solution [2015/12/08 15:02] – 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 Parametern erzeugt vier Rückgabewerte | + | Der Aufruf der RewriteMap mit den erforderlichen |
- 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 | ||
Zeile 16: | Zeile 16: | ||
- 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 | + | - doLogin – nur bei Anwendungsszenario „lazy“ \\ Am Webserver |
- | - doAppSession \\ muss am Webserver mit einer RewriteRule die Initialisierung der Anwendungs-Session sicher | + | - doAppSession \\ Am Webserver |
- 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, | + | 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 | + | ===== 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. | 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. | ||
Zeile 29: | Zeile 29: | ||
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 | 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: | ||