Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibsp:config-slo [2020/04/22 14:24] – Silke Meyer
+++ de:shibsp:config-slo [2020/04/23 16:44] (aktuell) – Schreiterer, Frank
@@ Zeile 24: / Zeile 24: @@
 Die Lösungen variieren je nach Session-Initialisierungsmodus.
-===== Session-Initialisierung normal und lazy =====
+**Einschränkungen:** Es ist nicht möglich, auf einem Server mehrere Anwendungen im Modus "mixedLazy" und "normal" bzw. "lazy" gemeinsam zu betreiben, da bei "mixedLazy" der sessionHook mit dem zugehörigen Weiterleitungsskript nicht verwendet werden darf (s.u.). Der gemeinsame Betrieb von Anwendungen im Modus "normal" und "lazy" stellt kein Problem dar.
+==== Session-Initialisierung normal und lazy ====
 Da es nahezu unmöglich ist, alle Bedingungen im Apache-Webserver selbst abzubilden, wird hier auf eine externe Lösung zurückgegriffen: Am Apache-Webserver wird eine RewriteMap konfiguriert, die ein externes Programm aufruft.
@@ Zeile 41: / Zeile 43: @@
     - zusätzlich eine weitere Anwendungssession und / oder ein Shibboleth-Cookie einzuschleusen
     - die Shibboleth-Session während der Sitzung zu verändern
