Seminarvortrag Shibboleth

Transkript

1 Seminarvortrag Shibboleth René Wagner Rechen- und Kommunikationszentrum der RWTH Aachen 14. Januar 2011 Rechen- und Kommunikationszentrum (RZ)

2 Motivation Ein Nutzer - viele Webanwendungen Kurse belegen viele Passwörter viele Anmeldevorgänge Klausurergebnisse Wie hieß nochmal das Passwort? Rechnerpool Wünschenswert: Student ein Account, der Zugriff auf mehrere Dienste ermöglicht Lösung: Single Sign-On Systeme Einmal anmelden und für mehrere Dienste Zugriff erhalten Folie 2

3 Agenda Was ist Shibboleth? Technische Aspekte und Funktionsweise Shibboleth in Einsatz Alternativen/Zusammenfassung Folie 3

4 Was ist Shibboleth? Folie 4

5 Shibboleth Wortherkunft Hintergrund ist Bibelstelle aus Altem Testament (Richter 12, 5-6) Gileaditer hatten Abschnitt des Jordan besetzt und nutzten Shibboleth als Codewort, um Fremde zu erkennen hießen sie ihn sprechen: Schiboleth; so sprach er Siboleth und konnte es nicht recht reden; Ein Shibboleth ist ein Erkennungszeichen, das eine Person eindeutig charakterisiert Ein Beispiel für ein deutsches Shibboleth wäre: Oachkatzlschwoaf Folie 5

6 Shibboleth Logo Logo zeigt einen Greif (Fabelwesen, eine Mischung aus mehreren Tieren) Symbolisiert, je nach Kulturkreis, einen Wächter und Bewacher Folie 6

7 Grundlegendes wurde/wird von Internet2 Middleware Initiative entwickelt Open Source unter Apache 2.0 Lizenz Entwicklungsziel: Schaffung einer Identity und Accessmanagement Infrastruktur (IAM) Soll interoperabel und auch über Organisationsgrenzen hinweg nutzbar sein Version 1.0 Juni 2003 Version 2.0 März 2005 Folie 7

8 Komponenten und ihre Interaktion Drei grundlegende Komponenten, auf denen Shibboleth aufbaut: Identity Provider Service Provider Discovery Service Folie 8

9 Identity Provider (IdP) Steht bei Heimateinrichtung des Nutzers und verwaltet Nutzerdaten Art der Datenspeicherung nicht vorgeschrieben (bspw. LDAP, DB) Einzige Stelle im Shibboleth System, wo administrative Aufgaben im Bereich Nutzeraccounts anfallen Nutzer muss sich bei seinem IdP authentifizieren lassen IdP schickt SP nötige Informationen für Zugang des Nutzers Folie 9

10 Service Provider (SP) Schützt einen Dienst, eine Ressource Auf gleichem Rechner wie die zu schützende Ressource Erhält zuerst die Anfrage, wenn Nutzer seinen Dienst nutzen will Ist Nutzer bereits angemeldet, kann er sofort zugreifen Ist er nicht angemeldet, muss er sich bei seinem IdP authentifizieren Folie 10

11 Discovery Service Auch Lokalisierungsdienst genannt und häufig auch als WAYF (Where Are You From) bezeichnet Wird eingesetzt, wenn es mehrere IdPs in einem Shibboleth System gibt Verwaltet die Liste mit allen IdPs Wenn SP nicht weiß, zu welchem IdP Nutzer gehört, wird dieser an Discovery Service weitergeleitet Nutzer wählt aus der Liste der IdPs seinen aus und wird zu diesem weitergeleitet Folie 11

12 Vorteile für Anwender Muss sich nur ein Passwort für mehrere Dienste merken Dienste können unabhängig vom Standort des Nutzers aufgerufen werden Erhöhung des Datenschutzes, weil nur minimal benötigte Daten von IdP zu SP gesendet werden Anmeldedaten werden Just in time von zentraler Stelle gesendet Folie 12

13 Vorteile für Anbieter - 1 Zu schützender Dienst kann mit vergleichsweise geringem Aufwand gesichert werden, weil eigene Nutzerverwaltung auf SP Seite nicht nötig ist Auf IdP Seite können schon bestehende Identity Management Strukturen verwendet und an Shibboleth angebunden werden Wegfall des Sendens von Daten über Nutzeraccounts an Service Anbieter, da Daten Just in time gesendet werden und keine eigene Nutzerverwaltung benötigt wird Folie 13

14 Vorteile für Anbieter - 2 Zugriff auf Webdienste recht leicht zu steuern und somit auch Zugriff für organisationsfremde Nutzer gut realisierbar Art der Authentifizierung nicht festgelegt (biometrisch, Zertifikat, Chipkarte auch möglich) Open Source keine Lizenzkosten Wird weltweit verwendet und genießt hohe Akzeptanz Folie 14

15 Föderationen Föderation DFN Lokalisierungsdienst Organisation Folie 15

