Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
de:shibslohttpd:functioning [2015/12/09 11:17]
Schreiterer, Frank [Sonderzustände]
de:shibslohttpd:functioning [2015/12/09 11:17] (aktuell)
Schreiterer, Frank [Sonderzustände]
Zeile 27: Zeile 27:
   - Im Context „lazy“ gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden sind, was  eine gültige Anfrage sein muss. Hier wird als Rückgabeparameter „doLogin“ geliefert. Es liegt bei der Administration,​ auf diesen Zustand mit einer RewriteRule zum Login zu reagieren, falls die Anwendung nicht selbsttätig zum Shibboleth-Login weiter leitet. Erfolgt keine Weiterleitung zum Login, so entsteht hier eine Sicherheitslücke,​ da dann eine ungewollte Anwendungs-Session eingeschleust werden kann!   - Im Context „lazy“ gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden sind, was  eine gültige Anfrage sein muss. Hier wird als Rückgabeparameter „doLogin“ geliefert. Es liegt bei der Administration,​ auf diesen Zustand mit einer RewriteRule zum Login zu reagieren, falls die Anwendung nicht selbsttätig zum Shibboleth-Login weiter leitet. Erfolgt keine Weiterleitung zum Login, so entsteht hier eine Sicherheitslücke,​ da dann eine ungewollte Anwendungs-Session eingeschleust werden kann!
   - Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sicher gestellt werden, dass zur Shib-Session-ID die korrekte Anwendungs-Session zugeordnet wird. Hier wird als Rückgabeparameter „doAppSession“ geliefert. \\ Auf diesen Zustand muss die Administration reagieren, sonst besteht die Gefahr, dass ein Cookie einer vorherigen Session der Anwendung eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungs-Session in den Variablen für das Prüfskript zur Verfügung gestellt werden. Hierzu bestehen zwei Möglichkeiten:​   - Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sicher gestellt werden, dass zur Shib-Session-ID die korrekte Anwendungs-Session zugeordnet wird. Hier wird als Rückgabeparameter „doAppSession“ geliefert. \\ Auf diesen Zustand muss die Administration reagieren, sonst besteht die Gefahr, dass ein Cookie einer vorherigen Session der Anwendung eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungs-Session in den Variablen für das Prüfskript zur Verfügung gestellt werden. Hierzu bestehen zwei Möglichkeiten:​
-  ​- Es ist möglich, die Session mittels einer Umleitung auf ein zusätzliches Skript zu erzeugen (funktioniert bei PHP), was zu bevorzugen ist, oder falls dies nicht möglich ist +    ​- Es ist möglich, die Session mittels einer Umleitung auf ein zusätzliches Skript zu erzeugen (funktioniert bei PHP), was zu bevorzugen ist, oder falls dies nicht möglich ist 
-  - am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen,​ der einmalig für den Reload der Seite sorgt.+    - am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen,​ der einmalig für den Reload der Seite sorgt.
  
 Siehe auch: [[de:​shibslohttpd:​configuration|Konfigurationsbeispiele]] Siehe auch: [[de:​shibslohttpd:​configuration|Konfigurationsbeispiele]]
  • Zuletzt geändert: vor 4 Jahren