Fakultät für Informatik Professur für Rechnernetze und verteilte Systeme Studienarbeit Authentifizierungs- und Informationsdienst Verfasser: Jens Wegener 30. Juni 2004 Prüfer: Betreuer: Prof. Dr.-Ing. habil. Uwe Hübner Dipl.-Inf. Ronald Schmidt
Inhaltsverzeichnis Abkürzungsverzeichnis iii 1 Aufgabenstellung 1 2 Einleitung 3 2.1 Motivation............................ 3 2.2 Identität und Authentifizierungsverfahren........... 4 2.3 Attribute eines Nutzers..................... 5 2.4 Situation und Verbesserungsmöglichkeiten.......... 6 3 Anforderungen an den Identitätsmanager 7 3.1 Datenschutzrechtliche Erwägungen.............. 7 3.1.1 Anwendbares Recht................... 7 3.1.2 Einwilligung des Nutzers in die Datenweitergabe... 8 3.1.3 Form der Einwilligung................. 9 3.1.4 Anforderungen an die Datenübermittlung....... 9 3.1.5 Möglichkeit der anonymen und pseudonymen Nutzung 10 3.2 Technische Anforderungen................... 10 4 Technische Grundlagen 13 4.1 Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager............................. 13 4.2 Sicherheit der Kommunikation................. 17 4.3 Cookies............................. 18 5 Vorhandene Ansätze 21 5.1 ITS Central Authentication Service.............. 21 5.1.1 Überblick........................ 21 5.1.2 Funktionsweise..................... 22 5.1.3 Single Sign-On..................... 24 5.1.4 Erweiterungen des CAS 2.0.............. 24 5.2 Microsoft.NET Passport.................... 25 i
Inhaltsverzeichnis 5.2.1 Überblick........................ 25 5.2.2 Funktionsweise der Authentifizierung......... 26 5.2.3 Single Sign-On..................... 27 5.3 Liberty Alliance Project.................... 29 5.3.1 Überblick........................ 29 5.3.2 Architektur....................... 30 5.4 Shibboleth/Internet2...................... 33 5.4.1 Überblick........................ 33 5.4.2 Aufbau und Funktionsweise.............. 34 5.4.3 Verfügbare Implementierung.............. 38 5.5 Bewertung der betrachteten Ansätze............. 38 5.5.1 ITS Central Authentication Service.......... 38 5.5.2 Microsoft.NET Passport................ 38 5.5.3 Liberty Alliance Project................ 39 5.5.4 Shibboleth........................ 39 5.6 Nicht betrachte Ansätze.................... 40 5.7 Abgrenzung der weiteren Arbeit................ 40 6 Testbetrieb von Shibboleth 43 6.1 Vorbemerkungen........................ 43 6.2 Installation des Identitätsverwalters.............. 44 6.3 Installation des Anbieter-Server................ 45 6.4 Schlüssel und Zertifikate.................... 46 6.5 Konfiguration von Shibboleth................. 46 6.5.1 Konfiguration des Identitätsverwalters........ 47 6.5.2 Konfiguration des Anbieter-Servers.......... 48 6.6 Testergebnisse.......................... 49 6.7 Offene Fragen.......................... 50 7 Schlussfolgerung 51 Literaturverzeichnis 53 ii
Abkürzungsverzeichnis AA............ AAP.......... AFS........... AQH.......... AQM.......... ARM.......... ARP.......... BDSG......... CA............ CAS.......... DNS.......... GG............ HS............ HTML........ HTTP........ IP............. ITS........... JSP........... MACE........ MDStV....... NAT.......... Attribute Authority Attribute Acceptance Policy Andrew File System Attribute Query Handle Attribute Query Message Attribute Response Message Attribute Release Policy Bundesdatenschutzgesetz Certificate Authority Central Authentication Service Domain Name System Grundgesetz Handle Service Hyper Text Markup Language Hyper Text Transfer Protocol Internet Protocol Information Technology Services Java Server Pages Middleware Architecture Committee for Education Mediendienste-Staatsvertrag Network Address Translation iii
Abkürzungsverzeichnis PHP.......... PHP Hypertext Preprocessor PUID......... Microsoft.NET Passport Unique ID RM........... Resource Manager SächsDSG.... Sächsisches Datenschutzgesetz SächsHG..... Gesetz über die Hochschulen im Freistaat Sachsen SächsVerf... Verfassung des Freistaates Sachsen SAML........ Security Assertion Markup Language SHAR......... Shibboleth Attribute Requester SHIRE........ Shibboleth Indexical Reference Establisher SSL........... Secure Socket Layer SSO........... Single Sign-On TCP.......... Transport Control Protocol TDDSG....... Teledienste-Datenschutzgesetz TDG.......... Teledienstegesetz TLS........... Transport Layer Security TUC.......... Technische Universität Chemnitz URI........... Uniform Resource Identifier URL.......... Uniform Resource Locator URZ.......... Universitätsrechenzentrum WAYF........ Where Are You From? (-Dienst) WWW........ World Wide Web XML.......... extensible Markup Language XNS.......... extensible Name Service iv
1 Aufgabenstellung An der TU-Chemnitz werden auf verschiedenen Servern dezentral Dienste per HTTP angeboten, die einerseits die Nutzer zuverlässig authentifizieren müssen und andererseits auch persönliche Informationen dieser Nutzer benötigen. Dies führt zu einer Mehrfacherhebung von personenbezogenen Daten, obwohl die zentrale Nutzerdatenbank des Universitätsrechenzentrums bereits viele dieser Informationen enthält und ohne dass die Daten erhebende Stelle auf die Korrektheit der Daten vertrauen kann. Für die dezentrale Authentifizierung wurden bisher mehr oder weniger elegante Hilfskonstruktionen eingesetzt. Diese sind möglicherweise nicht robust gegen Änderungen an dritter Stelle. Außerdem nutzen sie unter Umständen Verfahren, die keinen ausreichenden Schutz der vertraulichen Kennworte gewährleisten. Das Ziel dieser Arbeit ist es, einen Dienst zu schaffen, der als vertrauenswürdiger Vermittler zwischen zentraler Nutzerdatenbank, Daten anfordernder Stelle und Nutzer auftritt und der anfordernden Stelle die Korrektheit der Authentifizierung und der Nutzerdaten zusichert. Besonderes Augenmerk wird auf die damit verbundenen datenschutzrechtlichen Aspekte gelegt. Als Vorarbeit sind vorhandene Ansätze zu recherchieren und zu bewerten, zum Beispiel: Shibboleth/Internet2 (http://shibboleth.internet2.edu) ITS Central Authentication Service (http://www.yale.edu/tp/auth).net Passport (http://www.passport.net) Liberty Alliance (http://www.projectliberty.org) 1
1 Aufgabenstellung 2
2 Einleitung 2.1 Motivation An der Technischen Universität Chemnitz (TUC) werden über das Internet, vor allem per WWW, verschiedene Dienste angeboten. Dazu zählen zum Beispiel: das Kursverwaltungssystem des Sprachenzentrums KuVeS 1 das Skriptportal des Instituts für Print- und Medientechnik 2 der Skriptshop des Fachschaftsrats Informatik 3 zugriffsbeschränkte Bereitstellung von Lehrmaterialien zum Download 4 private nichtkommerzielle Dienste zur Organisation von Grill 5 - und Pizzabestellungen 6 und zeitlichen Koordination von Gremiumssitzungen 7 und anderen Veranstaltungen 8 Die Bereitstellung dieser Dienste erfolgt dabei jeweils durch Einrichtungen der Universität, einzelne Universitätsmitarbeiter oder Studenten, im Folgenden kurz durch die Anbieter. Demgegenüber stehen Personen, die diese bereitgestellten Dienste in Anspruch nehmen, sie seien im Folgenden kurz als Nutzer bezeichnet. Im Zuge des Trends, bisher konventionell angebotene Dienstleistungen auf 1 http://www.tu-chemnitz.de/sprachenzentrum/kuves/ 2 http://www.pm.tu-chemnitz.de/php/printportal/ 3 http://www.tu-chemnitz.de/fsrif/shop.php 4 etwa http://www.tu-chemnitz.de/informatik/ce/lehre/digtech.php 5 http://www-user.tu-chemnitz.de/~jaw/grill/ 6 http://hart.csn.tu-chemnitz.de/pizza/ (Zugriff nur innerhalb der TUC) 7 http://www-user.tu-chemnitz.de/~mie/zeitplan/ 8 http://www-user.tu-chemnitz.de/~geni/menatwork/ 3
2 Einleitung Online-Systeme umzustellen, ist zudem mit einem kontinuierlichen Anstieg der Anzahl solcher Dienste zu rechnen. Die Anbieter benötigen für ihre Dienste Daten über die Nutzer. Für alle Shop -Dienste ist es zum Beispiel erforderlich festzustellen, welcher Nutzer eine bestimmte Bestellung veranlasst hat. Dienste wie das KuVeS fragen zusätzlich Matrikelnummer und Fakultät ab. Für andere Dienste kann es dagegen ausreichend sein, zu prüfen, ob ein Nutzer ein Student der TUC ist. Die benötigten Daten lassen sich damit in zwei Gruppen unterteilen: 1. die Identität des Nutzers 2. andere Daten (Attribute) über einen Nutzer 2.2 Identität und Authentifizierungsverfahren Der Begriff der Identität soll hier im Sinne eines eindeutigen Identifikators des Nutzers verstanden werden, der also jeweils nur genau einer Person zugeordnet ist. Zur Ermittlung dieses Identifikators werden Authentifizierungsverfahren eingesetzt. Es wird meist das vom Universitätsrechenzentrum der TUC vergebene Nutzerkennzeichen 9 und das zugehörige Zugangs- oder AFS-Passwort abgefragt. [30] Bei diesem Authentifizierungsverfahren muss der Nutzer dem Anbieter allerdings dahingehend vertrauen, dass dieser das übergebene Passwort nicht abspeichert und dann ggf. später sogar selbst unter der Identität des Nutzers auftritt. Einige der oben angegebenen Dienste sind zum Beispiel in PHP implementiert. Das Nutzerkennzeichen lässt sich dabei nach erfolgter Authentifizierung mittels $_SERVER[ PHP_AUTH_USER ] auswerten. Ebenso leicht kann aber, in der derzeit an der TUC betriebenen Konfiguration, auch das Passwort des Nutzers per $_SERVER[ PHP_AUTH_PW ] ermittelt werden, ohne dass der Nutzer dies bemerken würde oder verhindern könnte 10. 9 ist TUC-weit eindeutig einer Person zugeordnet 10 natürlich abgesehen davon, bestimmte Dienste nicht zu nutzen 4
2.3 Attribute eines Nutzers Vereinzelt findet man auch IP-basierte Authentifizierungsverfahren 11 oder andere anbieterspezifische Nutzer/Passwort-Systeme. 2.3 Attribute eines Nutzers Zu den Attributen eines Nutzers gehören im TUC-Bereich zum Beispiel: Name und Vorname Matrikelnummer Anschrift E-Mail-Adresse Gruppenzugehörigkeit (Mitarbeiter oder Student der TUC) Fakultätszugehörigkeit (oder sonstige Einrichtung) Telefonnummer Diese Attribute sind zum Teil für die Nutzung der Dienste der Anbieter direkt durch die Nutzer einzugeben. Einige, wie Name, E-Mail-Adresse und Fakultätszugehörigkeit, können innerhalb der TUC auch über einen LDAP- Server 12 abgefragt werden. Bei anderen Attributen muss ein Anbieter jedoch den vom Nutzer gemachten Angaben vertrauen, versehentliche oder absichtliche Fehleingaben können nicht direkt erkannt werden. Zudem muss ein Nutzer in diesen Fällen seine Daten ggf. wiederholt bei verschiedenen Anbietern eingeben. Viele der im Normalfall benötigten Attribute sind jedoch durch direkte Übernahme aus dem Datenbestand des Studentenamtes ohnehin bereits in der zentralen Nutzerdatenbank des Universitätsrechenzentrums, der MoUSe, gespeichert. [10, Datenübernahme vom Studentenamt] Andere, wie zum Beispiel die Adresse, können über das Nutzermenü 13 der MoUSe direkt vom Nutzer eingegeben werden. Fehleingaben bleiben bei diesen Attributen dann allerdings unerkannt. 11 Eine im Chemnitzer Studentennetz vergebene IP ist jeweils genau einem Nutzer zugeordnet. 12 ldap.tu-chemnitz.de 13 https://mouse.hrz.tu-chemnitz.de/user/ 5
2 Einleitung 2.4 Situation und Verbesserungsmöglichkeiten Es ergibt sich die Konstellation, dass eine dritte Instanz, nämlich das Universitätsrechenzentrum, insbesondere durch die MoUSe, über Daten verfügt, die die Anbieter für die Bereitstellung von Diensten benötigen. Sie kann zuverlässig und sicher Nutzer authentifizieren, Attribute über Nutzer bereitstellen und deren Korrektheit im oben beschriebenen Umfang zusichern. Seitens der Nutzer besteht jedoch auch ein regelmäßiges Interesse daran, dass ihre Attribute nicht frei verfügbar abgefragt werden können. Zudem können diese Daten aufgrund rechtlicher Zwänge nicht ohne weiteres an interessierte Anbieter herausgegeben werden. Eine Lösung wäre ein vom Universitätsrechenzentrum betriebener Dienst, der die Bereitstellung und den Zugriff auf die Daten geeignet regelt, im Folgenden nur noch kurz als Identitätsmanager oder auch Identitätsverwalter bezeichnet 14. Er wäre zudem für die korrekte Authentifizierung der Nutzer verantwortlich, ohne dass diese ihr Zugangs- oder AFS-Passwort gegenüber den einzelnen Anbietern offen legen müssen. 14 unter anderem auch zur besseren Unterscheidbarkeit zu den Diensten der Anbieter 6
3 Anforderungen an den Identitätsmanager 3.1 Datenschutzrechtliche Erwägungen 3.1.1 Anwendbares Recht Grundlage des Datenschutzrechtes auf Bundesebene ist das durch Rechtssprechung des Bundesverfassungsgerichts aus Art. 2 Abs. 1 Grundgesetz (GG) [39] in Verbindung mit Art. 1 Abs. 1 GG abgeleitete Grundrecht auf informationelle Selbstbestimmung. [37] In Sachsen ist ein derartiges Grundrecht explizit in der Verfassung [40] verankert 15 und auf europäischer Ebene existiert eine entsprechende Richtlinie [38], die für die nationale Gesetzgebung bindend ist. Die Ausgestaltung dieses Grundrechts erfolgt für den öffentlichen Bereich auf Bundesebene und für den nicht-öffentlichen Bereich durch das Bundesdatenschutzgesetz (BDSG) 16 [41] und für den öffentlichen Bereich in Sachsen durch das Sächsische Datenschutzgesetz (SächsDSG) [42]. Das SächsDSG gilt insbesondere auch für der Aufsicht des Freistaates Sachsen unterstehenden juristischen Personen des öffentlichen Rechts. 17 Des Weiteren finden sich Regelungen zum Datenschutz in einer Reihe weiterer Gesetze und Verordnungen, die als Spezialregelungen dem BDSG bzw. dem SächsDSG vorgehen. 18 Hinsichtlich der Hochschulen in Sachsen und damit auch der Technischen Universität Chemnitz wäre hier das Gesetz über die Hochschulen im Freistaat Sachsen (SächsHG) 19 [43] zu nennen. 15 vgl. Art. 33 der Verfassung des Freistaates Sachsen (SächsVerf) 16 vgl. 1 Abs. 2 BDSG 17 vgl. 2 Abs. 1 SächsDSG 18 vgl. 1 Abs. 3 BDSG und 2 Abs. 4 SächsDSG 19 konkret 106 SächsHG 7
3 Anforderungen an den Identitätsmanager Auf die Dienste der Anbieter kann das Teledienstegesetz (TDG) [44] und damit auch das Teledienste-Datenschutzgesetz (TDDSG) [45] bzw. der Mediendienste-Staatsvertrag (MDStV) [46] anwendbar sein. Die Einhaltung der für sie geltenden rechtlichen Vorschriften ist jedoch alleinige Angelegenheit der Anbieter und bedarf daher hinsichtlich des Identitätsmanagers hier keiner tief greifenden Erörterung. 3.1.2 Einwilligung des Nutzers in die Datenweitergabe Die in der MoUSe gespeicherten personenbezogenen Daten werden für jeden Studenten zum Teil direkt aus dem Datenbestand des Studentenamtes übernommen (siehe Abschnitt 2.3). Dabei handelt es sich um nach 106 Abs. 1 SächsHG erhobene und weitergegebene 20 Daten. Sie dürfen unter anderem für die Teilnahme an Lehrveranstaltungen und die Nutzung von Hochschuleinrichtungen verarbeitet werden. Inwieweit einzelne in der Einleitung genannte Dienste und Anbieter unter diese Ermächtigung fallen, kann offen bleiben, da sie jedenfalls nicht auf alle dort genannten Beispiele anwendbar ist. Ansonsten ist die Übermittlung und Nutzung dieser Daten im Normalfall 21 nur aufgrund einer Rechtsvorschrift oder mit Einwilligung des Betroffenen, also des Nutzers, zulässig. 22 Mangels entsprechender Rechtsvorschriften für alle abzudeckenden Dienste und Anbieter und im Interesse einer hohen Nutzerakzeptanz erscheint es daher sinnvoll und geboten, dass der Identitätsmanager generell die Einwilligung des Nutzers in die Datenweitergabe einholt, auch wenn dies für Einzelfälle rechtlich nicht zwingend erforderlich sein sollte. Auf welchem Wege die Daten anderer Personen, also der Nicht-Studenten, in die MoUSe gelangen, ist aus der Spezifikation der MoUSe [10] nicht klar ersichtlich. Jedenfalls ist auch hier davon auszugehen, dass eine Weitergabe, wenn überhaupt, jeweils nur bei Einwilligung der betroffenen Person in Betracht kommt. 20 in Verbindung mit 2 Abs. 4 der Benutzungsordnung des Universitätsrechenzentrums der Technischen Universität Chemnitz [47] 21 Ausnahmen, wie zum Beispiel die Gefährdung der öffentlichen Sicherheit, sollen hier nicht näher betrachtet werden. 22 vgl. 106 Abs. 2 SächsHG 8
3.1.3 Form der Einwilligung 3.1 Datenschutzrechtliche Erwägungen Ein wichtiger Punkt ist die Frage, ob die Einwilligung zu ihrer Wirksamkeit der Schriftform bedarf, oder ob auch eine Zustimmung in elektronischer Form ausreichend ist. In 106 SächsHG finden sich dazu keine Angaben. Nach BDSG und SächsDSG bedarf die Einwilligung der Schriftform, soweit nicht wegen besonderer Umstände eine andere Form angemessen ist 23. Ob eine Einwilligung über das Internet als besonderer Umstand anzusehen ist, ist umstritten. [4, Seite 13] Das SächsDSG erwähnt 24 die elektronische Form explizit in Verbindung mit einer qualifizierten elektronischen Signatur, ein für den Identitätsmanager untaugliches Verfahren. Diese Arbeit geht im Folgenden davon aus, dass eine einfache elektronische Einwilligung ausreichend ist, sofern sie bestimmten Grundsätzen genügt (siehe unten) und sich der Nutzer geeignet 25 authentifiziert. Bei Annahme einer gegenteiligen Auffassung wäre ein der Einleitung entsprechender Identitätsmanager nicht sinnvoll betreibbar, da der dann damit erforderliche Zusatzaufwand in keinem Verhältnis zum Nutzen mehr stehen würde. Als Anhaltspunkt für Anforderungen an die einfache elektronische Einwilligung kann, auch wenn es hier nicht direkt anwendbar ist, das TDDSG dienen 26 : Sie muss durch eine eindeutige und bewusste Handlung des Nutzers erfolgen. Sie muss protokolliert werden. Der Nutzer muss den Inhalt der Einwilligung jederzeit abrufen können. Auf das Recht auf jederzeitigen Widerruf mit Wirkung für die Zukunft ist hinzuweisen. 3.1.4 Anforderungen an die Datenübermittlung Insoweit die Übermittlung personenbezogener Daten zulässig ist, hat sie so zu erfolgen, dass die Daten nicht unbefugt gelesen, kopiert, verändert oder 23 vgl. 4a Abs. 1 BDSG und 4 Abs. 4 SächsDSG 24 4 Abs. 5 SächsDSG 25 etwa per URZ-Nutzerkennzeichen und Zugangs- bzw. AFS-Passwort 26 3 Abs. 3 TDDSG in Verbindung mit 4 Abs. 2 und 3 TDDSG 9
3 Anforderungen an den Identitätsmanager entfernt werden können. 27 3.1.5 Möglichkeit der anonymen und pseudonymen Nutzung In die neuere Gesetzgebung eingeflossen ist das Ziel, personenbezogene Daten möglichst sparsam zu erheben und zu verarbeiten. 28 Soweit es angemessen und technisch möglich ist, ist auch eine anonyme oder pseudonyme Nutzung vorzusehen. 29 Vor allem geht es dabei auch darum, das Mitführen der vollen Identität der Betroffenen während der eigentlichen Datenverarbeitungsvorgänge zu reduzieren. [4, Seite 11] In erster Linie ist es natürlich Aufgabe und Verantwortungsbereich der Anbieter ggf. entsprechende Verfahren einzusetzen. Der Identitätsmanager könnte diese Zielstellung jedoch unterstützen, indem er bei Bedarf ermöglicht, dass nur einzelne Attribute über einen Nutzer, ohne Preisgabe seiner Identität 30, zur Verfügung gestellt werden. 3.2 Technische Anforderungen Neben den Anforderungen, die sich bereits aus datenschutzrechtlichen Erwägungen ergeben, existieren zusätzliche Anforderungen, die hinsichtlich des Identitätsmanagers beachtet werden sollten, auch in technischer Hinsicht. Verfügbarkeit: Der Identitätsmanager muss ausreichend stabil sein. Sicherlich ist es wünschenswert, dass der Identitätsmanager immer verfügbar ist und korrekt funktioniert. Es dürfte in der Praxis jedoch ausreichend sein, wenn seine Ausfallzeiten im Rahmen der üblichen Ausfallzeiten der anderen kritischen Dienste des Universitätsrechenzentrums liegen. 27 vgl. Anlage zu 9 Satz 1 BDSG (BGBl. I 2003, S.88), sinngemäß auch 9 Abs. 2 SächsDSG 28 vgl. 3a BDSG 29 vgl. 3a BDSG und 4 Abs. 6 TDDSG 30 der konkreten Person 10
3.2 Technische Anforderungen Geschwindigkeit: Anfragen an den Identitätsmanager sollten möglichst schnell beantwortet werden. Jedenfalls darf die Zusammenarbeit mit dem Identitätsmanager nicht zu übermäßigen 31 Verzögerungen bei der Nutzung der Dienste der Anbieter führen. Wartbarkeit: Der sich durch den Betrieb des Identitätsmanagers unweigerlich ergebende Zusatzaufwand für das Universitätsrechenzentrum sollte möglichst gering sein. Dies erfordert automatisierte Verfahren. 32 Offenheit und Anpassungsfähigkeit: Aufgrund des Umgangs mit personenbezogenen Daten und der sicherheitskritischen Rolle des Identitätsmanagers erscheint die Verfügbarkeit der Implementierung auch im Quellcode, schon zur Prüfung auf mögliche Sicherheitslücken, unabdingbar. Eigene Anpassungen sollten zudem lizenzrechtlich möglich sein, um sich nicht in zu starke Abhängigkeit zu einem etwaigen Hersteller zu begeben. Gleiches gilt hinsichtlich der Verwendung von offenen Protokollen. Komplexität: Eine geringe Komplexität des Identitätsmanagers erscheint anstrebenswert. Komplexe Systeme neigen im Betrieb zu Fehlfunktionen. Mögliche Fehlerquellen können im Vorfeld schwieriger erkannt werden, die Lokalisierung und Behebung von auftretenden Fehlern gestaltet sich aufwändiger. erforderliches Betriebssystem: Bei dem Identitätsmanager handelt es sich offensichtlich um einen sicherheitskritischen Dienst. Daher bedarf auch das zugrunde liegende Betriebssystem einer ständigen Wartung, insbesondere hinsichtlich neu entdeckter und zu beseitigender Sicherheitslücken. Das Universitätsrechenzentrum betreibt derzeit alle kritischen Netzdienste auf der Basis von Linux. 33 Ein zukünftiger Identitätsmanager sollte daher ebenfalls unter Linux, möglichst unabhängig von einer konkreten Distribution, betreibbar sein. Dadurch kann zusätzlicher Administrationsaufwand, der durch den Einsatz eines speziellen 31 mehr als wenige Sekunden 32 auf eine nähere Definition wird verzichtet 33 vgl. http://bb.hrz.tu-chemnitz.de 11
3 Anforderungen an den Identitätsmanager Betriebssystems nur für den Identitätsmanager entstehen würde, vermieden werden. Kosten: Die durch den Betrieb des Identitätsmanagers anfallenden Kosten sollten möglichst gering sein. Offensichtlich ist der Einsatz gewisser zusätzlicher Hardware-Ressourcen notwendig. Hinsichtlich der Software, also dem eigentlichen Identitätsmanager, verursachen unentgeltlich zur Verfügung gestellte Lösungen keine direkten Kosten. Jedoch scheiden trotzdem kommerzielle Lösungen nicht von vornherein aus. Diese könnten sich im Betrieb, zum Beispiel aufgrund besserer Wartbarkeit, letztendlich als günstiger erweisen. Eigenentwicklungen bedeuten zusätzlichen Aufwand, der sich in zusätzlichen Kosten niederschlägt. Unvergütet durchgeführte Studien- und Diplomarbeiten liefern allenfalls Realisierungsansätze, jedoch gewöhnlich keine Systeme für den sofortigen Produktionseinsatz. Zukunftssicherheit: Der Identitätsmanager sollte zukunftssicher sein. Dies betrifft vor allem die Fragen, wie die Zusammenarbeit mit zukünftigen Betriebssystemen und Anwendungen gewährleistet werden kann, welche Modifikationen dafür voraussichtlich erforderlich sind, welchen Umfang diese haben und vor allem, wer diese durchführt. Eigenentwicklungen und wenig verbreitete Lösungen sind hier wahrscheinlich im Nachteil gegenüber Standardlösungen. Anforderungen auf Nutzerseite: Der Identitätsmanager sollte auf Nutzerseite möglichst geringe Erwartungen hinsichtlich der benötigten Software stellen, insbesondere auch hinsichtlich der Features des eingesetzten Webbrowsers, wobei aber typischerweise zur Verfügung stehende Möglichkeiten 34 als zusätzliche Anforderungen hingenommen werden können. Dagegen ist die Installation zusätzlicher Software schon mangels kaum erreichbarer, breiter Portabilität abzulehnen. 34 etwa Cookies, Java-Script, Java 12
4 Technische Grundlagen In nächsten Kapitel werden einige bereits existierende Systeme untersucht. Alle haben ähnliche technische Probleme zu bewältigen, dies betrifft insbesondere die Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager und die Sicherung der Vertraulichkeit und Integrität der Kommunikation. Dabei fällt auf, dass diese Systeme in ihrer Realisierung zum Teil ähnliche Lösungen verwenden, welche in diesem Kapitel vorab betrachtet werden. 4.1 Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager Die Nutzung eines Dienstes eines Anbieters durch einen Nutzer beginnt im Sinne dieser Arbeit typischerweise damit, dass der Nutzer mit seinem WWW-Browser eine zum Dienst des Anbieters gehörende WWW-Seite aufruft. Dabei kommt das Hyper Text Transfer Protocol (HTTP) [7] zum Einsatz. Im Folgenden wird davon ausgegangen, dass dieses, wie im Internet üblich, auf TCP/IP aufsetzt. Begonnen wird mit einer HTTP- GET - Anforderung vom Nutzer an den Anbieter. Der Anbieter benötigt nun weitere Daten über den Nutzer, die er mittels des Identitätsmanagers ermitteln möchte. Vom Nutzer ist ihm nur die derzeitige IP und der Port bekannt, auf dem die Antwort auf die GET -Anforderung erwartet wird. Zur Vereinfachung sei angenommen, dass sich hinter dieser IP, über den Zeitraum des hier beschriebenen Ablaufs, nur genau dieser eine Nutzer befindet. 35 Jedenfalls dann ist der Port für Dritte ohne Bedeutung, 35 Durch die zusätzliche Übertragung geeigneter Kennungen und Schlüssel zwischen den Beteiligten wären auch mehrere Nutzer pro IP möglich, ebenso wie möglicherweise sichergestellt werden könnte, dass sich der Nutzer zwischenzeitlich nicht ändert. 13
4 Technische Grundlagen da er zur TCP-Verbindung zwischen Nutzer und Anbieter gehört. Der Anbieter könnte nun direkt mit dem Identitätsmanager kommunizieren 36 und ihm die IP des Nutzers mitteilen, mit dem Wunsch, Daten über diesen Nutzer zu erhalten. Damit der Identitätsmanager Daten über den Nutzer liefern kann, muss er zunächst selbst feststellen, um welchen konkreten Nutzer es sich handelt, der Nutzer muss sich also auf irgendeine Weise gegenüber dem Identitätsmanager authentifizieren. Dazu ist Kommunikation zwischen Nutzer und Identitätsmanager erforderlich. Der Identitätsmanager würde nun zwar die vom Anbieter erhaltene IP des Nutzers kennen und könnte damit theoretisch eine Kommunikationsverbindung zum Nutzer aufbauen. Dann wäre aber auf Seiten des Nutzers spezielle Software nötig, die solche Anfragen eines Identitätsmanagers auf einem vorher bekannten Port entgegennimmt und verarbeitet. Etwaige Firewalls zwischen Identitätsmanager und Nutzer müssten zudem so konfiguriert sein, dass ein Aufbau solcher Verbindungen vom Identitätsmanager zum Nutzer möglich ist (Abbildung 4.1). Wird nutzerseitig NAT eingesetzt, treten offensichtlich weitere, nichttriviale Probleme auf. Nutzer (WWW-Browser) Bearbeitung? 1. GET Anbieter (Dienst) Firewall Durchleitung? 3. Wer bist du? 2. Liefere mir Daten über Nutzer... (Nutzer-IP) (bekannter Port) Identitätsmanager Abbildung 4.1: einfacher Kommunikationsansatz 36 Das Protokoll sei an dieser Stelle offen gelassen. 14
4.1 Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager Man wählt daher einen anderen Weg (Abbildung 4.2). Statt direkt eine Verbindung zwischen Anbieter und Identitätsmanager aufzubauen, nutzt man die bereits bestehende Verbindung zwischen Nutzer und Anbieter, indem man als Antwort auf die GET -Anforderung des Nutzers (1.) einen Redirect 37 auf den Identitätsmanager zurückschickt, der Anbieter wird dabei geeignet kodiert mit übergeben (2.). Aufgrund dieses Redirect baut nun der Nutzer selbst eine Verbindung zum Identitätsmanager auf, indem er diesem jetzt eine GET -Anforderung schickt (3.). Nun kann über einen Zwischenschritt 38 die Authentifizierung abgewickelt werden (4.). Danach erfolgt analog, mittels eines weiteren Redirect, die Übergabe von Daten über den Nutzer vom Identitätsmanager an den Anbieter, entweder direkt oder in Form eines so genannten Ticket, das vom Anbieter beim Identitätsmanager eingereicht werden kann, um Nutzerdaten abzufragen (5. und 6.). Nutzer (WWW-Browser) 3. GET 1. GET 2. Redirect 6. GET plus Daten vom Identitätsmanager Anbieter (Dienst) 4. Authentifizierung 5. Redirect Identitätsmanager Abbildung 4.2: verbesserter Kommunikationsansatz 37 Um-/Weiterleitung auf ein neues Ziel 38 Zum Beispiel könnte der Identitätsmanager als Antwort eine HTML-Seite mit einem HTML-Formular zurückschicken, welches der Nutzer mit Nutzerkennzeichen und Passwort auszufüllen hat, und danach zurück an den Identitätsmanager sendet. 15
4 Technische Grundlagen Zur technischen Realisierung der Redirects sind verschiedene Möglichkeiten gebräuchlich 39 : HTTP-Redirect: Bei Einsatz des HTTP-Redirect wird die ursprüngliche GET -Anforderung mit einer HTTP-Antwort mit dem Statuscode 302 ( Found ) [7, Abschnitt 10.3.3] beantwortet, das gewünschte Ziel wird dabei als Location -URI gesetzt, weitere Daten können als Parameter angehängt werden. Der Browser des Nutzers reagiert auf eine solche Antwort normalerweise automatisch mit einer entsprechenden Anfrage an das neue Ziel. FORM-Redirect: Hier wird mittels einer normalen HTTP-Antwort, also Statuscode 200 ( OK ) [7, Abschnitt 10.2.1], ein gewöhnliches HTML-Dokument ausgeliefert, welches ein HTML-Formular [25, Abschnitt 17.3] enthält. Daten können dabei innerhalb der Formularfelder übergeben werden, geschieht dies mittels INPUT -Elementen vom Typ hidden [25, Abschnitt 17.4] können diese Daten in der normalen Browserdarstellung vor dem Nutzer verborgen werden. Damit wird der Nutzer nicht durch ungewöhnliche Ausgaben irritiert. Die eigentliche Weiterleitung erfolgt über in das HTML-Dokument eingebettete Skriptbefehle, etwa per Java-Script. Werden diese vom Browser des Nutzers nicht unterstützt, so muss der Nutzer das Versenden des Formulars manuell auslösen. SCRIPT-Redirect: Auch hier wird ein gewöhnliches HTML-Dokument zurückgeliefert, wobei aber auf die Einbettung eines Formulars verzichtet wird. Stattdessen wird wieder über Scriptbefehle eine Weiterleitung veranlasst, wobei Daten direkt als Parameter der Ziel-URL übergeben werden können. Diese URL, einschließlich ihrer Parameter, sollte in einem <noscript> -Bereich [25, Abschnitt 18.3.1] wiederholt werden, damit der Nutzer die URL manuell aufrufen kann, falls sein Browser die Scriptbefehle nicht unterstützt. 39 Die Benennung ist willkürlich gewählt, allein mit dem Zweck einer kurzen sprachlichen Unterscheidungsmöglichkeit im Rahmen dieser Arbeit. 16
4.2 Sicherheit der Kommunikation Nach Abschluss dieser initialen Kommunikationsschritte kennt also der Anbieter bereits die gewünschten Nutzerdaten oder ihm steht ein Ticket zur Verfügung, anhand dessen er diese beim Identitätsmanager abfragen kann. Insbesondere ist der Identitätsmanager in der Lage, anhand des Tickets auf den konkreten Nutzer zu schließen. Weitere Kommunikation zwischen Anbieter und Identitätsmanager bedarf daher nicht mehr dem Umweg über den Nutzer, sie kann auch direkt stattfinden. 4.2 Sicherheit der Kommunikation Um die Zuverlässigkeit des Gesamtsystems zu gewährleisten, ist es notwendig, es gegen Angriffe zu schützen, insbesondere muss dazu die Integrität und Vertraulichkeit der Kommunikation sichergestellt werden. Dies dient im Fall der Übermittlung von Nutzerdaten zudem datenschutzrechtlichen Zielen, vgl. Abschnitt 3.1.4. Die Sicherung der Kommunikationsverbindungen erfolgt gewöhnlich mittels Secure Socket Layer (SSL) [24] bzw. der Weiterentwicklung Transport Layer Security (TLS) [3]. Vor allem in Kombination mit dem HTTP- Protokoll sind diese Verfahren weit verbreitet (HTTPS). Vertrauliche Kommunikation wird durch den Einsatz von symmetrischer Verschlüsselung erreicht. Das Verschlüsselungsverfahren und die Schlüssellänge wird von den beiden Beteiligten im Zuge des Aufbaus der Kommunikationsverbindung ausgehandelt, der eigentliche Schlüssel wird über ein übliches Schlüsselaustauschverfahren, in der Regel RSA key exchange, gewonnen. Dazu authentifiziert sich mindestens der Server (das Ziel der Verbindung) gegenüber dem Klient (der Initiator der Verbindung) unter Verwendung von Zertifikaten. Die Integrität der Kommunikation wird auf der Basis von schlüsselabhängigen Einweg-Hashfunktionen (Message Authentication Codes) gewährleistet. Veränderungen durch Dritte können so leicht erkannt werden. [31] Zu beachten ist, dass mittels SSL/TLS nur Punkt-zu-Punkt-Verbindung geschützt sind. Insbesondere könnte der Nutzer Daten, welche mittels Redirect zwischen Anbieter und Identitätsmanager über ihn weitergeleitet werden, einsehen und unbemerkt verändern. Damit verbundene Probleme lassen sich bei Bedarf durch den Einsatz von zusätzlicher Verschlüsselung, Signaturen, Einmalcodes, etc. auf höherer Ebene vermeiden. 17