16 Teilnahmevoraussetzungen Anmeldeschritte von neuem Bewerber bei deutscher Föderation: Vertrag abschließen Anmelden bei der Testföderation In Mailingliste eintragen Daten des SP und/oder IdP in Metadaten der Testföderation eintragen SP und/oder IdP konfigurieren, wozu Metadaten benötigt werden Funktionstest bestehen Aufnahme in die Föderation Folie 16

17 Einsatzbereiche/ Implementierungsoptionen Einsatz: Vor allem im Bereich Wissenschaft, Forschung und Lehre Immer mehr Onlinebibliotheken treten der deutschen Föderation bei und schützen ihr Angebot mit Shibboleth Implementierung als SSO innerhalb einer Organisation Kontrollmechanismus SSO innerhalb einer Föderation Virtual Identity Provider Folie 17

18 Technische Aspekte und Funktionsweise Folie 18

19 Metadaten Bilden Föderationsstruktur auf Softwareebene ab Enthalten Informationen über alle SPs und IdPs Sichern Kommunikation der Komponenten ab (Signatur) Sind auf der Seite der DFN AAI Föderation einzusehen und werden vom DFN verwaltet Shibboleth nutzt Teile der SAML 2.0 Metadaten mit zusätzlichen eigenen Erweiterungen Folie 19

20 Metadaten Beispiel 1 Folie 20

21 Metadaten Beispiel 2 Organisation Ansprechpartner der Organisation Folie 21

22 Security Markup Language XML basiertes Framework zur Erzeugung und Austausch von Authentifizierungs- und Autorisierungsinformationen Entwicklung durch OASIS Konsortium begann 2001 (ca. ein Jahr nach Beginn des Shibboleth Projekts) Von Begin an Chefentwickler von Shibboleth im Entwicklerteam von SAML Synergien, die sich bis heute positiv auswirken Wird bei Shibboleth genutzt um Zugangsinformationen zu übertragen (SAML Assertions) Folie 22

23 SAML Assertions - Zusicherungen Werden bei Shibboleth vom IdP zum SP geschickt SP wertet Assertion aus und regelt aufgrund dessen den Zugang zu der geschützten Anwendung Drei Arten von Assertions Attributes Authentikation Authorization Folie 23

24 SAML Binding Konzepte SAML Nachrichten können in andere Protokolle wie z.b. (HTTP, TCP, ) eingebunden werden Binding Konzepte sind: SAML SOAP Binding Reverse SOAP (PAOS) Binding HTTP Redirect Binding HTTP POST Binding HTTP Artifact Binding SAML URI Binding Folie 24

25 Shibboleth Funktionsweise _shibstate 1 2 Shibboleth Session vorhanden? 3 nein ja 6 Anmeldung Heimateinrichtung - Identity Provider Lokalisierungsdienst 5 Authn Attribute 7 Anbieter Service Provider Folie 25 4 Authentifizierungsanfrage _shibstate 8 Zugriff erlaubt? nein ja 2 a

26 Shibboleth im Einsatz Folie 26

27 Shibboleth im Einsatz weltweit Wird mittlerweile weltweit eingesetzt Viele landesweite Föderationen Beispiele Europa: DFN AAI, SWITCHaai, DK AAI Amerika: InCommon Asien: CARSI, Oman KnowledgeID Australien: MAMS Folie 27

28 Shibboleth im Einsatz an der RWTH Einsatz an der RWTH seit 2006 Mittlerweile über 40 Anwendungen an Shibboleth angebunden Telefonkonferenzsystem des RZ Gigamove Dienst zum Austausch großer Daten Verschiedene Online Bibliotheken Matse-Dienste RWTH also eigene Föderation, wobei Metadaten von RZ verwaltet werden Folie 28

29 Alternativen und Zusammenfassung Folie 29

30 Alternativen - OpenID Weit verbreitete Software, die SSO Funktionalität bietet Wird u.a. von und verwendet Wichtigster Unterschied: Shibboleth föderativer Ansatz OpenID nutzerzentrierter Ansatz Vorteile: z.b. bleibt OpenID Account lebenslang bestehen und ist nicht an Zugehörigkeit zu einer Organisation gebunden Jedoch: Shibboleth hat sich im Hochschulbereich als Technologie durchgesetzt Folie 30

31 Zusammenfassung Einsatz von Shibboleth seit 2003 weltweit in der Praxis bewährt Sind evtl. Startschwierigkeiten überwunden, kommen Vorteile zur Geltung Shibbolisierung von auch von bereits bestehenden Webdiensten lässt sich bequem realisieren Datensicherheit wird verbessert und Nutzer sparen Zeit Zusammenarbeit mit anderen Organisationen wird vereinfacht Keine Alternative, die einen föderativen Ansatz gleichwertig unterstützt Folie 31

32 Vielen Dank für ihre Aufmerksamkeit Folie 32