| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
| de:shibslohttpd:solution [2015/12/09 08:26] – Schreiterer, Frank | de:shibslohttpd:solution [2015/12/09 11:11] – 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. |
| |