INSTITUT FÜR INFORMATIK

Transkript

1

2 INSTITUT FÜR INFORMATIK DER LUDWIG-MAXIMILIANS-UNIVERSITÄT MÜNCHEN Diplomarbeit Interoperabilitätsanalyse föderierter Identitätsmanagement-Systeme Frederik Weishäupl Aufgabensteller: Prof. Dr. Hans Jürgen Ohlbach Betreuer: Benjamin Weyl (BMW Group Forschung und Technik) Felix Grabmeyer (BMW Group) Abgabetermin: 09. Juli 2005

3 Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 7. Juli (Unterschrift des Kandidaten)

4 Zusammenfassung Das Ziel dieser Arbeit ist die Durchführung einer umfassenden Produktanalyse im Bereich Federated Identity Management. Da in heutigen Netzwerken eine Vielzahl von heterogenen Systemarchitekturen miteinander kommunizieren, ist der Interoperablitätsaspekt dieser Systeme von besonderer Bedeutung. Vor allem für den Einsatz von Identitätsmanagement- Softwareprodukten ist es entscheidend, dass diese in der Lage sind, Föderationen mit Produkten anderer Hersteller bzw. Domänen unterschiedlicher Unternehmen und Organisationen aufzubauen. Drei solcher weit verbreitender Sicherheitslösungen werden im Rahmen dieser Diplomarbeit vorgestellt und analysiert. Dies sind der Netegrity Siteminder 6.0 SP1, der RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5 und der IBM Tivoli Access Manager 5.1 & IBM Federated Identity Manager 6.0. Eine zentrale Rolle nimmt in dieser Arbeit die Security Assertion Markup Language (SAML) ein. Dieser XML-basierte Standard kann verwendet werden, um Informationen bzgl. der Identität eines Benutzers (z.b. Authentifizierungsdaten) plattform- und herstellerunabhängig über Domänengrenzen hinweg auszutauschen. Dabei werden diese Domänen meist von unterschiedlichen Unternehmen bzw. Organisationen verwaltet. Durch die Übertragung von sog. SAML-Assertions ist es nun möglich, Authentifizierungs-, Autorisierungs- und Attributdaten eines Benutzers vertrauenswürdigen Partnerunternehmen mitzuteilen. Dies ermöglicht u.a. die Umsetzung einer Single Sign-On Umgebung, in der sich User - nach einer einmaligen Authentifizierung - frei zwischen unterschiedlichen Domänen bewegen können. Die im Rahmen dieser Diplomarbeit verwendeten Sicherheitsprodukte unterstützen den domänenübergreifenden Austausch von SAML-Nachrichten. Bei der durchgeführten Interoperablitätsanalyse ist die Konformität dieser Softwareprodukte bzgl. des offiziellen SAML-Standards von entscheidender Bedeutung.

5 Für meinen Vater LUDWIG WEISHÄUPL der mir sagte, ich soll aus mir machen, was ich will

6 Danksagung Eine Reihe von Leuten hat die ganze Diplomarbeit oder Teile davon auf verschiedenen Stufen ihres Enstehens gelesen. Ich möchte ihnen allen für ihre wertvollen Anregungen und ihre Kritik danken. Mein besonderer Dank gilt Herrn Prof. Dr. Hans Jürgen Ohlbach, der immer ein offenes Ohr für die Probleme und Anliegen seiner Studenten hatte und mir bei der Betreuung meiner Diplomarbeit jederzeit hilfreich zur Seite stand. Ein wichtiges Anliegen ist es mir, mich ganz besonders bei meinen Betreuer Benjamin Weyl von der BMW Forschung und Technik zu bedanken. Er hat mit seiner außergewöhnlichen Hilfsbereitschaft und Menschlichkeit einen gewaltigen Anteil daran, dass diese Diplomarbeit zu einem erfolgreichen Abschluß gebracht werden konnte. Beim Auftreten von Problemen half er mir immer durch das Einbringen neuer kreativer Ideen. Er unterstützte mich zudem jederzeit mit seinem ausserordentlich fundierten Fachwissen. Ferner bedanke ich mich ganz herzlich bei meinem Betreuer Felix Grabmeyer (BMW IT), der mich auf eine erfrischende und praxisnahe Art und Weise in das Forschungsfeld Federated Identity Management einführte und meine Begeisterung für dieses Thema weiter gefördert hat. Ebenfalls möchte ich mich bei meinen Kollegen der BMW Forschung und Technik für die stete Unterstützung und die tolle Arbeitsatmosphäre bedanken. Nicht vergessen möchte ich an dieser Stelle meinen Bruder, der während der Diplomarbeit meinen Stressfaktor stets zu steigern wusste, indem er mich mit seinen eigenen IT-Problemen belästigte. Abschließend möchte ich besonders meine Mutter hervorheben, ohne deren unermüdlichen Einsatz beim Korrekturlesen so manches fehlende Komma unentdeckt geblieben wäre.

7 Inhaltsverzeichnis 1. Einleitung Motivation Ziel der Arbeit Aufbau und Gliederung der Arbeit Grundlagen des Federated Identity Managements Identifikation in einem Computer Netzwerk Zugang zu Ressourcen Multiple Sign On vs. Single Sign On Federated Identity Single Sign-On Beispielszenarios Konzepte einer Föderation Web-Services Sicherheitsstandards in einer Identity Federation Microsoft.NET Passport Security Assertion Markup Language SAML OASIS SAML 1.1 Spezifikation Liberty Alliance Projekt Web-Services Security WS-Federation Vergleich der Föderationsstandards Zusammenfassung Einrichtung der Testumgebungen Netegrity Siteminder Funktionalitäten Architektur Federated Identity Management Installation RSA Cleartrust 5.5 & RSA Federated Identity Manager Funktionalitäten Architektur Federated Identity Management Installation IBM Tivoli Access Manager 5.1 & Tivoli Federated Identity Manager Funktionalitäten Architektur Federated Identity Management Installation Vergleich der eingesetzten IAM-Softwareprodukte Aufbau einer föderierten Systemumgebung Anwendungsfälle für ein föderiertes Identitätsmanagement 82 i

8 4.1 Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Anwendungsfall: Föderierter Attribut-Austausch Anwendungsfall: Lokale Autorisierung Anwendungsfall: Entfernte (Remote) Autorisierung Anwendungsfall: Föderiertes Single Logout Umsetzung und Analyse Testszenario Netegrity Siteminder 6.0 (IdP) SAML Affiliate Agent 6.x QMR2 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit Testszenario Netegrity Siteminder 6.0 (IdP) RSA Cleartrust 5.5 & FIM 2.5 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit Testszenario Netegrity Siteminder 6.0 (IdP) IBM TAM 5.1 & TFIM 6.0 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit Testszenario RSA Cleartrust 5.5 & FIM 2.5 (IdP) Netegrity Siteminder 6.0 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit Testszenario RSA Cleartrust 5.5 & FIM 2.5 (IdP) IBM TAM 5.1 & TFIM 6.0 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP) RSA Cleartrust 5.5 & FIM 2.5 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP) Netegrity Siteminder 6.0 (SP) Konfiguration der Testumgebung Test der Anwendungsfälle Fazit OpenSAML-Autorität der BMW Group Zusammenfassung und Ausblick 130 A. Anhang 134 A.1 Quellcode Assertion Generator Plugin (Netegrity Siteminder 6.0 SP1) A.2 Beispiele zum Liberty ID-FF 1.2 Protokoll A.3 SAML-Requests & SAML-Responses A.3.1 Testszenario Netegrity Siteminder 6.0 SAML Affiliate Agent 6.x QMR A.3.2 Testszenario Netegrity Siteminder 6.0 RSA Cleartrust & RSA FIM A.3.3 Testszenario RSA Cleartrust & RSA FIM 2.5 Netegrity Siteminder A.3.4 Testszenario IBM TAM 5.1 & TFIM 6.0 RSA Cleartrust 5.5 & FIM A.3.5 Testszenario IBM TAM 5.1 & TFIM 6.0 Netegrity Siteminder ii

9 Abkürzungsverzeichnis 149 Literaturverzeichnis 151 iii

10 Abbildungsverzeichnis Abbildung 1: Föderation zwischen Unternehmen... 2 Abbildung 2: Identity Lifecycle Management... 2 Abbildung 3: Austausch von Identitäten in einer Trust Relationsship Abbildung 4: B2C Szenario Beispiel Reiseindustrie Abbildung 5: B2B Szenario - Beispiel Outsourcing von Dienstangeboten Abbildung 6: B2B Szenario Aufbau von Wertschöpfungsketten Abbildung 7: Beispiel Account Linking Abbildung 8: Struktur einer SOAP-Nachricht Abbildung 9: Struktur einer SAML-Assertion Abbildung 10: Austausch von SAML-Request- & Response-Nachrichten Abbildung 11: Single Sign-On mit dem Browser/Artifact Profile Abbildung 12: Single Sign-On mit dem Browser/POST Profile Abbildung 13: Liberty Alliance SSO-Prozess Abbildung 14: Erweiterungen des Liberty ID-FF Protokolls Abbildung 15: Architektur Netegrity Siteminder Abbildung 16: Komponenten des SAML Affiliate Agents Abbildung 17: Architektur RSA Cleartrust Abbildung 18: Architektur IBM Tivoli Access Manager Abbildung 19: Architektur IBM Federated Identity Manager Abbildung 20: Föderierte heterogene Systemarchitektur Abbildung 21: Ablauf Föderierte Authentifizierung/Föderiertes Single Sign-On Abbildung 22: Ablauf Föderierter Attribut-Austausch (explizite Übertragung) Abbildung 23: Ablauf Entfernte Autorisierung (dynamisch) Abbildung 24: Lokale Autorisierung durch den IBM TAM Abbildung 25: Klassendiagramm OpenSAML-Autorität (BMW Forschung &Technik) Abbildung 26: Ergebnisse der Interoperablitätsanalyse iv

11 Tabellenverzeichnis Tabelle 1: Vergleich Liberty Alliance - WS-Federation Tabelle 2: Vergleich der SSO-Protokolle Tabelle 3: Vergleich IAM - Softwareprodukte Tabelle 4: SSO-Einstellungen Netegrity Siteminder Tabelle 5: SSO-Einstellungen RSA FIM Tabelle 6: SSO-Einstellungen IBM FIM Tabelle 7: SAML-Features Netegrity Siteminder vs. SAML Affiliate Agent Tabelle 8: Einstellungen Netegrity Siteminder & SAML Affiliate Agent...93 Tabelle 9: Testergebnisse - Netegrity Siteminder (IdP) & SAML Affiliate Agent (SP) Tabelle 10: SAML-Features Netegrity Siteminder vs. RSA FIM Tabelle 11: Einstellungen Netegrity Siteminder & RSA FIM Tabelle 12: Testergebnisse - Netegrity Siteminder (IdP) & RSA FIM (SP) Tabelle 13: SAML-Features Netegrity Siteminder vs. IBM TFIM Tabelle 14: Einstellungen Netegrity Siteminder & IBM TFIM Tabelle 15: Testergebnisse - Netegrity Siteminder (IdP) & IBM TFIM (SP) Tabelle 16: SAML-Features RSA FIM vs. Netegrity Siteminder Tabelle 17: Einstellungen RSA FIM & Netegrity Siteminder Tabelle 18: Testergebnisse - RSA FIM (IdP) & Netegrity Siteminder (SP) Tabelle 19: SAML-Features RSA FIM vs. IBM TFIM Tabelle 20: Einstellungen RSA FIM & IBM TFIM Tabelle 21: Testergebnisse - RSA FIM (IdP) & IBM TFIM (SP) Tabelle 22: SAML-Features IBM TFIM vs. RSA FIM Tabelle 23: Einstellungen IBM TFIM & RSA FIM Tabelle 24: Testergebnisse - IBM TFIM (IdP) & RSA FIM (SP) Tabelle 25: SAML-Features IBM TFIM vs. Netegrity Siteminder Tabelle 26: Einstellungen IBM TFIM & Netegrity Siteminder Tabelle 27: Testergebnisse - IBM TFIM (IdP) & Netegrity Siteminder(SP) v

12 Kapitel 1: Einleitung 1. Einleitung 1.1 Motivation Die heutige E-Business-Landschaft bietet Unternehmen und Organisationen zahlreiche Möglichkeiten für eine Zusammenarbeit weit über die eigenen Standorte hinaus. Da immer mehr Dienstleistungen heute als Web-Service angeboten werden, müssen Unternehmen neben stark steigenden Nutzerzahlen auch eine stetig steigende Anzahl von Geschäftsbeziehungen verwalten können. Vor allem Interaktionen mit externen Nutzern innerhalb moderner Business-to-Business (B2B), Business-to-Customer (B2C), Business-to-Employee (B2E) oder kombinierten B2B/B2C Umgebungen treten zunehmend in den Vordergrund. Die Folge dieser Entwicklung bedeutet für ein einzelnes Unternehmen oft Millionen, wenn nicht sogar Milliarden von potentiellen Nutzern und zugehörigen Speichersätzen. Identitäten müssen nun nicht mehr nur innerhalb interner Applikationen, sondern auch innerhalb Systemen und Diensten jenseits der Grenzen eines Unternehmens (Cross-Domain) verwaltet werden [TowFIM]. Diese Entwicklung führt dazu, dass Firmen ihre bisherigen Sicherheits- und Informations-Architekturen überdenken bzw. erweitern müssen, um den zukünftigen Anforderungen gerecht zu werden. Schnell wurde klar, dass diese neuen Herausforderungen mit Hilfe von herkömmlichen Identity Management Systemen nur schwer zu lösen sind. Kaum ein Unternehmen ist bereit, seinen Partnerunternehmen Zugriff auf die eigenen Nutzerdatenbanken zu gewähren. Die andere Alternative, eine vielfache Abspeicherung der gleichen Informationen innerhalb der verschiedenen Identitätsdomänen stellt ebenso keine zufriedenstellende Lösung dar. Ein aussichtsreicher neuer Ansatz, der Unternehmen hilft, diese Schwierigkeiten zu bewältigen, wird unter dem Begriff Federated Identity Management zusammengefasst: The agreements, standards, and technologies that make identity and entitlements portable across autonomous domains. -Burton Group [BurtonFIM] Dieses neue Konzept kann das Kosten- und Komplexitätsproblem der domänenübergreifenden Benutzerverwaltung nachhaltig lösen. Federated Identity Management dient als Rahmenwerk, um verteilte Benutzerdaten verwalten zu können. Identitäten und werden dabei in Zukunft nicht mehr vollständig zentral, sondern dezentral verwaltet, d.h., es existiert am Ende keine zentrale Stelle mehr, bei der alle für ein Unternehmen relevante Identitäten gespeichert sind. Bedingung hierfür ist jedoch eine Vertrauensbeziehung zwischen den Unternehmen, d.h., die Teilnehmer einer Föderation müssen sich gegenseitig kennen und vertrauen. Ansonsten sind alle ausgetauschten Informationen (z.b. Authentifizierungsinformationen) wertlos. Der Begriff Föderation betrifft dabei eine Gruppe von Unternehmen bzw. Organisationen, die Vereinbarungen getroffen haben, um gegenseitig Nutzer- und Ressourceninformationen austauschen zu können 1

13 Kapitel 1: Einleitung Das Prinzip ist mit einem Führerschein oder Reisepass vergleichbar: Ein Staat stellt einen Abbildung 1: Föderation zwischen Unternehmen [TowFIM] individuellen Berechtigungsnachweis bereit, der als absolut vertrauenswürdig gilt und somit auch in anderen Ländern als Identitätskennung anerkannt wird. Federated Identity Management beruht sowohl auf technischen als auch auf geschäftlichen Übereinkünften zwischen den Beteiligten einer Föderation. Die technologische Komponente sollte dabei einen Single Sign-On- bzw. Single Logout-Mechanismus, einen Identitätscheck bei den Partnern, eine Autorisierung (basierend auf definierten Sicherheitsregeln), einen domänenübergreifenden Austausch von Nutzer-Profilen bzw. Nutzer-Attributen, ein umfassendes Identity Lifecycle Management, die Bereitstellung von Benutzerdaten, eine sichere Infrastruktur sowie einen gesicherten Zugriff auf Ressourcen der Geschäftspartner unterstützen (vgl. Abbildung 2). Wesentlich für das Funktionieren eines unternehmensübergreifenden Identitäten- Managements sind Standards. Momentan gibt es mehrere, zum Teil parallel verlaufende Bemühungen, die versuchen, diesen Anforderungen gerecht zu werden (siehe Kapitel 2.4). Die momentan wichtigsten sind SAML, das Liberty Alliance Projekt und WS-Federation. Diese Föderationsstandards definieren einen Mechanismus, um Identitätsinformationen über mehrere Domänen hinweg, plattformunabhängig, austauschen zu können. Service Consumers Vertrauensbeziehung Benutzer Identifikation Authentifizierung Zugriffskontrolle Austausch von Identitäts- und Attributinformationen Service Providers Identity Lifecycle Management Abbildung 2: Identity Lifecycle Management 2

14 Kapitel 1: Einleitung Neben der technischen Herausforderung erfordert FIM jedoch auch ein komplettes wirtschaftliches Umdenken der Unternehmen. Es verändern sich Geschäftsmodelle und Unternehmensgrenzen verschwimmen. Over the next few years we have to deal with some very messy problems namely what it takes to deploy federated technology along with what it takes to bash out contracts between partners... - Michael Barrett, Vice President of Internet Strategy at American Express & President of Liberty Alliance [PingID] Nutzer-Identitäten und Nutzer-Profile werden sich zukünftig zumindest teilweise außerhalb des Kontrollbereichs eines einzelnen Unternehmens befinden. Dieser Gedanke fällt Unternehmen nach wie vor sehr schwer. Langfristig werden Unternehmen jedoch, wenn sie im Wettbewerb weiter bestehen wollen, nicht um diese Veränderungen herumkommen. Diese Diplomarbeit ist in Kooperation mit der BMW Forschung und Technik und der BMW IT entstanden. Dort werden im Wesentlichen zwei Einsatzbereiche für ein Federated Identity Management gesehen. Dies ist zum einen die B2B-Kommunikation, d.h., BMW IT will den Mitarbeitern seiner zahlreichen Partnerunternehmen den Zugriff auf BMW-Interne Applikationen bzw. Ressourcen per Single Sign-On ermöglichen. Der andere Einsatzbereich betrifft die Telematik-Dienste im Auto. Der Trend in diesem Bereich entwickelt sich in die Richtung, dass immer mehr solcher Dienste wie z.b. MP3- oder Wetter-Service in die Autos von BMW integriert werden. Da diese Dienste meist nicht direkt von BMW, sondern indirekt von Partnerunternehmen angeboten werden, wird auch hier der Einsatz von föderierten Identity Management Systemen angestrebt. Neben der Automobilbranche besteht vor allem bei Telekommunikationsunternehmen großes Interesse am Federated Identity Management. Zum Beispiel gaben der Mobilfunkanbieter Orange und IBM im Juli 2004 bekannt, dass das Telekommunikationsunternehmen mit Hilfe eines föderierten Identitäts-Managements seinen Kunden den Zugang zu diversen Diensten vereinfachen will. Mit nur einer Nutzerkennung soll es möglich sein, Zusatzdienste wie E- Mail, Online-Banking, Instant-Messaging, Spiele-Download sowie Location-Based Services zu nutzen [ITSec]. Auch der Mobilfunkhersteller Nokia arbeitet aktuell daran, das Föderationsframework der Liberty Alliance in seine mobile Service-Infrastruktur zu integrieren [FedFuture]. Die Vorteile eines konsequenten Federated Identity Managements sind für Unternehmen und Nutzer enorm. Dass sich heute die meisten größeren Unternehmen des Konzeptes und der potentiellen Möglichkeiten dieser neuen Technologie bewusst sind, ist unbestritten. Nahezu jeder IT-Experte hat heutzutage schon einmal etwas von den Federated Identity Standards Security Assertion Markup Language (siehe Kapitel 2.4.2), Liberty Alliance (siehe Kapitel 2.4.4) und WS-Federation (siehe Kapitel 2.4.6) gehört. Jedoch besteht in diesen Kreisen 3

15 Kapitel 1: Einleitung oftmals noch eine große Unsicherheit und Verwirrung über den aktuellen Entwicklungsstand dieser Standards. Die Technologie Federated Identity befindet sich heute in der frühen Umsetzungsphase (engl. Early Adoption Phase). Vor allem große Unternehmen setzen diese neue Technologie bereits in ersten begrenzten Geschäftsgebieten ein. Dass ein umfassendes Federated Identity Management längst keine Vision mehr ist, sondern in nicht allzu ferner Zukunft liegt, zeigen die Anstrengungen der Hersteller von Identity- und Access- Management (IAM)-Software. Hier sind vor allem Computer Associates [CA], IBM [IBM], Microsoft [MS], RSA Security [RSA] und Sun Microsystems [SUN] zu nennen. Alle diese Unternehmen haben den Trend Federated Identity Management rechtzeitig erkannt und darauf reagiert. Sie bieten grundlegende Sicherheitslösungen an, welche es Organisationen auf einfache Weise ermöglichen soll, eine Federated Identity Umgebung aufzubauen und zu realisieren. 1.2 Ziel der Arbeit Im Rahmen dieser Diplomarbeit soll - auf Basis des föderierten Standards SAML (Security Assertion Markup Language) 1.0/1.1 - die Interoperabilität zwischen drei weit verbreiteten Web Identity- und Access-Management (IAM)-Produkten unterschiedlicher Hersteller evaluiert werden. Jedes dieser Sicherheitsprodukte enthält eine SAML-Implementierung, die es ermöglicht, SAML-Nachrichten zu erstellen und zu verschicken. Zu den Sicherheitslösungen, die analysiert werden, gehören der Netegrity Siteminder 6.0 SP1, der RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5 und der IBM Tivoli Access Manager 5.1 & IBM Federated Identity Manager 6.0 (Beta-Version). Die Produkte dieser Hersteller sind in der Praxis weit verbreitet. Bei der BMW Group Deutschland wird beispielsweise der Netegrity Siteminder als grundlegende Sicherheitslösung eingesetzt. SAML unterstützt einen standardisierten Austausch von Sicherheitsinformationen (z.b. Authentifizierungsdaten eines Benutzers) zwischen Domänen. Diese können sich dabei unter der Kontrolle unterschiedlicher Unternehmen bzw. Organisationen befinden. Um im Rahmen dieser Diplomarbeit eine solche heterogene Systemumgebung simulieren zu können, werden die drei verwendeten Produkte im ersten Schritt auf jeweils verschiedenen Testservern installiert und geeignet konfiguriert. Um eine umfassende und nachvollziehbare Interoperablitätsanalyse zwischen den unterschiedlichen Produkten durchführen zu können, werden in Kapitel 4 SAML- Anwendungsfälle definiert, die in einer komplexen föderierten Identitätsumgebung unbedingt umgesetzt werden sollten. In der Evaluierungsphase soll dann festgestellt werden, inwieweit sich diese Use-Cases von den SAML-Implementierungen der verschiedenen Hersteller realisieren lassen. Insbesondere soll dabei die Konformität der Softwareprodukte zum OASIS 4

16 Kapitel 1: Einleitung SAML 1.0/1.1 Standard überprüft werden. Für eventuell auftauchende Inkompatibilitäten zwischen den Produkten sollen sinnvolle Lösungsansätze entworfen und - wenn möglich - umgesetzt werden. Anhand der Testergebnisse soll festgestellt werden, ob es für Unternehmen, wie z.b. die BMW Group, möglich und sinnvoll ist, Föderationen mit Partner- und Dienstleistungsunternehmen aufzubauen. Eine funktionierende Zusammenarbeit unterschiedlicher FIM-Produkte ist für Unternehmen wie die BMW AG maßgeblich für ein verstärktes Engagement im Bereich Federated Identity Management, da Partner- und Dienstleistungsunternehmen oftmals nicht die gleichen Sicherheitsprodukte verwenden. 1.3 Aufbau und Gliederung der Arbeit Die vorliegende Arbeit umfasst sechs Kapitel. Diese werden im Folgenden kurz vorgestellt. Im ersten Kapitel wird die Motivation und das Ziel der Diplomarbeit vorgestellt. Dabei wird auch der Begriff Federated Identity Management eingeführt. Das zweite Kapitel beschäftigt sich mit den Grundlagen, die für den Aufbau einer föderierten Identitätsumgebung unerlässlich sind. Neben der Vorstellung und Erklärung fundamentaler Konzepte, wie der föderierten Authentifizierung und Autorisierung von Nutzern, umfasst dieses Kapitel vor allem die Einführung und den Vergleich anerkannter Föderationsstandards. Diese bilden die Basis für einen standardisierten Austausch von Identitätsinformationen in einem heterogenen Netzwerk. Das Hauptaugenmerk liegt dabei auf der OASIS SAML (Security Assertion Markup Language) 1.0/1.1 Spezifikation. Dieser XML-Dialekt bietet die Möglichkeit, Identitätsinformationen (wie z.b. Authentifizierungsdaten eines Benutzers) zwischen unterschiedlichen Domänen auszutauschen. In Kapitel 3 werden die drei verwendeten Identity/Access-Management-Produkte vorgestellt, mittels derer eine föderierte und heterogene Systemumgebung simuliert wird. Insbesondere wird an dieser Stelle detailliert auf die Federated Identity Management Fähigkeiten dieser Produkte eingegangen. Abschließend wird die komplette Systemarchitektur vorgestellt, die das technologische Fundament für die durchgeführten Interoperablitätsanalysen bildet. Um eine umfassende und nachvollziehbare Interoperablitätsevaluierung zu gewährleisten, werden in Kapitel 4 wichtige SAML-Anwendungsfälle definiert. Grundlage für diese Testfälle bilden die föderierten Dienste (föderierte Authentifizierung, Autorisierung und Attributsauskünfte). Anhand dieser Use-Cases wird die Interoperablitätsanalyse umgesetzt. In Kapitel 5 werden die in Kapitel 4 definierten Anwendungsfälle auf die aufgebaute Testumgebung angewendet. Dabei wird jedes Produkt einer genauen Interoperablitätsanalyse 5

