Ein Überblick Michael Jäger 15. Juni 2010 1 / 55 Inhalt 1 Begriffe Web Single Sign-On Identität und Web-SSO SSO Szenarien Föderative Identitätsverwaltung SSO und SOA 2 Identitätsverwaltungssysteme Überblick 3 Architektur Bindings Implementierung 4 Fazit 2 / 55
Begriffe Sicherheitsdomäne Bereich mit zentralisiertem Identitätsmanagement flach oder hierarchisch Föderation Gruppe von Systembetreibern, i.d.r. mehrere Unternehmen kooperatives, domänenübergreifendes Identitätsmanagement Webbrowser Single Sign-On (Web SSO) SSO beim Surfen Kontext: Internet, Unternehmen, Föderation Enterprise SSO (ESSO) Dezentrale Sicherheitsdomänen SSO auch für nicht-interaktive Anwendungs-Szenarien (z.b. Webservices) 3 / 55 Web Single Sign-On Die gute alte Zeit: Surfen ohne Zugangsbeschränkungen 4 / 55
Web Single Sign-On Zunehmende Verknüpfung der Angebote 5 / 55 Web Single Sign-On Login-Barrieren 6 / 55
Web Single Sign-On Login-Barrieren 7 / 55 Web Single Sign-On Login-Barrieren 8 / 55
Web Single Sign-On Login-Barrieren: Sicherheitsrisiko für Unternehmen 9 / 55 Identität und Web-SSO Identität 10 / 55
Identität und Web-SSO Im Internet ist Max Meier manchmal nicht er selbst 11 / 55 Identität und Web-SSO Was ist Digitale Identität? Digitales Subjekt Eine Entität (Mensch, Organisation, Computer) hat digitale Repräsentanten Digitales Subjekt: Digitaler Repräsentant einer Entität mit endlicher Menge von Identitätsattributen Digitale Identität Assoziation eines digitalen Subjekts mit einer Entität Kontroverse: Objektiv oder subjektiv? Digitale Identität ist eine objektive und beweisbare Eigenschaft Digitale Identität ist ein Verhältnis zwischen einem digitalen Subjekt und einem Beobachter 12 / 55
Identität und Web-SSO Single Sign-On und Digitale Identität SSO assoziiert unterschiedliche digitale Subjekte mit derselben Entität The entity may wish to be seen as a single customer of a group of financial institutions and may or may not want a new identity with which to unite them. [Identipädia] 13 / 55 Identität und Web-SSO Identität und Benutzerkonten 14 / 55
SSO Szenarien Szenario: Single Sign-On im Portal 15 / 55 SSO Szenarien Rollen: Identity Provider und Service Provider 16 / 55
SSO Szenarien Was sind Identitäts-bezogene Informationen? 17 / 55 SSO Szenarien Was sind Identitäts-bezogene Informationen? 18 / 55
SSO Szenarien Was sind Identitäts-bezogene Informationen? 19 / 55 SSO Szenarien Was sind Identitäts-bezogene Informationen? 20 / 55
SSO Szenarien Was sind Identitäts-bezogene Informationen? 21 / 55 SSO Szenarien Szenario IdP initiiert SSO 22 / 55
SSO Szenarien Szenario SP initiiert SSO 23 / 55 SSO Szenarien Szenario SP initiiert SSO mit IdP-Lokalisierung 24 / 55
Föderative Identitätsverwaltung : Föderative Verwaltung digitaler Identität 25 / 55 Föderative Identitätsverwaltung Domänen-übergreifende Verarbeitung von Identitäts-Information: Verteilte Speicherung und Verwaltung Dynamischer Austausch Delegation der Verarbeitung Mehr als ESSO Verbund mit kooperierenden Partnern, Verträge Dynamische IdP-Entdeckung Hosting-Problematik: Id-Management-Provider? 26 / 55
SSO und SOA SSO in einer SOA 27 / 55 SSO und SOA SSO in einer SOA 28 / 55
SSO und SOA Wozu Identitätsmanagement? Nutzer mehr Sicherheit mehr Komfort Service Provider Aufwandsreduktion durch Delegation Bessere Servicequalität bei föderativen Angeboten mehr Sicherheit 29 / 55 Identitätsverwaltungssysteme Überblick Identitätsverwaltungssysteme Quelle: Maler, Drummond: The Venn of Identity, IEEE SECURITY & PRIVACY 2008, S. 16ff 30 / 55
Architektur - Security Assertion Markup Language Rahmenwerk für Austausch von Sicherheits-Informationen Verantwortlich: OASIS Security Services TC seit 2000, aktuelle Version: 2.0, Web: http://saml.xml.org Ideengeber zu 2.0: Liberty Alliance Project (heute Kantara) eingebettet in WS-Security, unabhängig davon nutzbar breite Unterstützung durch Industrie Info: http://docs.oasis-open.org/security/saml/v2.0 31 / 55 Architektur -Begriffe Rollen Authority, Asserting Party (AP): Identity Provider Relying Party (RP): Service Provider -Requestor/Responder: Rollen in einer -Konversation -Assertion Paket mit Aussagen des Systems ( Authority) über ein Subjekt Authentication Assertion: Subjekt hat sich authentisiert Attribute Assertion: Subjekt hat (beliebige) Attribute (z.b. Rollen) Authorization Decision: Entscheidung über Zugriffserlaubnis Digital signiert, bei Bedarf verschlüsselt 32 / 55
Architektur -Begriffe Name Identifier eindeutiger Bezeichner für Subjekt oder AP Namensräume für Föderationen / Qualifizierte Bezeichner Authentisierungskontext Zusatzinformationen über verwendete Authentisierungstechniken Viele vodefinierte Kontextklassen, z.b. Internetzugriff mit Passwort, X.509, Kerberos, Mobilfunkzugriff mit PIN,... 33 / 55 Architektur -Bausteine 34 / 55
Architektur -Architektur Quelle: Maler, Drummond: The Venn of Identity, IEEE SECURITY & PRIVACY 2008, S. 16ff 35 / 55 Architektur -Profile 36 / 55
Bindings Bindings für alle Anwendungsfälle Ein Binding standardisiert die Abwicklung einer -Konversation auf der Transportebene Problem -Requestor und -Responder müssen in bestimmten Anwendungsfällen über Vermittler kommunizieren Beispiel: Client kommuniziert mit SP und IdP -Dialog zwischen SP und IdP muss vom Client vermittelt werden Primitiver Client (Webbrowser) hat nur beschränkte Vermittlungsfähigkeiten! 37 / 55 Bindings Client als Vermittler im -Dialog 38 / 55
Bindings -Konversation zwischen SOAP Webservices Binding: SOAP über HTTP -Nachrichten als Rumpf von SOAP-Nachrichten -Konversation mit einfachem Webbrowser als Vermittler Problem: Webbrowser als -Vermittler? Lösungen: HTTP-Redirect Binding HTTP-Proxy übernimmt -Anteil -Konversation mit aufgemotztem Client Enhanced Client : leichtgewichtige -Unterstützung (Browser-Plugin) PAOS Binding anstelle von HTTP-Redirect verwendbar 39 / 55 Bindings PAOS Binding (Reverse SOAP) Quelle: OASIS 2.0 Spezifikation 40 / 55
Bindings HTTP Redirect Binding Vermittlung des -Dialogs durch Webbrowser -Nachrichten werden im URL codiert Client wird über HTTP-Redirects zum Dialogpartner weitergeleitet Ende-zu-Ende-Sicherheit nötig! 41 / 55 Bindings HTTP Redirect Binding Quelle: OASIS 2.0 Spezifikation 42 / 55
Bindings HTTP POST Binding Vermittlung des -Dialogs durch Webbrowser -Nachricht ist in verstecktem Formularfeld codiert Formularübermittlung via HTTP-POST -Dialogschritte können vor dem Client versteckt werden: Javascript onload -Aktion submit Verwendungsszenarien ähnlich HTTP Redirect 43 / 55 Bindings HTTP POST Binding Quelle: OASIS 2.0 Spezifikation 44 / 55
Bindings Artifact Binding Probleme HTTP Redirect: Längenbeschränkung für URLs HTTP Redirect/POST: Client soll ggf. -Nachricht nicht sehen Lösung: Kombination mehrerer Bindings Client vermittelt Referenz auf Nachricht (per Redirect/POST) Artifact: Die Referenz auf die Nachricht Nachricht selbst wird ohne Client-Vermittlung kommuniziert: Artifact Resolution Protocol / SOAP-Binding 45 / 55 Bindings Enhanced Client/Proxy Profile Quelle: OASIS 2.0 Spezifikation 46 / 55
Implementierung Implementierung von 2.0 ist das weltweit am häufigsten eingesetzte Föderierungsprotokoll Kommerzielle Systeme Entrust IdentityGuard IBM Tivoli Federated Identity Manager (TFIM) Oracle/Sun Java System Federated Access Manager Microsoft Active Directory Federation Services Novell Access Manager 3.1 PingFederate SAP NetWeaver Identity Management Siemens DirX Access 47 / 55 Implementierung Open Source Implementierungen Auswahl OpenSSO (Sun Microsystems) Lasso - Liberty Alliance Single Sign-On (Java, Perl, Python and PHP) Open (Internet2, für C++ and Java) Shibboleth (Internet2) Ping SourceID ZXID Open Source IdM for the Masses (C, Perl, PHP, Java) simplephp (für PHP, Shibboleth-kompatibel) 48 / 55
Implementierung Shibboleth Shibboleth ist ein -Projekt der Internet2-Initiative für Forschung und Lehre Basis: Open Bausteine: Identity Provider Service Provider (Apache Modul) IdP-Lokalisierungsdienst 2.0 vollständig implementiert 49 / 55 Implementierung DFN-AAI - Authentifikations- und Autorisierungs-Infrastruktur Zitat aus der Homepage: https://www.aai.dfn.de Die DFN-AAI-Föderation ist ein Dienst des DFN-Vereins für wissenschaftliche Einrichtungen (Universitäten, Institute) und Anbieter (kommerziell und nicht kommerziell). Sie schafft das notwendige Vertrauensverhältnis sowie einen organisatorischen und technischen Rahmen für den Austausch von Benutzerinformationen zwischen Einrichtungen und Anbietern. Anwendungen, welche die DFN-AAI nutzen sind z.b. Recherche-Datenbanken, Grid-Computing (z.b. D-Grid), Portale (z.b. ReDI), DFG-Nationallizenzen, Verwaltungssysteme, e-science und e-learning-systeme. 50 / 55
Fazit Fazit ist Stand der Technik Domänen-übergreifende Sicherheit ist eine must have -Anforderung Delegation von Identitätsmanagement vereinfacht SP-Anwendungen skalierbares Identitätsmanagement möglich Welche Technologie? Für ESSO und föderierte Identität ist 2.0 derzeit das einzige skalierbare Rahmenwerk Wie benutzen? Einsatz von an der FH auf unterschiedlichen Ebenen möglich: Eigenimplementierung: mittels JAXB-Tools kein Hexenwerk Verwendung offener -Bibliotheken wie Open Einsatz von kompletten -Systemen wie Shibboleth Verwendung der DFN-AAI Infrastruktur 51 / 55 Fazit Wo stehen wir? Viele Login-Barrieren! 52 / 55
Fazit Verteilte Identitätsverwaltung? 53 / 55 Fazit Wo wollen wir hin? 54 / 55
Fazit Weiterführende Literatur Identipädia http://identityaccessman.blogspot.com/ engl. Wikipedia: Artikel zu digital identity 55 / 55