Shibboleth

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

„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)

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

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

Single-Sign-On Verschiedene Typen

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

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

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

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

SAML: Assertion Bsp. Assertion codiert im Prinzip folgende Informationen  The assertion ("b07b804c-7c29-ea f3d6f7928ac") was issued at time " T09:22:05Z" by identity provider ( regarding subject (3f7b3dcf ecd-92c8-1544f346baf8) exclusively for service provider (

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

SAML: Bindings Bindings  SAML SOAP Binding  Reverse SOAP Binding  HTTP Redirect Binding  HTTP Post Binding  HTTP Artifact Binding  SAML URI Binding HTTP Redirect Binding  aJtZ1BqsURRC2bbw95ivc5Am3TJrXPffmmLY3%2FA15Pzuyf33On8XJXBCaxTRmeEhT EJQBdmr%2FRbRp63K3pL5rPhYOpkVdYb%2FCon%2BC9AYfDQRB4WDvRvWWksVoY 6ZQTWlbgBBZik9%2FfCR7GorYGTWFK8pu6DknnwKL%2FWEetlxmR8sBHbHJDWZqO KGdsRJM0kfQAjCUJ43KX8s78ctnIz%2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2%2F BK5MNo1FdgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1 CWJgqanfl0%2Bin8xutxYOvZL18NKUqPlvZR5el%2BVhYkAgZQdsA6fWVsZXE63W2itrT Q2cVaKV2CjSSqL1v9P%2FAXv4C

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

Security Assertion Markup Lang.

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

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

Zusammenspiel (einfach) Vor Autorisierung Nach Autorisierung

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: ( )

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

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

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

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

Shibboleth: Metadata Beispiel

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

Shibboleth: Architektur Entspricht dem Standard SSO

Shibboleth: Kommunikation

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

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

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)

Implementierte Profile & Protokolle

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

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

SP: Metadata Beispiel

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

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

SP: SHAR & SHIRE

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

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

SP: Config shibboleth2.xml

SP: Config attribute-map.xml

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

IdP: Metadata Beispiel

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

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

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

Big Picture

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

Praxis: Kommunikation

Praxis: Bereits Autorisiert

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

Sicherheitsaspekte Session Handling „Trust Management“ SAML Metadata Problem

Vulnerability Matrix (IdP)

Vulnerability Matrix (SP)

„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

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“

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“

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

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

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

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

Live Demo

Vielen Dank für Ihre Aufmerksamkeit