17 Kapitel 1: Einleitung unterzogen. Insbesondere wird dabei jedes der verwendeten Produkte bzgl. seiner Konformität zum SAML Standard überprüft. Die Ergebnisse dieser Evaluierung sollen aufzeigen, ob die getesteten Sicherheitslösungen den Ansprüchen einer komplexen heterogenen Föderation genügen. Das letzte Kapitel gibt eine Zusammenfassung der wichtigsten Ergebnisse dieser Diplomarbeit wieder und endet mit einem Ausblick. 6

18 Kapitel 2: Grundlagen des Federated Identity Managements 2. Grundlagen des Federated Identity Managements 2.1 Identifikation in einem Computer Netzwerk Einer der Hauptgründe für den Einsatz heutiger moderner Computer Netzwerke ist die Möglichkeit, auf entfernte Ressourcen bzw. Objekte lokal zuzugreifen und diese nutzen zu können. Zunehmend möchten Organisationen ihren Mitarbeitern, aber auch ihren Partnern und Kunden, einen sicheren und einfachen Zugriff auf Ressourcen bieten und dabei das Firmenwachstum gewährleisten, die Zugriffskosten senken, die Sicherheit verbessern und behördlichen Anforderungen gerecht werden. Der Begriff Ressource ist dabei eine Abstraktion von z.b. Daten, Computerprogrammen, Netzwerkdruckern etc.. Um Missbrauch zu verhindern, ist es jedoch wichtig, dass die unterschiedlichen Ressourcen vor unerlaubten Zugriff geschützt werden. Dieses Problem führt uns zur Identifikation und Authentifizierung von Nutzern bzw. Entitäten Zugang zu Ressourcen Bevor eine Entität auf eine Ressource zugreifen und diese nutzen kann, muss sich die Entität gegenüber dem betreffenden Netzwerk identifizieren. Um den Begriff identifizieren besser verstehen zu können, ist es sinnvoll, den Begriff der Identität bzw. der Identifikation zu definieren: Identität: Der Begriff der Identität beschreibt die einzigartige Kombination von persönlichen und damit unverwechselbaren Eigenschaften des Individuums und umfasst dabei beispielsweise den Namen, das Geschlecht und den Beruf - durch diese Charakteristika lässt sich die Person von anderen Individuen unterscheiden. [DefID] Identifikation: Identifikation beschreibt den Prozess, in dem der Nutzer seine Identität einem anderen Nutzer bzw. einer anderen Entität wie z.b. einem Computerprogramm übermittelt. In Computernetzen geschieht dies oft durch Angabe eines User Namens. [DefIF] Nachdem der Nutzer nun den Identifikationsprozess eingeleitet hat, muss die Autorität, welche die Ressourcen vor unerlaubten Zugriff schützen soll, die Identität des Nutzers prüfen, d.h., sie muss feststellen, ob der Nutzer wirklich der ist, der er behauptet zu sein. Diesen Prozess bezeichnet man gewöhnlich als Authentifizierung. Authentifizierung: Authentifizierung bezeichnet die Überprüfung der Identität einer Person oder eines Prozesses. Dies erfolgt über die Kenntnis eines Geheimnisses (z.b. Passwort oder biometrische Attribute). Bei erhöhten Sicherheitsanforderungen kommen kryptografische Methoden zum Einsatz, die entweder das Geheimnis oder auch den gesamten Authentifizierungsvorgang absichern. [DefAuth] 7

19 Kapitel 2: Grundlagen des Federated Identity Managements Nachdem sich ein Nutzer (bzw. Prozess) erfolgreich authentifiziert hat, kann dieser jedoch nur auf die Objekte zugreifen, für die ihm entsprechende Rechte zugeteilt wurden. Den Vorgang, welcher entscheidet, ob eine authentifizierte Entität auf eine Ressource zugreifen (z.b. lesender und/oder schreibender Zugriff) darf, bezeichnet man als Autorisierung : Autorisierung: Autorisierung bzw. Autorisation ist der Prozess, durch den bestimmt wird, ob ein Nutzer oder eine Entität Zugriff auf eine Ressource erhalten soll, d.h., ob der Zugriff autorisiert und damit die Integrität gewährleistet ist. Dazu müssen Sicherheitsregeln (Policies) angewendet bzw. ausgewertet werden. [DefAuz] Die tatsächliche Authentifizierung und Autorisierung von Nutzern oder Prozessen werden in Netzwerken von zahlreichen Authentifizierungs- bzw. Autorisierungs-Servern übernommen. Jeder dieser Server verwaltet einen Teil der Ressourcen in einem verteilten Netzwerk. Dieser Bereich wird oft als administrative Domäne (engl. Domain) bezeichnet. Will nun der Nutzer, obwohl er sich schon einmal in seiner Heim-Domäne eingeloggt hat, auf ein Objekt einer anderen Domäne zugreifen, so muss sich dieser dort meist neu authentifizieren, da für diese neue Domäne ein anderer Authentifizierungs-Server verantwortlich ist. Muss sich nun der Nutzer bei jedem Wechsel in eine neue Domäne wieder neu authentifizieren, so spricht man von Multiple Sign On (MSO) [FIMReq] Multiple Sign On vs. Single Sign On Unternehmen, staatliche Einrichtungen und Universitäten stehen heute vor dem Problem, dass sie nicht mehr nur den Zugang zu ihren eigenen administrativen Domänen, sondern auch zu den Domänen von Partnerunternehmen und anderen externen Einheiten bereitstellen müssen. Im Falle von Multiple Sign On muss ein Nutzer bzgl. jeder Domäne, für die er Rechte besitzt, eigene Zugriffsdaten wie z.b. Username und Passwort verwalten. Bewegt sich ein Nutzer nun innerhalb vieler Domänen, so muss dieser - neben dem nicht unerheblichen Aufwand der Verwaltung zahlreichen Authentifizierungsdaten - viel Zeit damit verbringen, sich ständig neu einzuloggen. Eine Reduktion dieses zeitlichen Aufwandes könnte die Produktivität der Mitarbeiter bzw. die Zufriedenheit der Kunden und Partner maßgeblich erhöhen. Im Jahr 2002 führte die PricewaterhouseCoopers /Meta Group unter Unternehmen in Nord-Amerika eine Studie mit dem Namen The Value of Identity Management [ValIM] durch. Diese Studie kam zu dem Ergebnis, dass der durchschnittliche User täglich 16 Minuten mit der Authentifizierung und Anmeldung verbringt. Für ein großes Unternehmen - in der Untersuchung als eine Organisation mit Benutzern definiert - entspricht dies pro Tag Stunden bzw. dem Äquivalent von 1,3 Vollzeitstellen. Zudem entstehen Organisationen hohe Kosten für die Unterhaltung von Helpdesks. Da sich jeder Nutzer zahlreiche Usernamen und Kennwörter merken muss, erhöht sich die Wahrscheinlichkeit, dass dieser seine Authentifizierungsdaten häufig vergisst. 45 % aller Anrufe bei den Helpdesks betreffen das Zurücksetzen von Kennwörtern. 8

20 Kapitel 2: Grundlagen des Federated Identity Managements Ein weiteres Problem ist die redundante Datenhaltung. Durch die Beseitigung von mehrfach gespeicherten Identitätsdaten können die Verwaltungsprozesse vereinfacht und die Betriebskosten reduziert werden. 38 % der externen Nutzer und 75 % der internen Nutzer sind in mehreren Datenspeichern enthalten. Wären die Identitäten eines jeden Benutzers nur noch einmal gespeichert, so ließen sich laut der Studie jährlich bis zu 1236 Stunden an Verwaltungsaufwand einsparen [MSTech]. Alle diese oben genannten Probleme entstehen durch den Einsatz von uneffektiven Multiple Sign-On Umgebungen. Obwohl solche Umgebungen immer noch die Regel sind, gewinnt ein relativ neues Konzept immer mehr an Bedeutung. Dieses wird unter dem Namen Single Sign- On (SSO) zusammengefasst. Die Open Group definiert SSO folgendermaßen [OpenSSO]: Single Sign-On (SSO) is a mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where that user has access permission, without the need to enter multiple passwords. Ziel von SSO ist es, dass User nach einer einmaligen Authentifizierung auf alle lokalen und entfernten Ressourcen, für die sie Rechte besitzen, zugreifen können. Es gibt jedoch zwei Arten von SSO. Einfaches SSO betrifft nur eine Domäne, d.h., Nutzer sind in der Lage, viele verschiedene Applikationen und Objekte innerhalb einer Domäne zu benutzen, ohne sich jedes Mal neu authentifizieren zu müssen. Diese Art von SSO ist heute schon problemlos möglich und hat sich deshalb in den meisten größeren Unternehmen bereits durchgesetzt. Schwieriger wird es, wenn SSO über viele unterschiedliche Domänen hinweg, d.h. Domänen mit verschiedenen Authentifizierungs- und Autorisierungsautoritäten, funktionieren soll. Erschwerend kommt hinzu, dass sich diese zahlreichen Authentifizierungs- und Autorisierungsautoritäten meist unter der Kontrolle von unterschiedlichen, eventuell unabhängigen Organisationen befinden. Diese Art von SSO wird oft auch als Federated Identity Single Sign-On [FedSSO] bezeichnet. Während einfaches SSO heute bei vielen Unternehmen und anderen Einrichtungen allgemeiner Standard ist, befindet sich Federated Identity Single Sign-On aufgrund seiner Komplexität noch in der Forschungs- bzw. Testphase Federated Identity Single Sign-On Das Konzept Identity Federation ist entwickelt worden, um den Nutzern die Möglichkeit zu geben, sich innerhalb einer Föderation übergangslos zwischen verschiedenen Domänen bewegen zu können. Da die Identitätsinformationen nun nicht mehr zentral gespeichert werden können, muss zwischen den verschiedenen Domänen ein Vertrauensverhältnis (engl. trust relationsship) bestehen. Loggt sich beispielsweise ein Nutzer in der Domäne der Organisation A ein und versucht anschließend, auf eine Applikation der Organisation B zuzugreifen, so muss Organisation A 9

21 Kapitel 2: Grundlagen des Federated Identity Managements der Organisation B bestätigen, dass sich der Nutzer bereits erfolgreich authentifiziert hat. Um Federated Identity SSO zu ermöglichen, muss die Organisation B den Zusagen von Organisation A vertrauen. Innerhalb einer Föderation wird die Stelle, welche den Nutzer authentifiziert als Asserting Party (AP) bzw. Identity Provider (IdP) und die Stelle, welche Ressourcen und Dienste zur Verfügung stellt als Relying Party (RP) bzw. Service Provider (SP) bezeichnet. Abbildung 3: Austausch von Identitäten in einer Trust Relationsship [RSATech] Für die Übermittlung der Sicherheitsinformationen zwischen IdP und SP gibt es verschiedene Standards (z.b. X509 Zertifikate [X509], Kerberos Tokens [Kerb], SAML-Assertions [SAMLDef]). Zur Übertragung der sicherheitsrelevanten Informationen wird gewöhnlich das Kommunikationsprotokoll SOAP (Simple Object Access Protocol) eingesetzt [RSATech] Beispielszenarios Die folgenden Beispiele zeigen die grundlegenden Einsatzmöglichkeiten von Federated Identity Management [FIMReq]: B2C (Business-to-Customer): Beispiel Reiseindustrie Dieses Beispiel umfasst eine Fluglinie, eine Autovermietungsfirma und eine Hotelkette. Alle drei Beteiligten haben ein Bündnis geschlossen, dass es ihnen erlaubt, Identitätsinformationen auszutauschen. Innerhalb dieser Föderation (im Englischen oft auch Circle of Trust genannt) existiert eine Partei, welche als IdP fungiert. An dieser Stelle sind die Nutzerprofile gespeichert. Abbildung 4 zeigt ein solches Szenario. Nutzer Bob will seinen Urlaub für das nächste Jahr buchen. Deshalb besucht er die Webseite seiner bevorzugten Fluglinie. Auf dieser Seite authentifiziert sich Bob, um eine Flugreise nach New York City zu buchen. Anschließend 10

22 Kapitel 2: Grundlagen des Federated Identity Managements benötigt er noch eine Unterkunft. Dazu folgt Bob einem Link auf der Webseite der Fluglinie und wird daraufhin - per Single Sign-On-Mechanismus - auf die Webseite der Hotelkette umgeleitet. Dort kann er nun sofort ein Hotel seiner Wahl buchen. Die Buchung eines Mietwagens erfolgt analog. Airline, Inc. TravellsUs.com CarRentals.com Identity Store CheapHotel, Inc. Bob Abbildung 4: B2C Szenario Beispiel Reiseindustrie [FIMReq] Im diesem Szenario ist der Identity Provider gewöhnlich eine Portal-Seite (TravelsUs.com), welche an der Föderation beteiligt ist. B2E (Business-to-Employee): Outsourcing von Dienstangeboten In diesem Beispiel ermöglicht ein Arbeitgeber seinen Angestellten, ausgelagerte Dienste (engl. Benefits) zu nutzen. Diese werden von externen Dienstleistungsunternehmen erbracht. Die angebotenen Dienste betreffen beispielsweise die medizinische Vorsorge, Rentenvorsorge, Angebote von kostengünstigen Versicherungen, Pläne für die Geldanlage etc. Arbeitgeber und Dienstanbieter bilden wieder einen Circle of Trust. Innerhalb dieser Geschäftbeziehung fungiert der Arbeitgeber als IdP, d.h., er authentifiziert seine Angestellten und leitet auf Wunsch die Authentifizierungs-/Autorisierungsinformationen an die externen Dienstleistungsunternehmen weiter. Abbildung 5 zeigt ein Beispiel für eine solche B2E-Umgebung. Dabei ist Jane eine neue Angestellte. Für sie wird sowohl auf Arbeitgeberseite als auch auf Seite der Dienstanbieter ein Nutzer-Konto erstellt. Im Fachjargon wird die Verknüpfung dieser Konten Account Linking genannt. Mit Account Linking können Anwender Konten, die sie bei verschiedenen Webseiten bzw. Unternehmen haben, miteinander verbinden, sobald die Dienste eine Zusammenarbeit erlauben. Das Sign-On auf verlinkte Konten ist dann nur einmal notwendig. Will Jane nun ihre Rentenversicherungsbeiträge verwalten, so wird sie mittels SSO von der Intranet-Seite des Arbeitgebers auf die Seite des zuständigen Dienstproviders weitergeleitet. 11

23 Kapitel 2: Grundlagen des Federated Identity Managements Geht Jane fünf Jahre später in Ruhestand, so müssen die Account-Verbindungen zwischen den Benefits-Providern und dem Arbeitgeber gelöst werden, damit Jane nicht mehr die Möglichkeit hat, von der Webseite ihres ehemaligen Arbeitgebers aus auf die Dienstangebote zuzugreifen. Employee Portal Jane s Employer Benefits Provider Identity Store 401k Provider Jane Abbildung 5: B2B Szenario - Beispiel Outsourcing von Dienstangeboten [FIMReq] Da Jane jedoch immer noch auf ihr Rentenkonto zugreifen soll und darf, übernimmt in diesem Fall der Benefits-Provider sowohl die Aufgabe des IdPs als auch die des SPs. B2B (Business-to-Business): Management einer Wertschöpfungskette Im Bereich eines B2B-Umfeldes ist es interessant, heutige logistische Wertschöpfungsketten von Unternehmen zu betrachten. Aufgrund der bestehenden Konkurrenzsituationen ist gerade in diesen Szenarios Sicherheit von enormer Bedeutung. Deshalb ist es innerhalb solcher Geschäftsbeziehungen nicht ungewöhnlich, dass jeder Teilnehmer der Föderation sowohl als IdP als auch als SP auftritt. Dieser Umstand erlaubt es Unternehmen als IdP für seine eigenen Angestellten und als SP für die Mitarbeiter von den Partnern der Föderation aufzutreten. Abbildung 6 zeigt ein Beispiel für eine B2B-Umgebung. Dabei ist Bob ein Einkaufsleiter, welcher die Aufgabe bekommen hat, für seine Firma eine größere Menge von Produkten (engl. widgets) zu bestellen. Dem Unternehmen von Bob stehen dabei mehrere Zuliefererfirmen für dieses Produkt zur Auswahl. Bob authentifiziert sich nun auf der Plattform seines Arbeitgebers und kann dann per SSO auf den Zulieferer seiner Wahl zugreifen und die Bestellung durchführen. Wichtig ist, dass Bob nur auf die Dienste der Partnerunternehmen zugreifen darf, für die innerhalb der Geschäftsbeziehung eine Berechtigung ausgehandelt wurde. Er darf keinesfalls Zugriff auf alle Daten und Ressourcen besitzen. 12

24 Kapitel 2: Grundlagen des Federated Identity Managements Widget Provider A Bob s Employer Widget Provider C Identity Store Widget Provider B Bob Abbildung 6: B2B Szenario Aufbau von Wertschöpfungsketten [FIMReq] 2.2 Konzepte einer Föderation Dieser Abschnitt führt vier wesentliche Konzepte ein, die föderierte Identitäts-Umgebung unterstützen sollten: Single Sign-On Siehe Kapitel bzw Account Linking Account Linking (siehe Kapitel 2.4.4) erlaubt es einem Benutzer, seine zahlreichen Konten aus unterschiedlichen Domänen zu verbinden, um den zukünftigen Authentifizierungs- und Autorisierungsprozess zu vereinfachen und SSO zu ermöglichen. Dazu werden die verschiedenen Konten eines Nutzers aufeinander abgebildet bzw. miteinander verbunden. Beispiel (vgl. Abbildung 7): Alice hat ein Nutzerkonto (UserID Alice123) bei einem Bankinstitut, um Online-Banking nutzen zu können. Zusätzlich zu diesem Bank-Account besitzt sie ein Konto bei einer Online- Buchhandlung (UserID BücherWurmAlice). Damit das Versandhaus Identitätsinformationen vom Bankinstitut empfangen und zudem Anfragen bezüglich der Kreditwürdigkeit stellen kann, müssen die beiden Unternehmen ihre Account-Identifier aufeinander abbilden, d.h., das Versandhaus muss wissen, dass die ID Alice123 der Identität AliceBücherWurm entspricht. Aus Gründen der Sicherheit und des Datenschutzes wird beim Account Linking statt des tatsächlichen Usernamens meist ein Pseudonym (Alias) verwendet. In Abbildung 7 werden beispielsweise statt der tatsächlichen Nutzernamen AliceBücherWurm bzw. Alice123 die Pseudonyme PEIIKD889 bzw. JKR67HY zwischen den beteiligten Parteien ausgetauscht. Neben der dadurch gewährleisteten Anonymität verhindert der Einsatz 13

25 Kapitel 2: Grundlagen des Federated Identity Managements von Pseudonymen darüber hinaus Namenskonflikte zwischen verschiedenen Service Providern. Attributaustausch Das Konzept der Föderierung von Identitäten bedeutet mehr als ausschließlich die Fähigkeit, eine Single Sign-On Umgebung aufbauen zu können. Es sollte auch den sicheren domänenübergreifenden Austausch individueller Attribute wie z.b. Kontonummer, Rollenbezeichnungen oder Standort eines Nutzers beinhalten. Die Übertragung von Attributen - zusammen mit der Identität eines Nutzers - soll Applikationen die Möglichkeit geben, dem Benutzer personalisierte Dienste und Ressourcen anbieten zu können. Zudem besteht die Möglichkeit, anhand übersendeter Attributwerte feingranulare Zugriffsentscheidungen (Autorisierung) zu treffen. Buchhandel Bankinstitut Local User: AliceBücherWurm Alias : PEIIKD889 Mapping: JKR67HY = BücherWurmAlice Local User: Alice123 Alias : JKR67HY Mapping: PEIIKD889 = Alice123 Abbildung 7: Beispiel Account Linking Im obigen Beispiel wäre es zum Beispiel sinnvoll, wenn das Versandhaus berechtigt wäre, vom Bankinsitut die Kreditkartennummer von Alice in Form eines Attribut/Werte-Paares zu erhalten. Dadurch müsste Alice bei einer Online-Bestellung nicht jedes Mal ihre Kreditkartennummer neu angeben. Datenschutz Innerhalb einer Föderation, in der Nutzerkonten miteinander verbunden und Attribute ausgetauscht werden, spielt der Datenschutz eine besondere Rolle. Dabei müssen personenbezogene Daten, neben starken Sicherheitsvorkehrungen bezüglich der Protokolle und der Transportschicht, unbedingt vor einem unerlaubten Zugriff geschützt werden. Auch die Anonymität eines Nutzers spielt eine große Rolle. Aus diesen Gründen darf eine Verbindung von Nutzerkonten nur durchgeführt werden, wenn der Benutzer sein ausdrückliches Einverständnis dafür gegeben hat. Welche Attribute dabei mit wem 14

26 Kapitel 2: Grundlagen des Federated Identity Managements ausgetauscht werden dürfen, sollte auf Regeln (Policies) basieren, welche vom Nutzer festgelegt wurden. Des Weiteren sollte die Möglichkeit bestehen, Attribute auf eine anonymisierte Art und Weise zu übermitteln. Oftmals ist es für einen Service Provider nicht notwendig, die tatsächliche Identität eines Benutzers zu kennen, was es unnötig macht, diese zu übermitteln. Ein Beispiel für einen solchen Service Provider wäre eine Wetterstation. Diese muss ausschließlich den Ort eines Nutzers erfahren, nicht aber seinen Namen, Telefonnummer oder ähnliche persönliche Daten. Management Jede Lösung bezüglich einer Föderierung von Identitäten muss Möglichkeiten zum Management dieser Technologie anbieten. Dies ist eine maßgebliche Vorraussetzung dafür, dass ein föderiertes Netzwerk geschaffen und verwaltet werden kann. Dies schließt die Schaffung von komplexen Geschäftsbündnissen mit ein, welche abgeschlossen werden müssen, um den Einsatz von Federated Identity Technologien zu ermöglichen. Solche Vertrauensbeziehungen werden oftmals, wie anfangs erwähnt, Circles of Trust genannt. 2.3 Web-Services Web-Services bilden die technologische Grundlage für eine Federated Identity Umgebung. Der Grundstein für die Entwicklung der Web-Services wurde mit XML gelegt. Während sich früher im HTML-basierten und damit rein Layout-Orientierten Web die Semantik nur dem menschlichen Betrachter aus Inhalt und Kontext erschließen konnte, hat XML die Semantik der Daten in den Vordergrund gestellt. Ein universelles Austauschformat für Daten war damit geschaffen. Was aber noch fehlte, war ein entsprechender Transportmechanismus. Technologien wie CORBA [CORBA] oder Java RMI [RMI] sind solche Mechanismen. Deren Anwendung ist aber zu komplex für bezahlbare und einfache Projekte. In diese Lücke trat die Technologie der Web-Services. Web-Services richten sich primär an andere Rechnersysteme. Ein Dienst spricht mit einem anderen oder gleich mit mehreren auf einmal. So entsteht ein dynamisches Netzwerk aus unterschiedlichsten Anwendungen, sozusagen eine lose Kopplung verteilter Systeme unterschiedlichster Architekturen ohne menschliche Interaktion und damit auch ohne Login- Masken oder ähnlichen Schwachstellen bei der Erkennung und Authentifizierung von Benutzern. Web-Services stellen dabei Funktionen von Anwendungen nach außen zur Verfügung. Sie verhalten sich dabei nicht anders als Schnittstellen für CORBA oder Java RMI, nur eben einfacher und auch in heterogenen Umgebungen nutzbar. Anwendungen können Web-Services dynamisch nutzen. Die Idee von SOAs (Service Oriented Architectures) [SOA] sieht vor, dass Anwendungen Prozesse definieren, mit denen verschiedene Web-Services im Unternehmen und außerhalb miteinander verbunden werden. Anwendungen nutzen also Funktionen anderer Programme über Web-Services und verbinden diese miteinander. Der Web-Service ist dabei eine Schnittstelle. Google hat eine solche 15

