Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel

Größe: px

Ab Seite anzeigen:

Download "Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel"

Clemens Hofer
vor 2 Jahren
Abrufe

Transkript

1 Organisationsübergreifendes Single Sign On mit shibboleth Tobias Marquart Universität Basel

2 Überblick Einordnung von Shibboleth, Abgrenzung zu OpenID Organisatorische und technische Komponenten einer Federation Grundlegendes zur Funktionalität Probleme aus der Sicht eines Applikationsentwicklers Fragen / Details bei Bedarf

Federation Grundlegendes zur Funktionalität Probleme aus

3 Applikationen organisationsübergreifend anbieten: warum? Erreichen von bestimmten, übergreifenden Benutzergruppen (Studenten z. B.) Kommerziell sehr wertvoll Benutzer sind an mehreren beteiligten Organisationen tätig Gegenseitig Services zur Verfügung stellen Shibboleth als Lösung Motivation: Erhöhung von Sicherheit, Datenqualität, Komfort: keine logoninfos auf Applikationsseite nur wirklich gültige Benutzerdaten Benutzerverwaltung für Applikationen fällt weg SSO fast mehr als Nebeneffekt

4 Was ist Shibboleth? Authentisierungs- und Autorisierungs-Mechanismus Für browserbasierte Webapplikationen Über HTTP 302 Redirect Per cookies/post/get-parameter, Session-based SSL abgesichert middleware zwischen Webserver und Applikation: apache-modul / ISAPI-Filter Jeder Benutzer, der bis zur Applikation durchkommt, ist schon gültig angemeldet Attribute werden (falls verwendet) bei jedem Request per CGI/Server-Variablen an die Applikation weitergegeben

cookies/post/get-parameter, Session-based SSL abgesichert middleware zwischen Webserver und Applikation:

5 Verschiedene SSO-Mechanismen im Verlgeich Active Directory shibboleth openid Scope Intra-institutional Inter-institutional global Benutzer Mitarbeiter einer Firma Alle Beteiligten jeder Web-user Datenqualität sehr hoch sehr hoch unklar Entscheidungsrichtung top down demokratisch bottom up Datenquellen 1 n x Aufbau zentral dezentral und zentral dezentral IT-Landschaft homogen heterogen heterogen Shibboleth verbindet die Vorteile einer zentralen Verwaltung von Benutzerdaten mit den Vorteilen von openid Aber: Zweck ist ein anderer!

down demokratisch bottom up Datenquellen 1 n x Aufbau zentral dezentral und zentral dezentral IT-Landschaft homogen heterogen

6 Shibboleth und IDM IDM im engeren Sinne: kommerzielle IDM- Systeme Eine zentrale Datendrehscheibe, die login-daten werden an die Systeme verteilt. jeder SP ist sein eigener IDP IDM im weiteren Sinne: openid, shibboleth Verteilte Struktur, lockerer Verbund, es gibt keine bestimmende Zentrale, nur Absprachen bzw. Standards, IDM on the fly Identity Provider und Consumer sind getrennt

jeder SP ist sein eigener IDP IDM im weiteren Sinne: openid, shibboleth Verteilte Struktur,

7 Komponenten einer Federation organisatorisch technisch Finanzierung Organisatorischer Rahmen: Gremien, beteiligte Organisationen Definitionen, Richtlinien => Metadaten, ARP HomeOrgs IDP's Zentrale Dienste RR WAYF Applikation SP's

beteiligte Organisationen Definitionen, Richtlinien =>

8 Wie kann das funktionieren? Jede beteiligte Organisation hat u. U. eine (andere) Vorstellung vom Datenschutz, der Vertraulichkeit der Daten etc. Jeder IDP hat verschiedene Attribute zur Verfügung (Benennung und Inhalt) Welcher SP braucht welches Attribut? und Welcher User möchte welches Attribut für welche Resource freigeben? ARP Gut gelöst bei OpenID Bei shibboleth: auch möglich, aber nicht per default

Jeder IDP hat verschiedene Attribute zur Verfügung (Benennung und Inhalt) Welcher SP braucht welches

9 Interoperation über zentrale (!) Metadaten (XML) Jeder SP weiss, von welchen IDPs er Anmeldungen annehmen darf jeder IDP weiss welche Resourcen es gibt und welche Attribute er jeweils schicken darf Metadata-updates bei jeder Änderung eines SP/IDP Zentrale Verwaltungsstelle: Resource Registry: generiert die Metadaten, diese müssen regelmässig abgeholt werden von den SP's und IDP's

welche Resourcen es gibt und welche Attribute er jeweils schicken darf Metadata-updates bei

10 Verwendung von Attributen (SP's) Nur Anmeldung (wer, ist egal) Verwendung von Benutzer-Attributen nur in der aktuellen Session Speichern von session-übergreifenden Profil- Informationen Widerspricht eigentlich der Idee, es entstehen viele Probleme: alte accounts, (lokale) updates Cross-sp attribute matching: Datenschutzproblem, lösbar (uniqueid => targetedid)

Profil- Informationen Widerspricht eigentlich der Idee, es entstehen viele Probleme: alte

11 Schwierigkeiten WAYF: spof Abhängigkeiten beim Aufsetzen eines SP Debugging ist nicht einfach Identische Testsysteme nicht möglich Garbage collection (alte accounts löschen) nicht möglich Single logout nicht möglich User auf anderen IDP übertragen geht nicht

möglich Garbage collection (alte accounts löschen) nicht möglich

12 1 logon 10 requests Quelle:

13 Quelle:

14 Shibbolized applications (Beispiele) Quelle: https://wiki.internet2.edu/confluence/display/seas/home

15 Definitionen IDP: Identity Provider, hält Benutzerdaten SP: Service Provider (i.d.r: web-applikation) IDM: Identity Management, Identity Management System SAML: Security Assertion Markup Language (XML-Spezifikation, OASIS-Standard und Basis für den Datenaustausch zwischen shibboleth-applikationen) ARP: Attribute Release Policy WAYF: Where are you from (Serverkomponente in der Federation) RR: Resource Registry

16 Quellen und Links https://spaces.internet2.edu/display/shib2/sloissues Kieron O'Hara, Nigel Shadbolt: The spy in the coffee machine (Oneworld Oxford UK, 2008) Mike Andrews, James A. Whittaker: How to break web software (Adison Wesley 2006)

Ähnliche Dokumente

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS