Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:shibsp:config-slo [2020/04/22 15:10] – Silke Meyer | de:shibsp:config-slo [2020/04/23 16:44] (aktuell) – Schreiterer, Frank | ||
---|---|---|---|
Zeile 26: | Zeile 26: | ||
**Einschränkungen: | **Einschränkungen: | ||
- | ===== Session-Initialisierung normal und lazy ===== | + | ==== 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: | Da es nahezu unmöglich ist, alle Bedingungen im Apache-Webserver selbst abzubilden, wird hier auf eine externe Lösung zurückgegriffen: | ||
Zeile 43: | Zeile 43: | ||
- zusätzlich eine weitere Anwendungssession und / oder ein Shibboleth-Cookie einzuschleusen | - zusätzlich eine weitere Anwendungssession und / oder ein Shibboleth-Cookie einzuschleusen | ||
- die Shibboleth-Session während der Sitzung zu verändern | - 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 | + | - 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! |
- | - 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 | + | - 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, |
- good \\ wenn keine Aktion notwendig ist. | - 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, | 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, | ||
- | ===== Session-Initialisierung mixedLazy | + | ==== Session-Initialisierung mixedLazy ==== |
Im Session-Initialisierungsmodus " | Im Session-Initialisierungsmodus " | ||
Zeile 59: | Zeile 59: | ||
===== Das Prüfskript ===== | ===== Das Prüfskript ===== | ||
- | Wenn das Prüfskript im Apache-Webserver für die RewriteMap konfiguriert wurde, wird es in der '' | + | Wenn das Prüfskript |
RewriteCond ${Context, | RewriteCond ${Context, | ||
Zeile 78: | Zeile 78: | ||
Zusätzlich erfolgt bei " | Zusätzlich erfolgt bei " | ||
- | |||
- | ==== Sonderzustände ==== | ||
Es existieren noch zwei Sonderzustände: | 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 | + | - Im Modus "lazy" |
- | - Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungs-Session | + | - Im Moment der durchgeführten Authentifizierung mit Shibboleth darf noch keine Anwendungssession |
- | - 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: |
- | - am Apache-Webserver | + | - Alternativ: Am Apache-Webserver |
- | + | ||
- | FIXME php7 | + | |
<callout color="# | <callout color="# | ||
- | * 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 |
- | * shibd Version >= 2.5\\ | + | * shibd Version >= 2.5 |
- | * Apache-Webserver | + | * Apache-Webserver mit mod_rewrite und mod_headers |
</ | </ | ||
Zeile 536: | Zeile 532: | ||
- | ====== Konfiguration | + | ===== Konfiguration ===== |
+ | FIXME | ||
Je nach [[de: | Je nach [[de: | ||
Für alle Anwendungsszenarien muss die [[de: | Für alle Anwendungsszenarien muss die [[de: | ||
Zeile 547: | Zeile 544: | ||
FIXME Alle hier aufgeführten Skripte sind beispielhaft und müssen ggf. angepasst werden. | FIXME Alle hier aufgeführten Skripte sind beispielhaft und müssen ggf. angepasst werden. | ||
- | ==== checker.php | + | checker.php |
Sorgt für den notwendigen zusätzlichen Request beim SessionHook. | Sorgt für den notwendigen zusätzlichen Request beim SessionHook. | ||
Zeile 557: | Zeile 554: | ||
</ | </ | ||
- | ==== initsess.php ==== | + | initsess.php => Erzeugt eine appsession |
<file php initsess.php> | <file php initsess.php> | ||
<?php | <?php | ||
Zeile 571: | Zeile 569: | ||
- | ==== remsess.php ==== | + | remsess.php => entfernt bei Zugriff mit einer ungültigen Kombination shibsession appsession beides sessions |
<file php remsess.php> | <file php remsess.php> |