27 Kapitel 2: Grundlagen des Federated Identity Managements Schnittstelle ebenso wie ebay. Aber auch bei Enterprise-Systemen wie SAP R/3 und PeopleSoft rücken Web-Services immer mehr in den Mittelpunkt des Interesses. Die technische Basis für Web-Services sind XML, SOAP 1.2 (Simple Object Access Protocol) [SOAP12], WSDL 1.1 (Web-Services Description Language) [WSDL11] und UDDI 2.0 (Universal Description, Discovery, and Integration) [UDDI2]. UDDI ist ein Verzeichnisdienst, der beschreibt, welche Web-Services in einem Netzwerk existieren. Unternehmen wie IBM, SAP und Hewlett-Packard bieten solche Verzeichnisse im Internet an. WSDL legt fest, wie ein Web-Service definiert werden muss. SOAP wird verwendet, um Informationen mit dem Web-Service auszutauschen. Dazu werden SOAP-Nachrichten über HTTP versendet. Neben der Anbindung an ein Transportprotokoll (z.b. HTTP) definiert SOAP ein Nachrichtenformat und Regeln zur Kodierung. Eine SOAP-Nachricht besteht aus drei Teilen: dem Umschlag (engl. envelope), optionalen Angaben im sog. Header und der eigentlichen Nachricht (engl. body). Die letzten beiden Teile sind in den Umschlag eingebettet. Abbildung 8 zeigt die Struktur einer SOAP-Nachricht. Ein Problem ist jedoch, dass weder TCP/IP noch HTTP, SOAP oder XML sichere Protokolle sind. Bei der Sicherheit von Web-Services gibt es zwei Ebenen. Da ist zum einen die Sicherheit auf Transportebene und zum anderen die Sicherheit auf Anwendungsebene. Die erste Herausforderung ist also die Sicherheit auf Transportebene. Da mit HTTP gearbeitet wird, kommt hier SSL [SSL3] in Frage. SSL (Secure Sockets Layer) ist ein von Netscape für die Authentifizierung und Verschlüsselung von HTTP entwickelter Standard. Das Problem bei SSL ist, dass es immer nur die Daten zwischen einem Client und einem Server verschlüsselt. Die Grenzen werden am besten am Dienst deutlich. Eine wird von einem Client über SMTP an seinen Postausgangsserver und von diesem dann in der Regel an mindestens einen weiteren SMTP-Server gesendet, auf den dann der Empfänger zugreift. SSL kann nun die Verbindung zwischen dem Client und seinem SMTP-Server oder zwischen den SMTP-Servern oder vom letzten SMTP-Server zum Empfänger sichern. Die Nachricht jedoch ist auf jedem Server ungeschützt. Daher gibt es spezielle - Verschlüsselungstechnologien wie PGP (Pretty Good Privacy) [PGP] oder S/MIME [MIME]. SSL ist nur für Punkt-zu-Punkt Verbindungen geeignet. Bei SOAP werden sog. Envelopes verschickt, also eine Analogie zu s. Diese können ebenfalls über mehrere Server gehen. Wenn Client und Server bei Web-Services direkt zusammenarbeiten, kann die Verbindung über SSL geschützt werden. Bei mehreren genutzten Servern manche sprechen auch von multiplen Web-Services gibt es keinen durchgehenden Schutz. SSL reicht als Schutzmechanismus für Web-Services daher nicht aus, weil es mehrere Transportstrecken geben kann und weil die SOAP-Envelopes auf Servern zwischengespeichert und verarbeitet werden und dort nicht durch SSL geschützt werden. Protokolle wie SSL, die bei der Übertragung von Web-Services nur Schutz auf der Transport- Ebene bieten können, reichen also alleine nicht aus. Deswegen wurden Standards geschaffen die die Sicherheit auch auf Anwendungsebene gewährleisten sollen. Die wichtigsten 16

28 Kapitel 2: Grundlagen des Federated Identity Managements Standards dieser Ebene sind WS-Security (siehe Kapitel 2.4.5) und SAML (siehe Kapitel 2.4.2). [WSBasics] SOAP-Envelope SOAP-Header Headerblock Headerblock SOAP-Body Nachrichten -Body Abbildung 8: Struktur einer SOAP-Nachricht [SOAP12] 2.4 Sicherheitsstandards in einer Identity Federation Standards spielen in einer Identity Federation eine wichtige Rolle, indem sie die grundlegende Syntax, Semantik und die grundlegenden Verarbeitungsregeln definieren mit dem Ziel, eine Zusammenarbeit verschiedener heterogener Systemumgebungen zu erlauben. Diese Standards bilden die Basis für ein föderiertes Identitätsmanagement. Dieses Kapitel beschreibt die grundlegenden Standards bzw. Industrie-Initiativen, welche sich dem komplexen Problem der Identity Federation widmen: Microsoft Passport Security Assertion Markup Language (SAML) Liberty Alliance Identity Federation Framework WS-Security bzw. WS-Federation Microsoft.NET Passport Microsoft.NET Passport [NETPass] wurde im Jahr 1999 ins Leben gerufen. Passport ist eine weit verbreitete, Web-basierte Single Sign-On Implementierung. Microsoft.NET Passport ermöglicht es seinen Nutzern, einen Usernamen und ein Passwort zu erstellen, mit dem der Benutzer auf jede Webseite, welche den Passport Single Sign-In (SSI) Dienst implementiert hat, zugreifen kann. Microsoft versucht mit diesem System, das Ziel einer individuellen und verteilten Authentifizierung von Benutzern im Internet durch einen zentralen Dienst zu ermöglichen. 17

29 Kapitel 2: Grundlagen des Federated Identity Managements Anbietern von Webangeboten soll dadurch die Möglichkeit eröffnet werden, die Authentifizierung an einen zentralen Dienst bei Microsoft auszulagern und sich somit den eigenen Implementierungsaufwand einer sicheren Single Sign-On Authentifizierung zu ersparen. Neben der Einsparung des Implementierungsaufwands soll dieses Verfahren auch die Sicherheit der Authentifizierung erhöhen, da der Authentifizierungsdienst in einer entsprechend abgesicherten Umgebung betrieben werden kann. Aus Sicht des Benutzers verspricht dieser Dienst einen höheren Komfort bei der Nutzung von webbasierten Diensten, da sich dieser nur noch ein Passwort für alle am Microsoft.NET Passport-Service teilnehmenden Webseiten merken braucht. Nach Aussagen von Microsoft gibt es mittlerweile weltweit mehr als 165 Mio. Passport-Konten, die monatlich mehr als zwei Milliarden Authentifizierungen generieren [MSInf]. Trotz dieser auf den ersten Blick recht beeindruckenden Zahlen wird Passport außerhalb der eigenen Seiten von Microsoft nur selten eingesetzt. Die meisten Konten, die momentan bestehen, stammen von dem freien -Dienst Hotmail. Die grundlegende Funktionsweise der Microsoft Passport Services besteht darin, dass der/die Webserver eines Unternehmens die Authentifizierung eines Zugriffs auf eine geschützte Ressource nicht selbst übernimmt/übernehmen, sondern diese Aufgabe an einen zentralen Dienst auslagern. Loggt sich ein Nutzer mit seinem Passport Account auf einer Webseite ein, wird dieser mittels eines HTTP-Redirects auf einen Server der.passport.com Domäne weitergeleitet. Dort wird der Benutzer mittels seines Usernamens und Passwortes beim Passport-Service authentifiziert. Der Passport-Service legt bei erfolgreicher Authentifizierung mehrere Cookies sowohl in der.passport.com Domäne als auch im Browser des Nutzers ab, damit sich dieser später nicht erneut authentifizieren muss. Diese Cookies implementieren den Single Sign-On Mechanismus. Dieser Mechanismus basiert dabei grundlegend auf den Prinzipien von Kerberos [Kerb]. Die drei wichtigsten Cookies sind [AuthWeb]: MSPSec: Dieses Cookie enthält das Passwort des Nutzers. Gespeichert wird dieses Cookie in der.passport.com Domäne. Es ist gültig, solange der Benutzer sein Kennwort nicht ändert. MSPAuth: Dieses Cookie enthält eine eindeutige 64-bit Passport Unique ID (PUID), um den Nutzer gegenüber dem/den Server(n) in der.passport.com Domäne zu identifizieren. Zudem enthält dieses Cookie Informationen über den Zeitpunkt, an dem sich der Nutzer das letzte Mal manuell eingeloggt hat. Mit diesem Zeitstempel kann vom User z.b. verlangt werden, dass seine manuelle Authentifizierung nicht länger als 20 Minuten zurückliegen darf. Eine Abfrage dieser Art wird vor allem bei besonders sicherheitskritischen Diensten verwendet. 18

30 Kapitel 2: Grundlagen des Federated Identity Managements MSPProf: Dieses Cookie speichert die Profilinformationen eines Nutzers. Die Gültigkeit besteht, solange der Nutzer seine Passport Profildaten nicht ändert. Im nächsten Schritt erstellt der Passport-Service ein Ticket für den Webserver des Nutzers, das die PUID des authentifizierten Benutzers sowie zusätzliche, vom Benutzer explizit zur Weitergabe an den Web-Dienstleister freigegebene Informationen, wie z.b. die Adresse, enthält. Dieses Ticket wird mit einem für den Webserver individuellen Schlüssel kodiert. Der Benutzer wird danach wieder an den ursprünglichen Webserver zurückverwiesen, wobei das Ticket für diesen Webserver als Parameter übergeben wird. Der Webserver leitet das Ticket anschließend an den lokal installierten Passport-Manager weiter, der das Ticket entschlüsselt und die PUID sowie die zusätzlichen Daten zur weiteren Auswertung an der Webserver zurück liefert. Zum Schluss legt der Webserver selbst noch einige Cookies im Browser des Benutzers ab, unter anderem, um weitere Authentifizierungsanfragen beim Passport-Service zu vermeiden. An dieser Stelle wird deutlich, dass mit Hilfe des Passport-Services lediglich eine Authentifizierung des Benutzers vorgenommen wird. Der Web-Dienstleister weiß damit, dass der Benutzer mit dieser PUID sich gegenüber dem Passport-Service erfolgreich authentifiziert hat. Die anschließende Autorisierung des Zugriffs liegt aber weiterhin in der Verantwortung des Dienstleisters. Durch die Verwendung des Passport-Services entfällt nicht die Notwendigkeit, sich auf Websites registrieren zu lassen. Damit der oben beschriebene Authentifizierungsdienst von einem Web-Dienstleister oder einem Benutzer genutzt werden kann, müssen sich beide Parteien beim Passport-Service registrieren [AuthWeb]. Trotz mancher guter Ansätze von MS Passport hat sich diese Technologie in der Netzwelt nicht durchgesetzt. Das Hauptproblem an Passport ist, dass es auf einem zentralen und nicht auf einem föderierten Ansatz beruht. Deshalb wurde frühzeitig Kritik an diesem System laut. Datenschützer befürchten, dass Microsoft aus der Menge der Informationen, die jeder Passport-Nutzer meist unbewusst an die Microsoft Server liefert, Kundenprofile erstellen und speichern könnte. Zudem haben IT-Experten im Juni 2000 das Passport-Protokoll der Redmonder untersucht und kamen zu dem Schluss, dass das System erhebliche Sicherheitsrisiken bzw. Sicherheitslücken in sich trägt [PassTrouble]. Wohl vor allem aus diesen Gründen hat kürzlich das Online-Auktionshaus ebay angekündigt, ab Ende Januar 2005 auf.net Passport verzichten zu wollen. Damit ist ebay nur der jüngste von vielen Kunden, die den Einsatz von Passport aufgegeben haben. Zuletzt hatte das Karriere-Netzwerk Monster.com im Oktober auf die Anmeldung via dem Microsoft-Web- Service verzichtet [ZDNet]. Aufgrund dieser Entwicklungen hat Microsoft im Oktober 2004 mitgeteilt, dass die Weiterentwicklung von.net Passport eingestellt wird. Nachdem nun auch ebay Abschied von Passport genommen hat, wird Passport in der Zukunft wohl nur noch bei Microsoft- 19

31 Kapitel 2: Grundlagen des Federated Identity Managements Webseiten und Produkten wie dem MSN Messenger oder Hotmail zum Einsatz kommen [INQ] Security Assertion Markup Language SAML Die Security Assertion Markup Language (SAML), entwickelt vom Security Technical Services Committee der Organization for the Advancement of Structured Information Standards (OASIS) [OASISTC], ist ein auf XML basierter Standard, um Nutzer-, Authentifizierungs-, Autorisierungs- und Attribut-Informationen über ein Netzwerk austauschen zu können. OASIS [OASIS] ist eine Non-Profit Organisation, die sich der Entwicklung von E-Business-Standards verschrieben hat. Diese Gruppe besteht aus zahlreichen bekannten Mitgliedern. Exemplarisch seien Computer Associates, IBM, SUN, Nokia und SAP genannt. Diese kurze Auflistung des Who-is-Who in der IT-Branche zeigt schon, dass SAML nicht fürchten muss, von der Wirtschaft nicht akzeptiert zu werden. SAML ist ein flexibles und erweiterbares Protokoll, welches von anderen Standards genutzt werden kann. Die Liberty Alliance [LibAll], das Internet2 Shibboleth-Projekt [Shibb] und der OASIS Standard Web-Services Security (WS-Security) [WS-Sec] nutzen SAML in unterschiedlich starkem Maße als technologische Grundlage. SAML 1.0 [SAML10] wurde Ende 2002 als OASIS Standard verabschiedet. SAML 1.1 [SAML11] folgte im September 2003 und erreichte einen beachtlichen Erfolg in verschiedenen Industriezweigen (z.b. Finanzwesen). SAML wird aktuell von nahezu allen namhaften Herstellern in ihren Web Identity/Access-Management Produkten unterstützt. Anfang dieses Jahres veröffentlichte die Gruppe der OASIS den Standard SAML 2.0 (vgl. Kapitel ). Ein Ausblick auf diesen aktuellen Standard wird am Ende dieses Kapitels gegeben. Da SAML 2.0 aufgrund seiner Aktualität in den Softwareprodukten der großen IT- Firmen noch keine Verwendung findet, beschränkt sich diese Diplomarbeit auf den Standard SAML 1.0 bzw.1.1. Vorteile des SAML-Standards: Plattformunabhängig SAML trennt das Sicherheits-Framework von den konkreten Implementierungen und Architekturen verschiedener Hersteller. Lose Koppelung von Nutzerdatenbanken SAML ermöglicht eine verteilte Speicherung von Nutzerdaten. Die verschiedenen Benutzerverzeichnisse müssen nicht synchronisiert werden. Bedienungsfreundlichkeit für den End-Nutzer SAML Authentication-Assertions ermöglichen Single Sign-On. Reduzierung der administrativen Kosten für Service Provider Verwendung von SAML reduziert innerhalb einer Federated Identity Umgebung die Kosten für den 20

32 Kapitel 2: Grundlagen des Federated Identity Managements Service Provider (SP), da die Verwaltung von Nutzerinformationen vom Identity Provider (IdP) übernommen wird. Risiko Übertragung SAML ermöglicht es, das Risiko für eine sichere Verwaltung der Nutzerdaten vom SP an den IdP zu übertragen. Die Spezifikation SAML alleine reicht jedoch nicht aus, um das gesamte Spektrum der Funktionalitäten abzudecken, die für einen Aufbau einer komplexen föderierten Identitätsumgebung nötig sind. Die Regelungen bzgl. eines Vertrauensverhältnisses zwischen zwei Partnern, wie Benutzerverwaltung und Datenschutz, bleiben außerhalb der SAML- Spezifikation Anwendungsbereiche von SAML SAML unterstützt in einer Federated Identity Umgebung zahlreiche Anwendungsbereiche. Die wichtigsten sollen hier noch einmal kurz vorgestellt werden. Web Single Sign-On Web SSO ermöglicht es einem Anwender, sich auf einer Webseite zu authentifizieren, um dann ohne eine erneute Authentifizierung auf weitere, eventuell personalisierte Ressourcen und Informationen einer anderen Webseite zugreifen zu können. Erreicht wird dies durch den Austausch von SAML Authentication-Assertions (siehe Kapitel ) zwischen IdP und SP. Die Webseite, welche die SAML-Assertion erhält, kann nun, falls die Herkunft der Assertion bekannt ist, den Benutzer automatisch authentifizieren, ohne dass dieser noch einmal explizit seine Nutzerdaten angeben muss. Sicherung von Web-Services SAML-Assertions können innerhalb des SOAP Headers als Security-Token verwendet werden, um Sicherheits- und Identitätsinformationen zwischen den Beteiligten einer Web- Service Transaktion auszutauschen. Das SAML Token-Profile des OASIS WS-Security TCs [WSSTC] spezifiziert, wie SAML-Assertions in das <Security> Element von WS-Security (vgl. Kapitel 2.4.5) integriert werden kann. Das Liberty Alliance ID-Web-Service Framework (vgl. Kapitel ) verwendet ebenso SAML-Assertions als grundlegendes Security-Token- Format, um einen sicheren und anonymen Zugriff auf Web-Services zu gewährleisten. Attribut-basierte Autorisation Ähnlich dem Web SSO-Szenario kommunizieren im Attribut-basierten Autorisierungs- Modell zwei unterschiedliche Webseiten miteinander, um Identitätsinformationen auszutauschen. Jedoch, anders als im SSO Szenario, wird keine Authentication-Assertion, sondern eine Attribute-Assertion ausgetauscht. Diese Assertion enthält bestimmte Attribute (z.b. die Rolle eines Nutzers innerhalb eines B2B Szenarios), die einem Benutzer zugeordnet werden können. Mittels dieser übermittelten Attribute kann eine feingranularere Autorisierung bzgl. bestimmter Ressourcen vorgenommen werden als dies mit reinen Authentication-Assertions möglich wäre. 21

33 Kapitel 2: Grundlagen des Federated Identity Managements OASIS SAML 1.1 Spezifikation Der Standard SAML 1.1 [SAML11], Nachfolger von SAML 1.0 [SAML10], wurde Ende 2003 vom Non-Profit-Konsortium OASIS (Organization for the Advancement of Structured Information Standards) [OASIS] offiziell herausgegeben. SAML liefert einen standardisierten Weg für die Beschreibung von existierenden Sicherheits- Modellen, ermöglicht den Austausch sicherheitsrelevanter Informationen zur Authentifizierung und Autorisierung, basiert darüber hinaus auf Standards und ist plattformund herstellerunabhängig. Konzeptionell unterteilt sich die SAML-Spezifikation 1.1 in folgende Hauptbestandteile [SAMLArch]: SAML-Assertions: Hier werden Informationen zur Authentifizierung, Autorisierung sowie weitere Session-Attribute innerhalb eines XML-Dokuments beschrieben. SAML-Request- und Response-Protokoll: Hier wird definiert, wie SAML-Assertions angefordert und übermittelt werden. SAML Bindings und Profiles: Hier wird festgelegt, wie SAML-Dokumente (Assertions) in standardisierte Transport- und Messaging-Frameworks eingebunden werden. Die SAML-Assertions sind die Basis, um Informationen über ein Subjekt (z.b. über einen Benutzer) zwischen einem IdP und einem SP auszutauschen. Das SAML-Request-Protokoll wird vom SP genutzt, um beim IdP eine SAML-Assertion über einen bestimmten Nutzer abzufragen. Der IdP wiederum antwortet auf diese Anfrage mit einer SAML-Response- Nachricht, welche die angeforderten Informationen im Rahmen einer Assertion enthält. Verschickt werden die Request- bzw. Response-Nachrichten innerhalb von SOAP-Envelopes (SAML-Binding), welche per HTTP zwischen den beteiligten Providern ausgetauscht werden (SAML-Profiles). Die komplette Spezifikation besteht aus folgenden Dokumenten: Assertion & Protocol [SAMLProt]: Diese Spezifikation definiert die Syntax und Semantik der SAML-Assertions und der Request- und Response-Protokolle. Bindings & Profiles [SAMLBind]: Ein Binding definiert die Abbildung einer SAML- Request- bzw. Response-Nachricht auf ein Kommunikationsprotokoll einer niedrigeren Schicht wie z.b. SOAP oder SMTP. Der Satz von Regeln, welcher die Einbettung und Extraktion von SAML Informationen in und aus diesen Kommunikationsprotokollen erlaubt, wird SAML-Profile genannt. Conformance Specifications [SAMLConf]: In den verschiedenen SAML- Implementierungen unterschiedlicher Hersteller und Organisationen wird meist nicht die komplette, sondern nur Teile der OASIS SAML-Spezifikation integriert. Die Conformance Specifications definieren einen Basis-Standard, welcher unbedingt bei 22

34 Kapitel 2: Grundlagen des Federated Identity Managements einer SAML-Implementierung berücksichtigt werden sollte. Eine vollständige Beachtung dieser Regeln erleichtert die Interoperabilität und Kompatibilität zwischen verschiedenen unabhängigen SAML-Implementierungen. Security & Privacy Specifications [SAMLSec]: Diese Spezifikation widmet sich den Sicherheitsrisiken innerhalb der SAML-Architektur. Glossary [SAMLGlos]: Dieses Dokument erläutert die Fachwörter, welche in den anderen Dokumenten verwendet werden. Der Vorgänger von SAML 1.1 war SAML 1.0. Nach Angaben des OASIS Konsortiums korrigiert der SAML-Standard 1.1 die Richtlinien zum Einsatz von digitalen Zertifikaten bei der Unterzeichnung von Benutzerinformationen. Prateek Mishra von Netegrity Inc, Mitglied des OASIS Security Services Technical Committees berichtete, dass die Bestimmungen des SAML 1.0 Standards über die Signierung von SAML-Assertions zu vage waren. Dies sorgte oftmals für Probleme beim Zusammenspiel zwischen SAML 1.0 basierten Web-Services [TecChannel]. SAML 1.1 hat zudem viele Fehler (Bugs) der Vorgängerversion behoben SAML-Assertions Eine Assertion oder Bestätigung ist ein XML-Dokument mit einer bestimmten Syntax, welche von dem Konsortium OASIS in seiner SAML-Assertion & Protocol Specification [SAMLProt] festgelegt wurde. Eine Assertion kann Authentifizierungs-, Autorisierungs- und Attributdaten von einem Subjekt (z.b. einem Nutzer) enthalten. OASIS definiert drei Arten von Assertions, welche von einer sog. SAML-Autorität generiert werden können [SAMLProt]: Authentication-Assertion: Diese Assertion enthält Aussagen, ob sich ein Subjekt mittels einer bestimmten Methode zu einem bestimmten Zeitpunkt, an einem bestimmten Ort bereits einmal erfolgreich bzw. nicht erfolgreich authentifiziert hat. Attribute-Assertion: Diese Assertion enthält Eigenschaften bzw. Attribute eines Subjekts (z.b. Kontostand eines Nutzers). Authorization-Assertion: Diese Assertion enthält Informationen über die Berechtigungen eines Subjekts bzgl. bestimmter Ressourcen. Eine SAML-Assertion kann gleichzeitig Authentifizierungs-, Eigenschafts- und Autorisierungsinformationen enthalten. Es ist jedoch auch möglich, diese Informationen auf mehrere SAML-Assertions aufzuteilen. Abbildung 9 stellt den prinzipiellen Aufbau einer SAML-Assertion vor. Die detaillierte Beschreibung des Aufbaus erfolgt in Abschnitt

35 Kapitel 2: Grundlagen des Federated Identity Managements MajorVersion MinorVersion Issuer IssueInstant AssertionID NotBefore NotOnOrAfter Assertion Conditions Condition AudienceRestrictionCondition Audience Advice AttributeStatement SubjectStatement AuthenticationStatement AuthorizationDecisionStatement ds:signature Abbildung 9:Struktur einer SAML-Assertion [SSOTele] Im Folgenden ein Beispiel für eine SAML Authentication-Assertion: <?xml version="1.0" encoding="utf-8"?> <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:1.0: AssertionID="abc123" IssueInstant=" T09:13:29Z" Issuer=" MajorVersion="1" MinorVersion="1"> <saml:conditions NotBefore=" T09:12:29Z" NotOnOrAfter=" T09:18:29Z"> </saml:conditions> <saml:authenticationstatement AuthenticationInstant=" T09:13:29Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml:subject> <saml:nameidentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName" NameQualifier=" uid=admin </saml:nameidentifier> </saml:subject> </saml:authenticationstatement> </saml:assertion> 24

36 Kapitel 2: Grundlagen des Federated Identity Managements Aufbau einer SAML-Assertion Die folgenden Punkte definieren die SAML-Konstrukte, welche in einer SAML-Assertion vorkommen müssen bzw. dürfen [SAMLProt]: Element <saml:assertion> Das Element <saml:assertion> ist das Wurzelelement einer SAML-Assertion. Folgende Attribute sind im <saml:assertion>-element enthalten: MajorVersion & MinorVersion [verpflichtend] Diese Attribute legen fest, auf welcher SAML-Version die Assertion beruht. AssertionID [verpflichtend] Der Identifier einer Assertion. Dieses Attribut verweist eindeutig auf eine Assertion und ist deshalb vom Typ xsd:id. Issuer [verpflichtend] Bezeichnet den Namen der SAML-Autorität, welche die Assertion generiert hat. Der Typ dieses Attributs ist xsd:string. Der Name eines Issuers sollte eindeutig sein, damit bei den verschiedenen Service Providern keine Zuordnungsprobleme auftreten. Deshalb ist es sinnvoll, als Identifier eine URI-Referenz zu benutzen, die in jedem Kontext eindeutig ist. IssueInstant [verpflichtend] Der Zeitpunkt, zu dem diese Assertion ausgestellt wurde. Das Zeitformat ist dargestellt als Universal Coordinated Time (UTC). Als Typ wird der W3C XML Schema Simple-Type xsd:datetime verwendet [W3CSchema]. Weiter können folgende Elemente verwendet werden: <Conditions> [optional] Dieses Element legt den Gültigkeitsbereich einer Assertion fest. <Advice> [optional] Zusätzliche Informationen, welche helfen sollen, eine Assertion in bestimmten Situationen verarbeiten zu können. Falls Applikationen das Advice-Element nicht unterstützen, kann dieses jedoch auch ignoriert werden. <ds:signature> [optional] Aus Sicherheitsgründen kann eine Assertion mittels XML Digital Signature signiert werden. Zudem muss eine syntaktisch korrekte SAML-Assertion mindestens eines der folgenden Elemente enthalten: <SubjectStatement> Beschreibung eines Subjekts. <AuthenticationStatement> Aussage über die Authentifizierung eines Subjekts. <AuthorizationDecisionStatement> Aussage über die Autorisierung eines Subjekts bzgl. bestimmter Ressourcen. 25

37 Kapitel 2: Grundlagen des Federated Identity Managements <AttributeStatement> Enthält die Attribut-/Werte-Paare (Eigenschaften), welche einem Subjekt zugeordnet wurden. Das folgende Schema Fragment definiert das <saml:assertion>-element: <element name="assertion" type="saml:assertiontype"/> <complextype name="assertiontype"> <sequence> <element ref="saml:conditions" minoccurs="0"/> <element ref="saml:advice" minoccurs="0"/> <choice maxoccurs="unbounded"> <element ref="saml:statement"/> <element ref="saml:subjectstatement"/> <element ref="saml:authenticationstatement"/> <element ref="saml:authorizationdecisionstatement"/> <element ref="saml:attributestatement"/> </choice> < element ref ="ds:signature" minoccurs ="0"/> </sequence> <attribute name="majorversion" type="integer" use="required"/> <attribute name="minorversion" type="integer" use="required"/> <attribute name="assertionid" type="id" use="required"/> <attribute name="issuer" type="string" use="required"/> <attribute name="issueinstant" type="datetime" use="required"/> </complextype> Element <saml:conditions> Das Element <saml:conditions> kann die folgenden optionalen Elemente und Attribute enthalten: NotBefore [optional] Spezifiziert den frühesten Zeitpunkt, zu dem die Assertion gültig ist. Das Zeitformat ist analog zum Attribut IssueInstant definiert. NotOnOrAfter [optional] Spezifiziert den Zeitpunkt, ab dem die Assertion ungültig ist. Das Zeitformat ist analog zum Attribut IssueInstant definiert. <Condition> [beliebige Anzahl] Dieses Element kann verwendet werden, um mit Hilfe eines Extension-Schemas neue Bedingungen zu definieren. <AudienceRestrictionCondition> [beliebige Anzahl] Spezifiziert, an welche Teilnehmer eine Assertion adressiert werden kann. <DoNotCacheCondition> [beliebige Anzahl] Dieses Element legt fest, dass eine Assertion sofort verwendet werden muss, d.h., sie darf nicht für einen zukünftigen Zeitpunkt aufbewahrt werden. Wird das <saml:conditions> Element verwendet, so sind einige Regeln zu beachten: Werden innerhalb des <saml:conditions>-elements keine Attribute oder Subelemente verwendet, so ist die SAML-Assertion gültig. 26

38 Kapitel 2: Grundlagen des Federated Identity Managements Ist ein Attribut oder Subelement ungültig, so ist die gesamte SAML-Assertion ungültig. Kann die Gültigkeit für eines der Attribute bzw. Subelemente nicht evaluiert werden, so ist die Gültigkeit unbestimmt, d.h., die Gültigkeit der Assertion kann nicht eindeutig bestimmt werden. Sind alle Attribute und Subelemente gültig, so ist die gesamte SAML-Assertion gültig. Das folgende Schema-Fragment definiert das <saml:conditions>-element: <element name="conditions" type="saml:conditionstype"/> <complextype name="conditionstype"> <choice minoccurs="0" maxoccurs="unbounded"> <element ref="saml:audiencerestrictioncondition"/> <element ref= saml:donotcachecondition > <element ref="saml:condition"/> </choice> <attribute name="notbefore" type="datetime" use="optional"/> <attribute name="notonorafter" type="datetime" use="optional"/> </complextype> Element <saml:subjectstatement> Die Elemente <saml:conditions> sowie <saml:advice> sind optional. Sie enthalten Informationen über Annahmen sowie Hinweise für die Bearbeitung dieser Nachricht. Daran schließen sich eine oder mehrere Aussageelemente (Statements) an. Durch die Verwendung des <saml:subjectstatement>-elements können Subjekte (z.b. ein Benutzer) beschrieben werden. Dieses Element enthält ein <saml:subject>-element, welches die tatsächliche Identität des Subjekts sowie Informationen für die Durchführung der Authentifizierung enthält. Dabei kann die Identität in Form von adressen, X509v3- Zertifikaten oder aber Namen, die sich an die Windows-Domänen-Namenskonvention halten, vorkommen. Das <saml:subject>-element enthält entweder eines oder beide der folgenden Subelemente: <NameIdentifier> Identifizierung eines Subjekts durch seinen Namen und seine Sicherheitsdomäne. <SubjectConfirmation> Enthält Informationen, damit ein Subjekt authentifiziert werden kann. Das folgende Schema-Fragment definiert das <saml:subject>-element: <element name="subject" type="saml:subjecttype"/> <complextype name="subjecttype"> <choice> <sequence> <element ref="saml:nameidentifier"/> <element ref="saml:subjectconfirmation" minoccurs="0"/> </sequence> <element ref="saml:subjectconfirmation"/> </choice> </complextype> 27

39 Kapitel 2: Grundlagen des Federated Identity Managements Das Element <saml:nameidentifier> hat folgende Attribute: NameQualifier [optional] Angabe einer Sicherheitsdomäne, welche den Namen des Subjekts bestätigt. Dieses Attribut ist sinnvoll, wenn mehrere verschiedene Autoritäten nebeneinander existieren. Subjektnamen können dann eindeutig einer bestimmten Autorität zugeordnet werden. Dieses Konzept entspricht im Wesentlichen den Konzepten der XML-Namespaces. Format [optional] Enthält eine URI-Referenz, welche das Format der Informationen vom <saml:nameidentifier>-element vorgibt. Das Schema vom Element <NameIdentifier> sieht folgendermaßen aus: <element name="nameidentifier" type="saml:nameidentifiertype"/> <complextype name="nameidentifiertype"> <simplecontent> <extension base="string"> <attribute name="namequalifier" type="string" use="optional"/> <attribute name="format" type="anyuri" use="optional"/> </extension> </simplecontent> </complextype> Das Element <saml:subjectconfirmation> innerhalb des Elements <saml:subject> spezifiziert die Beziehung zwischen dem Subjekt und dem Aussteller (Autor) der SAML- Assertion. Das Element unterteilt sich in folgende Subelemente: <ConfirmationMethod> [eins oder mehr] Speichert eine URI-Referenz, die das Protokoll bezeichnet, welches zur Authentifizierung des Subjekts benutzt werden soll. Dieses Element ist nicht optional, d.h., es muss mindestens einmal innerhalb des Elements <saml:subjectconfirmation> vorkommen. <SubjectConfirmationData> [optional] Dieses optionale Element speichert zusätzliche Authentifizierungsinformationen, die von einem spezifischen Authentifizierungsprotokoll verwendet werden können. <ds:keyinfo> [optional] Enthält den Zugang für den kryptografischen Schlüssel des Subjekts. Das folgende Schema-Fragment definiert das <saml:subjectconfirmation>-element: <element name="subjectconfirmation" type="saml:subjectconfirmationtype"/> <complextype name="subjectconfirmationtype"> <sequence> <element ref="saml:confirmationmethod" maxoccurs="unbounded"/> <element ref="saml:subjectconfirmationdata" minoccurs="0"/> <element ref="ds:keyinfo" minoccurs="0"/> </sequence> </complextype> <element name="subjectconfirmationdata" type="anytype"/> <element name="confirmationmethod" type="anyuri"/> 28

40 Kapitel 2: Grundlagen des Federated Identity Managements Element <saml:authenticationstatement> Das <saml:authenticationstatement>-element beinhaltet Informationen darüber, ob das Subjekt bereits von einer Stelle authentifiziert wurde. Dieses Element speichert Daten, die angeben, wo und wann diese Authentifizierung mit welchem Verfahren durchgeführt wurde. Die Basis für das Element stellt der SubjectStatementAbstractType. Folgende Attribute und Elemente kommen hinzu: AuthenticationMethod [verpflichtend] Eine URI-Referenz, welche den Authentifizierungsmechanismus spezifiziert, der zur Authentifizierung des Subjekts verwendet wurde. AuthenticationInstant [verpflichtend] Der Zeitpunkt, zu dem das Subjekt authentifiziert wurde (Format UTC). <SubjectLocality> [optional] Die DNS-Domäne und die IP-Adresse der Autorität, bei der das Subjekt authentifiziert wurde. <AuthorityBinding> [beliebige Anzahl] Referenz auf eine Instanz, bei der ggf. weitere Informationen bzgl. des Subjekts abfragbar sind. Das folgende Schema definiert das <saml:authenticationstatement>-element: <element name="authenticationstatement" type="saml:authenticationstatementtype"/> <complextype name="authenticationstatementtype"> <complexcontent> <extension base="saml:subjectstatementabstracttype"> <sequence> <element ref="saml:subjectlocality" minoccurs="0"/> <element ref="saml:authoritybinding"minoccurs="0" maxoccurs="unbounded"/> </sequence> <attribute name="authenticationmethod" type="anyuri"use= required /> <attribute name="authenticationinstant" type="datetime"use= required /> </extension> </complexcontent> </complextype> Element <saml:authorizationdecisionstatement> In diesem Element befinden sich Informationen über Autorisierungsentscheidungen bzgl. des Zugriffs eines Subjekts auf bestimmte Ressourcen. Dabei beschreibt dieses Element die Ressource, auf die zugegriffen werden soll, die Aktion, die darauf ausgeführt wird und letztendlich die Entscheidung, ob diese Aktion ausgeführt werden darf oder nicht (z.b. ein schreibender Zugriff). Die Ressource wird dabei durch eine URI-Referenz identifiziert. Der Typ SubjectStatementAbstractType wird um folgende Attribute und Elemente erweitert: Ressource [verpflichtend] Eine URI-Referenz, welche die Ressource identifiziert, auf die zugegriffen werden soll. 29

41 Kapitel 2: Grundlagen des Federated Identity Managements Decision [verpflichtend] Enthält die Entscheidung der SAML-Autorität. Mögliche Werte sind: Permit, Deny, Indeterminate. <Action> [eins oder mehr] Art der Aktionen, die auf der Ressource ausgeführt werden dürfen. <Evidence> [optional] Eine Menge von SAML-Assertions, welche von einer SAML-Autorität herangezogen wurden, um die Authorization-Assertion zu erstellen. Das folgende Schema definiert das <saml:authorizationdecisionstatement>- Element: <element name="authorizationdecisionstatement" type="saml:authorizationdecisionstatementtype"/> <complextype name="authorizationdecisionstatementtype"> <complexcontent> <extension base="saml:subjectstatementabstracttype"> <sequence> <element ref="saml:action" maxoccurs="unbounded"/> <element ref="saml:evidence" minoccurs="0"/> </sequence> <attribute name="resource" type="anyuri" use="required"/> <attribute name="decision" type="saml:decisiontype" use="required"/> </extension> </complexcontent> </complextype> Element <saml:attributestatement> Dieses Element enthält die Eigenschaften bzw. Attribute, welche einem Subjekt zugeordnet wurden. Die SAML-Autorität beglaubigt mit der Generierung eines Attribute-Statements die Eigenschaften eines Subjekts. Der SubjectStatementAbstractType wird um folgendes Element erweitert: <Attribute> [verpflichtend] Spezifiziert ein Attribut für ein Subjekt. Das Element muss mindestens einmal in einem <saml:attributestatement> vorkommen. Das folgende Schema-Fragment definiert das <saml:attributestatement>-element: <element name="attributestatement" type="saml:attributestatementtype"/> <complextype name="attributestatementtype"> <complexcontent> <extension base="saml:subjectstatementabstracttype"> <sequence> <element ref="saml:attribute" maxoccurs="unbounded"/> </sequence> </extension> </complexcontent> </complextype> Das Element <saml:attribute> enthält wiederum mindestens ein Unterelement <saml:attributevalue>. Dieses Element speichert den Wert eines Attributs. 30

42 Kapitel 2: Grundlagen des Federated Identity Managements SAML-Protokoll Das SAML-Request- bzw. Response-Protokoll definiert ein standardisiertes Nachrichtenformat, um Assertions von einer SAML-Autorität abfragen zu können. Die Anfrage wird als SAML-Request- und die Antwort als SAML-Response-Nachricht geschickt. Zur Übertragung dieser Nachrichten können Transportprotokolle verwendet werden. Ein solches Binding ist z.b. das SOAP über HTTP-Binding. Abbildung 10 zeigt den prinzipiellen Ablauf einer SAML-Anfrage und einer darauf folgenden SAML-Antwort. Identity Provider (Trusted SAML Authority) SAML-Request SAML Query SAML-Response SAML Assertion Service Provider (SAML Consumer) Abbildung 10: Austausch von SAML-Request- & Response-Nachrichten Das SAML-Request-Protokoll definiert folgende Anfragetypen [SAMLProt]: SubjectQuery AuthenticationQuery AttributeQuery AuthorizationDecisionQuery AssertionIDReference AssertionArtifact Der Aufbau einer SAML-Response-Nachricht bleibt stets gleich, unabhängig von der Art der Anfrage. Im Folgenden wird auf die Art und den Aufbau der SAML-Request-Nachrichten eingegangen. RequestAbstractType Dieser Complex-Type definiert Attribute und Elemente für den allgemeinen Aufbau einer SAML-Request-Nachricht. 31

43 Kapitel 2: Grundlagen des Federated Identity Managements Folgende Attribute und Elemente müssen bzw. können in einem SAML-Request vorhanden sein: RequestID [verpflichtend] Eine eindeutige ID für jede Anfrage (xsd:id). MajorVersion [verpflichtend] SAML-Versionsnummer. MinorVersion [verpflichtend] SAML-Versionsnummer. IssueInstant [verpflichtend] Zeitpunkt, zu dem der SAML-Request generiert wurde (Format UTC). <RespondWith> [beliebige Anzahl] Art der Response-Nachricht (z.b. Authentication-Assertion), welche der Empfänger vom Sender erwartet. Beinhaltet ein SAML-Request kein <RespondWith> Element, so kann die SAML-Autorität mit einem Statement eines beliebigen Typs (z.b. Attribute-Statement) antworten. <ds:signature> [optional] XML Signature, um die Anfrage zu authentifizieren. Element <samlp:request> Dieses Element spezifiziert das Root-Tag eines SAML-Requests. Im Folgenden die Zusammensetzung eines <samlp:request>-elements: <SubjectQuery> [optional] Eine Erweiterung, die es mittels eines selbstdefinierten Schemas erlaubt, neue Anfragetypen zu definieren. <AuthenticationQuery> [optional] Anfrage nach einer Authentication-Assertion. <AttributeQuery> [optional] Anfrage nach einer Attribute-Assertion. <AuthorizationDecisionQuery> [optional] Anfrage nach einer Authorization-Assertion. <AssertionIDReference> [eins oder mehr] Anfrage nach einer Assertion mittels einer Referenz auf den Wert des Attributs AssertionID. <AssertionArtifact>[eins oder mehr] Anfrage nach einer Assertion mit Hilfe eines Artefakts. Dieses Artefakt ist ein eindeutiger Zeiger auf eine Assertion, welche von einer SAML-Autorität generiert wurde. 32

44 Kapitel 2: Grundlagen des Federated Identity Managements Das folgende Schema Fragment definiert das <samlp:request>-element: <element name="request" type="samlp:requesttype"/> <complextype name="requesttype"> <complexcontent> <extension base="samlp:requestabstracttype"> <choice> <element ref="samlp:query"/> <element ref="samlp:subjectquery"/> <element ref="samlp:authenticationquery"/> <element ref="samlp:attributequery"/> <element ref="samlp:authorizationdecisionquery"/> <element ref="saml:assertionidreference" maxoccurs="unbounded"/> <element ref="samlp:assertionartifact" maxoccurs="unbounded"/> </choice> </extension> </complexcontent> </complextype> Element <samlp:response> Das <samlp:response>-element ist das Wurzelelement einer SAML-Response-Nachricht. Es spezifiziert den Status eines SAML-Requests. Die Antwort kann dabei keine, eine oder mehrere Assertions enthalten. Der Aufbau einer SAML-Response-Nachricht ist stets gleich, unabhängig von dem vorangegangenen SAML-Request. Die Basis dieses Elements bildet der ResponseAbstractType. Die Attribute bzw. Elemente entsprechen im Wesentlichen denen des RequestAbstractTypes mit der Ausnahme, dass das Attribut RequestID durch das entsprechende Attribut ResponseID ersetzt wurde. Zudem wurde das Element <samlp:respondwith> durch <samlp:recipient> ausgetauscht. Dieses optionale Element speichert den beabsichtigten Empfänger der Nachricht in Form einer URI. ResponseAbstractType wird darüber hinaus durch folgende Elemente erweitert: <Status> [verpflichtend] Enthält Statusinformationen bzgl. eines zugehörigen SAML-Requests. <Assertion> [beliebige Anzahl] Enthält eine SAML-Assertion eines beliebigen Typs (z.b. Authentication-Assertion). <element name="response" type="samlp:responsetype"/> <complextype name="responsetype"> <complexcontent> <extension base="samlp:responseabstracttype"> <sequence> <element ref="samlp:status"/> <element ref="saml:assertion" minoccurs="0" maxoccurs="unbounded"/> </sequence> </extension> </complexcontent> </complextype> Das Element <samlp:status> ist in folgende Subelemente unterteilt: <StatusCode> [verpflichtend] Enthält den Code, welcher den Status einer korrespondierenden SAML-Anfrage repräsentiert. 33

45 Kapitel 2: Grundlagen des Federated Identity Managements <StatusMessage> [optional] Nachricht, die an einen Operator zurückgegeben werden kann (z.b. Fehlermeldung). <StatusDetail> [optional] Speichert zusätzliche Informationen, um bestimmte Fehlermeldungen genauer zu erläutern. <element name="status" type="samlp:statustype"/> <complextype name="statustype"> <sequence> <element ref="samlp:statuscode"/> <element ref="samlp:statusmessage" minoccurs="0"/> <element ref="samlp:statusdetail" minoccurs="0"/> </sequence> </complextype> Das Element <samlp:statuscode> spezifiziert eine beliebige, möglicherweise verschachtelte Anzahl von Codes, welche den Status eines zugehörigen SAML-Requests angeben. Es enthält die folgenden Attribute bzw. Elemente: Value [verpflichtend] Der Wert eines Status-Codes. Der Typ dieses Attributs ist QName. <StatusCode> [optional] Ein untergeordneter (verschachtelter) Status-Code, um die Fehlermeldung genauer zu spezifizieren. In der SAML Spezifikation 1.1 wurden folgende Standardwerte für das <samlp:statuscode>-element bzw. für das zugehörige Attribut Value definiert: Success Die Anfrage war erfolgreich, d.h., die angefragte SAML-Assertion konnte erfolgreich übermittelt werden. VersionMismatch Die SAML-Autorität konnte die Anfrage nicht bearbeiten, da die SAML-Version der Anfragenachricht nicht korrekt war. Requester Aufgrund eines Fehlers auf Seite des Anfragenden (SP) konnte die Anfrage nicht verarbeitet werden. Responder Aufgrund eines Fehlers auf Seite des Antwortenden (IdP) konnte die Anfrage nicht verarbeitet werden. RequestVersionTooHigh Der Aussteller einer SAML-Nachricht kann auf die Anfrage nicht antworten, da die Protokoll-Version des SAML-Requests zu hoch ist, d.h., der Antwortende unterstützt eine niedrigere Version. RequestVersionTooLow Der Aussteller einer SAML-Nachricht kann auf die Anfrage nicht antworten, da die Protokoll-Version des SAML-Requests zu niedrig ist. 34

46 Kapitel 2: Grundlagen des Federated Identity Managements RequestVersionDeprecated Der Aussteller kann keine SAML-Requests mit dieser Protokoll Version bearbeiten. TooManyResponses Die Antwort würde mehr Elemente enthalten als die SAML-Autorität zurückgeben kann. RequestDenied Der Antwortende konnte zwar die Anfrage bearbeiten, verweigert dies jedoch aus bestimmten Gründen. Dies geschieht oftmals infolge von Sicherheitsbedenken. RessourceNotRecognized Die SAML-Autorität unterstützt entweder keine Anfragen bzgl. Ressourcen oder die angegebene Ressource ist ungültig bzw. kann nicht gefunden werden Neben diesen vordefinierten Standard-Werten ist es möglich, weitere eigene Status-Codes in anderen Namensräumen zu entwerfen. Es ist jedoch nicht möglich, neue Codes innerhalb des SAML-Assertion- bzw. Protokoll-Namensraums zu definieren SAML-Bindings Die SAML-Bindings [SAMLBind] legen Regeln fest, die angeben, wie SAML-Request- bzw. Response- Nachrichten auf standardisierte Transport- und Kommunikationsprotokolle abgebildet werden. Aktuell definiert die SAML-Spezifikation 1.1 nur ein Binding, das sog. SAML SOAP Binding. Dieses beschreibt, wie SAML-Request- bzw. Response-Nachrichten in eine SOAP-Nachricht verpackt bzw. eingefügt werden können. Obwohl eine SOAP- Nachricht unabhängig vom darunter liegenden Transportprotokoll ist, muss eine SAML- Autorität als Standard das SOAP über HTTP Binding definieren. Eine genaue Definition dieses Bindings kann unter [SOAPAdj] gefunden werden. Ein Beispiel für eine SAML-Anfrage mittels SOAP über HTTP: POST /SamlService HTTP/1.1 Host: Content-Type: text/xml Content-Length: nnn SOAPAction: <SOAP-ENV:Envelope xmlns:soap-env= > <SOAP-ENV:Body> <samlp:request xmlns:samlp:= xmlns:saml= xmlns:ds= > <ds:signature> </ds:signature> <samlp:authenticationquery> </samlp:authenticationquery> </samlp:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SAML-Profiles Die SAML-Profiles [SAMLBind] legen fest, wie SAML-Assertions in ein Message- Framework oder ein Protokoll eingebunden und wieder extrahiert werden. Das OASIS Security Services Technical Committee definiert in SAML 1.1 zwei Web- Browser-Profile, um Single Sign-On (SSO) möglich zu machen: 35

47 Kapitel 2: Grundlagen des Federated Identity Managements Browser/Artifact-Profile Browser/POST-Profile Neben diesen beiden, speziell für den Web-Browser-Einsatz entwickelten Profilen wurden außerhalb des Security Services Technical Committees weitere Profile veröffentlicht: Das OASIS Web-Services Technical Commitee entwickelte innerhalb der WS-Security Spezifikation das so genannte SAML Token Profile. Dieses beschreibt, wie SAML- Assertions verwendet werden können, um eine Web-Service Nachricht abzusichern. Das Liberty Alliance Projekt definiert mehrere verschiedene Profile, welche den SAML Standard erweitern. Browser/Artifact-Profile Das SAML Single Sign-On Browser/Artifact-Profile ist ein Authentifizierungsprotokoll, an dem drei Parteien beteiligt sind (vgl. Abb.11). Bei Einsatz dieses Profils wird ein SAML- Artefakt als Teil eines URL Query Strings zwischen den beteiligten Parteien übertragen. Das Artefakt ist eine eindeutige Referenz bzw. Pointer auf eine SAML-Assertion. Technisch betrachtet ist ein SAML-Artefakt eine 8-42 Byte große Hexadezimalzahl. Die folgende Grafik zeigt einen Single Sign-On Prozess, beruhend auf dem Browser/Artifact- Profile: Web Browser Source Site Destination Site (1) (2) (3) (4) (5) (6) Abbildung 11: Single Sign-On mit dem Browser/Artifact Profile (1) Zugriff auf Inter-Site Transfer Service: Ein Nutzer/Browser versucht per Link, auf eine Ressource der Destination Site zuzugreifen. Da der Nutzer/Browser der Zielseite unbekannt ist und die gewünschte Ressource geschützt ist, kann dieser nicht direkt auf die Ressource zugreifen. Stattdessen ruft der Nutzer/Browser mittels eines Hyperlinks den sog. Inter-Site Transfer Service (ISX) URL auf. Dieser URL setzt sich aus folgenden Bestandteilen zusammen: http(s)://<inter-site transfer host name>?target=<target> 36

