Shibboleth. Agenda Shibboleth? Single-Sign-On SAML & Co. Shibboleth  Eigenschaften  Architektur & Komponenten  Implementierungen  Kommunikation 

Präsentation zum Thema: "Shibboleth. Agenda Shibboleth? Single-Sign-On SAML & Co. Shibboleth  Eigenschaften  Architektur & Komponenten  Implementierungen  Kommunikation "—  Präsentation transkript:

1 Shibboleth

2 Agenda Shibboleth? Single-Sign-On SAML & Co. Shibboleth  Eigenschaften  Architektur & Komponenten  Implementierungen  Kommunikation  Sicherheitsaspekte / Vor- & Nachteile  Vergleich & Ausblick Zusammenfassung

3 „Shibboleth“ Bedeutet wörtlich aus dem hebräischen „Getreideähre“ Ein Wort, Klang oder Gegenstand, welcher von einer nicht vertrauten Person nicht ausgesprochen oder verstanden (verwendet) werden kann Im WWII wurde das Wort als Shibboleth gegen nicht identifizierte Personen verwendet (Kennwort)

4 „Shibboleth“ Verfahren zur verteilten  Authentifizierung (Nachweis)  Autorisierung (Zustimmung)  von Webanwendungen und Services  Web Single-Sign-On – kennen wir alle

5 Single-Sign-On Einmalige Authentifizierung für mehrere Dienste Beschränkt auf einen lokalen „Zugriffspunkt“, z.B. Arbeitsplatz bzw. Organisation Vorteile  Komfortabel für End Nutzer  Leichte Integration  Bessere Sicherheit? Wichtige Begriffe  Web Browser  SAML  IdP  SP  WAYF  EntityID  Metadata  Attributes

6 Single-Sign-On Verschiedene Typen

7 Security Assertion Markup Lang. XML Framework zum Austausch von  Authentifizierung- und Autorisierungsinformationen  Verteilte Transaktionen Von OASIS entwickelt (2001) Aktuell Version 2.0 Kern-Eigenschaften  Open Source  Robust  Sicher  Standard

8 Security Assertion Markup Lang. Anwendungsfälle  Web Single- Sign-On  Attributbasierte Autorisierung  Verbessern der Sicherheit von Web Services (vor allem SOAP)

9 Security Assertion Markup Lang. Komponenten  SAML Assertion (Aussagen)  SAML Protokoll  SAML Bindings  SAML Profile Sicherheit  TLS 1.0+  XML Signaturen & XML Encryption

10 SAML: Assertion Assertion-Typen  Authentication Statements  Attribute Statements  Authorization Decision Statements Inhalte  Issuer  Signature  Subject  Conditions  AuthnStatement  AttributeStatement

