Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:shibslohttpd:introduction [2015/12/09 11:06] – [Notwendiger Datenspeicher] Schreiterer, Frankde:shibslohttpd:introduction [2015/12/09 12:01] (aktuell) Schreiterer, Frank
Zeile 12: Zeile 12:
 Durch den Besitz einer (gültigen) Anwendungs-Session  ist es möglich, ohne eine gültige Shibboleth-Authentifizierung eine Webanwendung zu verwenden bzw. eine alte Anwendungs-Session einzuschleusen. Ist beispielsweise ein Nutzer gesperrt worden und die Shibboleth-Session am ServiceProvider wurde beendet, so besteht immer noch die Anwendungs-Session  und die Webanwendung kann weiterhin genutzt werden. Durch den Besitz einer (gültigen) Anwendungs-Session  ist es möglich, ohne eine gültige Shibboleth-Authentifizierung eine Webanwendung zu verwenden bzw. eine alte Anwendungs-Session einzuschleusen. Ist beispielsweise ein Nutzer gesperrt worden und die Shibboleth-Session am ServiceProvider wurde beendet, so besteht immer noch die Anwendungs-Session  und die Webanwendung kann weiterhin genutzt werden.
  
-===== 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 33: Zeile 32:
 **[[de:shibslohttpd:solution#anwendungsszenario_mixedlazy|mixedLazy:]]**\\  **[[de:shibslohttpd:solution#anwendungsszenario_mixedlazy|mixedLazy:]]**\\ 
 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 ===== 
-Grundsätzlich empfiehlt sich den Einsatz eines persistenten Speichers, am besten einer Datenbank, um dauerhaft den Zusammenhang zwischen Shib-Session-ID und Anwendungs-Session zu speichern. Prinzipiell kann hier auch memcached eingesetzt werden, aber es gehen bei einem Reboot oder Neustart des Dienstes die Beziehung zwischen Shib-Session-ID und der Anwendungs-Session sowie die Ids der Anwendungs-Session zur Duplikatsprüfung bei „mixedLazy“ verloren. 
- 
-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. 
- 
-Das [[de:shibslohttpd:checkerscript|Prüfskript]] ist mit memcached implementiert, das der Aufwand für Anwendungsbetreuer gegenüber einer Datenbank wesentlich geringer ist. 
  
 Weiter zu [[de:shibslohttpd:solution|Lösung]] Weiter zu [[de:shibslohttpd:solution|Lösung]]
  
  • Zuletzt geändert: vor 8 Jahren