48 Kapitel 2: Grundlagen des Federated Identity Managements Der erste Teil dieser Adresse bezeichnet den Zugangspunkt für den Inter-Site Transfer Service der Source Site. Nach Aufruf dieses Dienstes wird von einer SAML-Autorität eine SAML-Assertion (falls noch nicht vorhanden) und ein zugehöriges Artefakt erstellt. Der Wert des angehängten Parameters TARGET entspricht der Adresse der Zielressource, auf welche der Benutzer zugreifen will. (2)+(3) Umleitung auf die Destination Site: Der Inter-Site Transfer Service leitet den Nutzer/Browser auf den Artifact Receiver Service der Zielseite um. Dabei wird an diesen Redirect-URL als Parameter das SAML-Artefakt des Nutzers angehängt. Das Format dieses URLs sieht im Allgemeinen folgendermaßen aus: http(s)://<artifact_receiver_host_name>?target=<target>&samlart=<ar tifact> (4)+(5) Übermittlung einer SAML-Assertion: Die Zielseite schickt den erhaltenen Artefakt innerhalb eines SAML-Requests an die Source Site, um die entsprechende SAML- Assertion zu erhalten. Existiert eine solche SAML-Assertion, so wird diese von der Source-Site in Form einer SAML-Response- Nachricht an die Destination Site geschickt. (6) Zugriff auf die gewünschte Ressource: An den Browser des Nutzers wird eine HTTP-Antwortnachricht geschickt, die angibt, ob der Benutzer auf die gewünschte Ressource zugreifen darf oder nicht. Wichtig ist, dass ein SAML-Artefakt nur für eine Anfrage verwendet werden kann (one-timeuse), um Sicherheitsprobleme wie z.b. Replay-Attacken zu vermeiden. Browser/POST-Profile Dieses Profil ermöglicht es, Authentifizierungs- bzw. Autorisierungsdaten direkt, ohne die Verwendung eines SAML-Artefakts, zu übertragen. SAML-Assertions werden dabei durch ein HTML-Formular zuerst in den Browser des Nutzers geladen, um danach als Teil eines HTTP Post Payloads an die Destination Site übertragen zu werden. Die folgende Grafik zeigt einen Single Sign-On Prozess, beruhend auf dem Browser/POST- Profile: Web Browser Source Site Destination Site (1) (2) (3) (4) Abbildung 12: Single Sign-On mit dem Browser/POST Profile 37

49 Kapitel 2: Grundlagen des Federated Identity Managements (1) Zugriff auf den Inter-Site Transfer Service: analog zu Browser/Artifact-Profile. (2) Übermittlung der SAML-Response: Die Source Site übergibt in Form eines HTML-Formulars eine SAML-Response-Nachricht an den Browser des Nutzers. Innerhalb der Response-Nachricht befindet sich eine SAML-Assertion. (3) Der Browser übermittelt das Formular bzw. Formulardaten an die Destination Site. (4) Zugriff auf die gewünschte Ressource: Analog zu Browser/Artifact-Profile. Wird das Browser/Post-Profile verwendet, so muss jede SAML-Response digital signiert werden. Eine Signierung der SAML-Assertions ist hingegen optional. Um die Übertragung von unverschlüsselten Nachrichten zu vermeiden, sollte sowohl bei Einsatz des Browser/Artifact-Profiles als auch bei Einsatz des Browser/POST-Profiles der jeweilige Inter-Site Transfer Service URL durch SSL 3.0 oder TLS 1.0 geschützt werden Sicherheit von SAML Um die Vertraulichkeit von SAML-Nachrichten auch außerhalb der Transportebene (SSL/TLS) gewährleisten zu können, besteht die Möglichkeit, diese mit XML Encryption [XMLEnc, XMLDec] zu verschlüsseln. XML Encryption liefert eine Syntax, um XML- Dokumente oder Dokumentenblöcke selektiv zu verschlüsseln und zu dekodieren. XML Signature [XMLSig] kann verwendet werden, um die Datenintegrität und Authentizität bei SAML Inhalten sicherzustellen. XML Signature ist eine Norm zur digitalen Signatur von XML-Dokumenten. Dieses Verfahren garantiert, dass eine XML Nachricht genau so beim Empfänger eintrifft, wie sie der Absender abgeschickt hat. Außerdem lässt sich die Urheberschaft einer Information auf diese Weise verbindlich validieren, so dass sich diese im Nachhinein nicht abstreiten lässt (engl. Non-Repudiation) Ausblick auf SAML 2.0 Im März dieses Jahres wurde SAML 2.0 [SAML20], der Nachfolger von SAML 1.1, vom OASIS Konsortium offiziell zum aktuellen OASIS-Standard erklärt. SAML 2.0 wurde in Zusammenarbeit mit dem OASIS Konsortium, der Liberty Alliance und der Shibboleth Gruppe entworfen mit dem Ziel, die verschiedenen Föderationsstandards zu einem einzigen zu vereinigen. SAML 2.0 ist eine umfangreiche Überarbeitung der Vorgängerversion SAML 1.1. Im Wesentlichen wurden folgende Änderungen vorgenommen bzw. Funktionalitäten hinzugefügt [SAMLOv20]: Konvergenz Mit SAML 2.0 werden die Konzepte von SAML 1.1 mit den Konzepten der Hochschulinitiative Shibboleth und des Liberty Alliance Identity Federation Frameworks (vgl. Kapitel 2.4.4) verbunden. Nach Meinung vieler Experten ist SAML 2.0 ein maßgeblicher Schritt in Richtung einer vollständigen Konvergenz der verschiedenen Federated Identity Standards. 38

50 Kapitel 2: Grundlagen des Federated Identity Managements Federated Identity Management In SAML 1.0 und SAML 1.1 ist zwar Single Sign-On durch das Übertragen eines Identifiers (innerhalb eines Authentication-Statements) möglich, jedoch wird nicht spezifiziert, wie sich zwei unterschiedliche Seiten eines Circle of Trust auf die zu verwendenden Nutzer-Identifier einigen können. Bisher mussten sich die Teilnehmer einer Single Sign-On Umgebung außerhalb von SAML 1.0 bzw. 1.1 über die Identifier der berechtigten Nutzer abstimmen. SAML 2.0 löst dieses Problem, indem festgelegt wird, wie zwei Webseiten sich online, unter Teilnahme des Nutzers, auf einen (oder mehrere) Identifier für diesen Nutzer einigen können. Federation Profiles Sowohl das Browser/Artifact- als auch das Browser/POST-Profil wurden erweitert, so dass mehr Anwendungsfälle abgedeckt werden können als dies in Version 1.1 der Fall war. Das neue Webbrowser SSO-Profile integriert die Konzepte dieser beiden Profile und ein HTTP- Redirect Binding. Dies ermöglicht eine zusätzliche Flexibilität zwischen Identity- und Service-Provider, da diejenige Partei, welche den SSO-Prozess initiert, individuell entscheiden kann, welches dieser Profile zum Austausch von SAML-Assertions verwendet werden soll. Neben den Browser-Profilen wurde zusätzlich ein Profil (Enhanced Client or Proxy Profile) für die Unterstützung von mobilen Endgeräten hinzugefügt. Dieses Profil gestattet den Einsatz der Federated Identity Technologie im Mobilfunkbereich, in dem eine Interaktion mit Web Access Protocol (WAP) Gateways ermöglicht wird. Datenschutz Die Vorgängerversionen beschäftigen sich mit dem Aspekt Datenschutz und Anonymität nur rudimentär. SAML 2.0 bietet nun eine Anzahl von Möglichkeiten, um sicherheitskritische Anwendungen zu unterstützen. Zu erwähnen ist hier vor allem die Möglichkeit, Pseudonyme für einen Nutzer zu definieren. Diese Pseudonyme erlauben es Service Providern, Benutzer zu identifizieren, ohne Kenntnis über deren tatsächliche Identität zu haben. SAML 2.0 integriert zudem einen Mechanismus, mit dem Provider die Möglichkeit haben, sog. Privacy Policies/Einstellungen, welche ein Endnutzer bei einer Partei definiert hat, auszutauschen. Mit diesen Privacy Policies kann ein Nutzer individuell festlegen, welche Aktionen die beteiligten Parteien einer Föderation durchführen dürfen und welche nicht. Erhält z.b ein Provider die Erlaubnis eines Benutzers, dass dessen Adresse innerhalb der Föderation ausgetauscht werden darf, so kann der Provider diese Tatsache den anderen Parteien des Circles of Trust mittels einer SAML-Assertion mitteilen. Session Management SAML 2.0 unterstützt Single Logout [SAMLProt2]. Beispiel: Nachdem sich ein Nutzer bei einer SAML-Autorität erfolgreich authentifiziert hat, baut dieser anschließend, mittels des Single Sign-On-Mechanismus, Sessions zu mehreren verschiedenen Webseiten auf. Beendet der Benutzer nun eine dieser Sitzungen durch Ausloggen, so werden automatisch alle anderen aktiven Sessions des Nutzers auch beendet. 39

51 Kapitel 2: Grundlagen des Federated Identity Managements Die aktiven Sessions eines Benutzers werden dabei von dessen Identity Provider verwaltet. Dieses Verfahren wird Single Logout genannt. SAML 2.0 ist durch die Zusammenführung von SAML 1.1 und Liberty ID-FF 1.2 (vgl. Kapitel ) ein maßgeblicher Schritt in Richtung eines einheitlichen Standards im Bereich Federated Identity Management. Ob dieser Standard jedoch die hohen Erwartungen vieler Experten und Entwickler erfüllen kann, bleibt abzuwarten, da bisher keine der namhaften Sicherheitsfirmen wie RSA Security, Computer Associates etc. Produkte anbieten, die diese neue Version unterstützen. SAML 2.0 spielt deshalb in der Praxis momentan noch keine Rolle. Aus diesem Grund bezieht sich diese Diplomarbeit ausschließlich auf den Standard SAML 1.0 bzw Liberty Alliance Projekt Das Liberty Alliance Project [LibAll] ist ein weltweiter Zusammenschluss von mehr als 180 verschiedenen Unternehmen und Organisationen. Das Projekt wurde 2001 von Sun Microsystems als Konkurrenz zu Microsoft.NET Passport ins Leben gerufen. Das Projekt hat eine breite Unterstützung erhalten; namhafte Firmen wie IBM, Intel, American Express, Nokia, Oracle und VeriSign arbeiten daran mit. Das Konsortium hat die Aufgabe, ein offenes Framework für den Aufbau von heterogenen Federated Identity Umgebungen (basierend auf Web-Services) zu entwickeln. Neben Identity Federation, Single Sign-On, Single Logout und Account Linking liegt ein besonderer Schwerpunkt auf der Einhaltung der Privatsphäre eines Benutzers. Um die gesetzten Ziele zu erreichen, baut das Liberty Framework auf anderen existierenden Standards wie z.b. SAML auf. In den Spezifikationen der Liberty Alliance ist unter anderem festgelegt, dass Anwender ihre Nutzerkonten (engl. Accounts), die sie auf verschiedenen Webseiten oder in verschiedenen Unternehmen haben, miteinander verbinden können (Account-Linking), sofern die Dienstanbieter eine Zusammenarbeit erlauben. Die Authentifizierung wird zudem für den Fall, dass sich ein User abmeldet, bei allen beteiligten Anbietern zurückgezogen (Single Logout). Die zusammengeschlossenen Firmen und Einrichtungen können sich intern darüber verständigen, welcher Authentifizierungsmechanismus nötig ist, um einen Nutzer korrekt anzumelden. Bei diesem Vorgang sollen jedoch keine Kundendaten ausgetauscht werden, d.h., innerhalb eines dezentralen Circle of Trust sollen ausschließlich die Informationen weitergegeben werden, die angeben, ob ein User bei einer vertrauenswürdigen Autorität bereits erfolgreich authentifiziert wurde oder nicht. Die folgenden Begriffe sind im Kontext des Liberty Alliance Projektes üblich und sollen hier erklärt werden: Account Linking: Der Benutzer kann seine Service Provider Accounts selbstständig mit einem oder mehreren Identity Provider Accounts verbinden. Durch diese erstellte Verknüpfung können Authentifizierungsinformationen zwischen den verschiedenen Providern übergangslos ausgetauscht werden. 40

52 Kapitel 2: Grundlagen des Federated Identity Managements Circle of Trust bzw. Authentication Domain: Eine Gruppe von Service Providern (mit mindestens einem Identity Provider), welche sich zusammengeschlossen haben, um mit Hilfe der Liberty Technologie Authentifizierungsdaten von Nutzern untereinander auszutauschen. Nach dem Aufbau eines solchen Circle of Trust bzw. einer Authentication Domain kann zwischen den beteiligten Providern das Single Sign-On- Verfahren genutzt werden. Federation Termination: Der Benutzer kann bestehende Föderationen seiner Accounts selbstständig beenden. Principal: Ein aktives Subjekt (z.b. ein Benutzer oder eine System-Komponente) mit einer eindeutigen Identität. Identity Provider: Ein Identity Provider speichert die Identitäten von Principals und führt deren Authentifizierung durch. Service Provider: Ein Service Provider stellt Principals Dienste zur Verfügung. Name Identifier: Ein beliebiges Pseudonym für einen Nutzer. Dieses Pseudonym erlaubt es den Providern, einen Benutzer ohne Kenntnis der tatsächlichen Identität zu identifizieren. Single Logout: Beendet ein Principal eine seiner aktiven Sitzungen bei einem Identity oder Service Provider durch Ausloggen, so werden automatisch alle seine bestehenden Sitzungen innerhalb der betroffenen Authentifizierungsdomäne beendet. Das Dokument Introduction to the Liberty Alliance Identity Architecture [LibArch] gibt einen guten Überblick über das Wirkungsfeld der Liberty Alliance. Die Liberty Spezifikationen bestehen aus vier Komponenten. Diese werden in den folgenden Abschnitten genauer vorgestellt ID-FF: Identity Federation Framework Liberty ID-FF ist das zentrale Modul der Liberty Spezifikationen. Dieses Modul erlaubt die Umsetzung von Single Sign-On durch eine Verlinkung von Identitäten zwischen IdP und SP. Dieses Framework ermöglicht die Interoperabilität verschiedenster Plattformen und definiert Föderationen sowohl für PCs als auch für mobile Endgeräte (Handy, PDAs etc.). Neben den Beschreibungen für die Implementierung einer SSO-Umgebung definiert das Modul ID-FF zudem den Austausch von Metadaten. Die Liberty ID-FF 1.2 Spezifikation [LibID] umfasst folgende Protokolle: Single Sign-On und Federation Protokoll Name Registration Protokoll Federation Termination Protokoll Single Logout Protokoll Name Identifier Mapping Protokoll Single Sign-On und Federation Protokoll Hier werden die Request/Response-Protokolle definiert, die benötigt werden, um einen Principal bei einem Service Provider zu authentifizieren. Im Gegensatz zu SAML 1.0/1.1 beruhen diese Protokolle auf Account Linking bzw. Account Federation. 41

53 Kapitel 2: Grundlagen des Federated Identity Managements Im Folgenden ein Überblick über die Konzepte, die durch die Anwendung des Single Sign- On- und Federation-Protokolls umgesetzt werden können: Account Linking/Federation Ein Principal hat die Möglichkeit, seine Identität (gespeichert bei einem Identity Provider) mit seiner Identität (gespeichert bei einem Service Provider) zu verbinden. Authentication Context Ein Service Provider kann die Authentifizierungsart (z.b. Username/Passwort) festlegen, die benutzt werden soll, wenn sich ein Principal einloggt. Account Handle Ein Identity Provider kann für einen Principal, während der Kommunikation mit einem Service Provider, ein temporäres Pseudonym anstatt seiner tatsächlichen Identität verwenden. Dynamic Proxying Erhält ein IdP eine Authentifizierungsanfrage eines SPs bzgl. eines Principals, obwohl dieser Nutzer bereits von einem anderen IdP authentifiziert wurde, so kann der erste IdP die Anfrage an den zweiten IdP weiterleiten. Identity Provider Introduction Existiert in einer Domäne mehr als ein IdP, so kann ein SP nach dem IdP suchen, der für den Principal verantwortlich ist. Message Exchange Profiles Der Authentication-Request legt fest, wie Nachrichten zwischen IdP und SP ausgetauscht werden sollen. Dabei werden vier unterschiedliche Profile unterstützt [LibBind]: o Liberty Browser Artifact Profile (basiert auf SAML 1.1 Artefakten bzw. Assertions) o Liberty Browser POST Profile (Erweiterung des gleichnamigen SAML 1.1 Profils) o Liberty WML POST Profile (optimiert für WAP-Browser) o Liberty Enabled Client and Proxy Profile (Unterstützung von Proxy-Gateways) Name Registration Protokoll Dieses Protokoll ermöglicht es einem SP, in Verbindung mit einem IdP einen Namen für einen gemeinsamen Nutzer zu registrieren. Dabei ist es nicht erforderlich, dass der SP dem IdP detaillierte Informationen über die vorhandene lokale Identität des Benutzers mitteilt. Beim Aufbau einer Föderation generiert der IdP einen sog. Opaque Handle (Pseudonym) für den Principal. Auf der Basis dieses Name Identifiers erfolgt die Kommunikation mit dem SP (Element <IDPProvidedNameIdentifier>). Der SP kann für den gleichen Principal einen anderen Opaque Handle definieren (Element <SPProvidedNameIdentifier>). Federation Termination Protokoll Das Federation Termination Protokoll benachrichtigt sowohl die Service- als auch die Identity-Provider über das Ende einer Föderation. Dies hat zur Konsequenz, dass ein SP den Authentication-Assertions eines IdPs in Zukunft nicht mehr vertraut. Das Protokoll verwendet für diesen Zweck das Element <FederationTerminationNotification>. 42

54 Kapitel 2: Grundlagen des Federated Identity Managements Single Logout Protokoll Dieses Protokoll benachrichtigt sowohl die beteiligten SP als auch den zuständigen IdP, dass die aktuelle Session für einen Principal beendet werden soll. Für diese Operation wird eine <LogoutRequest> Nachricht verwendet. Name Identifier Mapping Protokoll Hier wird definiert, wie ein SP einen Name Identifier eines Principals erhalten und verstehen kann, wenn diese ID im Namensraum eines anderen SPs erstellt wurde. Dazu muss der betroffene SP eine Anfrage an den IdP stellen, der mit beiden Service Providern ein Account Linking bzgl. dieses Principals besitzt. Auf diese Weise können beide SP miteinander kommunizieren, ohne dass für den Benutzer eine Identity Federation zwischen diesen zwei Parteien besteht. Der Ablauf eines Liberty SSO-Prozesses soll anhand der folgenden Grafik deutlich gemacht werden: User/Browser Service Provider Identity Provider 1. HTTP Request() 3. HTTP Response mit AuthnRequest() 2. Suche passenden IdP 4. HTTP Request mit AuthnRequest() 6. HTTP Response mit AuthnResponse oder Artifact() 7. HTTP Request mit AuthnResponse oder Artifact() 5. Verarbeite AuthnRequest 8. HTTP Request mit Artifact() 9. HTTP Response mit Assertion() 10. Verarbeite Assertion 11. HTTP Response() Abbildung 13: Liberty Alliance SSO-Prozess Die Schritte 8 und 9 sind nur dann notwendig, wenn das Liberty Browser/Artifact-Profil verwendet wird. Diese beiden Schritte basieren vollständig auf dem SAML Browser/Artifact- Profil (SAML-Request/Response). Wie anfangs erwähnt, sind die Liberty ID-FF Protokolle im Wesentlichen eine Erweiterung der SAML-Spezifikation. Dabei ergänzt der Liberty <lib:authnrequest> den 43

55 Kapitel 2: Grundlagen des Federated Identity Managements samlp:requestabstracttype; die <lib:authnresponse> ist abgeleitet vom samlp:responsetype. Die von einem Identity Provider ausgestellten Assertions (<lib:assertiontype>) basieren auf dem saml:assertiontype. Abb. 14 zeigt eine Übersicht aller Liberty Erweiterungen bzgl. der grundlegenden SAML- Datenstruktur. Die genauen Schemata der einzelnen Liberty Elemente (wie z.b. <lib:authnrequest>) können unter [LibID] eingesehen werden. samlp:requestabstracttype samlp:responsetype lib:authnrequest lib: ProviderID ForceAuth (boolean) IsPassive (boolean) Federate (boolean) lib: ProtocolProfil lib: AuthnContext lib: RelayState lib: AuthnContextComparison saml: AssertionType lib:assertiontype attribute: InResponseTo attribute: ID lib:authnresponse lib: ProviderID lib: RelayState attribute: ID saml:authenticationstatementtype lib:authenticationstatementtype lib: AuthnContext attribute: ReAuthenticateOnOrAfter attribute: SessionIndex Abbildung 14: Erweiterungen des Liberty ID-FF Protokolls Ein Beispiel für einen <lib:authnrequest> bzw. eine <lib:authnresponse> befindet sich im Anhang A.2 dieser Diplomarbeit Erweiterung von Industriestandards Diese Komponente ist kein eigentliches Liberty Modul. Vielmehr ist es die Sammlung der für das Liberty Projekt relevanten Industriestandards, d.h., ID-FF, ID-WSF und ID-SIS basieren auf diesen Industriestandards. Es handelt sich dabei um verschiedene offene Standards. Diese werden nach Bedarf erweitert und mit den entsprechenden Standardisierungsorganisationen verabschiedet. Dazu gehören folgende drei Organisationen: 1. Organization for the Advancement of the Structured Information Standards (OASIS) [OASIS] 2. World Wide Web Consortium (W3C) [W3C] 3. Internet Engineering Task Force (IETF) [IETF] 44

56 Kapitel 2: Grundlagen des Federated Identity Managements Die Spezifikationen der Liberty Alliance greifen u.a. auf folgende Standards zurück: SOAP, WSDL, SAML, WS-Security, HTTP, SSL/TLS, XML Encryption und XML Signature ID-WSF: Identity Web-Services Framework ID-WSF [LibWSF] basiert auf dem ID-FF und ist die Grundlage, um personalisierte Dienstleistungen anbieten zu können. ID-WSF behandelt folgende Punkte [LibWSFOv]: Austausch von individuellen Attributen (Permission Based Attribute Sharing) Zusammentragen von Identitätselementen in einer verteilten Umgebung (Identity Service Discovery) Interaktions-Dienste (Interaction Service) Zusätzliche Sicherheitsprofile, die beim Datenaustausch zu berücksichtigen sind (Security Profiles) SOAP Anbindung (Simple Object Access Protocol Binding) Erweiterter Support für Endgeräte (Extended Client Support) Spezifikation über Persönlichkeitsprofile (Identity Services Templates) Anfang 2005 wurde ein Entwurf für Version 2 des ID-WSF vorgelegt. Wichtigste Neuerung ist die Unterstützung des Standards SAML ID-SIS: Identity Services Interfaces Specifications Die vierte Komponente (ID-SIS) [LibSIS] ist für zukünftige Applikationen ausgelegt. ID-SIS basiert auf dem ID-WSF und beinhaltet Spezifikationen für Funktionen wie Benutzer- Anmeldung, Adressbuch, Kalender, Location-based Services und die verschiedensten Alarmmeldungen (engl. Alerts) Web-Services Security Im April 2002 veröffentlichten IBM, Microsoft und VeriSign zusammen die Spezifikation Web-Services Security (WS-Security). Diese liefert einen Mechanismus, um einen sicheren Austausch von SOAP-Nachrichten möglich zu machen. Im Sommer 2002 wurde die Spezifikation dem Konsortium OASIS übergeben. Um die Entwicklung des Standards weiter voranzutreiben, wurde das OASIS Web-Services Technical Commitee gegründet. Im März 2004 erreichte WS-Security schließlich den Status eines offiziellen OASIS Standards [SOAPSec]. Ein großes Problem von Web-Services war lange Zeit die mangelnde Sicherheit. Die Sicherheitskomponenten von HTTP ermöglichen nur sichere Punkt-zu-Punkt Verbindungen. Vor allem bei komplexen und sicherheitskritischen Anwendungen ist eine sichere Ende-zu- Ende Verbindung jedoch unerlässlich. Hier kommt WS-Security ins Spiel. WS-Security setzt auf bereits bestehenden Standards und Spezifikationen auf. Deshalb muss in WS-Security keine vollständige Sicherheitslösung definiert werden. WS-Security ergänzt 45

57 Kapitel 2: Grundlagen des Federated Identity Managements bestehende Spezifikationen, wie z.b. XML Signature oder XML Encryption, um ein Rahmenwerk zum Einbetten dieser Mechanismen in eine SOAP-Nachricht. Die Integration dieser Mechanismen ist dabei unabhängig vom verwendeten Transportprotokoll. WS-Security definiert dabei ein SOAP Header-Element, in dem sicherheitsbezogene Daten enthalten sind. Wenn XML Signature verwendet wird, kann dieser Header die von XML Signature definierten Informationen enthalten. Diese geben an, wie die Nachricht signiert und welcher Schlüssel verwendet wurde und sie enthalten den resultierenden Signaturwert. Wenn ein Element in der Nachricht verschlüsselt ist, können die Verschlüsselungsinformationen, wie sie beispielsweise von XML Encryption bereitgestellt werden, auch im WS-Security- Header enthalten sein. WS-Security legt nicht das Format der Signatur oder Verschlüsselung fest. Stattdessen gibt WS-Security an, wie die von anderen Spezifikationen festgelegten Sicherheitsinformationen in eine SOAP-Nachricht eingebettet werden können. WS-Security spezifiziert in erster Linie einen XML-basierten Container für Sicherheitsmetadaten. [WSSGrund] Neben der Einbindung von XML Signature und XML Encryption bietet WS-Security die Möglichkeit, sog. Security-Tokens in den SOAP-Header zu integrieren. In WS-Security wurden im Wesentlichen zwei Tokenformate vordefiniert. Das ist zum einen das UsernameToken Element (enthält Nutzername und Passwort) und zum anderen das BinarySecurityToken Element (enthält ein X.509 Zertifikat oder ein Kerberos Ticket). Die Spezifikation erlaubt jedoch auch die Integration anderer Tokenformate, wie z.b. eine SAML- Assertion. Hierfür wurde das WS-Security Profile for XML-based Tokens [SOAPSec] spezifiziert. Durch den Einsatz dieses Profils können SAML-Assertions über SOAP ausgetauscht und durch die Anwendung der Verschlüsselung und der digitalen Signatur abgesichert werden. Neben der Basistechnologie WS-Security veröffentlichte IBM und Microsoft im Jahr 2002 ein Whitepaper mit dem Namen Security in a Web-Services World: A Proposed Architecture and Roadmap [WS-Road]. Dieses Dokument weist den Weg in Richtung eines umfassenden Web-Service Security Frameworks. Neben WS-Security wurden weitere Standards definiert, die auf dem grundlegenden Fundament WS-Security aufbauen sollen. Darunter sind WS- Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation und WS- Authorization. Außer WS-Security hat bisher jedoch keine dieser Spezifikationen den Status eines offiziellen Standards erreicht WS-Federation WS-Federation steht in direkter Konkurrenz mit den Protokollen der Liberty Alliance. In Tabelle 1 werden die Gemeinsamkeiten und die Unterschiede dieser beiden Protokolle veranschaulicht. 46

