Wirkungsweise

Wenn das Prüfskript im Apache-Webserver für die RewriteMap konfiguriert wurde, wird dieses in der RewriteCond im zu schützenden Verzeichnis aufgerufen:

RewriteCond ${Context,Shib-Session-ID,Name des Cookies der Anwendungssession,Cookies,[,mixedLazy]} ^return$

Der Aufruf erfolgt mit 4 Parametern und einem optionalen Parameter

1. Context: sessionHook für Aufruf der RewriteMap für das Skript im SessionHook, normal oder lazy
2. Shib-Session-ID: die Session-ID %{HTTP:Shib-Session-ID}
3. Name des Cookies der Anwendungssession: z.B. APPSESSIONNAME
4. Cookies: alle Cookies %{HTTP:COOKIE}
5. mixedLazy: Angabe nur, wenn die Anwendung neben Shibboleth noch andere Authentifizungen unterstützt, sonst entfällt der Parameter

Das Prüfskript selbst führt im ersten Schritt grundsätzliche Validierungen durch. Die erste Prüfung ist immer, ob die Shib-Session-ID aus Parameter 2 mit der ermittelten Shib-Session-ID aus dem übertragenen Cookie Parameter 4 übereinstimmt. Falls nicht, ist die Anfrage ungültig. Dies dient zur Erkennung von Manipulationen am Session-Cookie bzw. an den Headern. Weiterhin wird in diesem Schritt auch geprüft, ob versucht wurde, zusätzliche Anwendungs-Sessions und / oder Cookies mit Shibboleth-Sessions einzuschleusen. Ist dies der Fall, ist die Anfrage ungültig.

Im Context „sessionHook“ wird geprüft, ob keine Anwendungs-Session vorhanden ist, bei normal und lazy wird die Anwendungs-Session und die Shibboleth-Session gegen ein Muster geprüft. Beide Prüfungen müssen erfolgreich sein. Ist diese Prüfung erfolgreich werden erweiterte Prüfungen durchgeführt.

In de erweiterten Prüfung wird untersucht, ob die Shib-Session-ID im Datenspeicher existiert und zu dieser die passende Anwendungs-Session-ID geliefert wird. Sind die Anwendungs-Session-ID verschieden, ist die Anfrage ungültig, sonst gültig. Anderen falls handelt es sich um einen neuen Eintrag, der dann im Datenspeicher vermerkt wird und die Anfrage als gültig erklärt.

Zusätzlich erfolgt bei mixedLazy bei einem Neueintrag die Prüfung, ob die Anwendungs-Session-ID bereits vergeben wurde. Ist die Anwendungs-Session-ID bereits vergeben, ist die Anfrage ungültig.

Es existieren noch zwei Sonderzustände:

1. 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!
2. 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:
   1. 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
   2. am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen, der einmalig für den Reload der Seite sorgt.

Siehe auch: Konfigurationsbeispiele

Weiter zu Prüfskript