-  - doLogin – nur bei Anwendungsszenario „lazy“ \\ Am Webserver muss mit einer RewriteRule auf das Login umgeleitet werden, sonst ist das Einschleusen einer vorhanden Anwendungs-Session möglich! Beim Login muss die Anwendungs-Session erzeugt werden! [[de:shibslohttpd:functioning#sonderzustaende|Siehe auch Wirkungsweise Prüfskript – Sonderzustände Punkt 1]]
+  - doLogin – nur bei Anwendungsszenario „lazy“ \\ Am Webserver muss mit einer RewriteRule auf das Login umgeleitet werden, sonst ist das Einschleusen einer vorhanden Anwendungs-Session möglich! Beim Login muss die Anwendungs-Session erzeugt werden! Siehe weiter unten bei [[de:shibsp:config-slo#das_pruefskript|Prüfskript]] Sonderzustände Punkt 1
-  - doAppSession \\ Am Webserver muss mit einer RewriteRule die Initialisierung der Anwendungs-Session sicher gestellt werden. Da beim Login noch keine Anwendungs-Session vorhanden sein darf ist es möglich, dass unmittelbar nach dem erfolgreichen Shibboleth-Login noch keine Anwendungs-Session für die RewriteRule existiert, aber das Cookie schon existiert und somit verändert werden könnte, [[de:shibslohttpd:functioning#sonderzustaende|siehe auch Wirkungsweise Prüfskript – Sonderzustände Punkt 2]]
+  - doAppSession \\ Am Webserver muss mit einer RewriteRule die Initialisierung der Anwendungs-Session sicher gestellt werden. Da beim Login noch keine Anwendungs-Session vorhanden sein darf ist es möglich, dass unmittelbar nach dem erfolgreichen Shibboleth-Login noch keine Anwendungs-Session für die RewriteRule existiert, aber das Cookie schon existiert und somit verändert werden könnte, Siehe weiter unten bei [[de:shibsp:config-slo#das_pruefskript|Prüfskript]] Sonderzustände Punkt 2
   - good \\ wenn keine Aktion notwendig ist.
 Mit Hilfe der RewriteMap wird das Prüfskript bei jeder Anfrage an den Webserver ausgeführt. Beim Login beträgt die dadurch zusätzlich verursachte Ausführungszeit bis zu 20 Millisekunden, danach benötigen die Prüfungen i.d.R. unter 0,5 Millisekunden.
-===== Session-Initialisierung mixedLazy =====
+==== Session-Initialisierung mixedLazy ====
 Im Session-Initialisierungsmodus "mixedLazy" sind neben Shibboleth weitere Authentifizierungsmethoden möglich. Bei einer Authentifizierung, die nicht gegen Shibboleth erfolgt, muss man sich auf die Schutzmechanismen der Anwendung verlassen.
@@ Zeile 55: / Zeile 57: @@
 Ob eine Anwendungssession besteht, kann und darf hier nicht vorab mittels sessionHook geprüft werden!
-====== Wirkungsweise ======
+===== Das Prüfskript =====
-Wenn das [[de:shibslohttpd:checkerscript|Prüfskript]] im Apache-Webserver für die RewriteMap konfiguriert wurde, wird dieses in der RewriteCond im zu schützenden Verzeichnis aufgerufen:
+Wenn das Prüfskript (s.u.) im Apache-Webserver für die RewriteMap konfiguriert wurde, wird es in der ''RewriteCond'' im zu schützenden Verzeichnis aufgerufen:<code apache>
+RewriteCond ${Context,Shib-Session-ID,Name des Cookies der Anwendungssession,Cookies,[,mixedLazy]} ^return$</code>
-RewriteCond ${Context,Shib-Session-ID,Name des Cookies der Anwendungssession,Cookies,[,mixedLazy]} ^return$
+Der Aufruf erfolgt mit 4 Parametern und einem optionalen Parameter:
-Der Aufruf erfolgt mit 4 Parametern und einem optionalen Parameter
   - Context: sessionHook für Aufruf der RewriteMap für das Skript im SessionHook, normal oder lazy
   - Shib-Session-ID: die Session-ID %{HTTP:Shib-Session-ID}
   - Name des Cookies der Anwendungssession: z.B. APPSESSIONNAME
   - Cookies: alle Cookies %{HTTP:COOKIE}
-  - mixedLazy: Angabe nur, wenn die Anwendung neben Shibboleth noch andere Authentifizungen unterstützt, sonst entfällt der Parameter
+  - optional: mixedLazy: Angabe nur, wenn die Anwendung neben Shibboleth noch andere Authentifizierungsmethoden unterstützt
-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.
+Das Prüfskript führt im ersten Schritt grundsätzliche Validierungen durch:
-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.
+Zuerst wird geprüft, 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 Anwendungssessions und / oder Cookies mit Shibboleth-Sessions einzuschleusen. Ist dies der Fall, ist die Anfrage ungültig.
-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.
+Im Context „sessionHook“ wird geprüft, ob keine Anwendungssession vorhanden ist. Bei "normal" und "lazy" werden die Anwendungssession und die Shibboleth-Session gegen ein Muster geprüft. Beide Prüfungen müssen erfolgreich sein. Ist diese Prüfung erfolgreich, wird die erweiterte Prüfung durchgeführt.
-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.
+In der erweiterten Prüfung wird untersucht, ob die Shib-Session-ID im Datenspeicher existiert und ob die dazu passende Anwendungssession-ID geliefert wird. Sind die Anwendungssession-IDs unterschiedlich, ist die Anfrage ungültig. Ist sie gültig, handelt es sich um einen neuen Eintrag, der dann im Datenspeicher vermerkt wird.
-==== Sonderzustände ====
+Zusätzlich erfolgt bei "mixedLazy" bei einem Neueintrag die Prüfung, ob die Anwendungssession-ID bereits vergeben wurde. Wenn ja, ist die Anfrage ungültig.
 Es existieren noch zwei Sonderzustände:
-  - 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 Modus "lazy" gibt es beim ersten Aufruf einen Zustand, bei dem weder die Shib-Session-ID noch die Anwendungs-Session-ID vorhanden ist. Dies muss eine gültige Anfrage sein. 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 weiterleitet. **Achtung:** Erfolgt keine Weiterleitung zum Login, so entsteht hier eine Sicherheitslücke, da dann eine ungewollte Anwendungssession 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 Anwendungssession vorhanden sein, aber es muss eine Shib-Session-ID existieren. Dieser Zustand muss als gültige Anfrage erklärt werden, aber es muss noch sichergestellt werden, dass zur Shib-Session-ID die korrekte Anwendungssession 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 eingeschleust wird! Es muss ein zusätzlicher Request erfolgen, in dem die Anwendungssession in den Variablen für das Prüfskript zur Verfügung gestellt wird. 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
+    - Empfohlen: Es ist möglich, die Session mittels einer Umleitung auf ein zusätzliches Skript zu erzeugen (funktioniert bei PHP).
-    - am Apache-Webserver einen Refresh-Header dem Request hinzuzufügen, der einmalig für den Reload der Seite sorgt.
+    - Alternativ: Am Apache-Webserver kann dem Request ein Refresh-Header hinzugefügt werden, der einmalig für den Reload der Seite sorgt.
-Siehe auch: [[de:shibslohttpd:configuration|Konfigurationsbeispiele]]
-===== Prüfskript =====
-FIXME php7
 <callout color="#ff9900" title="Voraussetzungen">
-  * php -> Versionen?
+  * php -> getestet mit php5, php7(.2)
-  * memcached auf localhost (oder ggf. in Skripten anpassen)\\
+  * memcached auf localhost (oder ggf. in Skripten anpassen)
-  * php5-memcache nicht php5-memcached!!!\\
+  * php-memcache (nicht php-memcached!!!)
-  * shibd Version >= 2.5\\
+  * shibd Version >= 2.5
-  * Apache-Webserver Version, empfohlen 2.4 \\ mit mod_rewrite und mod_headers aktiviert
+  * Apache-Webserver mit mod_rewrite und mod_headers
 </callout>
@@ Zeile 329: / Zeile 323: @@
-====== Entfernen der Sicherungseinträge beim Logout ======
+===== Cleanup beim Logout =====
-Es wird das <Notify>-Element [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPNotify
+Um die Einträge beim Logout zu entfernen, wird in ''/etc/shibboleth/shibboleth2.xml'' das [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPNotify|<Notify>-Element]] des Shibboleth-Daemons verwendet. Es wird unterhalb des <Session>-Elements definiert und kann für Front- und Back-Channel konfiguriert werden.
-]] des Shibboleth-Daemons in shibboleth2.xml verwendet, welches unterhalb des <Session>-Elements definiert wird. Es kann für Front- und Back-Channel jeweils konfiguriert werden. Dieser Umstand wird genutzt, um per Front-Channel nur die Cookies der Anwendung zu zerstören und um per Back-Channel die Einträge im Datenspeicher zu entfernen und die Anwendungs-Session in der Anwendung selbst zu zerstören.
+Über den Front-Channel werden die Cookies der Anwendung gelöscht. Über den Back-Channel werden die Einträge im Datenspeicher und die Anwendungssession in der Anwendung selbst zerstört.
 Konfiguration:
 <code xml shibboleth2.xml>
-…
+...
 <Errors supportContact="foobar@beispiel-uni.de"
             logoLocation="/shibboleth-sp/logo.jpg"
@@ Zeile 344: / Zeile 339: @@
  <Notify Channel="back" Location="https://sp.beispiel-uni.de/PATH/TO/logoutnotify.php" />
  <Notify Channel="front" Location="https://sp.beispiel-uni.de/PATH/TO/logoutnotify.php" />
-…
+...
 </code>
-Skript: [[de:shibslohttpd:helperscripts#logoutnotifyphp|logoutnotify.php]]
+Das Skript ''logoutnotify.php'' wird hier zur Bereinigung aufgerufen:
-Weiter zu [[de:shibslohttpd:limitations|Einschränkungen, Voraussetzungen, Todo]]
-====== Einschränkungen, Todo ======
-===== Einschränkungen =====
-Es ist nicht möglich, auf einem Server mehrere Anwendungen im Context „mixedLazy“ und „normal“ bzw. „lazy“ gemeinsam zu betreiben, da bei „mixedLazy“ der sessionHook mit dem zugehörigen Weiterleitungsskript nicht verwendet werden darf.
-Der gemeinsame Betrieb von Anwendungen im Context „normal“ und „lazy“ stellt kein Problem dar.
-===== Todo =====
-  * Implementierung der Funktionalität in Shibd
-  * ggf. für weitere Tests:
-    * Implementierung am IIS
-    * eventuell Portierung des Prüfskripts auf eine andere Sprache
-====== Konfiguration ======
-Je nach [[de:shibslohttpd:introduction#anwendungsszenarien|Anwendungsszenario]] sind unterschiedliche Konfigurationen notwendig.
-Für alle Anwendungsszenarien muss die [[de:shibslohttpd:configuration:all|allgemeine Konfiguration]] durchgeführt werden.
-Alle Konfigurationen sind für Apache 2.4. Man beachte, dass sich die Konfigurationselemente von Apache 2.2 nach Apache 2.4 geändert haben, siehe z.B. [[https://www.switch.ch/aai/support/presentations/techupdate-2014/12_Apache_24_vs_22.pdf]], [[https://www.switch.ch/aai/guides/sp/access-rules/]] und [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig]].
-====== Hilfsskripte ======
-Alle hier aufgeführten Skripte sind beispielhaft und müssen ggf. angepasst werden.
-===== checker.php =====
-Sorgt für den notwendigen zusätzlichen Request beim SessionHook.
-<file php checker.php>
-<?php
-//redirect to application
-header('Location: '.$_GET['return']);
-?>
-</file>
-===== initsess.php =====
-<file php initsess.php>
-<?php
-//initialize application session
-session_start();
-//applicationpath
-$path = "Path/to/NORMALAPPLICATION";
-//and redirect to application
-$redirect = "https://".$_SERVER['SERVER_NAME']."/$path";
-header('Location: '.$redirect);
-?>
-</file>
-===== logoutnotify.php =====
-Dieses Skript [[de:shibslohttpd:removallogout|entfernt die Anwendungs-Session]] via Back-Channel und die Cookies via Front-Channel.
 <file php logoutnotify.php>
@@ Zeile 592: / Zeile 531: @@
 </file>
-===== remsess.php =====
+===== Konfiguration =====
+FIXME
+Je nach [[de:shibslohttpd:introduction#anwendungsszenarien|Anwendungsszenario]] sind unterschiedliche Konfigurationen notwendig.
+Für alle Anwendungsszenarien muss die [[de:shibslohttpd:configuration:all|allgemeine Konfiguration]] durchgeführt werden.
+Alle Konfigurationen sind für Apache 2.4. Man beachte, dass sich die Konfigurationselemente von Apache 2.2 nach Apache 2.4 geändert haben, siehe z.B. [[https://www.switch.ch/aai/support/presentations/techupdate-2014/12_Apache_24_vs_22.pdf]], [[https://www.switch.ch/aai/guides/sp/access-rules/]] und [[https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig]].
+===== Weitere Hilfsskripte =====
+FIXME Alle hier aufgeführten Skripte sind beispielhaft und müssen ggf. angepasst werden.
+checker.php
+Sorgt für den notwendigen zusätzlichen Request beim SessionHook.
+<file php checker.php>
+<?php
+//redirect to application
+header('Location: '.$_GET['return']);
+?>
+</file>
+initsess.php => Erzeugt eine appsession
+<file php initsess.php>
+<?php
+//initialize application session
+session_start();
+//applicationpath
+$path = "Path/to/NORMALAPPLICATION";
+//and redirect to application
+$redirect = "https://".$_SERVER['SERVER_NAME']."/$path";
+header('Location: '.$redirect);
+?>
+</file>
+remsess.php => entfernt bei Zugriff mit einer ungültigen Kombination shibsession appsession beides sessions
 <file php remsess.php>
@@ Zeile 678: / Zeile 655: @@
 </file>
 {{tag>fixme sp slo single-logout sessions}}

fixme sp slo single-logout sessions