58 Kapitel 2: Grundlagen des Federated Identity Managements Das WS-Federation Modell beschreibt, wie die Blöcke der WS-Security- bzw. WS-Trust- Spezifikation genutzt werden können um eine föderierte Identitätsumgebung aufzubauen. Dies beinhaltet den Aufbau von domänenübergreifenden Vertrauensbeziehungen, Single Sign-On, Single Logout und Attribut-Management. Im Gegensatz zu dem Framework der Liberty Alliance wurde die Spezifikationen von WS- Federation jedoch noch nicht an eine Standardisierungsorganisation weitergeleitet, d.h., WS- Federation ist momentan (Stand: Juni 2005) noch kein offizieller Standard [FedFuture]. WS-Federation besteht aus drei Spezifikationen: WS-Federation [WS-Fed], WS-Federation Passive Client [WS-FedPass] und WS-Federation Active Client [WS-FedAct]. Ähnlich den Protokollen der Liberty Alliance bietet WS-Federation die Möglichkeit, auf Basis von Web- Services, eine Föderation von Identitäten zu implementieren. Dazu definiert WS-Federation einen Mechanismus für die Anfrage, den Austausch und das Ausstellen von Security Tokens. Gemeinsamkeiten /Überlappungen Funktionalität Liberty Alliance WS-Federation Verknüpfung von Nutzerkonten (Account Linking) Verknüpfung von Nutzerkonten auf Basis von Opaque Identifiers Verknüpfung von Nutzerkonten unter Verwendung des Pseudonym Services Vertraulichkeit/Anonymität Security Tokens Richtlinien bzgl. Geschäftsvereinbarungen und Sicherheitsregeln (Policies) Sicherheitsfragen/Datenschutz Client Profile SSO Kontrollfluss (SSO Control Flow) Empfehlungen bzgl. der Bereiche Schutz bzw. Anonymität von persönlichen Daten wurden in die Spezifikation aufgenommen. Erweiterung von SAML- Assertions, um Authentifizierungs- bzw. Authorisierungstoken zwischen Providern austauschen zu können. Beschäftigt sich mit Fragen des Aufbaus einer Vertrauens-beziehung (siehe Business Guidelines und Authentication Context). Erweiterung von SAML. Sicherheitsfragen können mittels der Technologien SSL und WS-Security gelöst werden. Definition von Profilen sowohl für Browser als auch für Smart Clients. SSO-Ablauf sowohl auf Basis der Front- als auch der Back- Channel Technologie. Optionale Unterstützung durch Einsatz von WS- Policy und WS-Privacy. Baut auf verschiedenen WS-Security Profilen auf (z.b. X.509v3). Zusätzlich können auch SAML Tokens verwendet werden. Diese Fragen werden momentan nicht abgedeckt. Basiert auf WS-Trust, WS-Policy und WS- Metadata. Sicherheitsfragen können mittels der Technologien SSL und WS-Security gelöst d Definition von Profilen sowohl für Browser als auch für Smart Clients. SSO-Ablauf vor allem für den Front-Channel Mechanismus. Der Back-Channel Mechanismus wird erwähnt, jedoch nicht empfohlen. 47

59 Kapitel 2: Grundlagen des Federated Identity Managements Unterschiede Entwicklung Entwickelt als offener Standard unter Teilnahme von Unternehmen, End- Nutzern und Non-Profit- Organisationen. Entwickelt von Microsoft, IBM, VeriSign, BEA und RSA Security. Fokus Fokus auf Technologie-, Geschäfts- und Policyfragen im Bereich Federated Identity Management. Fokus alleine auf der technologischen Komponente des Federated Identity Managements. Reifheitsgrad Ausgereifte Spezifikationen, die über die letzten zwei Jahre von Unternehmen und Organisationen entwickelt wurden. Die Spezifi-kationen werden aktuell in zahlreichen Produkten unterstützt. Noch kein offizieller Standard. Die Spezifikationen werden aktuell nur in wenigen Produkten unterstützt. Implementierungskosten Spezifikationen können kostenlos in Produkte und Dienste implementiert werden. Implementierungs- und Nutzungskosten unbekannt. Tabelle 1: Vergleich Liberty Alliance WS-Federation WS-Federation Active beschreibt den Aufbau einer Föderation in einer Umgebung mit aktiven Clients. Als aktive Clients bezeichnet man Clients, welche in der Lage sind, Web- Service Anfragen zu stellen bzw. entsprechende Web-Service Antworten zu verarbeiten. Ein Beispiel für einen aktiven Client ist eine SOAP-Applikation. WS-Federation Passive hingegen beschäftigt sich mit dem Aufbau von Föderationen bei einer Teilnahme von passiven Clients. Ein typisches Beispiel für solch einen Client ist ein HTTP Browser. Dies bedeutet, dass der Austausch von Nachrichten auf den Funktionalitäten von HTTP 1.1 (GET, POST, Redirects und Cookies) basieren muss. Da an einer Föderation meist sowohl passive als auch aktive Clients beteiligt sind, müssen beide Spezifikationen (WS-Federation Passive Client, WS-Federation Active Client) in föderierten Umgebungen implementiert werden. WS-Federation unterstützt vier unterschiedliche Security Tokens: X.509v3 Token Kerberos Token XrML Token SAML Token Diese Tokenformate können verwendet werden, um Identitätsinformationen zwischen Providern auszutauschen. Obwohl SAML Token von WS-Federation unterstützt werden, ist jedoch keine vollständige Interoperablität mit dem SAML 2.0 Standard gegeben. Dies zeigt, dass der Konkurrenzkampf der Föderationstandards untereinander noch nicht beendet ist [FedTrend]. 48

60 Kapitel 2: Grundlagen des Federated Identity Managements 2.5 Vergleich der Föderationsstandards In diesem Kapitel sollen die unterschiedlichen Charakteristika der verschiedenen Föderationsstandards (SAML 1.0/1.1, Liberty ID-FF 1.0/1.1, WS-Federation) veranschaulicht werden. Die folgende Tabelle zeigt die Unterschiede und Gemeinsamkeiten der Standards. Das Hauptaugenmerk liegt dabei auf den Protokollen, die für den SSO-Prozess zuständig sind Funktionalitäten SAML 1.0/1.1 Liberty ID-FF 1.0/1.1 WS- Federation SSO, initiiert vom IdP (push SSO) Ja Nein Ja SSO, initiiert vom SP (pull SSO) Ja Ja Ja Front-Channel Security Token Austausch Ja Ja Ja Back-Channel Security Token Austausch Ja Ja Nein Wahl des Security Tokens Nein Nein Ja SSO-Prozess/Account Linking benötigt Konten sowohl auf IdP- als auch auf SP- Seite Ja Ja Nein Account Linking auf Initiative des IdPs Nein Nein Ja Account Linking auf Initiative des SPs Nein Ja Ja Erstellung eines Nutzerkontos beim SP auf Initiative des IdPs (außerhalb des SSO- Prozesses) Nein Nein Nein Tabelle 2: Vergleich der SSO-Protokolle In der obigen Tabelle werden die Begriffe Front-Channel und Back-Channel verwendet. Ein Front-Channel bezeichnet die Verbindung, die zwischen einem Webbrowser eines Endnutzers und einem IdP bzw. SP aufgebaut wird. Über diesen Kanal können per HTTP-Redirect Parameter, wie z.b. ein SAML-Artefakt gesendet werden. Der Back-Channel bezeichnet hingegen denjenigen Kanal, der zwischen einem IdP und einem SP aufgebaut wird, um SOAP-Nachrichten auszutauschen. 2.6 Zusammenfassung Heutige Unternehmen und Organisationen werden zunehmend vor die Herausforderung gestellt, neben ihren eigenen Mitarbeitern und Kunden auch den Mitarbeitern und Kunden ihrer Partnerunternehmen den Zugriff auf bestimmte Ressourcen und Dienste zu ermöglichen. Herkömmliche Identity Management Systeme sind aus Effizienz- und Sicherheitsgründen für diese neue Entwicklung ungeeignet. Einen Lösungsansatz, um diese Probleme zu beheben, bieten die Konzepte und Technologien aus dem Bereich Federated Identity Management. 49

61 Kapitel 2: Grundlagen des Federated Identity Managements Dieser Ansatz erlaubt es Unternehmen, innerhalb eines sog. Circle of Trust, digitale Nutzeridentitäten mit anderen Unternehmen auf einfache, sichere und schnelle Weise auszutauschen. Dabei sollen Partnerunternehmen, welche als Service Provider fungieren, mittels dedizierter Protokolle Zugriff auf die unter anderem zur Authentifizierung und Autorisierung notwendigen Benutzerdaten erhalten. Die Daten werden dabei von so genannten Identitätsprovidern gespeichert und gepflegt. Mehrere Standards bzw. Frameworks wurden definiert, um ein Federated Identity Management zu ermöglichen. Dazu gehören der SAML Standard, die Liberty Alliance Protokolle und WS-Federation. Der momentan bedeutendste davon ist SAML. SAML wurde als ein Standard für den Austausch von Authentifizierungs-, Attributs- und Authorisierungsinformationen in Rechnernetzen entworfen. Ziel ist im Wesentlichen der Aufbau einer domänenübergreifenden Single Sign-On-Umgebung. Dazu werden XML-basierte Assertions definiert, die zwischen den beteiligten Parteien bei Bedarf ausgetauscht werden können. Diese sog. SAML- Assertions werden von vertrauenswürdigen Autoritäten ausgestellt. SAML legt jedoch keinen Authentifizierungsmechanismus fest, sondern unterstützt viele verschiedene Authentifizierungstypen. Durch den standardisierten Austausch von Sicherheitsinformationen bietet SAML die Möglichkeit, dezentralisierte Infrastrukturen zur Authentifizierung und Autorisierung aufzubauen. Das Liberty Alliance Project ist ein Zusammenschluss verschiedener Firmen zur Entwicklung eines umfassenden föderierten Identitätsmanagement-Frameworks. Der Ansatz sieht im Gegensatz zu Microsoft.NET Passport eine verteilte, föderierte Benutzerprofilverwaltung vor. Die offenen Standards der Liberty Alliance bauen sowohl auf Teilen von SAML als auch auf Teilen von WS-Security auf. Die Liberty Spezifikationen können als eine Erweiterung von SAML angesehen werden, da zum einen die Use-Cases für ein Federated Identity Management wesentlich exakter definiert wurden als dies in SAML der Fall ist und zum anderen, da SAML um neue Anwendungsfälle wie z.b. Single Logout erweitert wurde. Ein großes Problem war jedoch lange Zeit die fehlende Konvergenz zu den SAML Standards. Der Wunsch der Industrie nach einem einheitlichen Standard resultierte in der Verabschiedung des SAML 2.0 Standards im März Dieser aktuelle Standard vereinigt die Vorteile der Security Assertion Markup Language mit den Vorteilen des Liberty Identity Federation Frameworks. Die WS-Spezifikationen beschreiben, im Gegensatz zu SAML oder zum Liberty Projekt, eine komplette Web-Service Infrastruktur. Der erste offizielle Standard dieser Spezifikationen ist WS-Security. Er liefert einen konsistenten Ansatz für die Gewährleistung von Sicherheit und Integrität bei der Übertragung von SOAP Nachrichten. Um dies zu erreichen, nutzt WS- Security bestehende Standards wie XML Encryption, XML Signature und SAML. Obwohl sich der SAML Standard bzw. die Standards der Liberty Alliance mit den WS- 50

62 Kapitel 2: Grundlagen des Federated Identity Managements Spezifikationen im Bereich Federated Identity (vgl. WS-Federation) teilweise überlappen, ergänzen sie sich doch in den meisten Bereichen. Sowohl SAML als auch die Standards der Liberty Alliance bieten beispielsweise die Möglichkeit, WS-Security bei der Übertragung von Nachrichten einzusetzen. Trotzdem ist der Konkurrenzkampf zwischen den Föderationsstandards noch nicht beendet. WS-Security und WS-Federation sind beispielsweise nach wie vor nicht vollständig interoperabel bzgl. des SAML-Standards. 51

63 Kapitel 3: Einrichtung der Testumgebungen 3. Einrichtung der Testumgebungen In diesem Kapitel werden die Softwareprodukte vorgestellt, welche in dieser Diplomarbeit eingesetzt wurden, um - basierend auf der Security Assertions Markup Language SAML - eine heterogene Federated Identity Umgebung zu realisieren. Neben allgemeinen Komponenten, wie z.b. verwendete Webserver oder Datenbanken, werden hier vor allem die zu testenden Identity- und Access-Management-Produkte (Netegrity Siteminder, RSA Cleartrust, IBM Tivoli Access Manager) detailliert vorgestellt. Abschließend wird die komplette System-Architektur erläutert, die aus diesen Softwarelösungen aufgebaut wurde. Mit Hilfe dieser Systemarchitektur sollen die SAML- Anwendungsfälle (vgl. Kapitel 4) umgesetzt werden. 3.1 Netegrity Siteminder Funktionalitäten Das Identity- und Access-Management-Produkt Netegrity Siteminder wurde ursprünglich von dem Softwarehersteller Netegrity entwickelt. Diese Firma wurde jedoch Ende 2004 von Computer Associates (CA) [CA] übernommen. Der Netegrity Siteminder ist eines der drei Produkte, welches im Rahmen dieser Diplomarbeit verwendet wurde, um eine heterogene föderierte Identitätsumgebung aufzubauen. Innerhalb dieser Umgebung soll die Interoperabilität mit den Produkten anderer Hersteller evaluiert werden. Voraussetzung hierfür ist eine Implementierung des SAML 1.0 bzw. 1.1 Standards durch die Produkte. Der Netegrity Siteminder 6.0 SP1 unterstützt Teile beider SAML Versionen. Wie die Testergebnisse in Kapitel 5 zeigen werden, unterstützt jedoch weder der Netegrity Siteminder noch eines der anderen Produkte die OASIS SAML 1.0/1.1 Spezifikation in vollem Umfang. CA bietet mit dem Netegrity Siteminder eine Vielzahl von Lösungen, um Web-Seiten, Webapplikationen und Web-Services in einem Netzwerk sicher anbieten zu können. So ermöglicht das Siteminder-Produkt die Nutzung von Authentifizierungsschemata und das Definieren und Verwalten von Autorisierungsregeln zum Schutz spezifischer Ressourcen. Im Folgenden ein kurzer Überblick über die Funktionalitäten des Netegrity Siteminders [NeteWhite]: Authentifizierungsmanagement Siteminder unterstützt eine große Zahl unterschiedlicher Authentifizierungsmethoden, wie z.b. Passwort, Token, X.509 Zertifikate, biometrische Daten oder eine Kombination unterschiedlicher Methoden. Die notwendigen Authentifizierungsdaten (z.b. Nutzername und Passwort) werden dabei in separaten Datenbanken bzw. LDAP-Verzeichnissen gehalten. Siteminder ermöglicht die 52

64 Kapitel 3: Einrichtung der Testumgebungen Integration und Anbindung von relationalen Datenbanken und LDAP-Verzeichnissen nahezu aller namhaften Hersteller. Autorisierungsmanagement Siteminder bietet eine zentrale Verwaltung von Benutzerdaten und deren Rechte bzgl. bestimmter Ressourcen. Mittels so genannter Policies oder Sicherheitsregeln wird der Zugriff auf bestimmte Ressourcen gesteuert. Rollenbasierte Zugriffskontrolle (RBAC) Siteminder bietet die Möglichkeit, Policies so zu definieren, dass neben einer herkömmlichen Autorisierung auch eine rollenbasierte Autorisierung unterstützt werden kann. Siteminder etelligent Rules Administratoren können mit etelligent Rules komplexe Sicherheitsrichtlinien definieren und bei der Autorisierung von Benutzern etelligent Rules Formationen aus unterschiedlichen Datenquellen wie etwa Web-Seiten, Verzeichnissen oder Datenbanken dynamisch mit einbeziehen. Dies bietet Unternehmen die Möglichkeit, bei Autorisierungsentscheidungen in Echtzeit auf alle relevanten Daten zugreifen zu können. Auditing und Reporting Diese Funktionalität gestattet es, Benutzerbewegungen und administrative Aktivitäten zu verfolgen. Dadurch können Unternehmen z.b. nachträglich feststellen, ob es zu Anomalien beim Zugriff auf bestimmte Ressourcen gekommen ist. Federation Security Services Das zugrunde liegende Föderationsmodell ermöglicht sowohl die Verarbeitung als auch die Erstellung so genannter SAML-Assertions. Für Partnerunternehmen ohne SAML- Implementierung stellt Netegrity den so genannten SAML Affiliate Agent zur Verfügung Architektur Wie im vorigen Kapitel erwähnt, ermöglicht der Netegrity Siteminder seinen Administratoren, Sicherheitsregeln bzw. Policies zu definieren, um den Zugriff auf Ressourcen (z.b. Webseiten) kontrollieren zu können. Der Siteminder besteht aus zwei Hauptkomponenten, dem Siteminder Policy Server und den Siteminder Agents. Die Aufgaben des Policy Servers sind Policy Management, Authentifizierung, Autorisierung und Accounting [NeteWhite]. Die Siteminder Agents (z.b. Webagent) haben die Aufgabe, den Zugriff auf sicherheitsrelevante Ressourcen zu steuern. Nur autorisierte Nutzer sollen auf diese Ressourcen zugreifen dürfen. Dazu kommuniziert der Agent mit dem Policy Server. 53

65 Kapitel 3: Einrichtung der Testumgebungen Abbildung 15 gibt einen Überblick über die Architektur des Netegrity Siteminders. 2 Webserver mit Siteminder Agent 6 Geschützte Ressourcen Benutzer 4 User Datenbank Siteminder Policy Server Abbildung 15: Architektur Netegrity Siteminder User versucht, auf eine geschützte Ressource zuzugreifen. 2. Agent fängt die Anfrage ab und fordert den Nutzer auf, sich zu authentifizieren (z.b. mittels Username und Passwort). 3. Agent leitet die Authentifizierungsdaten des Benutzers an den Policy Server weiter. 4. Policy Server (PS) versucht, den Nutzer mittels einer passenden User-Datenbank bzw. eines passenden User-Verzeichnisses zu authentifizieren. 5. PS prüft, ob der Nutzer autorisiert ist, die gewünschte Ressource zu nutzen. Die Entscheidung wird an den Siteminder Agent übermittelt. 6. Agent stellt der Webapplikation - zwecks Personalisierung - Nutzerdaten zur Verfügung 7. Nutzer wird der Zugriff auf die Ressource gewährt bzw. verweigert Policy Server Der Policy Server (PS) ist die Hauptkomponente des Netegrity Siteminders. Alle sicherheitsrelevanten Entscheidungen werden hier getroffen. Typischerweise wird der PS auf einem separaten Windows- oder Unix-System installiert. Der Siteminder Policy Server ist eine sog. Single-Process Engine, auf der folgende verteilte Dienste laufen [NeteWhite]: Authentifizierung PS unterstützt eine Vielzahl unterschiedlicher Authentifizierungsarten wie z.b. Passwort, X.509 Zertifikate, Smartcards etc.. 54

66 Kapitel 3: Einrichtung der Testumgebungen Autorisierung Policies legen fest, welche Operationen auf den jeweiligen geschützten Ressourcen durchgeführt werden dürfen. Administration Konfiguration des PS durch eine grafische Benutzerschnittstelle. Auditing PS generiert Log-Dateien, um die Ereignisse aufzuzeichnen, welche innerhalb des Systems ablaufen. Die Sicherheitsregeln, welche im PS erstellt wurden, werden in einem sog. Policy Store gespeichert Agenten Ein Siteminder Agent schützt Ressourcen vor unerlaubtem Zugriff. Um einen Benutzer bzgl. einer Ressource authentifizieren bzw. autorisieren zu können, kommuniziert der Agent mit einem Policy Server. In der Siteminder Architektur fungiert der Agent als Policy Enforcement Point (PEP) und der PS als Policy Decision Point (PDP). Das Netegrity Siteminder Paket bietet unterschiedliche Typen von Agenten [NeteWhite]: Webagenten Dieser Typ eines Agenten wird in einen Webserver, wie z.b. Apache oder Microsoft IIS, integriert, um den Zugang zu den Webinhalten dieses Webservers zu kontrollieren. Zudem können Webagenten (WA) ihren geschützten Webapplikationen Nutzerdaten übermitteln, damit diese personalisierte Inhalte anbieten können. Der Siteminder Webagent wird durch die Erweiterungs-API in den jeweiligen Webserver integriert. Er fängt alle Anfragen auf Ressourcen ab und stellt fest, ob diese durch einen vorhandenen Siteminder Policy Server geschützt sind. Wenn ja, interagiert der Webagent mit dem verantwortlichen Policy Server zwecks einer Authentifizierung des Benutzers. Ist die Ressource nicht geschützt, wird die Anfrage sofort zur Auswertung an den Webserver weitergeleitet. Um eine gute Performanz zu erreichen, werden Teile des Nutzerkontextes vom Webagenten zwischengespeichert. Das Ausmaß des Cachings kann jedoch vom Systemadministrator über die manuelle Festlegung von Caching-Parametern geändert werden. Agenten für Applikationsserver Dieser Agent-Typ wird in einen existierenden Applikationsserver, wie z.b. IBM Websphere oder BEA Weblogic, integriert. Er gewährleistet einen feingranularen Schutz für Objekte, wie z.b. Servlets, JSP-Seiten oder EJB-Komponenten. SAML Affiliate Agenten Der SAML Affiliate Agent - in Verbindung mit einem Netegrity Siteminder Produkt - soll es Unternehmen ermöglichen, auf einfache Weise eine Federated Identity Umgebung aufzubauen. Der SAML Affiliate Agent ist Teil der Federation Security Services des Netegrity Siteminders. 55

67 Kapitel 3: Einrichtung der Testumgebungen Der SAML Affiliate Agent ist eine standalone Komponente, welche auf der Seite des Service Providers (SP) installiert wird. Diese Seite wird oft auch als Consumer- bzw. Affiliate Site bezeichnet. Damit jedoch ein domänenübergreifendes Single Sign-On möglich wird, muss auf der Seite des Identity Providers (Portal-Site) eine vollständige Netegrity Siteminder Installation vorliegen. An dieser Stelle sind die Daten und Profile der Nutzer, welchen der Zugriff auf föderierte Dienste gestattet werden soll, gespeichert. Die Affiliate-Site verwaltet und speichert keine Nutzerinformationen. Aufgabe des SAML Affiliate Agents ist es, SAML-Nachrichten, welche von einer vertrauenswürdigen Portal-Site, d.h. von der dort installierten Netegrity SAML-Autorität geschickt wurden, zu konsumieren und zu validieren. Ist die erhaltene Nachricht gültig bzw. ist sichergestellt, dass diese von einem bekannten und vertrauenswürdigen IdP kommt, kann der SAML Affiliate Agent dem entsprechenden Nutzer Zugriff auf die gewünschte Ressource gewähren. Der SAML Affiliate Agent besteht aus zwei grundlegenden Komponenten [NeteAff]: Webserver Plugin für die Affiliate Services - Die Konfiguration dieses Plugins erfolgt durch die Datei AffiliateConfig.xml. Affiliate Server - Abhängig vom verwendeten Betriebssystem läuft der Affiliate Server als Unix-Dämon oder als NT-Service. Konfiguriert wird dieser Server mittels der Datei affiliateserverconf.properties. Der Affiliate Server kommuniziert im Auftrag des Webserver Plugins mit der Portal Seite. Die folgende Abbildung zeigt die Komponenten des SAML Affiliate Agents. Abbildung 16: Komponenten des SAML Affiliate Agents [NeteAff] 56

