Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:shibslohttpd:introduction [2015/12/08 14:50] – Schreiterer, Frank | de:shibslohttpd:introduction [2015/12/09 12:01] (aktuell) – Schreiterer, Frank | ||
---|---|---|---|
Zeile 3: | Zeile 3: | ||
===== Ausgangssituation ===== | ===== Ausgangssituation ===== | ||
- | 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 | + | Viele Web-Anwendungen verwenden eine eigene Anwendungs-Session, |
- | Besitzt die Anwendung ein Session-Management, | + | Besitzt die Anwendung ein Session-Management, |
- | Anmerkung: Man kann sich aber durchaus überlegen, einen Grundschutz zu implementieren, | + | |
+ | Anmerkung: | ||
===== Problem ===== | ===== Problem ===== | ||
Durch den Besitz einer (gültigen) Anwendungs-Session | 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, | 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, | * eine abgelaufene oder auch mutwillig veränderte Anwendungs-Session (wieder) zu verwenden, | ||
Zeile 24: | Zeile 24: | ||
Anwendungen können auf drei verschiedenen Arten mit Shibboleth geschützt werden: | Anwendungen können auf drei verschiedenen Arten mit Shibboleth geschützt werden: | ||
- | **normal: | + | **[[de: |
Die Anwendung erfordert immer eine Authentifizierung mit Shibboleth (Standardfall). | Die Anwendung erfordert immer eine Authentifizierung mit Shibboleth (Standardfall). | ||
- | **lazy: | + | **[[de: |
Die Authentifizierung gegen Shibboleth erfolgt anwendungsgesteuert nach Erfordernis. Shibboleth bleibt aber die einzige Authentifizierungsmöglichkeit. | Die Authentifizierung gegen Shibboleth erfolgt anwendungsgesteuert nach Erfordernis. Shibboleth bleibt aber die einzige Authentifizierungsmöglichkeit. | ||
- | **mixedLazy: | + | **[[de: |
Die Authentifizierung erfolgt anwendungsgesteuert nach Erfordernis. Neben der Authentifizierung gegen Shibboleth kann auch gegen andere Mechanismen authentifiziert werden. | Die Authentifizierung erfolgt anwendungsgesteuert nach Erfordernis. Neben der Authentifizierung gegen Shibboleth kann auch gegen andere Mechanismen authentifiziert werden. | ||
- | ===== Notwendiger Datenspeicher ===== | + | Weiter |
- | Grundsätzlich empfiehlt sich den Einsatz eines persistenten Speichers, am besten einer Datenbank, um dauerhaft den Zusammenhang zwischen Shib-Session-ID und Anwendungs-Session | + | |
- | + | ||
- | Die gespeicherten Einträge sollten nach einer Zeitspanne, die in Abhängigkeit der Bereinigung von inaktiven Anwendungs-Sessions und der Session-Lifetime der Shibboleth-Session gewählt sein muss, entfernt werden, was bei memcached direkt über einen Parameter und an einer Datenbank z.B. direkt in der Datenbank über Events geregelt werden kann. Auch der Einsatz von zeitgesteuert aufgerufenen Skripten ist denkbar. | + | |