Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
de:shibslohttpd:introduction [2015/12/08 14:33] – angelegt Schreiterer, Frankde:shibslohttpd:introduction [2015/12/09 12:01] (aktuell) Schreiterer, Frank
Zeile 1: Zeile 1:
 +====== Einleitung ======
 +
 +
 ===== 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 selbst auf Veränderungen zu prüfen, z.B. mit einem Remote-User zu assoziieren und so gegen Veränderungen zu schützen.+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 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, welches robust gegen Manipulationen ist und das Session-Management Shibboleth-Variablen verwendet, so ist die geforderte Verbindung zwischen Shibboleth-Session und Anwendungs-Session gegeben und das SLO ist möglich, da die verbleibende Anwendungs-Session nach dem Logout der Shibbolet-Session nicht mehr gültig ist und somit ein erneutes Login an Shibboleth (und damit an der Anwendung) angefordert werden muss.  +Besitzt die Anwendung ein Session-Management, welches robust gegen Manipulationen ist und das Session-Management Shibboleth-Variablen verwendet, so ist die geforderte Verbindung zwischen Shibboleth-Session und Anwendungs-Session gegeben und das Single Logout (SLOist möglich, da die verbleibende Anwendungs-Session nach dem Logout der Shibboleth-Session nicht mehr gültig ist und somit ein erneutes Login an Shibboleth (und damit an der Anwendung) angefordert werden muss.  
-Anmerkung: Man kann sich aber durchaus überlegen, einen Grundschutz zu implementieren, der eine gesetze Anwendungs-Session ohne Shibboleth-Session verhindert (aufrufen der RewriteMap nur für sessionHook und den Rest der Prüfung nicht am Apache-Webserver umsetzt). Dies würde die Nutzer eventuell dazu anregen, sich auch von Anwendungen abzumelden an wechselnden Arbeitsplätzen.+ 
 +Anmerkung: \\ Man kann sich aber durchaus überlegen, einen Grundschutz zu implementieren, der eine gesetzte Anwendungs-Session ohne Shibboleth-Session verhindert (aufrufen der RewriteMap nur für sessionHook und den Rest der Prüfung nicht am Apache-Webserver umsetzt). Dies würde die Nutzer eventuell dazu anregen, sich auch von Anwendungen abzumelden an wechselnden Arbeitsplätzen.
  
 ===== Problem ===== ===== Problem =====
 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 21: 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:shibslohttpd:solution#anwendungsszenarien_normal_und_lazy|normal:]]**\\ 
 Die Anwendung erfordert immer eine Authentifizierung mit Shibboleth (Standardfall). Die Anwendung erfordert immer eine Authentifizierung mit Shibboleth (Standardfall).
  
-**lazy:**\\ +**[[de:shibslohttpd:solution#anwendungsszenarien_normal_und_lazy|lazy:]]**\\ 
 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: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. 
 +
 +Weiter zu [[de:shibslohttpd:solution|Lösung]]
 +
  • Zuletzt geändert: vor 8 Jahren