68 Kapitel 3: Einrichtung der Testumgebungen Federated Identity Management Nach einer Installation des Netegrity Webagent OptionPacks bzw. Policy Server OptionPacks ist das Siteminder Produkt in der Lage, SAML 1.0/1.1 Assertions sowohl zu generieren als auch zu konsumieren. Im Rahmen der Diplomarbeit wurde das Netegrity OptionPack 6.0 SP1 verwendet. Dieses unterstützt ausschließlich das SAML Browser/Artifact-Profil. In der neuen Version des OptionPacks (OptionPack 6.0 SP2) wird neben dem Browser/Artifact- auch das Browser/POST-Profil unterstützt. Die sog. Federated Security Services des Netegrity Siteminders setzen sich aus folgenden Komponenten zusammen [NeteFed]: SAML-Assertion Generator SAML Artifact Authentication Schema Federation Web-Services SAML-Assertion Generator Diese Komponente fungiert als SAML-Autorität des Netegrity Siteminders. Sie kann für Nutzer eine SAML-Assertion erstellen. Wird eine solche Assertion angefordert, so ruft der Siteminder Webagent den SAML-Assertion Generator auf. Dieser generiert anhand der Sitzungsdaten eines Benutzers eine passende SAML-Assertion und hält diese innerhalb des Siteminder Session Servers. Dem Webagenten wird eine Referenz auf diese Assertion in Form eines SAML-Artefakts übergeben. Dieser übermittelt das Artefakt anschließend an den gewünschten Service Provider. SAML Artifact Authentication Schema Dieses konfigurierbare Schema ermöglicht dem Siteminder Produkt, als Service Provider, d.h. als Konsument von SAML-Assertions aufzutreten. Eine zentrale Aufgabe dieses Schemas ist zum einen die Extrahierung von Nutzeridentitäten aus SAML-Assertions und zum anderen die Abbildung dieser Bezeichner auf lokale Nutzeridentitäten. Federation Web-Services Die Federation Web-Services Applikation wird auf dem gleichen Webserver wie der Siteminder Webagent installiert. Die Anwendung besteht im Wesentlichen aus zwei Diensten: Assertion Retrieval extrahiert das Artefakt aus einer eingehenden SAML-Request Nachricht und sucht mittels diesem eindeutigen Zeiger nach einer entsprechenden Assertion. Existiert eine solche, so wird diese in eine SAML-Response Nachricht verpackt und an den anfragenden Service Provider übertragen. 57

69 Kapitel 3: Einrichtung der Testumgebungen SAML Credential Collector verpackt ein übermitteltes SAML-Artefakt in eine SAML-Request Nachricht und schickt diese zurück zum IdP, um die dazu passende SAML-Assertion zu erhalten. Zwecks Validierung wird diese an das SAML Artifact Authentication Schema weitergeleitet. Anschließend werden im Browser des zugreifenden Nutzers Session-Cookies gesetzt. Alle Dienste innerhalb der Federation Web-Services sind als Servlet realisiert. Damit ein unerlaubter Zugriff auf diese Dienste ausgeschlossen ist, werden die Servlets von einem Siteminder Webagenten geschützt Installation Der Netegrity Siteminder 6.0 SP1 (Service Pack 1) wurde auf einem Pentium III Testserver (2048 MB RAM) unter dem Betriebssystem Windows 2000 Advanced Server SP3 installiert. Bevor die Komponenten des Siteminders wie Policy Server und Webagent installiert werden konnten, musste eine geeignete Systemumgebung aufgebaut werden. Hierzu wurden folgende Produkte bzw. Programme auf dem Testsystem installiert: Java Runtime Environment (JRE) Siteminder Option Pack 6.0 SP1 unterstützt momentan ausschließlich die JRE (höhere Versionen, wie z.b. JRE 1.5, werden noch nicht unterstützt). Microsoft Internet Information Services (IIS) 5.0 Webserver Grundlage für die Installation des Siteminder Webagents 6.0 SP1 und des Webagent Option Packs 6.0 SP1. New Atlanta ServletExec/ISAPI 4.2 ServletExec ermöglicht die Verarbeitung von Servlets und Java Server Pages durch den IIS Webserver. Sun ONE Directory Server 5.2 LDAP-Verzeichnis zur Speicherung und Verwaltung von Identitätsprofilen und Zugriffsrechten (Policies). Microsoft SQL Server 2000 Enterprise Edition SP3a Relationale Datenbank zur temporären Speicherung von SAML-Assertions (in der Siteminder Dokumentation wird diese Datenbank als Session Server Database bezeichnet). Nach dem Aufbau der erforderlichen Systemumgebung konnte der Netegrity Siteminder 6.0 SP1 installiert werden. Dieser Vorgang unterteilte sich in folgende Schritte [NeteFed]: 1. Installation und Konfiguration des Policy Servers 2. Installation und Konfiguration des Policy Server OptionPacks 3. Installation und Konfiguration des Webagents 4. Installation und Konfiguration des Webagent OptionPacks 5. Konfiguration der Federation Security Services 6. Konfiguration der Federation Web-Services Applikation 58

70 Kapitel 3: Einrichtung der Testumgebungen Zu Schritt 1: Während der Installation müssen im Wesentlichen folgende Angaben gemacht werden: Encryption Key in dieser Dialogbox muss ein alphanumerischer Wert für die Verschlüsselung der Daten zwischen Policy Server und Policy Store (hier: Sun One LDAP-Verzeichnis) angegeben werden. Der Schlüssel kann eine Länge von 6 bis 24 Zeichen haben. LDAP Policy Store soll ein LDAP Verzeichnis als Policy Store verwendet werden, so kann dieses automatisch während der Policy Server Installationsroutine konfiguriert werden. Nötige Angaben sind: IP-Adresse, Port und weitere Zugriffsdaten des LDAP- Servers. Auswahl des verwendeten Webservers (hier: Microsoft IIS 5.0) Zu Schritt 2: Bevor die Siteminder Federated Security Services verwendet werden können, muss das Netegrity OptionPack installiert werden. Der Installationsvorgang erfordert die folgenden Angaben: Import Affiliate Data diese Checkbox ist per Default aktiviert, damit die Federation Services Objekte während der Installation automatisch importiert werden. Bei einer Deaktivierung dieser Option müssen die Daten später manuell mittels des smobjimport Befehls importiert werden. SM Admin Username und SM Admin Password die hier angegebenen Daten müssen mit dem Benutzernamen und Passwort der Policy Server Benutzerschnittstelle übereinstimmen. Zu Schritt 3: Der Siteminder Webagent muss in den verwendeten Webserver (hier: Microsoft IIS 5.0) integriert werden. Die Installation läuft weitgehend automatisch ab. Zu Schritt 4: Die wichtigste Komponente, die mit dem WA OptionPack installiert wird, ist die Federation Web-Services Applikation. Um die Funktionsfähigkeit dieser Anwendung zu testen, kann in einem Webbrowser folgender Link eingegeben werden: http(s)://<fully qualified hostname>:<port>/affwebservices/router/session Ist der Dienst aktiv, so erscheint die Nachricht SOAP RPC ROUTER im Browserfenster. Zu Schritt 5: Die Hauptkomponente der Federation Security Services ist der Assertion Generator. Die individuelle Konfiguration dieser SAML Autorität erfolgt durch folgende Properties- Dateien [NeteFed]: 59

71 Kapitel 3: Einrichtung der Testumgebungen AMAssertionGenerator.properties enthält wichtige Parameter, die bei der Erstellung einer SAML-Assertion nötig sind. Der Administrator kann die Standardwerte dieser Parameter entsprechend der vorliegenden Netzwerkumgebung abändern. Die Parameter dieser Datei sind: - AssertionIssuerID (Identifier des IdPs) - SecurityDomain (Domäne des IdPs) - SourceID (ID, welche in jeden SAML-Artefakt integriert wird, damit der SP den Aussteller einer SAML-Assertion eindeutig identifizieren kann) JVMOptions.txt speichert Einstellungen, die der Policy Server benötigt, um eine Java Virtual Machine zu erstellen. LoggerConfig.properties an dieser Stelle können Logging-Parameter konfiguriert werden. Zu Schritt 6: Die Federation Web-Services sind Webapplikationen, die Dienste anbieten, um SAML- Nachrichten in einer Föderation austauschen zu können. Diese können über den URL /<fully qualified hostname>:<port>/affwebservices/ angesprochen werden. Der Assertion Retrieval Service, zuständig für die Beantwortung eingehender SAML-Requests-Nachrichten, kann durch den URL /<fully qualified hostname>:<port>/affwebservices/ assertionretrieval aufgerufen werden. Alle HTTP-Anfragen, die mit diesem URL-Präfix beginnen, werden zu diesem Servlet geleitet. Am Ende der Konfiguration des Siteminder Produkts sollten die Federation Web-Services durch Siteminder Policies geschützt werden, damit von außen nicht beliebig auf diese Dienste zugegriffen werden kann. 3.2 RSA Cleartrust 5.5 & RSA Federated Identity Manager Funktionalitäten Die Web Access Management Software RSA [RSA] Cleartrust 5.5 ist das zweite Produkt, welches im Rahmen dieser Diplomarbeit eingesetzt wurde, um eine föderierte und heterogene Identitätsumgebung aufzubauen. In Kombination mit dem externen FIM-Modul RSA Federated Identity Manager 2.5 implementiert dieses Produkt zu großen Teilen sowohl die SAML 1.0 als auch die SAML 1.1 Spezifikation. Dabei wird sowohl das Browser/Artifact- als auch das Browser/POST-Profil unterstützt. RSA Cleartrust 5.5 ist, wie auch der Netegrity Siteminder von Computer Associates, eine Softwarelösung, um Webseiten und Webapplikationen vor unautorisiertem Zugriff zu schützen. 60

72 Kapitel 3: Einrichtung der Testumgebungen Im Folgenden ein kurzer Überblick über die Funktionalitäten von RSA Cleartrust 5.5 und RSA FIM 2.5 [RSAGuide, RSAFIM]: Management von Nutzeridentitäten RSA Cleartrust ermöglicht die Verwaltung und Steuerung der Lebenszyklen von Benutzeridentitäten. Neben der Erschaffung von Identitäten wird auch eine flexible Terminierung derselben unterstützt. Web Zugriff-Management Cleartrust ermöglicht den Aufbau und die Verwaltung von Policies (Sicherheitsregeln), welche die Privilegien eines Nutzers prüfen können. Anhand dieser Privilegien kann entschieden werden, ob ein Nutzer für eine spezifische Online-Ressource autorisiert werden kann. Mit Hilfe solcher Sicherheitsregeln besteht die Möglichkeit, feingranulare Zugriffskriterien zu definieren. Diese können sowohl statisch (z.b. Abteilung eines Nutzers) als auch dynamisch (z.b. Kontostand eines Nutzers) sein. Authentifizierungsmanagement Um einen Benutzer zu authentifizieren, können unterschiedliche Authentifizierungsmethoden verwendet werden. RSA Cleartrust 5.5 unterstützt folgende Authentifizierungsmechanismen: Basic Ein Benutzer authentifiziert sich mittels seines Nutzernamens und seines Passworts. X.509 Zertifikate Der Webbrowser eines Nutzers kann konfiguriert werden, so dass dieser Browser-Zertifikate zur Authentifizierung akzeptiert. Windows NT Ein User kann auf Basis seines Windows NT Kontos authentifiziert werden. Custom Die RSA Cleartrust Webagent Erweiterung (WAX) kann genutzt werden, um neue Authentifizierungsroutinen zu schreiben und in das System zu integrieren. Diese zahlreichen Authentifizierungsmethoden sorgen dafür, dass ein sicherer Zugriff auf das Netzwerk auch außerhalb einer Firewall möglich ist. Verteilte Administration Administrative Aufgaben können auf verschiedene Geschäftseinheiten aufgeteilt werden. Diese können sich sowohl innerhalb als auch außerhalb einer Organisation befinden. Auditing und Reporting Dieses Feature ermöglicht eine einheitliche Aufzeichnung aller auftretenden Ereignisse in der Systemumgebung. Im Wesentlichen sind dies Aktionen von Nutzern, Administratoren und Systemprozessen. 61

73 Kapitel 3: Einrichtung der Testumgebungen Föderiertes Identitäts-Management Das RSA Federated Identity Management Modul 2.5 fungiert als SAML-Autorität. Es können sowohl SAML 1.0 als auch SAML 1.1 Assertions generiert bzw. konsumiert werden Architektur In diesem Kapitel werden alle Komponenten von RSA Cleartrust 5.5 vorgestellt. Die Abbildung 17 gibt einen Überblick über die Architektur der benötigten Cleartrust- Bestandteile. Benutzer RSA Cleartrust Server Key Server Dispatcher Webserver mit Cleartrust Agent Authorization Server User Datenbank Entitlements Server Policy Datenbank Abbildung 17: Architektur RSA Cleartrust RSA Cleartrust Server Für eine lauffähige Implementierung von RSA Cleartrust 5.5 wird mindestens jeweils eine Instanz der folgenden Server benötigt [RSAGuide]: Entitlements Server Der Entitlements Server ist die zentrale Komponente für die administrativen Funktionen des RSA Cleartrust Systems. Neu erstellte bzw. geänderte Policies werden von diesem Server in eine angebundene Policy Datenbank geschrieben. Eine Verbindung mit dem Authorization Server soll es diesem ermöglichen, auf Policy- und Ressourcen-Informationen zuzugreifen. 62

74 Kapitel 3: Einrichtung der Testumgebungen Die Steuerung des Entitlements Servers erfolgt über den sog. Entitlements Manager. Mittels dieser grafischen Servlet Applikation kann der Systemadministrator Änderungen bzgl. Nutzern, Ressourcen und Policies vornehmen. Authorization Server Der Zuständigkeitsbereich dieser Komponente ist die Authentifizierung bzw. Autorisierung von Nutzern zur Laufzeit. Versucht ein Benutzer, auf eine Ressource zuzugreifen, so leitet ein RSA Agent die Anfrage an einen Authorization Server weiter. Ist die Ressource geschützt, prüft der Server, o ob der Nutzer (mittels Authentifizierungsmethode und seiner Daten) authentifiziert werden kann und o ob der Nutzer berechtigt (autorisiert) ist, um auf die gewünschte Ressource zuzugreifen. Der Authorization Server liest die Benutzerinformationen direkt aus einer ihm zugeordneten Datenbank aus. Um die Performanz des Systems zu verbessern, werden die angeforderten Informationen solange wie möglich im Cache dieses Servers gehalten. Dispatcher/Key Server Der Dispatcher/Key Server hat zwei Funktionen. Zum einen kennt der Dispatcher alle verfügbaren Authorization Server. Agenten können dadurch mit dem Dispatcher kommunizieren, um eine Liste aller verfügbaren Authorization Server zu erhalten. Für die Übermittlung der Anfragen bzw. Antworten wird jeweils eine TCP/IP-Verbindung aufgebaut. Der Key Server ist ein eigenständiger Prozess, welcher in periodischen Abständen neue Single Sign-On Token Encryption Keys (Sicherheitsschlüssel) erstellt. Agenten können mit dem Key Server in Kontakt treten, um den neuesten Schlüssel zu erhalten. Authentifiziert sich ein Benutzer beim Cleartrust-System, so weist der zuständige RSA Agent dem Nutzer einen Token zu. Solange dieser Token gültig ist, kann er sich mit diesem gegenüber dem System identifizieren. Token sind verschlüsselte Datenstücke, die Session-Informationen enthalten. Für die Entschlüsselung dieser Session-Token benötigt der Agent einen Encryption Key. Diesen erhält er vom Key Server. Aus Sicherheitsgründen erstellt der Key Server in regelmäßigen Abständen neue Sicherheitsschlüssel Agenten für Web- und Applikationsserver Ein RSA Agent schützt Ressourcen vor unerlaubten Zugriff. Um einen Benutzer bzgl. einer Ressource authentifizieren bzw. autorisieren zu können, kommuniziert der Agent mit einem verfügbaren Authorization Server. RSA bietet - wie auch der Netegrity Siteminder - unterschiedliche Agententypen [RSAGuide]: 63

75 Kapitel 3: Einrichtung der Testumgebungen Webagent RSA Cleartrust Webagenten erweitern die Sicherheitsmechanismen eines Webservers. Ein RSA Webagent läuft innerhalb desselben Prozesses wie auch der Webserver selbst. Aufgerufen wird ein Agent immer dann, wenn der Webserver eine Zugriffsentscheidung bzgl. eines bestimmten URLs treffen muss. Der Webagent leitet die ihm übergeben Anfragen bei Bedarf an den Authorization Server weiter. Dieser entscheidet über den Zugriff. Agenten für Applikationsserver Vgl. Kapitel Federated Identity Management Im Gegensatz zum OptionPack des Netegrity Siteminders ist der RSA Federated Identity Manager 2.5 eine standalone Applikation, d.h., er ist nicht an ein bestimmtes Identity/Access- Management-Produkt gekoppelt. Dadurch kann das Modul theoretisch mit einer beliebigen Authentifizierungs- und Autorisierungseinheit verbunden werden. Wie Kapitel zeigt, wurde in dieser Diplomarbeit RSA FIM 2.5 in Kombination mit RSA Cleartrust 5.5 verwendet. Der RSA FIM 2.5 basiert auf Web-Services und setzt zum einen bestehende Standards wie XML oder SOAP ein und unterstützt zum anderen Spezifikationen wie SAML 1.0 bzw. SAML 1.1 Eine Unterstützung der Föderationstandards Liberty Alliance ID-FF 1.2 und WS- Federation wird es voraussichtlich in der nächsten Version des RSA Federated Identity Managers geben [RSAPress]. Für den Austausch von SAML-Assertions wurde sowohl das Pull-Modell Browser/Artifact als auch das Push Modell Browser/POST implementiert. Die SAML-Autorität des Federated Identity Managers 2.5 basiert auf den Open Source SAML-Bibliotheken von OpenSAML [OpenSAML]. Dies verspricht eine hohe Konformität zu den SAML-Spezifikationen der OASIS Gruppe. Der RSA Federated Identity Manager 2.5 besteht aus FIM-Servern und FIM Runtime Servlets [RSAFIM]: FIM-Server Das RSA FIM-Modul besteht aus zwei Arten von Servern. Dies ist zum einen der Admin- Server und zum anderen der Managed-Server. Der Admin-Server übernimmt anfallende Verwaltungsaufgaben (z.b. Kontrolle des Managed-Servers). Der Managed-Server ist das Herzstück, auf dem die SAML-Autorität des Federated Identity Managers läuft. Diese kann sowohl als Identity Provider bzw. Asserting Party (Ausstellung von SAML-Assertions) als auch als Service Provider bzw. Relying Party (Konsumierung von SAML-Assertions) fungieren. 64

76 Kapitel 3: Einrichtung der Testumgebungen FIM Runtime Servlets Diese Servlets werden verwendet, um auf die FIM-Server zugreifen und diese konfigurieren zu können. Um einen entfernten Zugriff möglich zu machen, können die FIM-Servlets auch auf einem anderen Host als die FIM-Server installiert werden. Nach einer erfolgreichen Installation der Servlets kann der Systemadministrator - über eine Browser-basierte GUI - den Federated Identity Manager verwalten und konfigurieren (z.b. Hinzufügen von Vertrauensbeziehungen, Definition von Asserting und/oder Relying Parties, Anpassung von SAML-Assertions, Einsatz digitaler Signaturen etc.) Installation Die Authentifizierungsautorität RSA Cleartrust 5.5 und die SAML-Autorität RSA Federated Identity Manager 2.5 wurden auf einem Pentium III Testserver (2048 MB RAM) unter dem Betriebssystem Windows 2000 Advanced Server SP3 installiert. Bevor die Produkte installiert werden konnten, musste folgende Systemumgebung aufgebaut werden: Java Runtime Environment (JRE) Runtime Web-Services von RSA Cleartrust unterstützen ausschließlich Applikationsserver, basierend auf JRE 1.4. Apache 2.0 HTTP Webserver Hosting der sicherheitsrelevanten Webressourcen und Grundlage für die Integration des RSA Cleartrust Apache Agents 2.5. Apache Jakarta Tomcat 4.1 Applikationsserver (integriert in den Apache 2.0 Webserver), ermöglicht die Verarbeitung und Anzeige von Servlets und JSP-Seiten. Der Entitlements Manager wurde auf diesem Server installiert. Microsoft SQL Server 2000 Enterprise Edition SP3a Relationale Datenbank zur persistenten Speicherung von Nutzer- und Policyinformationen. NetDirect JDBC-Treiber JSQLConnect 3.0 (Release 3.30) RSA Cleartrust 5.5 benötigt diesen JDBC-Treiber, um eine Verbindung zu dem Microsoft SQL Server aufbauen zu können. Die Installation der RSA Cleartrust Komponenten untergliedert sich in die folgenden Schritte [RSAInstall]: 1. Installation eines Entitlements Servers, Authorization Servers und Dispatcher/Key Servers. 2. Konfiguration eines sog. Data Adapters für den Zugriff von RSA Cleartrust auf eine vorhandene User/Policy-Datenbank (hier: Microsoft SQL Server 2000). 3. Starten der RSA Cleartrust Server, um die Kommunikationsfähigkeit dieser Server mit der/den zugrunde liegenden(en) Datenbank(en) zu testen. 4. Installation und Konfiguration der RSA Entitlements Manager Webapplikation. 5. Installation und Konfiguration eines Webagenten auf allen Webservern, die geschützt werden sollen. 6. Start und Test des Entitlements Managers 65

77 Kapitel 3: Einrichtung der Testumgebungen Zu Schritt 1: Die Installation der Cleartrust-Server unter Windows läuft weitgehend eigenständig ab. Während der Installation müssen im Wesentlichen folgende Angaben gemacht werden: Auswahl des zu verwendenden Data-Adapters der Data-Adapter muss abhängig von der eingesetzten Nutzer/Policy-Datenbank gewählt werden (hier: SQL Data-Adapter) Host und Port der verwendeten Datenbank. Damit der Cleartrust Authorization- bzw. Entitlements-Server eine Verbindung mit der vorhanden Datenbank aufbauen kann, muss deren Host (hier: itacpi09.testeurope1.bmwgroup.com) und Portnummer (hier: 8001) angegeben werden. Administratorname und Administratorpasswort Angabe von Administratordaten für den vollen Zugriff auf den RSA Entitlements Manager. Zu Schritt 2: Bei der Installation der Cleartrust-Server kann wahlweise ein SQL Data-Adapter oder ein LDAP Data-Adapter installiert werden. Dies ist abhängig von der verwendeten Datenbank bzw. dem verwendeten Verzeichnis. Da in dieser Diplomarbeit dem Cleartrust-System eine relationale Datenbank zugrunde liegt (Microsoft SQL Server 2000), wurde ausschließlich ein SQL Data-Adapter installiert. Dieser SQL Adapter basiert auf einem Schema von Datentabellen, welche die Speicherung der Nutzer- und Policy-Informationen in der Datenbank organisieren. Um dieses Schema auf die SQL-Datenbank zu übertragen, musste ein entsprechendes SQL-Skript auf der Datenbank-Plattform ausgeführt werden. Zu Schritt 3: Die RSA Cleartrust Server können entweder als Windows-Dienst oder als Anwendung (Batch-Datei) ausgeführt werden. Die Server müssen in dieser Reihenfolge gestartet werden: 1. Dispatcher/Key Server 2. Entitlements Server 3. Authorization Server Zu Schritt 4: Um den Entitlements Manager auf dem verwendeten Applikations-Server (hier: Apache Tomcat 4.1) zu installieren, muss eine WAR-Datei (Web-Archiv) auf dem Applikations- Server ausgeführt werden. Um dies zu erreichen, muss die Datei admingui.war in das Tomcat webapps-verzeichnis kopiert werden. Zu Schritt 5: Der RSA Apache Webagent 2.5 wurde mit Hilfe des zugehörigen Installationsprogramms in den Apache 2.0 HTTP-Webserver integriert. 66

