Shibboleth: Vollständiges Single Logout durch Kopplung von Anwendungs- und Shibboleth-Session am Apache-Webserver

Transkript

1 Shibboleth: Vollständiges Single Logout durch Kopplung von Anwendungs- und Shibboleth-Session am Apache-Webserver 9. DFN-Forum Kommunikationstechnologien Frank Schreiterer Universität Bamberg S. 1

2 Agenda 1. Ausgangssituation 2. Vorüberlegungen 3. Implementierung 4. Implikationen für das Single Logout S. 2

3 1. Ausgangssituation Shibboleth: Single SignOn System für vorrangig webbasierte Anwendungen auf Basis SAML Auth/ Attribute S. 3

4 1. Ausgangssituation SSO (Single SignOn) vollständig implementiert SLO (Single Logout) erst ab Version 3.2 Front- Channel; davor Version nur durch Plugin des NIIF möglich Version 2.4: rudimentäre Implementierung durch Shibboleth-Team, Portierung des NIIF-Plugin für Version 2.4 durch Manuel Haim (Uni Marburg) S. 4

5 1. Ausgangssituation Probleme beim SLO: 1. Viele Anwendungen verwenden eine eigene Anwendungs-Session und nicht die Shibboleth (SAML)-Session 2. Alle Lösungen terminieren beim Logout nur die SAML-Session, jedoch nicht die Anwendungs- Session durch fehlende Kopplung Anwendungs- Session an die Shibboleth-Session 3. Weitere Probleme durch fehlende Session-Kopplung 1. Zugriff ohne Shibboleth-Session 2. Manipulation der Anwendungs-Session S. 5

6 1. Ausgangssituation S. 6

7 1. Ausgangssituation Idee: Anwendungs-Session und Shibboleth-Session ohne Eingriff in die Anwendung am Webserver koppeln, da 1. in bestehende Anwendungen kann nur sehr schwer eingegriffen werden kann (Wartung des Zusatzcodes bei Updates, kein Quellcode verfügbar, etc.) 2. Zugriffe ohne Shibboleth-Session bzw. Manipulationen an Session unterbunden werden müssen S. 7

8 1. Ausgangssituation Ziel: Anwendungs-Session beim SLO auch terminieren S. 8

9 2. Vorüberlegungen 1. Anwendungs-Session muss als Cookie vorhanden sein 2. Anwendungsszenarien Einsatz Shibboleth zur Authentifizierung 1. normal: immer (Standardfall) 2. lazy: anwendungsgesteuert nach Erfordernis, Shibboleth einzige Authentifizierungsmöglichkeit 3. mixedlazy: anwendungsgesteuert nach Erfordernis, Shibboleth nicht einzige Authentifizierungsmöglichkeit 3. Speicherung der Kopplung zwischen Anwendungs- Session und Shibboleth-Session 1. Datenbank: persistent, aber aufwändig aufzusetzen und Bereinigung schwierig 2. memcached: flüchtig, einfach zu installieren (Linux) S. 9

10 2. Vorüberlegungen 4. Eingriffspunkte am Apache-Webserver: MOD_REWRITE 5. Konfigurationselemente Shibboleth-SP 1. sessionhook beim Login für Prüfung, ob Anwendungs- Session ohne Shibboleth-Session existiert vespinterestingfeatures#nativespinterestingfeatures- Post-LoginHooksandAttributeChecking 2. <Notify Channel="back"/"front"> bei Logout zum Beseitigen der Anwendung-Session und Kopplung Shibboleth-Session vespnotify S. 10

11 2. Vorüberlegungen 6. Angriffsszenarien 1. Besitz Anwendungs-Session ohne Shibboleth-Session 2. Manipulation Anwendungs-Session und / oder Shibboleth-Session S. 11

12 3. Implementierung Regelwerk sehr komplex und nicht über reine RewriteRules abzubilden Einsatz RewriteMap in Kombination mit RewriteRules, um auf die Rückgabewerte der RewriteMap zu reagieren Dynamische RewriteMap als Skript in PHP implementiert, Storage memcached Parameterübergabe im Aufruf der RewriteRule - ShibUseHeaders on muss gesetzt werden, da Shiboleth-Variablen nicht immer in den Umgebungsvariablen im Apache-Webserver zur Verfügung stehen HeaderSpoofing theoretisch möglich, aber praktisch wird es vom SP erkannt tivespspoofchecking S. 12

13 3. Implementierung Rückgabewerte RewriteMap-Skript 1. good wenn keine Aktion notwendig ist. 2. doappsession wenn am Webserver mit einer RewriteRule die Initialisierung der Anwendungs-Session sicher gestellt werden muss 3. dologin nur bei Anwendungsszenario lazy wenn die Anwendung nicht selbständig das Login anfordert, muss am Webserver 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! S. 13

14 3. Implementierung Rückgabewerte RewriteMap-Skript 4. dologout wenn versucht wurde 1. mit einer Anwendungs-Session ohne Shibboleth- Session zuzugreifen oder 2. die Anwendungs-Session während der Sitzung zu verändern oder 3. zusätzlich eine weitere Anwendungs-Session und / oder Shibboleth-Cookie einzuschleusen oder 4. die Shibboleth-Session während der Sitzung zu verändern muss am Webserver mit einer RewriteRule auf das Logout umgeleitet werden. S. 14

15 3. Implementierung Anmerkung: Ist die Anwendung von Haus aus gegen die die Zustände aus 4.1. bis 4.3. resistent, so kann auf die Implementierung der Lösung verzichtet werden. Getestete Anwendungen: OTRS (lazy) Suchtool Eigenentwicklung (normal) Enwicklungsanwendung in PHP (lazy, normal, mixedlazy) S. 15

16 3. Implementierung Einschränkungen: Kein gemeinsamer Betrieb von Anwendungen mixedlazy mit lazy oder normal auf einem Server möglich Voraussetzungen: php5-memcache nicht php5-memcached!!! shibd Version >= 2.5 Apache-Webserver Version >= 2.2 Quellen und Konfigurationen sowie weitere Informationen: S. 16

17 4. Implikationen für das Single Logout Kopplung der Anwendungs-Session an die Shibboleth- Session möglich: technische Hürden weitestgehend überwunden Unterstützung der Nutzerakzeptanz durch vollständiges SLO Logout funktioniert nicht ist kein Argument mehr, um SSO (mit SLO) nicht einzuführen S. 17

18 4. Implikationen für das Single Logout Todo: Implementierung der Funktionalität in shibd mit Unterstützung des DFN-Vereins als Mitglied des Shibboleth- Consortiums keine Installation von Zusatzsoftware (PHP / memcached) einfachere Administration bessere Akzeptanz bei Administratoren Verbreitung von SLO (notfalls Portierung der Lösung z.b. für IIS oder nginx) S. 18