Single Logout Aktueller Stand 10/2015

Transkript

1 Single Logout Aktueller Stand 10/ DFN-Betriebstagung, AAI-Forum, Frank Schreiterer Universität Bamberg S. 1

2 Agenda 1. Aktuelle Probleme beim Single Logout 2. Maßnahmen seitens der DFN-AAI 3. Kopplung Anwendungs-Session und Shibboleth- Session am Apache-Webserver S. 2

3 1. Aktuelle Probleme beim Single Logout Single-Sign-On vollständig implementiert Single-Log-Out in IdP2 nur unzureichend implementiert Existenz verschiedener Lösungsansätze (Diskussion der Ansätze im Juni 2014 beim DFN-Verein), Ankündigung SLO im IdP 3 für Q4 / Roadmap ( Finish IdP Single Logout Implementation ) LOIssues ausführliche Diskussion S. 3

4 1. Aktuelle Probleme beim Single Logout Front-Channel (Webbrowser) Back-Channel: Kopplung der SAML-Session an Anwendungs-Session durch NameIdentifier muss durch die Anwendung erfolgen S. 4

5 1. Aktuelle Probleme beim Single Logout Ziel S. 5

6 1. Aktuelle Probleme beim Single Logout Ziel Voraussetzung: Shibboleth-Session und Anwendungs-Session sind gekoppelt! S. 6

7 2. Maßnahmen seitens der DFN-AAI Ausführliche Online-Dokumentation mit Konfigurationsbeispielen für SPs und IdPs Verstärktes Augenmerk auf SLO-Funktionalität bei Aufnahme von Service Providern; derzeit Schwerpunkt auf Autorisierung ( kommerzielle Anbieter) NB: grundsätzlich sind alle Teilnehmer in der DFN-AAI verpflichtet, korrekte Metadaten, d.h. auch nur funktionierende Bindings zu registrieren Mittelfristig Implementierung von Online-Checks nach dem Vorbild von Qualys SSL Labs inkl. entsprechender Ratings (A-, A+ etc.) S. 7

8 3. Kopplung Anwendungs-Session und Shibboleth-Session am Apache-Webserver 3.1 Ausgangssituation 3.2 Angriffsszenarien 3.3 Idee 3.4 Vorüberlegungen 3.5 Prototypische Implementierung 3.6 Demo S. 8

9 3.1 Ausgangssituation 1. zahlreiche Anwendungen lassen sich per Shibboleth authentifizieren, koppeln aber die eigenen Anwendungs-Session nicht an die Shibbleth-Session 2. In bestehende Anwendungen kann nur sehr schwer eingegriffen werden (Wartung des Zusatzcodes bei Updates, kein Quellcode verfügbar, etc.) 3.2 Angriffsszenarien 1. Besitz Anwendungs-Session ohne Shibboleth-Session 2. Manipulation Anwendungs-Session und / oder Shibboleth-Session S. 9

10 3.3 Idee Anwendungs-Session und Shibboleth-Session ohne Eingriff in die Anwendung am Webserver koppeln 3.4 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 S. 10

11 3.4 Vorüberlegungen 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) 4. Eingriffspunkte am Apache-Webserver: MOD_REWRITE S. 11

12 3.4 Vorüberlegungen 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. 12

13 3.5 Prototypische 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. 13

14 3.5 Prototypische Implementierung Rückgabewerte RewriteMap 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. 14

15 3.5 Prototypische Implementierung Rückgabewerte RewriteMap 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. 15

16 3.5 Prototypische Implementierung Getestete Anwendungen: OTRS (lazy) Suchtool Eigenentwicklung (normal) Enwicklungsanwendung in PHP (lazy, normal, mixedlazy) 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 S. 16

17 3.5 Prototypische Implementierung Todo: Implementierung für IIS für weitere Tests oder noch besser Implementierung der Funktionalität in shibd über internet2 S. 17

18 3.6 Demo S. 18