78 Kapitel 3: Einrichtung der Testumgebungen Zu Schritt 6: Nach der Installation aller RSA Cleartrust Komponenten kann das Entitlements Manager Servlet im Browser, abhängig von Host und Portnummer des Applikations-Servers, aufgerufen werden (hier: Nachdem alle RSA Cleartrust Komponenten funktionsfähig und einsatzbereit sind, kann der RSA Federated Identity Manager 2.5 installiert werden. Obwohl es möglich ist, das FIM- Produkt auf einem anderen Server als dem der zugrunde liegenden Authentifizierungsautorität zu installieren, wurde in dieser Diplomarbeit die RSA SAML-Autorität auf demselben System wie RSA Cleartrust installiert. Neben den FIM-Servern (Admin- und Managed-Server) und Runtime Servlets wird automatisch ein BEA WebLogic Embedded LDAP-Directory installiert. Dieses LDAP- Verzeichnis wird zur Speicherung der Konfigurationsdaten verwendet. Nach der erfolgreichen Installation des RSA Federated Identity Managers 2.5 kann über den URL auf die FIM-Administrationskonsole zugegriffen werden. Abschließend muss, um eine Verbindung zwischen RSA Cleartrust und dem Federated Identity Manager herzustellen, in der FIM-Administrationskonsole die jeweilige IP-Adresse und Portnummer des Dispatcher- und Entitlements-Servers angegeben werden. 3.3 IBM Tivoli Access Manager 5.1 & Tivoli Federated Identity Manager 6.0 Als drittes Produkt wurde der IBM [IBM] Tivoli Access Manager (TAM) 5.1 und der Tivoli Federated Identity Manager (TFIM) 6.0 installiert Funktionalitäten Der Tivoli Access Manager stellt Dienste zur Authentifizierung, Autorisierung und zum Session-Management zur Verfügung. Die Komponenten Authorization- und Policy-Server bilden dabei den Policy Decision Point (PDP). Als Policy Enforcement Point (PEP) wurde im Rahmen dieser Diplomarbeit ein HTTP-basierter WebSeal Reverse Proxy verwendet. Das Modul TFIM 6.0 wird benötigt, um eine Federated Identity Lösung aufbauen zu können. Die Funktionalitäten des TAMs 5.1 sind im Wesentlichen die gleichen wie die des RSA Cleartrusts 5.5 und des Netegrity Siteminders 6.0. Auch der TAM 5.1 unterstützt ein umfassendes Authentifizierungs- und Autorisierungsmanagement, d.h., auch hier können komplexe Policies zum Schutz von Webressourcen definiert werden. Im Folgenden eine kurze Zusammenfassung der wichtigsten Funktionalitäten des TAMs 5.1 [TAMRed]: 67

79 Kapitel 3: Einrichtung der Testumgebungen Authorization-Engine Policy Parameter können geändert werden, ohne dass Applikationen neu geschrieben bzw. neu kompiliert werden müssen. Rollenbasierte Sicherheitsregeln Möglichkeit einer feingranularen und dynamischen Authentifizierung bzw. Autorisierung. Unterstützung zahlreicher Verzeichnisse Anbindung von Verzeichnissen unterschiedlicher Hersteller zur Speicherung von Nutzer- und Policydaten. Direkte Registrierung durch den Endnutzer Template unterstützt direkte Registrierungen von Endnutzern in einer Webumgebung. Umfangreiches Auditing und Reporting Zentralisierte Überwachung und Kontrolle des gesamten Systems. Die Eigenschaften und Funktionen des Tivoli Federated Identity Managers 6.0, der in Verbindung mit dem Tivoli Access Manager eingesetzt wurde, werden in Kapitel vorgestellt Architektur Die Leistungen des Tivoli Access Managers 5.1 werden im Wesentlichen von zwei Kernkomponenten und einer Reihe von Management-Komponenten erbracht. Kernkomponenten Der TAM besteht aus zwei Hauptbestandteilen [TAMRed]: Benutzerverzeichnis Ein Verzeichnis zur Speicherung von Nutzeridentitäten und Nutzergruppen. Autorisierungsdienst Dieser Dienst setzt sich zusammen aus einer Autorisierungsdatenbank und einer Autorisierungsengine. Die Autorisierungsdatenbank enthält virtuelle Darstellungen der Ressourcen, die geschützt werden sollen (engl. protected object space). Die gespeicherten Objektdefinitionen verweisen dabei auf logische oder physische Ressourcen. Die Aufgabe der Autorisierungsengine ist es, den Zugriff auf geschützte Objekte (Ressourcen) zu erlauben bzw. zu verweigern. Um eine solche Entscheidung treffen zu können, kommuniziert die Autorisierungsengine sowohl mit dem Benutzerverzeichnis als auch mit der Autorisierungsdatenbank. Management-Komponenten Eine Access Manager Umgebung benötigt - neben den oben genannten primären Bestandteilen - Komponenten, die Verwaltungs- und Managementaufgaben wahrnehmen. Die wichtigsten sollen hier kurz erwähnt werden [AMAdmin, TAMRed]: 68

80 Kapitel 3: Einrichtung der Testumgebungen Policy Server Dieser Server verwaltet Autorisierungsdatenbank(en) und Autorisierungsengine(s), um den verschiedenen Applikationen bzw. Ressourcen einen Autorisierungsdienst anbieten zu können. PDADMIN Tool Dieses Tool ermöglicht es dem Systemadministrator, per Konsole Verwaltungsaufgaben wahrzunehmen (z.b. Hinzufügen von Nutzern oder Policies). Web Portal Manager Diese JSP-Applikation erlaubt es dem Systemadministrator, die Architektur über einen Webbrowser zu verwalten. Webserver http(s) Request http(s) Response Webseal Reverse Proxy Benutzerverzeichnis Benutzer Cache Policies Web Portal Manager Policies Access Manager Policy Server Abbildung 18: Architektur IBM Tivoli Access Manager 5.1 Wie in der Abbildung 18 ersichtlich, wird zusätzlich zu den oben beschriebenen Komponenten ein Policy Enforcement Point benötigt, welcher Anfragen von Nutzern bzgl. sicherheitsrelevanter Ressourcen abfängt. Diese Funktion übernimmt ein sog. WebSeal Reverse Proxy [AMWebseal]. Wie auch die Webagenten der anderen Produkte, wird dieser in einen Webserver integriert, um dort die HTTP(S)-Ports zu kontrollieren. Jedoch im Gegensatz zu den Webagenten von RSA und Computer Associates leitet der Reverse Proxy die Anfrage nicht an einen Policy Server o.ä. weiter, sondern führt die Authentifizierung bzw. die Autorisierung mittels Benutzerverzeichnis und vorhandener Policies selbstständig durch. Um dies zu ermöglichen, werden die aktuellen Policies im Cache des WebSeal Reverse Proxies gehalten. Für die Aktualität dieser Sicherheitsregeln sorgt der Access Manager Policy Server. Dazu führt dieser - wenn nötig - Updates auf dem WebSeal Cache aus. Zur Authentifizierung eines Benutzers wendet sich der Reverse Proxy direkt an das zuständige Benutzerverzeichnis. 69

81 Kapitel 3: Einrichtung der Testumgebungen Federated Identity Management Der IBM Tivoli Federated Identity Manager (TFIM) 6.0, eine modulare J2EE-Komponente, erweitert die Authentifizierungs- und Autorisierungsautorität Access Manager um Fähigkeiten des föderierten Identitäten-Managements. Dieses Produkt ermöglicht den Aufbau von Vertrauensbeziehungen und den domänenübergreifenden Austausch von Authentifizierungsund Attributinformationen. Die SAML-Autorität des TFIMs 6.0 unterstützt momentan im Gegensatz zu den FIM-Komponenten von RSA und CA ausschließlich die SAML Version 1.0 (inklusive Browser/Artifact- und Browser/POST-Profil). An dieser Stelle muss jedoch bemerkt werden, dass es sich beim IBM Tivoli Federated Identity Manager 6.0 noch um eine Beta-Version handelt. Nach Aussagen von IBM besteht die Möglichkeit, dass die endgültige Verkaufsversion noch um SAML 1.1 erweitert wird. Neben SAML 1.0 unterstützt TFIM 6.0 außerdem die Spezifikation WS-Federation und das Liberty Identity Federation Framework (Liberty ID-FF 1.1). Eine hohe Sicherheit und Vertraulichkeit beim Austausch von Benutzerinformationen kann durch den Einsatz von WS- Security gewährleistet werden. Die Implementierung des TFIMs 6.0 ist komplex. Sie setzt sich aus zahlreichen Diensten und Modulen zusammen. Die wichtigsten sollen an dieser Stelle kurz vorgestellt werden [IBMRed]: Trust Service Der Trust Service ist ein Hauptbestandteil des TFIMs 6.0. Diese J2EE-Applikation stellt Dienste zur Verfügung, die es auf eine sichere Art und Weise ermöglichen, die Domänen eines Unternehmens um die Domänen von vertrauenswürdigen Partnerseiten zu erweitern. Neben der Verwaltung von kryptografischen Elementen ist es die Hauptaufgabe dieser Komponente, Sicherheitstoken zwischen den Domänen einer Föderation auszutauschen. Der Trust Service verwaltet dabei die vorhandenen Beziehungen zwischen den verschiedenen Partnern (inklusive der gesendeten bzw. empfangenen Token-Typen). Zudem werden Informationen verwaltet, die festlegen, wie Identitätsinformationen auf unterschiedliche Token Typen abgebildet werden. Der Aufruf des Trust Services geschieht mittels SOAP over HTTP. Alias Service Der TFIM Alias Service verwaltet die Pseudonyme von Benutzern, die von den Single Sign- On-Protokollen verwendet werden. Für jeden Partner in der Föderation kann ein anderer Alias verwendet werden. Der Einsatz eines Alias soll verhindern, dass die wirkliche Identität eines Nutzers in einem Netzwerk ausgetauscht wird. Der FIM Alias Service speichert die Mapping-Informationen eines Alias im Access Manager Benutzerverzeichnis. 70

82 Kapitel 3: Einrichtung der Testumgebungen Dieser Dienst wird nur für das Liberty Alliance Protokoll benötigt. Die anderen Protokolle wie z.b. SAML unterstützen diese Funktionalität nicht. Der Zugriff auf den Alias Service erfolgt durch einen lokalen Java-Aufruf. Die Kommunikation mit dem Benutzerregister geschieht über JNDI. Key Encryption Signing Service Eine Vertrauensbeziehung innerhalb einer Föderation basiert auf öffentlichen/privaten Schlüsseln. In einer solchen Umgebung besitzt jeder Partner einen oder mehrere private Schlüssel, um Identitätsinformationen innerhalb von Sicherheitstoken (z.b. SAML-Assertion) signieren zu können. Die Entschlüsselung dieser Signaturen erfolgt mittels eines passenden öffentlichen Schlüssels. Die Aufgabe der Key Encryption Signing Services ist die Verwaltung bzw. Bereitstellung der vorhandenen Schlüssel. Ein Aufruf dieser J2EE-Komponente erfolgt wieder durch einen lokalen Java-Aufruf. Durchgeführt wird dieser sowohl vom Trust Service als auch vom SSO Protocol Service. SSO Protocol Service Der TFIM SSO Protocol Service (SPS) regelt die komplette HTTP- bzw. SOAP/HTTP- Kommunikation, um die verschiedenen Single Sign-On Protokolle (z.b. SAML) unterstützen zu können. Der Browser eines Clients greift dabei per HTTP(S), über den Umweg eines WebSeal Reverse Proxies, auf den SPS zu. Der WebSeal übernimmt dabei die Aufgaben des Web Session Managements und der Nutzer-Authentifizierung. Während der Ausstellung einer ausgehenden SSO-Nachricht ruft der SPS den Trust Service auf, um einen SSO-Sicherheitstoken zu erhalten. Dieser hat die Aufgabe, einen lokalen Benutzer auf einer Partnerseite zu authentifizieren. Bei einer eingehenden SSO-Nachricht ruft der SPS den Trust Service auf, damit dieser den erhaltenen SSO-Sicherheitstoken validiert. Die Abbildung 19 zeigt die komplette TFIM-Architektur, die benötigt wird, um SSO- Protokolle wie SAML 1.0, WS-Federation und Liberty zu unterstützen. Der WebSeal Proxy in dieser Umgebung verwaltet Sitzungen (Sessions) und Zugriffsrechte eines Benutzers und führt - wenn nötig - eine Authentifizierung durch. Die Policies, anhand derer eine Autorisation durchgeführt wird, werden vom Access Manager verwaltet. Eingehende SSO-Nachrichten werden vom WebSeal zur weiteren Verarbeitung an den SPS weitergeleitet. Soll selbst ein Single Sign-On-Prozess eingeleitet werden, so leitet der WebSeal Reverse Proxy den entsprechenden Client an den SPS weiter, damit dieser eine SSO-Nachricht für den Benutzer erstellen kann. Der SPS kommuniziert mit den Komponenten der Trust-Infrastruktur, um SSO-Nachrichten auszustellen bzw. zu konsumieren. 71

83 Kapitel 3: Einrichtung der Testumgebungen Die Verwaltung des SPSs geschieht über die TFIM-Konsole. Dazu muss diese Konsole als Plugin in die IBM Integrated Solutions Console (ISC) integriert werden. Auf die ISC kann per HTTP bzw. HTTPS zugegriffen werden. Geschützte Ressourcen WebSphere Key Encryption Signing Service ISC TFIM Konsole Access Manager WebSeal 5.1 SSO Protocol Service Trust Service Alias Service Access Manager 5.1 Policy Server & Authorization Server LDAP Benutzerverzeichnis Abbildung 19: Architektur IBM Federated Identity Manager Installation Der IBM Tivoli Access Manager 5.1 und der IBM Tivoli Federated Identity Manager 6.0 wurden zusammen auf einem Pentium III Testserver (2048 MB RAM) unter dem Betriebsystem Windows 2003 Enterprise Edition Server installiert. Noch bevor die beiden Produkte installiert werden konnten, mussten folgende Vorraussetzungen getroffen werden: Installation der IBM Java Runtime Environment Diese Java Runtime Environment Version wird vom Tivoli Access Manager 5.1 benötigt. Installation und Konfiguration eines WebSphere Application Servers 6.0 Der Federated Identity Manager läuft als Java-Applikation auf diesem Application-Server. DB2 Enterprise Server Edition 8.1 (Fixpack 2) Der Tivoli Directory Server nutzt diese Datenbank, um dort seine LDAP-Daten zu speichern. Installation und Konfiguration der IBM Integrated Solutions Console (ISC) 5.1 Die ISC stellt eine Web Portal Server-Infrastruktur für die TFIM Console 6.0 bereit. Diese FIM-Konsole wird als Plugin in die Infrastruktur der ISC integriert, um dort in Form einer Applikation ausgeführt zu werden. Installation Global Security Kit (GSKit), Version 7 Diese Komponente enthält SSL- Bibliotheken, um eine SSL Daten-Verschlüsselung zu ermöglichen. 72

84 Kapitel 3: Einrichtung der Testumgebungen Installation und Konfiguration eines IBM Tivoli Directory Servers (IDS) 5.2 Dieses LDAP-Verzeichnis wird vom TAM 5.1 als Benutzerverzeichnis verwendet. Für die Installation des Tivoli Access Managers 5.1 waren folgende Schritte nötig [IBMPreq]: 1. Installation und Konfiguration eines TAM 5.1 Policy Servers. 2. Konfiguration eines Access Manager Authorization Servers. 3. Installation und Konfiguration eines TAM Web Portal Managers (WPM). 4. Installation und Konfiguration eines TAM WebSeal Reverse Proxies. 5. Installation einer IBM Solutions Console (ISC) 5.1. Zu Schritt 1: Der Installationsvorgang des Policy Servers und des Authorization Servers läuft vollkommen automatisch ab. Nach der Installation müssen die TAM Runtime und der TAM Policy Server geeignet konfiguriert werden. Hierzu kann eine komfortable grafische Benutzeroberfläche genutzt werden. Folgende Angaben sind zu machen: Typ des Benutzerverzeichnisses (hier: LDAP), Verbindungsdaten des Benutzerverzeichnisses (Hostname, Portnummer, Administratorname und Administratorpasswort) und SSL-Verbindungseinstellungen (z.b. SSL-Port). Zu Schritt 2: TFIM 6.0 benötigt neben dem Policy Server auch einen Authorization Server. Dieser muss ebenfalls nach der Installation konfiguriert werden. Dem Authorization Server müssen hierzu folgende Informationen mitgeteilt werden: Domänenname, Verbindungsdaten des Policy Servers (Hostname, Portnummer) und Verbindungsinformationen des Authorization Servers (Hostname, Administration-Port, Authorization-Request-Port). Zu Schritt 3: Die Java-Applikation WPM muss in einen WebSphere 5.1 Applikations-Server integriert werden. Da bei den Vorbereitungen der WebSphere 6.0 (benötigt von TFIM 6.0) installiert wurde, und der WPM zu dieser Version nicht kompatibel ist, muss zusätzlich eine WebSphere 5.1 Instanz installiert werden. Bei der Konfiguration des Web Portal Managers müssen neben dem Pfad des zu verwendenden WebSphere 5.1 Servers vor allem die Verbindungsdaten des Policy Servers angegeben werden. Um zu kontrollieren, ob die WPM Applikation aktiv ist, kann man diese mit dem Browser über den URL Machine>:8426/pdadmin aufrufen. Zu Schritt 4: Während der Installationsroutine des WebSeal 5.1 Reverse Proxies wurden folgende Komponenten installiert: TAM Web Security Runtime, TAM WebSeal und AM Web Security Application Developer Kit. Konfiguriert wird der WebSeal - wie die Komponenten zuvor - mittels des TAM Konfigurationsprogramms. WebSeal erlaubt die Konfiguration mehrerer 73

85 Kapitel 3: Einrichtung der Testumgebungen Instanzen, die unterschiedliche Aufgaben im System wahrnehmen können. Jede WebSeal- Instanz hat dabei einen eindeutigen Namen, einen Hostnamen und einen Listening Port. Abschließend wird festgelegt, welche Arten von Verbindungen (HTTP, HTTPS) vom WebSeal Server akzeptiert werden sollen. Zu Schritt 5: Ebenso wie der WPM wird auch die IBM Solutions Konsole in den WebSphere 5.1 Server integriert. Während des Installationsvorgangs kann der gewünschte WebSphere Server aus einer Liste ausgewählt werden. Anschließend müssen die Verbindungsdaten für den ISC Portal Server angegeben werden (z.b. HTTP-Port, HTTPS-Port, SOAP-Port). Zum Schluss werden die Zugriffsdaten für das LDAP-Verzeichnis benötigt (z.b. LDAP-Port, LDAP Administrative DN, LDAP Bind DN etc.). Nachdem alle erforderlichen Komponenten des Tivoli Access Managers 5.1 installiert bzw. konfiguriert wurden, kann der Tivoli Federated Identity Manager 6.0 in das bestehende System integriert werden. Im ersten Schritt wird die TFIM 6.0 Konsole installiert. Dazu muss diese in den bereits existierenden ISC Portal Server integriert werden. Um zu überprüfen, ob die FIM-Konsole korrekt installiert wurde, kann die IBM Solutions Console in einem Browser aufgerufen werden (URL: Machine>:8421/ibm/console). Im zweiten Schritt wird die Hauptkomponente, der Tivoli Federated Identity Manager 6.0, installiert. Nach der erfolgreichen Installation können mittels der TFIM-Konsole Föderationen mit anderen Unternehmen bzw. Domänen aufgebaut werden. 3.4 Vergleich der eingesetzten IAM-Softwareprodukte In der folgenden Tabelle werden die drei Identity/Access-Management-Produkte, die im Rahmen dieser Diplomarbeit für den Aufbau einer föderierten Umgebung eingesetzt wurden, untereinander verglichen. Allgemein Installation Dokumentation Netegrity Siteminder 6.0 SP1 Installationsvorgang relativ einfach, jedoch etwas unübersichtlich, da zahlreiche Komponenten installiert werden müssen. Sehr ausführliche Dokumentationen. Mehr Beispiele und Abbildungen wären jedoch wünschenswert. RSA Cleartrust 5.5 & FIM 2.5 Installationsvorgang einfach und schnell. Gute und verständliche Dokumentationen, die jedoch etwas umfangreicher sein könnten. IBM TAM 5.1 & TFIM 6.0 (Beta) Installationsvorgang im Vergleich zu den anderen Produkten recht komplex und zeitintensiv. Sehr umgangreiche aber gute Dokumentationen. Es wird sehr viel Detailwissen vermittelt. 74

86 Kapitel 3: Einrichtung der Testumgebungen Management & Konfiguration Die Konfiguration ist trotz einer grafischen Benutzeroberfläche eher schwierig. Das Netegrity Sicherheitsmodell erfordert, dass sich der Administrator mit zahlreichen neuen Begriffen auseinander setzt. Die Benutzerschnittstelle zum Management und zur Konfiguration des Systems ist intuitiv und gut organisiert. Übersichtliche Konfiguration des Systems durch eine grafische Benutzeroberfläche (ISC). Manche Konfigurationsschritte müssen jedoch per Konsole durchgeführt werden. Dies erfordert eine Einarbeitung in die Konsolenbefehle. Logging & Reporting Gute Logging & Reporting Funktionen. Die Fehlerlogdateien liefern jedoch nicht immer den benötigten Detaillevel. Mittelmäßige Logging & Reporting Funktionen. Der Detailgrad der Fehlerlogdateien ist ausreichend (drei mögliche Abstufungen). Sehr gute Logging & Reporting Funktionen. Der Detailgrad kann beliebig genau eingestellt werden. Hohe Verfügbarkeit Gute Performanz durch Redundanz (Load- Sharing, Failover). Gute Performanz. Problem: Mehrfache Identity-Speicher werden nicht direkt unterstützt. Sehr gute Performanz (Failover, Load-Balancing). Anpassbarkeit Hohe Anpassbarkeit (zahlreiche Programmierschnittstellen). Sehr hohe Anpassbarkeit (ca. 300 Programmierschnittstellen für Java, C, DCOM, JAAS, XML, SOAP etc.). Hohe Anpassbarkeit (Zugriff auf zahlreiche Java 2-, J2EEund JAAS- Implementierungen). Identity Management Integration von Datenbanken bzw. Verzeichnissen Ausgelagerte (Delegated) Administration Rollen-basierte Zugriffskontrolle Attribut-basierter Zugang Selbstregistrierung durch den Nutzer CA etrust; IBM Directory Server; Lotus Domino LDAP; Microsoft Active Directory; Novell edirectory; Oracle Internet Directory, Oracle Databases; Sun One Directory Server; Siemens DirX. CA etrust; Calendra; IBM Tivoli; Microsoft Active Directory, SQL Server 2000; OpenLDAP; Novell edirectory; Oracle 8.1.7, Oracle Internet Directory; Sun One Directory Server; Sybase 12.5; Radiant Logic RadiantOne VDS; Siemens DirX. IBM Directory Server; Microsoft Active Directory; Novell edirectory; Sun One Directory Server; Lotus Domino LDAP. Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Zugangskontrolle Single Sign-On Ja Ja Ja Personalisierte Webseiten (basierend auf Nutzer-Attributen) Ja (Header oder Cookie) Ja (Header oder Cookie) Ja (Header) 75

87 Kapitel 3: Einrichtung der Testumgebungen Real-time access revocation Authentifizierungsmethoden Ja Ja Ja SAML; Smartcards; X.509 Zertifikate; Two- Factor Tokens; Integrierte Windows Authentifizierung; RADIUS; Passwort; Biometrie; selbstdefinierte Authentifizierungsmethoden; HTML-Formular Authentifizierung. SAML;Passwort; Integrierte Windows Authentifizierung; HTML-Formular Authentifizierung; Two- Factor Authentifizierung (RSA SecurID & RSA Mobile); X.509 Zertifikate; selbstdefinierte Authentifizierungsmethoden. SAML; Passwort; HTML- Formular Authentifizierung; SecurID Token; X.509 Zertifikate; RACF Authentifizierung; Entrust TruePass; Biometrie; Micosoft Passport; selbstdefinierte Authentifizierungsmethoden; LTPA Authentifizierung. Agenten-basiert Ja Ja Ja (Reverse Proxy Ansatz wird jedoch bevorzugt) Reverse Proxy Server-basiert Ja Ja (RSA ACM) Ja (IBM WebSeal) Federated Identity Management SAML Unterstützt SAML 1.0/1.1 Unterstützt SAML 1.0/1.1 Unterstützt SAML 1.0 Liberty ID-FF Keine direkte Unterstützung. Es müssen Zusatzmodule installiert werden (TPSO, TPSI). Diese ermöglichen den Einsatz von Liberty ID- FF 1.1. Momentan keine Unterstützung. Direkte Unterstützung des Liberty ID-FF 1.1 Protokolls. WS-Federation Nein Nein Ja WS-Security Nein Nein Ja Tabelle 3: Vergleich IAM-Softwareprodukte 3.5 Aufbau einer föderierten Systemumgebung Nach der Beschreibung der verwendeten Produkte soll die föderierte Systemarchitektur vorgestellt werden, die im Rahmen dieser Diplomarbeit aufgebaut wurde. Das Ziel dieser Architektur war es, die wechselseitige Interoperablität der Sicherheitslösungen im Bereich Federated Identity Management zu untersuchen und zu analysieren. Die zwischen den unterschiedlichen Systemen ausgetauschten Nachrichten basieren auf SAML 1.0/1.1. Die Liberty Alliance Protokolle bzw. das WS-Federation Protokoll wurde in dieser Diplomarbeit nicht getestet. 76

88 Kapitel 3: Einrichtung der Testumgebungen Um korrekte und nachvollziehbare Ergebnisse zu erhalten, wurden SAML-Anwendungsfälle (vgl. Kapitel 4) definiert. Anhand dieser Use-Cases wurde im Anschluss eine umfangreiche Produktevaluierung vorgenommen (vgl. Kapitel 5). Abbildung 20 zeigt die vernetzte Systemarchitektur auf einem hohen Abstraktionslevel. Ausgangspunkt sind drei unterschiedliche Domänen. Jede dieser drei Domänen wird von einer unterschiedlichen Sicherheitslösung kontrolliert und verwaltet. Der Austausch von Nachrichten zwischen den Föderationsprodukten erfolgt über SAML- Requests und SAML-Responses. Als Protokoll wird hierfür SOAP over HTTP verwendet. Domäne A WebServer mit Webagent Netegrity Siteminder Server SUN One LDAP-Verzeichnis SAML Request & Response Domäne B HTTP(S) Anfragen WebServer mit Webagent RSA Cleartrust & FIM Server Microsoft SQL Server 2000 SAML Request & Response Domäne C WebSeal IBM TAM & TFIM Server Tivoli Directory Server Abbildung 20: Föderierte heterogene Systemarchitektur 77