Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:shibslohttpd [2015/12/08 14:25] – Schreiterer, Frank | de:shibslohttpd [2015/12/08 15:38] – Schreiterer, Frank | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
====== Kopplung der Anwendungs-Session an die Shibboleth-Session am Apache-Webserver ====== | ====== Kopplung der Anwendungs-Session an die Shibboleth-Session am Apache-Webserver ====== | ||
- | ===== Ausgangssituation ===== | + | Die hier beschriebene Lösung beschäftigt sich mit dem Problem, |
- | Viele Web-Anwendungen verwenden eine eigene Anwendungs-Session , die in der Regel in einem oder mehreren Cookies gespeichert werden, und authentifizieren gegen Shibboleth. Dabei ist die Anwendung selbst nicht in der Lage, die Session selbst auf Veränderungen zu prüfen, z.B. mit einem Remote-User zu assoziieren und so gegen Veränderungen zu schützen. | + | |
- | + | ||
- | Besitzt die Anwendung ein Session-Management, | + | |
- | Anmerkung: Man kann sich aber durchaus überlegen, einen Grundschutz zu implementieren, | + | |
- | + | ||
- | ===== Problem | + | |
- | Durch den Besitz einer (gültigen) Anwendungs-Session | + | |
- | + | ||
- | ===== Herausforderung zur Lösung ===== | + | |
- | Es muss eine Lösung gefunden werden, die es einem Anwender nicht ermöglicht, | + | |
- | * eine abgelaufene oder auch mutwillig veränderte Anwendungs-Session (wieder) zu verwenden, | + | |
- | * die Shibboleth-Session zu manipulieren und weiter | + | |
- | + | ||
- | Voraussetzung hierzu ist, dass | + | |
- | * der Zusammenhang zwischen Shibboleth-Session und Anwendungs-Session hergestellt wird, | + | |
- | + | ||
- | damit die missbräuchliche Nutzung von Anwendungs- | + | |
- | + | ||
- | ===== Anwendungsszenarien ===== | + | |
- | Anwendungen können auf drei verschiedenen Arten mit Shibboleth geschützt werden: | + | |
- | + | ||
- | **normal: | + | |
- | Die Anwendung erfordert immer eine Authentifizierung mit Shibboleth (Standardfall). | + | |
- | + | ||
- | **lazy:**\\ | + | |
- | Die Authentifizierung gegen Shibboleth erfolgt anwendungsgesteuert nach Erfordernis. Shibboleth bleibt aber die einzige Authentifizierungsmöglichkeit. | + | |
- | + | ||
- | **mixedLazy: | + | |
- | Die Authentifizierung erfolgt anwendungsgesteuert nach Erfordernis. Neben der Authentifizierung gegen Shibboleth kann auch gegen andere Mechanismen authentifiziert werden. | + | |
- | + | ||
+ | * [[de: |