| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
| de:shibslohttpd:introduction [2015/12/09 11:03] – Schreiterer, Frank | de:shibslohttpd:introduction [2015/12/09 11:06] – [Notwendiger Datenspeicher] Schreiterer, Frank |
|---|
| |
| 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 (SLO) ist 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. | 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 (SLO) ist 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 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. | |
| | 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 ===== |
| |
| Die gespeicherten Einträge sollten nach einer Zeitspanne, die in Abhängigkeit der Bereinigung von inaktiven Anwendungs-Sessions und der Session-Lifetime der Shibboleth-Session gewählt sein muss, entfernt werden, was bei memcached direkt über einen Parameter und an einer Datenbank z.B. direkt in der Datenbank über Events geregelt werden kann. Auch der Einsatz von zeitgesteuert aufgerufenen Skripten ist denkbar. | Die gespeicherten Einträge sollten nach einer Zeitspanne, die in Abhängigkeit der Bereinigung von inaktiven Anwendungs-Sessions und der Session-Lifetime der Shibboleth-Session gewählt sein muss, entfernt werden, was bei memcached direkt über einen Parameter und an einer Datenbank z.B. direkt in der Datenbank über Events geregelt werden kann. Auch der Einsatz von zeitgesteuert aufgerufenen Skripten ist denkbar. |
| | |
| | Das [[de:shibslohttpd:checkerscript|Prüfskript]] ist mit memcached implementiert, das der Aufwand für Anwendungsbetreuer gegenüber einer Datenbank wesentlich geringer ist. |
| |
| Weiter zu [[de:shibslohttpd:solution|Lösung]] | Weiter zu [[de:shibslohttpd:solution|Lösung]] |
| |