11 SAML: Assertion Bsp. Assertion codiert im Prinzip folgende Informationen  The assertion ("b07b804c-7c29-ea16-7300- 4f3d6f7928ac") was issued at time "2004-12- 05T09:22:05Z" by identity provider (https://idp.example.org/SAML2) regarding subject (3f7b3dcf-1674-4ecd-92c8-1544f346baf8) exclusively for service provider (https://sp.example.com/SAML2).

12 SAML: Protokoll Protokolle  Assertion Query and Request Protocol  Authentication Request Protocol  Artifact Resolution Protocol  Name Identifier Management Protocol  Single Log-out Protocol  Name Identifier Mapping Protocol ARP-Beispiel

13 SAML: Bindings Bindings  SAML SOAP Binding  Reverse SOAP Binding  HTTP Redirect Binding  HTTP Post Binding  HTTP Artifact Binding  SAML URI Binding HTTP Redirect Binding  https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXv aJtZ1BqsURRC2bbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhT EJQBdmr%2FRbRp63K3pL5rPhYOpkVdYb%2FCon%2BC9AYfDQRB4WDvRvWWksVoY 6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8sBHbHJDWZqO KGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2F BK5MNo1FdgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1 CWJgqanfl0%2Bin8xutxYOvZL18NKUqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrT Q2cVaKV2CjSSqL1v9P%2FAXv4C

14 SAML: Profile Profile  SSO  Name Identifier Mapping  Artifact Resolution  SAML Attribute Profile  Assertion Query / Request Profile  …

15 Security Assertion Markup Lang.

16 Service Provider (SP) Partei, welche den zu nutzenden Dienst bereitstellt Besitzt (normalerweise) die zu schützenden Ressourcen

17 Identity Provider (IdP) Autorisierung Dienst „Service Provider“ der Identität Profile speichert und Autorisierungs-Dienst für andere Provider anbietet Beispiele

18 Zusammenspiel (einfach) Vor Autorisierung Nach Autorisierung

19 Shibboleth Implementierung von SAML  Web Single Sign On  „Föderativ“  Konfigurierbarer Austausch von Attributen Entwickelt von Internet2/MACE  Middleware Architecture Committee for Education  non-profit  Michigan, USA  500 Mitglieder aus Bildung, Industrie und Forschung Erster Release im Jahr 2003 Aktuelle Version: 3.0.0 (2014-12-22)

20 Shibboleth “A system for the secure exchange of interoperable authorization information which can be used in access control decisions ”

21 Shibboleth: Attributes Informationen (über den Nutzer), die vom Identity Provider bereitgestellt werden Informationen (Auszug)  Mail Adresse  Telefonnummer  Gruppe  Rolle  Spezifische Privilegien

22 Shibboleth: Attributes Konfiguriert in einer attribute-map.xml Welche Daten mit welchen SP geteilt werden, ist konfigurierbar  “attribute filter policies” Beispiel

23 Shibboleth: Metadata Grundlage für SAML Legt fest, wie SP und IdP miteinander kommunizieren „Konfigurationsdaten“ (XML) Beschreibt technische Eigenschaften der SPs und IdPs  Enthält die EntityID  Lesbaren Namen und Beschreibung  URL Mapping  Legt fest, welche Nachrichten an welche URL geschickt werden sollen  Legt Sicherheitsmechanismen zum Erstellen und Verifizieren von Nachrichten fest

24 Shibboleth: Metadata Beispiel

25 Shibboleth: EntityID URI zum Identifizieren von Applikation und Diensten über mehrere „Federations“ URI  urn:oasis:names:tc:SAML:2.0:nameid-format:entity

26 Shibboleth: Architektur Entspricht dem Standard SSO

27 Shibboleth: Kommunikation

28 Discovery Service (WAYF) Lokalisierungsdienst ist optional Ziel: „den Nutzer zum IdP schicken“

29 Shibboleth: Federations Gruppe von IdP‘s und SP‘s die eine gemeinsame „Regeln“ haben Wird nicht verpflichtend benötigt Vereinfacht aber das Zusammenspiel i.d.R eine „große Datei“ mit allen Metadaten Wichtiges Merkmal von Shibboleth

30 Shibboleth: Philosophie & „Goals“ „adherence to standards” Grenzen einer Organisation überschreiten (Federations) Kontrolle der Nutzerinformationen  Welche Informationen sind für wenn sichtbar Möglichst „Statuslos“ (stateless)

31 Implementierte Profile & Protokolle

32 Technik & Systemanforderungen Shibboleth Service Provider  Web Server Module  Unterstützt werden  Apache HTTPD  IIS  Java System Web Server (Sun) Shibboleth Identity Provider  Java Web Application  Container  Apache Tomcat  Mortbay Jetty  Jboss  Existierenden Authentifizierung Prozess

33 Shibboleth Service Provider (SP) Sessions Metadata Attr. Zugriffskontrolle Komponenten  SHIRE  SHAR  RM

34 SP: Metadata Beispiel

35 SP: SHIRE Shibboleth Indexical Reference Establisher  Keine Nutzerinformationen  Keine Homepage des Nutzers Zuständig für Kontext und Session Initialisierung Akzeptiert und Validiert Assertion Interagiert mit WAYF … oder ist selbst WAYF

36 SP: SHAR Shibboleth Attribute Requestor Regelt Zugriff auf die Attribute Benötigt ein „Handle“ von SHIRE

37 SP: SHAR & SHIRE

38 SP: Ressource Manager Zu schützender Bereich Akzeptiert Attribute von SHAR Vergleicht eingehende Attribute mit den Policies  Erlaubt oder verneint Zugriff

39 SP: Setup 1. Shibboleth Package installieren 2. Konfigurationen 1.Shibboleth2.xml 2.Attribute-map.xml 3.IdP Metadaten importieren 3. Server Konfiguration anpassen 1.Security 2.Routing 3.Rollen

40 SP: Config shibboleth2.xml

41 SP: Config attribute-map.xml

42 Shibboleth Identity Provider „Vertrauenswürdige Parteien“ Sessions Metadata Attribute Komponenten  „Runtime“  AA  HS

43 IdP: Metadata Beispiel

44 IdP: Attribute Authority Erhält Attribut Anfragen von SHAR und gibt Attribute zurück Prüft, welche Attribute zugreifbar sind Management Komponente der Zugriffsregeln Arbeitet wie eine „Datenbank“ Unterschiedliche Regeln für unterschiedliche Ziele und Nutzer

45 IdP: Handle Server Regelt die eigentliche Authentifizierung (AA) Interagiert mit SHIRE des SP Speichert ein Mapping der „Handles“ zu den Nutzern

46 IdP: Setup 1. Vorbereitung 1.SSL aufsetzen 2.SAML Metadaten der SPs sammeln 3.Servlet Container aufsetzten 2. IdP Package installieren 3. Automatisch werden erstellt 1.IdP EntityID 2.Schlüsselpaar und selbstsigniertes Zertifikat (nicht für HTTP Kommunikation) 3.Initiale IdP Metadaten 4.Basiskonfigurationsdateien

47 Big Picture

48

49 Praxis: HAW Landshut „StudiSoft Portal“  SP ist HAW Würzburg  IdP ist HAW LA

50 Praxis: Kommunikation

51

52

53

54

55

56

57

58

59

60

61

62 Praxis: Bereits Autorisiert

63

64 Warum Shibboleth Robusteste Implementierung Getestet & Geprüft Open Source Einfach Große Community Erweiterbarkeit

65 Sicherheitsaspekte Session Handling „Trust Management“ SAML Metadata Problem

66 Vulnerability Matrix (IdP)

67 Vulnerability Matrix (SP)

68 „Kenntnisse“ Technisch  Root Access  NTP IdP  Java (Professional)  LDAP  Verständnis von SSL, Netzwerk, HTTP und Web-Application im Allgemeinen SP  Standard OS Verständnis  XML und Public Key Kryptographie Verständnis  Verständnis von Web Authentifizierung  Verständnis von Server Konfiguration

69 Vorteil Für End Anwender  Zeitersparnis  Muss sich nur ein Passwort merken Für Administratoren  Sicherheitsgewinn  Passwort wird nur einmal übertragen  Phishing wird erschwert (nur an einer Stelle möglich)  Beim Entfernen oder Aktualisierungen muss nur ein Konto betrachtet werden „Federations“

70 Nachteile (Bezug zu SSO) Bei gestohlener Identität stehen alle Systeme für den Angreifer offen Akzeptanz der Nutzer nötig Verfügbarkeit eines Services hängt von zwei Systemen ab (selbst + SSO) Sign-off ist oft nicht implementiert Der SSO Anbieter kann den Verlauf verfolgen Bei Fehlern im Workflow (oder Benutzerfehleingaben) ist der Nutzer auf allen Systemen gesperrt Keine wirkliche Unterstützung von Non-Web/HTTP Protokollen „Vulnerability Matrix“

71 Vergleich zu … OAuth  OAuth für Autorisierung (Zugriff auf Nutzerdaten erlauben)  Shibboleth Autorisierung und Authentifizierung (Focus auf Authentifizierung)  OAuth ist weniger „standardisiert“ und „offener“  Shibboleth definiert Protokoll und Token Format (OAuth nur Protokoll)  „Federations“ nur in SAML/Shibboleth OpenID  Beide für Authentifizierung  Technische Unterschiede bei Authentifizierung  Zugriff auf Nutzerdaten unterschiedlich  Shibboleth benötigt zwingende Verbindung („Trust“) zwischen SP und IdP, im Gegensatz zu OpenID  Daten in OpenID stammen nicht immer von einem IdP, sondern vom Nutzer selbst

72 Vergleich zu … PKI  Shibboleth benutzt PKI für “Trust Model”  Zum “Turst Model”  Shibboleth: collaborative (fexibel, schnell, Privatsphäre)  PKI: legal (bindend, hierarchisch, formal)  PKI primär für Identitätsprüfung  Shibboleth für Autorisierung  PKI kann Shibboleth für Autorisierung nutzen

73 Aussicht SP Modul für IIS 7+ Updates  Cache Alternatives  IdP Features  Java SP OpenId Connect Integration Dokumentation

74 Zusammenfassung SSO? SAML? Shibboleth? Funktionsweise? Vorteile? Nachteile?

75 Live Demo https://www.switch.ch/aai/demo/

76 Vielen Dank für Ihre Aufmerksamkeit https://shibboleth.net/ https://wiki.shibboleth.net https://www.switch.ch/aai/demo/expert/ https://en.wikipedia.org/wiki/SAML_2.0 http://planet.jboss.org/post/saml_behind_the_wheel https://dev.e-taxonomy.eu/trac/wiki/ShibbolethProtocol