institut fÜr informatik - pms.ifi.lmu.de · hiermit versichere ich, dass ich die vorliegende...

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

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 2005

…………………………………. (Unterschrift des Kandidaten)

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.

Für meinen Vater

LUDWIG WEISHÄUPL

der mir sagte, ich soll aus mir machen, was ich will.

1932 - 2004

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.

i

Inhaltsverzeichnis

1. Einleitung 1

1.1 Motivation................................................................................................................................... 1 1.2 Ziel der Arbeit............................................................................................................................. 4 1.3 Aufbau und Gliederung der Arbeit ............................................................................................. 5

2. Grundlagen des Federated Identity Managements 7

2.1 Identifikation in einem Computer Netzwerk .............................................................................. 7 2.1.1 Zugang zu Ressourcen..................................................................................................................... 7 2.1.2 Multiple Sign On vs. Single Sign On .............................................................................................. 8 2.1.3 Federated Identity Single Sign-On .................................................................................................. 9 2.1.4 Beispielszenarios ........................................................................................................................... 10

2.2 Konzepte einer Föderation........................................................................................................ 13 2.3 Web-Services ............................................................................................................................ 15 2.4 Sicherheitsstandards in einer Identity Federation ..................................................................... 17

2.4.1 Microsoft .NET Passport ............................................................................................................... 17 2.4.2 Security Assertion Markup Language – SAML ............................................................................ 20 2.4.3 OASIS SAML 1.1 Spezifikation ................................................................................................... 22 2.4.4 Liberty Alliance Projekt ................................................................................................................ 40 2.4.5 Web-Services Security .................................................................................................................. 45 2.4.6 WS-Federation............................................................................................................................... 46

2.5 Vergleich der Föderationsstandards.......................................................................................... 49 2.6 Zusammenfassung .................................................................................................................... 49

3. Einrichtung der Testumgebungen 52

3.1 Netegrity Siteminder 6.0........................................................................................................... 52 3.1.1 Funktionalitäten ............................................................................................................................. 52 3.1.2 Architektur..................................................................................................................................... 53 3.1.3 Federated Identity Management .................................................................................................... 57 3.1.4 Installation ..................................................................................................................................... 58

3.2 RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5.................................................... 60 3.2.1 Funktionalitäten ............................................................................................................................. 60 3.2.2 Architektur..................................................................................................................................... 62 3.2.3 Federated Identity Management .................................................................................................... 64 3.2.4 Installation ..................................................................................................................................... 65

3.3 IBM Tivoli Access Manager 5.1 & Tivoli Federated Identity Manager 6.0............................. 67 3.3.1 Funktionalitäten ............................................................................................................................. 67 3.3.2 Architektur..................................................................................................................................... 68 3.3.3 Federated Identity Management .................................................................................................... 70 3.3.4 Installation ..................................................................................................................................... 72

3.4 Vergleich der eingesetzten IAM-Softwareprodukte ................................................................. 74 3.5 Aufbau einer föderierten Systemumgebung ............................................................................. 76

4. Anwendungsfälle für ein föderiertes Identitätsmanagement 82

ii

4.1 Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On ........................... 82 4.2 Anwendungsfall: Föderierter Attribut-Austausch..................................................................... 86 4.3 Anwendungsfall: Lokale Autorisierung.................................................................................... 87 4.4 Anwendungsfall: Entfernte (Remote) Autorisierung................................................................ 88 4.5 Anwendungsfall: Föderiertes Single Logout ............................................................................ 90

5. Umsetzung und Analyse 91

5.1 Testszenario Netegrity Siteminder 6.0 (IdP) – SAML Affiliate Agent 6.x QMR2 (SP) .......... 92 5.1.1 Konfiguration der Testumgebung.................................................................................................. 92 5.1.2 Test der Anwendungsfälle ............................................................................................................. 93 5.1.3 Fazit ............................................................................................................................................... 96

5.2 Testszenario Netegrity Siteminder 6.0 (IdP) – RSA Cleartrust 5.5 & FIM 2.5 (SP)................ 97 5.2.1 Konfiguration der Testumgebung.................................................................................................. 97 5.2.2 Test der Anwendungsfälle ............................................................................................................. 98 5.2.3 Fazit ............................................................................................................................................. 105

5.3 Testszenario Netegrity Siteminder 6.0 (IdP) – IBM TAM 5.1 & TFIM 6.0 (SP) .................. 106 5.3.1 Konfiguration der Testumgebung................................................................................................ 106 5.3.2 Test der Anwendungsfälle ........................................................................................................... 107 5.3.3 Fazit ............................................................................................................................................. 110

5.4 Testszenario RSA Cleartrust 5.5 & FIM 2.5 (IdP) – Netegrity Siteminder 6.0 (SP).............. 110 5.4.1 Konfiguration der Testumgebung................................................................................................ 110 5.4.2 Test der Anwendungsfälle ........................................................................................................... 111 5.4.3 Fazit ............................................................................................................................................. 114

5.5 Testszenario RSA Cleartrust 5.5 & FIM 2.5 (IdP)–IBM TAM 5.1 & TFIM 6.0 (SP) ........... 115 5.5.1 Konfiguration der Testumgebung................................................................................................ 115 5.5.2 Test der Anwendungsfälle ........................................................................................................... 116 5.5.3 Fazit ............................................................................................................................................. 120

5.6 Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP)–RSA Cleartrust 5.5 & FIM 2.5 (SP) ........... 120 5.6.1 Konfiguration der Testumgebung................................................................................................ 120 5.6.2 Test der Anwendungsfälle ........................................................................................................... 122 5.6.3 Fazit ............................................................................................................................................. 124

5.7 Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP) – Netegrity Siteminder 6.0 (SP) .................. 124 5.7.1 Konfiguration der Testumgebung................................................................................................ 124 5.7.2 Test der Anwendungsfälle ........................................................................................................... 125 5.7.3 Fazit ............................................................................................................................................. 127

5.8 OpenSAML-Autorität der BMW Group................................................................................. 127

6. Zusammenfassung und Ausblick 130

A. Anhang 134

A.1 Quellcode Assertion Generator Plugin (Netegrity Siteminder 6.0 SP1)................................ 134 A.2 Beispiele zum Liberty ID-FF 1.2 Protokoll ........................................................................... 141 A.3 SAML-Requests & SAML-Responses .................................................................................. 142

A.3.1 Testszenario Netegrity Siteminder 6.0 – SAML Affiliate Agent 6.x QMR2.............................. 142 A.3.2 Testszenario Netegrity Siteminder 6.0 – RSA Cleartrust & RSA FIM 2.5................................. 143 A.3.3 Testszenario RSA Cleartrust & RSA FIM 2.5 – Netegrity Siteminder 6.0................................. 145 A.3.4 Testszenario IBM TAM 5.1 & TFIM 6.0 – RSA Cleartrust 5.5 & FIM 2.5 ............................... 145 A.3.5 Testszenario IBM TAM 5.1 & TFIM 6.0 – Netegrity Siteminder 6.0 ........................................ 147

iii

Abkürzungsverzeichnis 149

Literaturverzeichnis 151

iv

Abbildungsverzeichnis

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

v

Tabellenverzeichnis

Tabelle 1: Vergleich Liberty Alliance - WS-Federation ....................................................................................... 48 Tabelle 2: Vergleich der SSO-Protokolle.............................................................................................................. 49 Tabelle 3: Vergleich IAM - Softwareprodukte ..................................................................................................... 76 Tabelle 4: SSO-Einstellungen Netegrity Siteminder............................................................................................. 78 Tabelle 5: SSO-Einstellungen RSA FIM .............................................................................................................. 79 Tabelle 6: SSO-Einstellungen IBM FIM .............................................................................................................. 79 Tabelle 7: SAML-Features Netegrity Siteminder vs. SAML Affiliate Agent....................................................... 93 Tabelle 8: Einstellungen Netegrity Siteminder & SAML Affiliate Agent ............................................................ 93 Tabelle 9: Testergebnisse - Netegrity Siteminder (IdP) & SAML Affiliate Agent (SP)...................................... 94 Tabelle 10: SAML-Features Netegrity Siteminder vs. RSA FIM......................................................................... 98 Tabelle 11: Einstellungen Netegrity Siteminder & RSA FIM .............................................................................. 98 Tabelle 12: Testergebnisse - Netegrity Siteminder (IdP) & RSA FIM (SP) ......................................................... 98 Tabelle 13: SAML-Features Netegrity Siteminder vs. IBM TFIM..................................................................... 106 Tabelle 14: Einstellungen Netegrity Siteminder & IBM TFIM .......................................................................... 107 Tabelle 15: Testergebnisse - Netegrity Siteminder (IdP) & IBM TFIM (SP)..................................................... 107 Tabelle 16: SAML-Features RSA FIM vs. Netegrity Siteminder ....................................................................... 111 Tabelle 17: Einstellungen RSA FIM & Netegrity Siteminder ............................................................................ 111 Tabelle 18: Testergebnisse - RSA FIM (IdP) & Netegrity Siteminder (SP) ....................................................... 112 Tabelle 19: SAML-Features RSA FIM vs. IBM TFIM ...................................................................................... 115 Tabelle 20: Einstellungen RSA FIM & IBM TFIM............................................................................................ 116 Tabelle 21: Testergebnisse - RSA FIM (IdP) & IBM TFIM (SP)....................................................................... 116 Tabelle 22: SAML-Features IBM TFIM vs. RSA FIM ...................................................................................... 121 Tabelle 23: Einstellungen IBM TFIM & RSA FIM............................................................................................ 121 Tabelle 24: Testergebnisse - IBM TFIM (IdP) & RSA FIM (SP)....................................................................... 122 Tabelle 25: SAML-Features IBM TFIM vs. Netegrity Siteminder..................................................................... 125 Tabelle 26: Einstellungen IBM TFIM & Netegrity Siteminder .......................................................................... 125 Tabelle 27: Testergebnisse - IBM TFIM (IdP) & Netegrity Siteminder(SP)...................................................... 126

Kapitel 1: Einleitung

1

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


2

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.

Abbildung 2: Identity Lifecycle Management

Benutzer Identifikation

Authentifizierung

Service Providers

Service Consumers Vertrauensbeziehung

Zugriffskontrolle

Austausch von Identitäts- und Attributinformationen

Identity Lifecycle Management


3

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


4

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


5

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


6

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.

Kapitel 2: Grundlagen des Federated Identity Managements

7

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. 2.1.1 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]


8

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]. 2.1.2 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 10.000 Benutzern definiert - entspricht dies pro Tag 2.666 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.


9

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. 2.1.3 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


10

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].

2.1.4 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


11

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.

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.

Airline, Inc.

CheapHotel, Inc. CarRentals.com Identity Store

TravellsUs.com

Bob


12

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.

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.

Employee Portal

401k Provider Benefits Provider Identity Store

Jane’s Employer

Jane


13

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 2.1.2 bzw. 2.1.3 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

Widget Provider A

Widget Provider B Widget Provider CIdentity Store

Bob’s Employer

Bob


14

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.

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

Local User: AliceBücherWurm Alias : PEIIKD889

Mapping: JKR67HY = BücherWurmAlice

Local User: Alice123 Alias : JKR67HY Mapping: PEIIKD889 = Alice123

Buchhandel Bankinstitut


15

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


16

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 E-Mail Dienst deutlich. Eine E-Mail 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 E-Mail-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 E-Mails. 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


17

Standards dieser Ebene sind WS-Security (siehe Kapitel 2.4.5) und SAML (siehe Kapitel 2.4.2). [WSBasics]

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

2.4.1 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.

SOAP-Envelope

SOAP-Body

Nachrichten -Body

SOAP-Header Headerblock

Headerblock


18

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 E-Mail-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.


19

• 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 E-Mail 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-


20

Webseiten und Produkten wie dem MSN Messenger oder Hotmail zum Einsatz kommen [INQ]. 2.4.2 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 2.4.3.7). 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


21

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äts-umgebung nötig sind. Die Regelungen bzgl. eines Vertrauensverhältnisses zwischen zwei Partnern, wie Benutzerverwaltung und Datenschutz, bleiben außerhalb der SAML-Spezifikation. 2.4.2.1 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 2.4.3.2) 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 2.4.4.3) 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.


22

2.4.3 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 plattform- und 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


23

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. 2.4.3.1 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 2.4.3.2.


24

MajorVersion

MinorVersion

Issuer

IssueInstant

AssertionID

Conditions

Advice

ds:Signature

Assertion

AttributeStatement

SubjectStatement

AuthenticationStatement

AuthorizationDecisionStatement

NotOnOrAfterNotBefore

Condition

AudienceRestrictionCondition Audience

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="2005-03-22T09:13:29Z"

Issuer="http://www.bmw.de"

MajorVersion="1" MinorVersion="1">

<saml:Conditions

NotBefore="2005-03-22T09:12:29Z"

NotOnOrAfter="2005-03-22T09:18:29Z">

</saml:Conditions>

<saml:AuthenticationStatement

AuthenticationInstant="2005-03-22T09: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="www.rsa.com"> uid=admin

</saml:NameIdentifier>

</saml:Subject>

</saml:AuthenticationStatement>

</saml:Assertion>


25

2.4.3.2 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.


26

<AttributeStatement>

Enthält die Attribut-/Werte-Paare (Eigenschaften), welche einem Subjekt zugeordnet wurden.

Das folgende Schema Fragment definiert das <saml:Assertion>-Element:

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.

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


27

• 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 <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 Emailadressen, 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="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 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>


28

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:

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="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>

<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"/>


29

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 <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.

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


30

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

Das Element <saml:Attribute> enthält wiederum mindestens ein Unterelement <saml:AttributeValue>. Dieses Element speichert den Wert eines Attributs.

<element name="AuthorizationDecisionStatement" type="saml:AuthorizationDecisionStatementType"/> <complexType name="AuthorizationDecisionStatementType">


<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"/>


</complexType>

<element name="AttributeStatement" type="saml:AttributeStatementType"/> <complexType name="AttributeStatementType">


<sequence> <element ref="saml:Attribute" maxOccurs="unbounded"/> </sequence>


</complexType>


31

2.4.3.3 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.

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.

SAML Query

SAML-Request

SAML Assertion

SAML-Response

Identity Provider

(Trusted SAML Authority)

Service Provider

(SAML Consumer)


32

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.


33

Das folgende Schema Fragment definiert das <samlp:Request>-Element:

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

Das Element <samlp:Status> ist in folgende Subelemente unterteilt: <StatusCode> [verpflichtend]

Enthält den Code, welcher den Status einer korrespondierenden SAML-Anfrage repräsentiert.

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


</complexType>

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


34

<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.

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.

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


35

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. 2.4.3.4 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:

2.4.3.5 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:

POST /SamlService HTTP/1.1 Host: www.example.com Content-Type: text/xml Content-Length: nnn SOAPAction: http://www.oasis-open.org/committees/security <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>

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


36

• 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:

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>

Web Browser Source Site Destination Site

(1)

(2)

(3)

(4)

(5)

(6)


37

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-time-use), 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:

Abbildung 12: Single Sign-On mit dem Browser/POST Profile

(1)

(3)

(4)

Web Browser Source Site Destination Site

(2)


38

(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.

2.4.3.6 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). 2.4.3.7 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.


39

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 E-Mail 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.


40

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 2.4.4.1) 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. 1.1. 2.4.4 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.


41

• 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. 2.4.4.1 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.


42

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>.


43

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:

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

User/Browser Service Provider Identity Provider

2. Suche passenden IdP

10. Verarbeite Assertion

3. HTTP Response mit AuthnRequest()

4. HTTP Request mit AuthnRequest()

6. HTTP Response mit AuthnResponse oder Artifact()

7. HTTP Request mit AuthnResponse oder Artifact()

8. HTTP Request mit Artifact()

9. HTTP Response mit Assertion()

1. HTTP Request()

11. HTTP Response()

5. Verarbeite AuthnRequest


44

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.

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. 2.4.4.2 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]

samlp:RequestAbstractType

saml: AssertionType

samlp:ResponseType

saml:AuthenticationStatementType

lib:AuthnRequest

lib: ProviderID ForceAuth (boolean) IsPassive (boolean) Federate (boolean) lib: ProtocolProfil lib: AuthnContext lib: RelayState lib: AuthnContextComparison

lib:AssertionType

attribute: InResponseTo attribute: ID

lib:AuthnResponse

lib: ProviderID lib: RelayState attribute: ID

lib:AuthenticationStatementType

lib: AuthnContext attribute: ReAuthenticateOnOrAfter attribute: SessionIndex


45

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. 2.4.4.3 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 2.0. 2.4.4.4 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). 2.4.5 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


46

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. 2.4.6 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.


47

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. 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

Empfehlungen bzgl. der Bereiche Schutz bzw. Anonymität von persönlichen Daten wurden in die Spezifikation aufgenommen.

Optionale Unterstützung durch Einsatz von WS-Policy und WS-Privacy.

Security Tokens

Erweiterung von SAML-Assertions, um Authentifizierungs- bzw. Authorisierungstoken zwischen Providern austauschen zu können.

Baut auf verschiedenen WS-Security Profilen auf (z.B. X.509v3). Zusätzlich können auch SAML Tokens verwendet werden.

Richtlinien bzgl. Geschäftsvereinbarungen und Sicherheitsregeln (Policies)

Beschäftigt sich mit Fragen des Aufbaus einer Vertrauens-beziehung (siehe Business Guidelines und Authentication Context).

Diese Fragen werden momentan nicht abgedeckt.

Sicherheitsfragen/Daten-

schutz

Erweiterung von SAML. Sicherheitsfragen können mittels der Technologien SSL und WS-Security gelöst werden.

Basiert auf WS-Trust, WS-Policy und WS-Metadata. Sicherheitsfragen können mittels der Technologien SSL und WS-Security gelöst

dClient Profile Definition von Profilen sowohl für Browser als auch für Smart Clients.

Definition von Profilen sowohl für Browser als auch für Smart Clients.

Gemeinsamkeiten /Überlappungen

SSO Kontrollfluss (SSO

Control Flow)

SSO-Ablauf sowohl auf Basis der Front- als auch der Back-Channel Technologie.

SSO-Ablauf vor allem für den Front-Channel Mechanismus. Der Back-Channel Mechanismus wird erwähnt, jedoch nicht empfohlen.


48

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 Spezifi-kationen werden aktuell nur in wenigen Produkten unterstützt.

Unterschiede

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].


49

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

1 SSO, initiiert vom IdP (push SSO) Ja Nein Ja

2 SSO, initiiert vom SP (pull SSO)

Ja

Ja

Ja

3 Front-Channel Security Token Austausch Ja Ja Ja

4 Back-Channel Security Token Austausch Ja Ja Nein

5 Wahl des Security Tokens Nein Nein Ja

6

SSO-Prozess/Account Linking benötigt Konten sowohl auf IdP- als auch auf SP-

Seite

Ja

Ja

Nein

7 Account Linking auf Initiative des IdPs Nein Nein Ja

8 Account Linking auf Initiative des SPs Nein Ja Ja

9 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.


50

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 2005. 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-


51

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öderations-standards noch nicht beendet. WS-Security und WS-Federation sind beispielsweise nach wie vor nicht vollständig interoperabel bzgl. des SAML-Standards.

Kapitel 3: Einrichtung der Testumgebungen

52

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 6.0 3.1.1 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


53

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. 3.1.2 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.


54

Abbildung 15 gibt einen Überblick über die Architektur des Netegrity Siteminders.

Abbildung 15: Architektur Netegrity Siteminder 6.0

1. 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. 3.1.2.1 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..

6

53

1 7

2

Benutzer

Geschützte Ressourcen

Webserver mit

Siteminder Agent

Siteminder Policy Server

User Datenbank

4


55

● 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. 3.1.2.2 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.


56

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]


57

3.1.3 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.


58

• 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. 3.1.4 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) 1.4.1 - Siteminder Option Pack 6.0 SP1 unterstützt

momentan ausschließlich die JRE 1.4.1 (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


59

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]:


60

● 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 http:/ /<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 http:/ /<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 2.5 3.2.1 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.


61

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.


62

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. 3.2.2 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.

Abbildung 17: Architektur RSA Cleartrust 5.5

3.2.2.1 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.

Benutzer

RSA Cleartrust Server

Key Server Dispatcher

Authorization Server

Entitlements Server

User Datenbank

Policy Datenbank

Webserver mit

Cleartrust Agent


63

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. 3.2.2.2 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]:


64

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 3.1.2.2. 3.2.3 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 3.2.1 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.


65

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.). 3.2.4 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) 1.4.1 – 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


66

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.


67

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: http://itacpi09.testeurope1.bmwgroup.com:7001/admingui). 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 http://host_and_domain:managedport/samlconfig 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. 3.3.1 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]:


68

● 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 3.3.3 vorgestellt. 3.3.2 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]:


69

● 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.

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.

Benutzer

Benutzer- verzeichnis

Policies

Access ManagerPolicy Server

Webseal Reverse Proxy

Policies Cache

Webserver

http(s) Request

http(s) Response

Web Portal Manager


70

3.3.3 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 Authentifizierungs- und 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.


71

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.


72

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.

Abbildung 19: Architektur IBM Federated Identity Manager 6.0

3.3.4 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 1.3.1.5 – 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.

Geschützte Ressourcen WebSphere

ISC

TFIM Konsole

LDAP Benutzer-

verzeichnis

Access Manager 5.1 Policy Server &

Authorization Server

Access Manager WebSeal 5.1

Key Encryption Signing Service

Trust Service

Alias Service

SSO Protocol Service


73

● 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 http://<Virtual 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


74

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: http:/<Virtual 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.

Netegrity Siteminder 6.0 SP1

RSA Cleartrust 5.5 & FIM 2.5

IBM TAM 5.1 & TFIM 6.0 (Beta)

Allgemein

Installation

Installationsvorgang relativ einfach, jedoch etwas unübersichtlich, da zahlreiche Komponenten installiert werden müssen.

Installationsvorgang einfach und schnell.

Installationsvorgang im Vergleich zu den anderen Produkten recht komplex und zeitintensiv.

Dokumentation

Sehr ausführliche Dokumentationen. Mehr Beispiele und Abbildungen wären jedoch wünschenswert.

Gute und verständliche Dokumentationen, die jedoch etwas umfangreicher sein könnten.

Sehr umgangreiche aber gute Dokumentationen. Es wird sehr viel Detailwissen vermittelt.


75

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 Konfigurations-schritte 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 Detail-level.

Mittelmäßige Logging & Reporting Funktionen. Der Detailgrad der Fehlerlog-dateien ist ausreichend (drei mögliche Abstufungen).

Sehr gute Logging & Reporting Funktionen. Der Detailgrad kann beliebig genau eingestellt werden.

Hohe Verfügbar- keit

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 Programmier-schnittstellen).

Sehr hohe Anpassbarkeit (ca. 300 Programmierschnitt-stellen für Java, C, DCOM, JAAS, XML, SOAP etc.).

Hohe Anpassbarkeit (Zugriff auf zahlreiche Java 2-, J2EE-und JAAS- Implementier-ungen).

Identity Management

Integration von

Datenbanken bzw. Verzeichnissen

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.

Ausgelagerte (Delegated)

Administration Ja Ja Ja

Rollen-basierte Zugriffskontrolle Ja Ja Ja

Attribut-basierter Zugang Ja Ja Ja

Selbstregistrierung durch den Nutzer Ja Ja Ja

Zugangskontrolle

Single Sign-On Ja Ja Ja

Personalisierte Web- seiten (basierend auf Nutzer-Attributen)

Ja (Header oder Cookie) Ja (Header oder Cookie) Ja (Header)


76

Real-time access revocation Ja Ja Ja

Authentifizierungs-methoden

SAML; Smartcards; X.509 Zertifikate; Two-Factor Tokens; Integrierte Windows Authentifi-zierung; RADIUS; Passwort; Biometrie; selbstdefinierte Authen- tifizierungsmethoden; 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 Authentifi-zierungsmethoden; 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.


77

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.

Abbildung 20: Föderierte heterogene Systemarchitektur

Domäne A

Domäne B

Domäne C

Netegrity Siteminder Server

RSA Cleartrust & FIM Server

IBM TAM & TFIM ServerWebSeal

WebServer mit Webagent

WebServer mit Webagent

SUN One LDAP-Verzeichnis

Microsoft SQL Server 2000

Tivoli Directory Server

SAML Request & Response

SAML Request & Response

HTTP(S) Anfragen


78

Alle drei verwendeten Identity/Access-Management-Produkte können sowohl als Identity Provider (Aussteller von SAML-Assertions) als auch als Service Provider (Empfänger von SAML-Assertions) fungieren. Für eine umfassende Interoperabilitätsüberprüfung müssen die in Kapitel 4 definierten Anwendungsfälle (engl. Use Cases) für folgende Einstellungen geprüft werden:

• Netegrity Siteminder 6.0 (IdP) – RSA Cleartrust 5.5 & RSA FIM 2.5 (SP) • RSA Cleartrust 5.5 & RSA FIM 2.5 (IdP) - Netegrity Siteminder 6.0 (SP) • IBM Tivoli Access Manager 5.1 & TFIM 6.0 (IdP) – Netegrity Siteminder 6.0 (SP) • Netegrity Siteminder 6.0 (IdP) - IBM Tivoli Access Manager 5.1 & TFIM 6.0 (SP) • RSA Cleartrust 5.5 & RSA FIM 2.5 (IdP) - IBM Tivoli Access Manager 5.1 & TFIM

6.0 (SP) • IBM Tivoli Access Manager 5.1 & TFIM 6.0 (IdP) - RSA Cleartrust 5.5 & RSA FIM

2.5 (SP)

Die folgenden Tabellen zeigen die im Rahmen dieser Diplomarbeit vorgenommenen Einstellungen der jeweiligen Softwareprodukte. Diese Informationen sind wichtig, damit ein IdP bzw. SP weiß, wohin er seine SAML-Requests bzw. SAML-Responses schicken soll. Der Austausch der Nachrichten erfolgt per SOAP over HTTP.

Netegrity Siteminder 6.0 SP1

Hostadresse (fully qualified domain name) itacpi29.testeurope1.bmwgroup.com

Inter-Site Transfer URL/Service (ISX) http://itacpi29.testeurope1.bmwgroup.com/site

minderagent/smprofile.ccc?SMASSERTIONR

EF=QUERY&NAME=<affiliate_name>&TAR

GET=http://<consumer_site>/<target_page>&S

MCONSUMERURL= <assertion_consumer

_url >&AUTHREQUIREMENT=2

Assertion Retrieval/SOAP Binding Service URL https://itacpi29.testeurope1.bmwgroup.com:443

/affwebservices/assertionretriever

Artifact Receiver Service URL https://itacpi29.testeurope1.bmwgroup.com:443

/affwebservices/public/samlcc

Tabelle 4: SSO-Einstellungen Netegrity Siteminder

RSA Cleartrust 5.5 & RSA FIM 2.5

Hostadresse (fully qualified domain name) itacpi09.testeurope1.bmwgroup.com


79

RSA Cleartrust 5.5 & RSA FIM 2.5

Inter-Site Transfer URL/Service (ISX) http://itacpi09.testeurope1.bmwgroup.com:7001

/samlassertingparty/AP?TARGET=http(s)://we

b-server-host.target-domain/protected-resource

Assertion Retrieval/SOAP Binding Service URL http:// itacpi09.testeurope1.bmwgroup.com:

7001/samlassertingparty/services/SamlRequest

Artifact Receiver Service URL http://itacpi09.testeurope1.bmwgroup.com:7001

/samlrelyingparty/RP

Tabelle 5: SSO-Einstellungen RSA FIM

IBM TAM 5.1 & IBM TFIM 6.0

Hostadresse (fully qualified domain name) itahpi14.testeurope1.bmwgroup.com

Inter-Site Transfer URL/Service (ISX) http://itahpi14.testeurope1.bmwgroup.com/FIM

/sps/samlfed/saml/login?TARGET=http(s)://we

b-server-host.target-domain/protected-resourc

Assertion Retrieval/SOAP Binding Service URL https:// itahpi14.testeurope1.bmwgroup.com/

FIM/sps/samlfed/saml/soap

Artifact Receiver Service URL https:// itahpi14.testeurope1.bmwgroup.com/

FIM/sps/samlfed/saml/login

Tabelle 6: SSO-Einstellungen IBM FIM

Der Inter-Site Transfer Service (ISX) befindet sich auf der Seite des IdPs. Er ist verantwortlich für die Initiierung des SAML Single Sign-On-Prozesses. Die Funktionsweise ist folgendermaßen:

1. Ein bereits authentifizierter Nutzer klickt auf einen Link (z.B. auf der IdP Portal-Webseite), um den ISX-Dienst zu starten.

2. Der Webbrowser des Nutzers übergibt dem Dienst folgende Daten: ● Benutzerinformationen (wie z.B. User ID) in Form eines HTTP-Cookies, ● Einen Parameter TARGET, der die geschützte Webseite (auf Seite des SPs)

spezifiziert, auf welche der Nutzer zugreifen will. 3. Benutzt der IdP das Browser/Artifact-Profil, so sendet der ISX-Dienst mittels des

Browsers ein SAML-Artefakt an den SP. Der Artifact Receiver Service (ARS) befindet auf der Seite des Service Providers. Dieser Dienst empfängt SAML-Artefakte von Identity Providern (Browser/Artifact-Profile). Die Funktionsweise ist folgendermaßen [RSAFIM]:


80

1. Der ARS verpackt das empfange Artefakt in eine SAML-Request-Nachricht und sendet diese an den Assertion Retrieval/SOAP Binding Service des verantwortlichen IdPs.

2. Der IdP antwortet mit einer passenden SAML-Assertion (SAML-Response). 3. Der SP validiert und verarbeitet die Assertion. 4. Der Browser leitet den Benutzer auf die gewünschte Webseite beim SP um.

Der Assertion Retrieval/SOAP Binding Service befindet sich beim Identity Provider. Dieser Service akzeptiert SAML-Requests und antwortet darauf mit passenden SAML-Response-Nachrichten (enthalten SAML-Assertions) [RSAFIM]. Sowohl der Assertion Retrieval/SOAP Binding Service als auch der Artifact Receiver Service wird über einen URL angesprochen. Beim Aufbau einer vertrauenswürdigen Identitätsföderation muss eine Vielzahl von Informationen zwischen einem IdP und einem SP ausgetauscht und synchronisiert werden. Die nachfolgenden Aufzählungen geben einen Überblick über diesen Informationsaustausch. Ein Identity Provider muss allen seinen vertrauenswürdigen Service Providern folgende Einstellungen mitteilen:

• Issuer ID – Eindeutiger Identifier eines IdPs, welcher innerhalb einer SAML-Assertion an den SP geschickt wird. Kennt ein SP die Issuer ID eines IdPs nicht, so werden SAML-Assertions, welche von diesem IdP ausgestellt wurden, als nicht vertrauenswürdig abgelehnt.

• Assertion Retrieval/SOAP Binding Service URL – siehe oben • SOAP Connection Type – Art der Authentifizierung, die von einem IdP verwendet

wird, um seinen SOAP Binding Service zu schützen (z.B. Basic Authentication). • Source ID – Die SourceID wird benötigt, wenn das Browser/Artifact-Profil eingesetzt

wird. Diese eindeutige ID (Base 64- oder Hexadezimal-Format) verweist auf den SOAP Binding Service URL eines IdPs. Durch diese ID weiß der SP, wohin er seinen SAML-Request schicken soll.

• Subject Name Qualifier – Jeder IdP mit einer Authentifizierungsautorität muss den SP den Wert des Subject Name Qualifiers mitteilen, welchen er in allen SAML <Subject>-Elementen verwendetet.

Ein Service Provider muss den Identity Providern, welchen er vertrauen will, folgende Daten übermitteln:

• Artifact Receiver Service URL – siehe oben. • Recipient Identifier URI (optional) – Ein SP vergleicht diesen URI mit der

Empfänger-URI, die ihm von einem IdP innerhalb einer Assertion geschickt wird.


81

• Audience Identifier URI (optional) – Dieser URI wird vom SP mit der Liste der ''Audiences'' verglichen, die ihm innerhalb einer SAML-Assertion vom IdP geschickt wurden.

Bezüglich folgender Informationen bzw. Einstellungen müssen sich beide Parteien einigen:

• SAML Version – Festlegung der zu verwendenden SAML Version. • Profile Type – Festlegung, auf welchem SAML-Profil die Föderation basieren soll. • Subject Namespace – Namensraum, der für alle Subjekte innerhalb einer SAML-

Assertion verwendet werden soll. • Subject/Name-Identifier Format – URI-Referenz, die für das Attribut Format

innerhalb der Elemente <saml:NameIdentifier> einer SAML-Assertion verwendet werden soll (z.B. urn:oasis:names:tc:SAML:1.0:assertion#X509Subject Name).

Das SAML 1.0/1.1 Browser Artifact Profil (BAP) benötigt einen sog. Back-Channel zwischen Identity und Service Provider. Über diesen Kanal werden SAML-Request- und korrespondierende SAML-Response-Nachrichten verschickt. Da SAML 1.0/1.1-Anfragen (SAML-Requests) nicht signiert werden können, wird eine Schutzmaßnahme auf der Transportebene benötigt, d.h., ein IdP muss eine eingehenden SAML-Request-Nachricht (SOAP über HTTP(S)) authentifizieren, bevor er diese verarbeiten kann. Die meisten föderierten Sicherheitslösungen bieten zwei unterschiedliche Möglichkeiten zur Authentifizierung eines Service Providers beim SOAP Endpoint (SOAP Binding Service URL) eines Identity Providers:

● Basic Authentication – Authentifizierung mittels einer UserID und einem Passwort. Bei dem Versuch eines SPs, auf den SOAP Binding Service eines IdPs zuzugreifen, sendet der Webserver des IdPs einen ''401 Authentication Required Header'' als Antwort auf die Anfrage. Der SP muss daraufhin Nutzernamen und Passwort zurücksenden, um Zugriff auf den Dienst des IdPs zu erhalten.

● Client-Zertifikat – Authentifizierung mittels eines Client-Zertifikats (z.B. X.509 Client- Certificate). Ein SP sendet ein Zertifikat an den IdP, um auf dessen SOAP Binding Service URL zuzugreifen. Damit die Authentifizierung erfolgreich sein kann, muss der IdP dem Zertifikat des Service Providers vertrauen.

Kapitel 4: Anwendungsfälle

82

4. Anwendungsfälle für ein föderiertes Identitätsmanagement In diesem Kapitel werden SAML-Anwendungsfälle definiert, die in einer komplexen föderierten Identitätsumgebung unterstützt werden sollten. Diese Use Cases sollen auf die Systemarchitektur angewendet werden, welche in Kapitel 3 vorgestellt wurde. Ziel ist es, anhand dieser Anwendungsfälle zu testen, inwieweit die Sicherheitslösungen der verschiedenen Hersteller bei der Föderierung von Identitäten interoperabel sind. Die tatsächliche Anwendung und Analyse der hier definierten Use-Cases wird in Kapitel 5 detailliert beschrieben. Jeder einzelne hier beschriebene Testfall soll für jede mögliche Kombination der verwendeten Sicherheits-Softwaresysteme durchgeführt werden. Da jedes dieser drei Softwaresysteme sowohl als Identity Provider als auch als Service Provider eingesetzt werden kann, ergeben sich für jeden Testfall sechs mögliche Kombinationen. Alle hier beschrieben Anwendungsfälle beziehen sich auf das SAML Browser/Artifact-Profil. Eine Kommunikation über das SAML Browser/POST-Profil wurde nicht geprüft, da dieses vom Netegrity Siteminder 6.0 SP1 nicht unterstützt wird [NeteFed]. 4.1 Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Die SAML-basierte Föderierte Authentifizierung erfolgt durch den domänenübergreifenden Austausch von Nutzeridentitäten. Dazu müssen Authentication-Assertions ausgetauscht werden. Dies ermöglicht die Umsetzung eines Federated Single Sign-On Szenarios. Abbildung 21 zeigt den vollständigen Ablauf dieses Anwendungsfalls.

Abbildung 21: Ablauf Föderierte Authentifizierung/Föderiertes Single Sign-On

Benutzer Identity Provider Service Provider

Authentifizierung (z.B. Passwort)

Zugriff Inter-Site Transfer URL

HTTP-Redirect

HTTP-GET-Request (Parameter SAMLArt & TARGET)

Generierung einer SAML Auth.-Assertion + SAML

Artefakt

SAML-Request

SAML-Reponse

Gewährung bzw. Verweigerung des Zugriffs auf die gewünschte Ressource

SOAP Binding Service

Inter-Site Transfer Service


83

Um den SSO-Prozess einzuleiten, ruft der Benutzer zunächst eine Webseite beim Identity Provider auf, um sich dort zu authentifizieren. Die Authentifizierung erfolgt mittels einer geeigneten Authentifizierungsmethode (z.B. Username und Passwort). Anschließend wird beim IdP der lokale ISX-Dienst aufgerufen. Für eine erfolgreiche Unterstützung dieses Testfalls müssen die zu testenden Sicherheitsprodukte folgende Schritte implementieren [FIM]: Schritt 1: Aufbau des SAML-Artefakts Der Aufbau des SAML-Artefakts hat den Vorgaben aus [SAMLBind] Abschnitt 4.1.1.8 zu genügen. Bei einem fehlerhaften Aufbau des Artefakts sollte auf Seite des Service Providers eine Fehlermeldung erfolgen, da das Artefakt nicht korrekt verarbeitet werden kann. Ist der Artefakt entsprechend den Vorgaben der SAML-Spezifikation gültig, so gilt der Test als bestanden. Schritt 2: Übertragung des generierten SAML-Artefakts an den Service Provider Der Inter-Site Transfer-Dienst beim Identity Provider muss das generierte SAML-Artefakt an den Service Provider mittels HTTP-Redirect übertragen. Für die weitere Übertragung der Informationen vom Browser des Nutzers zum Artifact Receiver Service beim Service Provider muss ein HTTP-GET-Request verwendet werden. Dieser muss folgende Elemente enthalten:

● Das Ziel des Requests muss auf den URL des Artifact Receiver Services zeigen. ● Der Parameter SAMLArt muss das generierte SAML-Artefakt enthalten ● Der Parameter TARGET muss auf die gewünschte (geschützte) Ressource beim Service

Provider verweisen. ● Der SourceID-Teil des übermittelten Artefakts muss der konfigurierten SourceID beim

IdP entsprechen. Der Test ist erfolgreich, wenn der Service Provider alle obigen Informationen erfolgreich empfängt und das erhaltene SourceID-Element eindeutig einem vertrauenswürdigen IdP zugeordnet werden kann. Schritt 3: Anfordern der SAML-Assertion Um die korrespondierende SAML-Assertion zu erhalten, muss der SP das empfangene Artefakt an den durch die SourceID spezifizierten Identity Provider zurücksenden. Hierfür sendet der SP eine Anfrage in Form eines SAML-Requests (SOAP over HTTP) an den IdP. Um eine Konformität zur OASIS SAML-Spezifikation zu gewährleisten, muss der SAML-Request folgende Elemente bzw. Attribute enthalten (vgl. Kapitel 2.4.3.3):

● RequestID


84

● MajorVersion ● MinorVersion ● IssueInstant ● <saml:AssertionArtifact>-Element mit dem Wert des übergebenen SAML-

Artefakts Fehlt eines der obigen Elemente im SAML-Request, werden fehlerhafte Werte verwendet oder ist der Zeitpunkt (IssueInstant) nicht im UTC-Format (Universal Coordinated Time) [SAMLProt], so muss der Test als nicht bestanden betrachtet werden. Das gleiche gilt, wenn trotz korrekt übertragener Elemente eine Fehlermeldung beim IdP ausgelöst wird. In diesem Fall ist davon auszugehen, dass die SAML-Implementierung des verwendeten Sicherheitsprodukts nicht konform zur SAML-Spezifikation ist. Schritt 4: Übertragung der SAML-Assertion Empfängt ein IdP einen SAML-Request von einem vertrauenswürdigen SP und ist der darin enthaltene SAML-Artefakt zum ersten Mal benutzt worden (one-time-use), so muss der IdP die Anfrage mit einer SAML-Response beantworten. Diese Antwort muss gemäß der SAML-Spezifikation unbedingt folgende Elemente enthalten (vgl. Kapitel 2.4.3.3):

● ResponseID ● MajorVersion ● MinorVersion ● IssueInstant ● Status

Der Test scheitert, wenn eines der Elemente fehlt bzw. fehlerhaft ist. Der Test misslingt ebenso, wenn die zuständige Software des Service Providers eine Fehlermeldung produziert, aus welchen Gründen auch immer. Schritt 5: Verarbeitung der empfangenen SAML-Assertion Zuerst muss vom Service Provider untersucht werden, ob die Syntax der empfangenen SAML-Response den Anforderungen der OASIS SAML-Spezifikation genügt. Als nächstes muss der SP den semantischen Teil der SAML-Response überprüfen. Die wichtigsten Punkte sind:

● <samlp:Status>-Element muss den Wert Success aufweisen. ● Assertion muss mindestens ein <saml:AuthenticationStatement> beinhalten.

Das AuthenticationMethod-Attribut muss dabei folgenden Wert besitzen: urn:oasis:names:tc:SAML:1.0:am:password. Dieser Wert gilt sowohl für SAML 1.0 als auch für SAML 1.1.


85

● Alle Assertions verwenden <saml:Subject>-Elemente. Folgende Anforderungen sind zu erfüllen: 1) Das <saml:NameIdentifier>-Element beinhaltet ein Format-Attribut mit dem

Wert: urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName (SAML 1.0) bzw. urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName (SAML 1.1).

2) Alle <saml:Subject>-Elemente verwenden ein NameQualifier-Attribut innerhalb des Tags <saml:NameIdentifier>.

3) Als Wert für das <saml:NameIdentifier>-Element muss ein X.509 Subjektname verwendet werden.

● Enthält die Assertion ein <saml:Subject>-Element, so muss diese auch ein <saml:SubjectConfirmation>-Element enthalten. Das darin enthaltene <saml:ConfirmationMethod>-Element muss folgenden Wert besitzen: urn:oasis:names:tc:SAML:1.0:cm:artifact-01 (SAML 1.0) bzw. urn:oasis:names:tc:

SAML:1.0:cm:artifact (SAML.1.1). Werden diese oder andere Punkte der offiziellen SAML-Spezifikation (SAML 1.0/1.1) nicht erfüllt, so muss der SP die Verarbeitung der SAML-Assertion unverzüglich abbrechen und eine entsprechende Fehlermeldung ausgeben. Werden die obigen Anforderungen hingegen erfüllt, so muss der SP die in der SAML-Assertion enthaltene Benutzeridentität (z.B. UserID) extrahieren, um diese im Anschluss auf eine lokale Identität in seinem Benutzerverzeichnis abzubilden. Dieser Vorgang wird User-Mapping genannt. Zwei Arten von Abbildungen sollten von den Softwareprodukten unterstützt werden:

● 1:1 Mapping – Abbildung eines entfernten Nutzers (gespeichert in einer Datenbank beim IdP) auf einen lokalen Nutzer (gespeichert in einer Datenbank beim SP).

● n:1 Mapping – Abbildung mehrer Benutzer beim IdP auf einen Nutzereintrag beim SP. Dieses Mapping Szenario hat den Vorteil, dass eine Gruppe von Nutzern authentifiziert werden kann, ohne das für jeden einzelnen Benutzer ein lokaler Datenbankeintrag verwaltet werden muss.

Kann der SP den in einer SAML-Assertion übergebenen entfernten Benutzer auf einen lokalen Benutzereintrag abbilden, so ist der Test erfolgreich bestanden. Schritt 6: Generierung von SSO-Cookies Damit der SSO-Vorgang erfolgreich abgeschlossen werden kann, muss der SP ein oder mehrere Session-Cookie(s) im Browser des Nutzers ablegen, damit dieser übergangslos, d.h. ohne erneute Authentifizierung, auf die geschützte Ressource zugreifen kann.


86

Der Test ist bestanden, wenn der SP die Cookies im Browser des Nutzers ablegt und diesen anschließend zur gewünschten Ressource weiterleitet. Am Ende muss der User Zugriff auf die Ressource(n) haben. 4.2 Anwendungsfall: Föderierter Attribut-Austausch Ein weiterer wichtiger Use-Case, neben Federated SSO, ist der domänenübergreifende Austausch von Nutzerattributen (wie z.B. Kontostände, Rollen etc.). Anhand dieser übertragenen Attribute eines Nutzers kann ein SP seine Dienste für den jeweiligen Benutzer personalisieren. Beim Austausch von User-Attributen unterscheidet SAML zwischen impliziter Übertragung und expliziter Nachfrage. Implizit bedeutet, dass beim IdP von Anfang an (statisch) festgelegt wird, welche Attribute an einen bestimmten SP übertragen werden sollen. Explizit heißt, dass der SP Nutzerattribute dynamisch (z.B. nach dem Erhalt einer Authentication-Assertion) beim IdP anfordern kann. Als Vorraussetzung für beide Fälle muss der Identity Provider eine Datenbank verwalten, in der die verschiedenen Nutzerattribute hinterlegt werden. Diese sollen dann auf Wunsch ausgelesen und in Form einer SAML Attribute-Assertion an den SP verschickt werden. Fall 1: Implizite Übertragung von Nutzerattributen Die implizite Übertragung von Nutzerattributen an einen Service Provider erfolgt mit Hilfe eines <saml:AttributeStatement>-Elements im Rahmen einer SAML-Assertion. Dieses Statement wird zusammen mit einem <saml:AuthenticationStatement>-Element an den Service Provider übertragen. Die Anforderungen hinsichtlich der Generierung und Übertragung dieses Statements wurden bereits im obigen Anwendungsfall “Föderierte Authentifizierung” ausführlich beschrieben. Der erste Teil des Tests ist bestanden, wenn Attributwerte SAML-konform an einen Service Provider übertragen werden können. Der zweite Teil des Tests betrifft den Empfang und die Verarbeitung der Attributwerte durch den Service Provider. Dazu muss der SP im ersten Schritt die Syntax des <saml:AttributeStatement>-Elements prüfen. Im Anschluss muss er die enthaltenen Attribute extrahieren, damit diese den internen Applikationen und Diensten zur Verfügung gestellt werden können. Der Test ist erfolgreich, wenn die Attributdaten eines Testnutzers von einer Testapplikation (z.B. Servlet oder JSP-Seite) ausgelesen und angezeigt werden können. Fall 2: Explizite Übertragung von Nutzerattributen Bei einer expliziten Nachfrage bzgl. bestimmter Attribute eines Nutzers sendet der Service Provider einen SAML Attribute-Request an den Attribut-Dienst beim IdP. Dieser Attribut-


87

Dienst besitzt Zugriffsrechte auf das gewünschte Nutzerprofil und kann Attributsanfragen eines Service Providers verarbeiten und entsprechend beantworten. Die Anfrage des SPs muss ein <samlp:AttributeQuery>-Element enthalten. Dieses muss den Regeln der SAML Protocol Spezifikation entsprechen (vgl. Kapitel 2.4.3.3). Beim IdP muss die Anfrage-Nachricht auf ihren syntaktisch korrekten Aufbau hin überprüft werden. Werden innerhalb der Anfrage explizite Namen von Attributen angegeben, so muss der IdP die korrespondierenden Werte in einer SAML Attribute-Response zurückgeben. Fehlt dagegen eine explizite Angabe von Attributsnamen, so werden alle Attribute eines Nutzers zurückgegeben, sofern die Sicherheitsregeln des IdPs ein derartiges Vorgehen erlauben. Die Antwortnachricht des IdPs enthält im erfolgreichen Fall ein <saml:AttributeStatement>-Element. Dieses enthält die gewünschten Name/Wert-Paare des Nutzers. Der Empfang und die Verarbeitung der Attributinformationen erfolgen analog zu Fall 1. Der detaillierte Ablauf dieses Anwendungsfalls wird in Abbildung 22 dargestellt. In diesem Ablaufdiagramm wird davon ausgegangen, dass der SP bereits eine SAML Authentication-Assertion vom IdP erhalten hat.

Abbildung 22: Ablauf Föderierter Attribut-Austausch (explizite Übertragung)

Können alle oben genannten Anforderungen sowohl vom IdP als auch vom SP erfüllt werden, so ist der Test erfolgreich abgeschlossen. 4.3 Anwendungsfall: Lokale Autorisierung Da unterschiedliche Benutzer meist auch unterschiedliche Berechtigungen bzgl. bestimmter Ressourcen haben, wird über eine Authentifizierung hinaus oftmals auch eine feingranulare Autorisierung benötigt. Im Federated Identity Szenario existieren mehrere Möglichkeiten, eine solche Autorisierung durchzuführen. Eine Möglichkeit ist, dass die Autorisierung direkt vom Service Provider übernommen wird (lokale Autorisierung). Die andere Möglichkeit ist eine entfernte Autorisierung durch einen IdP bzw. eine vertrauenswürdige dritte Partei. Zuerst soll der einfachere der beiden Testfälle, die lokale Autorisierung, betrachtet werden.


Generierung einer SAML Attribute-Assertion

SAML Attribute-Response


SAML Attribute-Request SOAP Binding Service

Autorisierung des Nutzers


88

In diesem Szenario liegen Policy-Daten in einem Repository beim SP, d.h., dort wird auch die Autorisierung eines Nutzers vorgenommen. Vorraussetzung zur Umsetzung dieses Use-Cases ist die Definition einer Policy, welche für die Nutzung einer Testapplikation bestimmte Zugriffsrechte erwartet (wie z.B. Kontostand des Nutzers >= 1000). Anschließend sollen verschiedene Testnutzer (mit unterschiedlichen Zugriffsattributen) definiert werden, damit eine umfassende Evaluierung dieses Anwendungsfalls möglich wird. Bezüglich der lokalen Autorisierung müssen zwei Fälle unterschieden werden: 1.Fall: 1:1 Account-Linking zwischen IdP und SP In diesem Fall werden ausgewählte Nutzer bzw. Nutzerkonten beim IdP per User-Mapping 1:1 auf eine Datenbank beim SP abgebildet. Schickt nun der IdP eine Nutzeridentität innerhalb einer SAML-Assertion an den SP, so kann dieser die übergebene Identität auf eine entsprechende lokale Identität innerhalb der eigenen Datenbank abbilden. Die Daten dieses lokalen Benutzerkontos können anschließend zur Autorisierung verwendet werden. Der Test ist erfolgreich, wenn der SP mit Hilfe eines lokalen Nutzerprofils und einer vorher festgelegten Policy eine Autorisierung bzgl. einer Testapplikation durchführen kann. 2.Fall: Übertragung von Autorisierungsinformationen an den SP Wie im ersten Fall, führt auch hier der SP die Autorisierung durch, jedoch mit dem Unterschied, dass diesmal die Zugriffsrechte bzw. das Nutzerprofil eines Nutzers nicht beim SP, sondern ausschließlich beim IdP in gespeicherter Form vorliegen. Damit der SP dennoch eine Autorisierungsentscheidung treffen kann, müssen die Zugriffsrechte eines Benutzers vom IdP an den SP übertragen werden. SAML erlaubt die Übertragung von Autorisierungsinformationen im Rahmen von <saml:AttributeStatement>-Elementen (siehe Kapitel 4.2). Die Daten innerhalb eines <saml:AttributeStatement> müssen als Name/Wert-Paar ausdrückbar sein. Der Testfall ist erfolgreich, wenn der SP die Attribute aus der erhaltenen SAML-Assertion verwenden kann, um einen Testnutzer auf Basis einer vorhandenen Policy bzgl. einer bestimmten Ressource zu autorisieren.

4.4 Anwendungsfall: Entfernte (Remote) Autorisierung In diesem Testszenario befindet sich der Policy Decision Point entweder direkt beim Identity Provider oder bei einer vertrauenswürdigen dritten Partei (z.B. Kreditkarteninstitut). Dort wird entschieden, ob ein Benutzer ausreichende Berechtigungen hat, um auf die gewünschte Ressource beim SP zuzugreifen. Da SAML keine Möglichkeit bietet, Policyinformationen bei einem SP abzufragen bzw. diese an einen entfernten Policy Decision Point zu übertragen, muss sich in diesem Fall das Policy-Repository beim IdP bzw. bei einer vertrauenswürdigen dritten Stelle befinden. Diese Form der Autorisierung wird als entfernte (Remote) Autorisierung bezeichnet.


89

Hinsichtlich der entfernten Autorisierung müssen wieder zwei Fälle unterschieden werden: 1.Fall: Statische Übertragung von Autorisierungsinformationen an den SP Beim Aufruf von Ressourcen eines SPs wird direkt beim IdP überprüft, ob der Nutzer hierzu berechtigt ist. Das positive (Permit) bzw. negative Ergebnis (Deny) dieser Überprüfung wird in ein <saml:AuthorizationDecisionStatement>-Element (vgl. Kapitel 2.4.3.2) verpackt und an den Policy Enforcement Point (z.B. Webagent) des betreffenden SPs übertragen. Ist die Syntax der übermittelten SAML-Assertion korrekt, so muss der SP anhand der übergegeben Informationen entscheiden, ob der Zugriff auf die angeforderte Ressource erlaubt oder verweigert werden soll. Wird der Zugriff genehmigt, so gewährt der Policy Enforcement Point dem Browser des Nutzers Zugriff auf die gewünschte Ressource. Wird der Zugriff hingegen verweigert, so erfolgt die negative Antwort in Form einer HTTP-Statusmeldung. Diese beiden Möglichkeiten müssen mit entsprechenden Eingabedaten getestet werden, um das Verhalten des jeweiligen Policy Enforcement Points überprüfen zu können 2.Fall: Dynamische Anforderung von Autorisierungsinformationen Dieses Szenario ist vor allem dann interessant, wenn neben einem IdP und mehreren SP eine vertrauenswürdige dritte Partei hinzukommt, die unterschiedliche Autorisierungsfunktionen wahrnehmen soll. Dazu muss der SP nach der Authentifizierung eines Benutzers eine Autorisierungsanfrage (SAML Authorization-Request) an diese vertrauenswürdige Partei schicken. Der übermittelte SAML-Request enthält dabei ein <saml:AuthorizationDecisionQuery>-Element (vgl. Kapitel 2.4.3.3). Damit die vertrauenswürdige dritte Partei eine Entscheidung treffen kann, werden die übermittelten Autorisierungsdaten anhand vorhandener Policies geprüft. Das Ergebnis wird, wie auch schon im 1.Fall, in ein <saml:AuthorizationDecisionStatement> verpackt und in Form einer SAML-Response-Nachricht an den SP geschickt. Der Test ist erfolgreich, wenn der SP eine Autorisierungsanfrage (SAML Authorization-Request) erstellen bzw. verschicken kann und diese geeignet mit einer Autorisierungsentscheidung (SAML Authorization-Response) beantwortet wird. Ähnlich zum 1.Fall soll dieser Use Case wieder mittels unterschiedlicher Eingabedaten geprüft werden. Der detaillierte Ablauf dieses Anwendungsfalls wird in Abbildung 23 dargestellt. In diesem Ablaufdiagramm wird davon ausgegangen, dass der SP bereits eine SAML Authentification-Assertion vom IdP erhalten hat.


90

Abbildung 23: Ablauf Entfernte Autorisierung (dynamisch)

4.5 Anwendungsfall: Föderiertes Single Logout Ziel dieses Anwendungsfalls ist ein globaler Logout auf allen besuchten Systemen. Hierzu muss beim SP ein Benachrichtigungssystem (engl. Notification System) vorhanden sein, welches den IdP über den Logout eines Nutzers informiert. Um einen globalen Logout durchführen zu können, muss sich der IdP alle die SP merken, bei denen der betreffende Nutzer eine aktive Session (Cookie) unterhält. Bekommt ein IdP von einem SP den Befehl zum Logout eines Nutzers, so werden alle aktiven Sessions des Nutzers beendet. Obwohl SAML 1.0/1.1 kein Single Logout-Protokoll spezifiziert, soll getestet werden, ob dieser Use Case dennoch durch die verwendeten Softwaresysteme unterstützt wird. Der Test besteht aus zwei Teilen:

● Ein SP muss den zuständigen IdP mittels einer Nachricht über den Logout eines Nutzers informieren können.

● Ein IdP muss auf Anfrage eines Benutzers all seine bestehenden Browser-Sitzungen beenden.

Der Test ist erfolgreich, wenn nach dem Logout eines Testnutzers all seine aktiven Sessions durch den verantwortlichen IdP beendet werden.


SOAP Binding Service

SAML Authorization -Request

Generierung einer SAML Authorization-Assertion

Autorisierung des Nutzers

SAML Authorization-Response


Kapitel 5: Umsetzung und Analyse

91

5. Umsetzung und Analyse Dieses Kapitel widmet sich der Umsetzung und der Analyse der in Kapitel 4 definierten Anwendungsfälle. Diese Use-Cases wurden auf die in Kapitel 3.5 vorgestellte föderierte Systemumgebung angewendet. Die Testergebnisse der Untersuchungen sollen zeigen, inwieweit die verwendeten Produkte bzgl. des föderierten Austauschs von Identitäten untereinander interoperabel sind. Für auftretende Probleme während der Tests werden im Rahmen dieser Diplomarbeit Lösungsvorschläge erbracht und - wenn möglich - werden diese auch gleich umgesetzt bzw. implementiert. Das Endergebnis der Interoperablitätsbetrachtungen soll Unternehmen wie der BMW AG zum einen Aufschluss über den Aufwand geben, der nötig ist, um eine föderierte Identitätsumgebung mit Partnerunternehmen aufzubauen und zum anderen soll festgestellt werden, inwieweit eine Föderierung von Identitäten beim Einsatz von heterogenen Softwaresystemen überhaupt möglich ist. Als Szenario für die Testphase wurde – basierend auf dem Browser/Artifact-Profil - das SAML IdP-Site-First Szenario verwendet. In diesem generischen Webszenario loggt sich ein Benutzer auf einer Portalseite ein, um sich zu authentifizieren. Diese wird vom IdP geschützt. Anschließend greift der Nutzer - mittels eines Inter-Site Transfer URLs (Link auf der Portalseite) - auf eine geschützte Demo-Webapplikation der SP-Seite zu. Der Ablauf gestaltet sich folgendermaßen (vgl. Abb. 21 in Kapitel 4):

1. Ein unauthentifizierter Nutzer besucht mit einem Browser seiner Wahl die IdP-Portalseite.

2. Der Nutzer wird von der Authentifizierungsautorität des IdPs aufgefordert, sich zu authentifizieren. Die erforderlichen Benutzerdaten speichert der IdP in einem User-Verzeichnis oder in einer User-Datenbank.

3. Nach der erfolgreichen Authentifizierung klickt der Benutzer auf den gewünschten Inter-Site Transfer URL (Link auf der Portalseite), um auf eine geschützte Webapplikation eines SPs zuzugreifen.

4. Die SAML-Autorität des IdPs erstellt eine SAML-Assertion und einen zugehörigen Artefakt für den Benutzer.

5. Das Artefakt wird mit Hilfe des Browsers an den Artifact Receiver Service des SPs geschickt.

6. Der SP verpackt das übermittelte SAML-Artefakt in eine SAML-Request-Nachricht und schickt diese an den SOAP Binding Service des IdPs.

7. Der IdP übergibt die gewünschte SAML-Assertion an den SP. 8. Der SP extrahiert die Nutzerdaten aus der SAML-Assertion und speichert eine Reihe

von Session-Cookies im Browser des Benutzers. 9. Der Benutzer erhält Zugriff auf die Ressource beim SP.


92

Zwischen IdP und SP werden in den Testszenarios jeweils folgende Nutzerdaten ausgetauscht:

1. Benutzer Admin: a. uid: admin b. businesscategory: gold

2. Benutzer JDoe a. uid:jdoe b. businesscategory: bronze

Diese Nutzerkonten müssen in den nachfolgenden Interoperabilitätstests auf SAML-Subjekte abgebildet bzw. aus denselbigen extrahiert werden. Die Mapping-Funktion darf dabei durch einen beliebigen Algorithmus ausgeführt werden. Für die Tests, die im Rahmen dieser Diplomarbeit stattfinden, sollen X.509 Subjektnamen verwendet werden. Diese müssen mit dem Relative Distinguished Name (RDN) uid beginnen (z.B. uid=admin). Die folgenden Unterpunkte zeigen die Ergebnisse der durchgeführten Interoperabilitätstests. Da außerhalb der eigentlichen Testreihe noch das Szenario “Netegrity Siteminder 6.0 (IdP) – Netegrity SAML Affiliate Agent 6.0 (SP)” aufgenommen wurde, existieren anstatt der im vorherigen Kapitel angekündigten sechs nun sieben Kombinationen, die geprüft und analysiert werden mussten. 5.1 Testszenario Netegrity Siteminder 6.0 (IdP) – SAML Affiliate Agent 6.x QMR2 (SP) Auf der Seite des Identity Providers (Host: itacpi29.testeurope1.bmwgroup.com) existierte eine vollständige Siteminder 6.0 SP1 Installation. Auf der Seite des Service Providers (Host: itacpi09.testeurope1.bmwgroup.com) befand sich ausschließlich ein SAML Affiliate Agent 6.x QMR2 (d.h. kein Netegrity Policy Server o.ä.). 5.1.1 Konfiguration der Testumgebung Der SAML Affiliate Agent (vgl. Kapitel 3.1.2) unterstützt ausschließlich den SAML 1.0 Standard. SAML 1.1 wird in der Version 6.x QMR2 nicht unterstützt. Deshalb erfolgte der Austausch von SAML-Assertions in dieser Testumgebung auf Basis von SAML 1.0. In Tabelle 7 wird detailliert aufgeschlüsselt, welche Teile der SAML-Standards vom Netegrity Siteminder bzw. SAML Affiliate Agent verwendet bzw. unterstützt werden.

Siteminder 6.0 SP1 SAML Affiliate Agent 6.x QMR2

Syntax SAML 1.0 Ja Ja

Syntax SAML 1.1 Ja Nein


93

SAML BAP (Browser Artifact Profile) Ja Ja

SAML BPP (Browser Post Profile) Nein Nein

SAML SOAP over HTTP Binding Ja Ja

SAML Authentication Request Ja Ja

SAML Authentication Response Ja Nein

SAML Attribute Request Nein Nein

SAML Attribute Response Nein Nein

SAML Authorization Request Nein Nein

SAML Authorization Response Nein Nein

Tabelle 7: SAML-Features Netegrity Siteminder vs. SAML Affiliate Agent

Tabelle 8 zeigt Einstellungen der Testumgebung, welche verwendet wurden, um eine funktionierende Identity Federation zwischen dem SP (SAML Affiliate Agent) und dem IdP (Netegrity Siteminder) zu erreichen.

Hostadresse SP itacpi09.testeurope1.bmwgroup.com

Hostadresse IdP itacpi29.testeurope1.bmwgroup.com

SSL Interceptor Root URL https://itacpi09.testeurope1.bmwgroup.com:443/smafa/amts/test1.htm

Portal Query Root URL http://itacpi29.testeurope1.bmwgroup.com:80/siteminderagent/smprofile.ccc

SOAP Binding Service URL https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/assertionretriever

IdP Portal Website URL http://itacpi29.testeurope1.bmwgroup.com/protected/portal.html

SP Demo Website URL http://itacpi09.testeurope1.bmwgroup.com/affiliate.asp

BAP SourceID (Hex) b818452610a0ea431bff69dd346aeeff83128b6a

Issuer http://www.netegrity.com/SiteMinder

Subject Name Qualifier www.netegrity.com

Tabelle 8: Einstellungen Netegrity Siteminder & SAML Affiliate Agent

Der SOAP Binding Service URL des Netegrity Siteminders wurde durch die Authentifizierungsmethode Basic Authentication geschützt. Ein Schutz des URLs auf Basis von Client-Zertifikaten war nicht möglich. 5.1.2 Test der Anwendungsfälle Computer Associates bietet mit dem SAML Affiliate Agent eine einfache Möglichkeit, in Verbindung mit dem Netegrity Siteminder Softwareprodukt (Policy Server + Webagent) eine Federated Single Sign-On Umgebung aufzubauen. Ob neben SSO auch weitere Use-Cases unterstützt werden, soll dieses Kapitel zeigen.


94

Tabelle 9 zeigt die untersuchten Anwendungsfälle und die jeweilige Unterstützung durch den SAML Affiliate Agent im Überblick. Eine genaue Analyse der einzelnen Use-Cases folgt im Anschluss.

Use Cases Erfolgreich getestet

Föderierte Authentifizierung/Föderiertes Single Sign-On Ja

Föderierter Attribut-Austausch Ja

Lokale Autorisierung Nein

Entfernte (Remote) Autorisierung Nein

Föderierter Single Logout Ja

Tabelle 9:Testergebnisse - Netegrity Siteminder (IdP) & SAML Affiliate Agent (SP)

Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Wie zu erwarten war, wird dieser Use-Case vom SAML Affiliate Agent unterstützt. Der Authentifizierungsprozess wurde vom Siteminder-Produkt (IdP) übernommen. Dort wurden auch die SAML Authentication-Assertions für den Nutzer generiert und gespeichert. Auf Anfrage (SAML-Request) wurden diese Assertions an den SAML Affiliate Agent geschickt. Dort wurde geprüft, ob die übermittelte SAML-Assertion von einem vertrauenswürdigen IdP ausgestellt wurde. Am Ende des SSO-Vorgangs wurde sowohl vom Netegrity Siteminder als auch vom SAML Affiliate Agent ein Session-Cookie erstellt und im Browser des Nutzers gespeichert. Der Testfall „Föderierte Authentifizierung/Föderiertes Single Sign-On“ wurde erfolgreich getestet, d.h., alle in Kapitel 4.1 definierten Schritte konnten in dieser Testumgebung erfolgreich umgesetzt werden. Trotz der erfolgreichen Umsetzung des Anwendungsfalls muss an dieser Stelle jedoch bemerkt werden, dass die von der SAML-Autorität des Netegrity Siteminders ausgestellten SAML-Assertions nicht vollständig konform zum offiziellen OASIS SAML-Standard waren. Ein konkretes Beispiel für einen SAML-Request (erstellt vom SAML Affiliate Agent) und eine daraufhin übermittelte SAML-Response Nachricht (erstellt vom Siteminder Assertion Generator) befindet sich im Anhang A.3.1 dieser Diplomarbeit. Anwendungsfall: Föderierter Attribut-Austausch Ein föderierter Austausch von Attributen ist mit dem SAML Affiliate Agent 6.x QMR2 und dem Netegrity Siteminder 6.0 SP1 generell möglich. Potentielle Attribute wurden vom Assertion-Generator des Netegrity Siteminder Produkts in ein <saml:AttributeStatement>-Element verpackt und im Rahmen einer SAML Authentication-Assertion an den SAML Affiliate Agent verschickt (vgl. Kapitel 4.2 Fall 1). Die Generierung von eigenständigen SAML Attribute-Response Nachrichten wird momentan


95

von der Siteminder SAML-Autorität nicht unterstützt. Aus diesem Grund war es dem SAML Affiliate Agent nicht möglich, Attribute vom IdP dynamisch anzufordern, d.h., SAML Attribute-Requests bzw. SAML Attribute-Responses wurden in diesem Testszenario nicht unterstützt. Der 2. Fall des Use-Cases „Föderierter Attributaustausch“ (vgl. Kapitel 4.2) konnte deshalb nicht umgesetzt werden. Aus diesem Grund musste die SAML-Autorität des Netegrity Siteminders stets von vornherein wissen, welche Attribute einem SAML Affiliate Agent zugestellt werden sollten. Schickte die Netegrity SAML-Autorität Attribute in einer Attribute-Assertion an den SAML Affiliate Agent, so extrahierte dieser die vorhanden Attribut/Wert-Paare und stellte sie seinen Webapplikationen (hier: affiliate.asp) zur Verfügung. Die übertragenen Attribute konnten vom SAML Affiliate Agent entweder in Form von Header-Variablen oder innerhalb von Cookies den Anwendungen zur Verfügung gestellt werden. In der verwendeten Testumgebung wurde der beschriebene Anwendungsfall getestet, indem das Attribut businesscategory für den Nutzer Admin bzw. JDoe erfolgreich innerhalb einer SAML-Assertion an den SAML Affiliate Agent übermittelt werden konnte (siehe Anhang A.3.1). Der Wert des Attributs konnte von der Testapplikation affiliate.asp angezeigt werden. Anwendungsfall: Lokale Autorisierung Eine lokale Autorisierung auf Basis von 1:1 Account Linking (vgl. Kapitel 4.3 1.Fall) oder auf Basis von übermittelten Attributen (vgl. Kapitel 4.3 2.Fall) wurde vom SAML Affiliate Agent nicht unterstützt, da der Agent keine Möglichkeit zur Autorisierung bot. Anwendungsfall: Entfernte (Remote) Autorisierung Da das aktuelle Netegrity Siteminder Produkt (Version 6.0 SP1) weder SAML Authorization- Assertion-Requests (<saml:AuthorizationDecisionQuery>) noch entsprechende Responses (<saml:AuthorizationDecisionStatement>) unterstützt, war eine entfernte Autorisierung in Verbindung mit dem SAML Affiliate Agent nicht möglich, d.h., weder eine statische Übertragung (vgl. Kapitel 4.4 1.Fall) noch eine dynamische Anforderung (vgl. Kapitel 4.4 2.Fall) von Autorisierungsinformationen konnten in dieser Testumgebung realisiert werden. Anwendungsfall: Föderiertes Single Logout Single Logout wird in der Version 6.x QMR2 des SAML Affiliate Agents unterstützt. Möglich ist dies durch das Shared-Session-Model des Netegrity Siteminders. Dieses Modell erstellt eine zentrale Session für einen Nutzer und speichert diese auf der Seite des IdPs. Dabei kann der Affiliate Agent mit dem IdP interagieren, um festzustellen, ob die aktuelle Session noch gültig ist oder ob sie terminiert werden soll. Dabei überprüft der SAML Affiliate Agent periodisch, ob die Session auf der Seite des IdPs noch aktiv ist.


96

Das Shared Session Modell ermöglicht ein Single Logout für zwei Fälle:

• Ein Nutzer hat die Möglichkeit, sich aktiv von jeder Affiliate- (SP) oder Portal-Site (IdP) auszuloggen. Loggt sich ein User an einer Affiliate-Site aus, so wird dem IdP dies sofort (per XML-Nachricht) mitgeteilt. Dieser beendet die Shared-Session des Benutzers. Dies entspricht einem sofortigen globalen Logout. Hat ein Nutzer während seiner gültigen Session verschiedene Affiliate-Sites besucht, so gilt dieser Logout für alle besuchten SP.

• Ein Nutzer kann aufgrund einer aktiven Session solange auf Ressourcen der Affiliate- und Portal-Seite zugreifen bis der Wert MaxTimeoutEnabled (konfigurierbar beim IdP) überschritten wurde. Danach wird der Nutzer automatisch ausgeloggt.

Jedes Mal, wenn der Affiliate Agent (SP) überprüft, ob noch eine aktive Session besteht, erneuert der Netegrity Siteminder (IdP) den Zeitstempel beim Portal. Dadurch wird verhindert, dass dieser automatisch ausgeloggt wird.

Die Tests konnten für beide Fälle erfolgreich durchgeführt werden. 5.1.3 Fazit Computer Associates bietet mit dem SAML Affiliate Agent eine einfache Möglichkeit, in Verbindung mit dem Netegrity Siteminder Softwareprodukt (Policy Server + Webagent) eine Federated Single Sign-On Umgebung aufzubauen. Der SAML Affiliate Agent kann jedoch nur auf der Seite des SPs eingesetzt werden, da der Agent keine Möglichkeit zur Authentifizierung bzw. Autorisierung von Nutzern anbietet. Ein sicherlich großer Vorteil des SAML Affiliate Agents ist die relativ einfache Installation und Konfiguration. Partner können sich somit - ohne großen Aufwand - mit einem Unternehmen, welches als IdP fungiert, verbinden. Die Daten, die bei der Installation bzw. Konfiguration benötigt werden, müssen im Wesentlichen von der Seite des IdPs geliefert werden. Deswegen mussten die meisten Probleme, die während der Tests mit dem SAML Affiliate Agent auftraten, auf der Seite des IdPs (Netegrity Siteminder 6.0 SP1) gelöst werden. Ein weiterer Vorteil des SAML Affiliate Agents ist die Unterstützung eines föderierten Single Logouts. Dieser Use-Case wird momentan nur von wenigen anderen Access/Identity-Management-Software Herstellern unterstützt. Einem umfassenden Einsatz des SAML Affiliate Agents steht jedoch die fehlende Kompatibilität zu Softwareprodukten anderer Hersteller im Wege, d.h., der Affiliate Agent kann ausschließlich mit dem hauseigenen Produkt Siteminder verbunden werden. Hier wäre es sicherlich sinnvoll, wenn Computer Associates in kommenden Versionen eine allgemeinere Schnittstelle definieren würde, damit eine Federated Identity Umgebung auch mit Produkten anderer Hersteller umgesetzt werden kann. Ein weiteres Problem ergibt sich, wenn ein SAML Affiliate Agent mehreren IdP den Zugriff auf eine oder mehrere gleiche Ressourcen gewähren soll. Um dies zu erreichen, müssten die Ressourcen dupliziert bzw. in vielfacher Ausfertigung gespeichert werden, da der Zugriff auf


97

eine bestimmte Ressource in der XML-Datei AffiliateConfig.xml stets nur einem bestimmten IdP zugeordnet werden kann. In zukünftigen Versionen des SAML Affiliate Agents wäre es deshalb wünschenswert, wenn gleiche Ressourcenadressen auch mehreren IdPs zugeordnet werden können. Ein weiterer Fortschritt wäre sicherlich auch eine Unterstützung von SAML Authorization- Assertions. Dadurch könnte der Anwendungsfall „Entfernte Autorisierung” umgesetzt werden. Dazu müsste jedoch auch das Netegrity Siteminder Produkt Authorization-Assertions unterstützen. Dies ist im Moment jedoch nicht der Fall.

Trotz dieser Probleme bietet der SAML Affiliate Agent eine einfache Möglichkeit für Unternehmen, schnell und effizient eine sichere Web Single Sign-On Umgebung mit Partnerunternehmen aufzubauen. Für komplexe föderierte Identitätsumgebungen, die über ein SSO hinausgehen, ist der SAML Affiliate Agent jedoch nicht zu empfehlen. 5.2 Testszenario Netegrity Siteminder 6.0 (IdP) – RSA Cleartrust 5.5 & FIM 2.5 (SP) Auf Identity Provider Seite (Host: itacpi29.testeurope1.bmwgroup.com) existierte nach wie vor eine vollständige Siteminder 6.0 SP1 Installation. Auf der Service Provider Seite (Host: itacpi09.testeurope1.bmwgroup.com) befand sich diesmal eine Installation des RSA Cleartrusts 5.5 und des RSA Federated Identity Managers 2.5. 5.2.1 Konfiguration der Testumgebung Der Austausch von SAML-Assertions basierte anfangs auf SAML 1.1. Da jedoch während der Tests Probleme mit dieser Version aufgetreten sind, wurde die Kommunikation auf SAML 1.0 umgestellt.

In Tabelle 10 wird wieder detailliert aufgeschlüsselt, welche Teile der SAML-Standards vom Netegrity Siteminder 6.0 SP1 bzw. RSA Federated Identity Manager 2.5 verwendet bzw. unterstützt werden.

Siteminder 6.0 SP1 Federated Identity Manager 2.5




SAML BPP (Browser Post Profile) Nein Ja



SAML Authentication Response Ja Ja

SAML Attribute Request Nein Ja

SAML Attribute Response Nein Ja



98


Tabelle 10: SAML-Features Netegrity Siteminder vs. RSA FIM

Tabelle 11 zeigt Einstellungen der Testumgebung „Netegrity Siteminder – RSA Federated Identity Manager“.



Artifact Receiver Service URL http://itacpi09.testeurope1.bmwgroup.com:7001/samlrelyingparty/RP



SP Demo Website URL http://itacpi09.testeurope1.bmwgroup.com/protected.php



Subject Name Qualifier http://www.netegrity.com/SiteMinder

Tabelle 11: Einstellungen Netegrity Siteminder & RSA FIM

Der SOAP Binding Service wurde durch den Authentifizierungstyp Basic Authentication geschützt. Ein Schutz des URLs auf Basis von Client-Zertifikaten wäre jedoch auch möglich gewesen. 5.2.2 Test der Anwendungsfälle In dieser Testumgebung wurde der Netegrity Siteminder 6.0 SP1 als Identity Provider und RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5 als Service Provider eingesetzt. Tabelle 12 zeigt einen Überblick bzgl. der Testergebnisse.




Lokale Autorisierung Ja


Föderierter Single Logout Nein

Tabelle 12: Testergebnisse – Netegrity Siteminder (IdP) & RSA FIM (SP)


99

Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Dieser Anwendungsfall konnte letztendlich erfolgreich umgesetzt werden. Dazu musste eine Vielzahl aufgetretender Probleme gelöst werden. Dies umfasste unter anderem die Konzeption und die Implementierung eines Java-Plugins. Dieses musste in den Assertion-Generator des Netegrity Siteminders integriert werden.

Die Bemühungen, die nötig waren, damit dieser Use Case erfolgreich umgesetzt werden konnte, werden im Folgenden detailliert erläutert. Dazu soll die Umsetzung des Testfalls Schritt für Schritt analysiert werden (vgl. Kapitel 4.1): Schritt 1: Aufbau des SAML-Artefakts Das SAML-Artefakt (generiert vom Netegrity Siteminder) entsprach den Anforderungen der SAML-Spezifikation. Der Test war somit erfolgreich bestanden. Schritt 2: Übertragung des generierten SAML-Artefakts an den Service Provider Der Artifact Receiver Service des RSA Federated Identity Managers empfing erfolgreich ein SAML-Artefakt (generiert und übermittelt vom Netegrity Siteminder). Darüber hinaus referenzierte der übergebene Parameter TARGET die gewünschte Ressource (http://itacpi09.testeurope1.bmwgroup.com/protected.php) beim Service Provider. Auch dieser Test war damit erfolgreich bestanden. Schritt 3: Anfordern der SAML-Assertion Die erfolgreiche Durchführung dieses Schritts erforderte die Lösung zahlreicher Probleme. Diese Probleme sollen im Folgenden beschrieben und die entsprechenden Lösungen vorgestellt werden: 1. Problem: Der SAML-Request (generiert vom RSA Federated Identity Manager) konnte

anfangs nicht erfolgreich an den Assertion Retriever/SOAP Binding Service (URL: https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/assertionretriever) übermittelt werden, da die im SAML-Request enthaltene SourceID dem IdP (Netegrity Siteminder) unbekannt war.

Lösung: Die SourceID, welche in der erschaffenen Trusted Asserting Party (innerhalb des RSA

Federated Identity Managers) konfiguriert wurde, musste dem IdP (Netegrity Siteminder) mitgeteilt werden. Dazu musste das Feld Company Source ID in der verantwortlichen Siteminder Affiliate-Konfiguration entsprechend dieser SourceID gesetzt werden.

2. Problem: Das Zeitformat des IssueInstant-Attributs (IssueInstant="2005-02-

25T11:31:56") innerhalb des übermittelten SAML-Requests konnte nicht erfolgreich


100

vom Netegrity Siteminder geparst werden. Das Siteminder Produkt stoppte den SSO-Prozess mit folgender Fehlermeldung:

java.text.ParseException: Unparseable date: "2005-02-25T11:31:56Z"

Der Grund hiefür war der Umstand, dass der Netegrity Siteminder 6.0 SP1 ein Zeitformat mit einer Genauigkeit von Millisekunden erwartete (z.B. IssueInstant="2005-02-25T11:31:56.000Z").

In der SAML-Spezifikation 1.0/1.1 ist für das Attribut IssueInstant ein UTC-Format (Typ xsd:datetime) vorgeschrieben. Dieses erlaubt sowohl eine Zeitangabe mit einer

Genauigkeit von Millisekunden (YYYYMMDD-HH:MM:SS.sss) als auch eine Zeitangabe mit einer Genauigkeit von Sekunden (YYYYMMDDHH:MM:SS). Die genaue Definition des UTC-Formats kann unter [W3CSchema] Abschnitt 3.2.7.1 eingesehen werden. Die SAML-Implementierung des Netegrity Siteminders 6.0 SP1 war damit hinsichtlich dieses Punktes nicht konform zur SAML-Spezifikation 1.0/1.1, da von diesem Produkt ausschließlich UTC-Zeitformate mit einer Genauigkeit von Millisekunden akzeptiert wurden.

Lösung: Auf Anfrage stellte die Support-Abteilung von Computer Associates das "Webagent

OptionPack 6.0 HF03" Hotfix zur Verfügung. Nach der Installation dieses Hotfixes unterstützte der Netegrity Siteminder auch UTC-Zeitformate mit einer Genauigkeit von Sekunden.

Nach der Behebung dieser beiden Probleme konnte auch dieser Testschritt erfolgreich abgeschlossen werden. Der SAML-Request (siehe Anhang A.3.2) des RSA Federated Identity Managers enthielt alle erforderlichen Elemente (inklusive SAML-Artefakt). Zudem konnte der übermittelte SAML-Artefakt erfolgreich vom Netegrity Siteminder extrahiert werden, um anschließend die SAML-Assertion für den entsprechenden Nutzer zu referenzieren. Schritt 4: Übertragung der SAML-Assertion Die SAML-Response-Nachricht des Netegrity Siteminders konnte anfangs nicht erfolgreich an den RSA Federated Identity Manager übermittelt werden, da kein sicherer SSL-Back Channel aufgebaut werden konnte. Der Grund hierfür war ein unbekanntes Zertifikat auf der Seite des RSA Federated Identity Managers. Um dieses Problem zu beheben, wurde das ROOT-Zertifikat des SPs der AM-keystore-Datei des Netegrity Siteminders hinzugefügt. Diese Datei muss alle Zertifikate der vertrauenswürdigen Partner enthalten, zu denen SSL-Verbindungen aufgebaut werden sollen. Nach dem Hinzufügen des ROOT-Zertifikats konnte der SSL-Back Channel erfolgreich etabliert und die SAML-Response-Nachricht an den SP (RSA FIM) übermittelt werden. Diese SAML-Response enthielt neben einer Authentication Assertion alle erforderlichen Attribute (vgl. Anhang A.3.2). Auch dieser Test war damit bestanden.


101

Schritt 5: Verarbeitung der empfangenen SAML-Assertion Die erfolgreiche Umsetzung dieses Schrittes erforderte einen erheblichen Aufwand. Es ergaben sich folgende Probleme, die gelöst werden mussten: 1. Problem: Der Wert für das Attribut ResponseID (ResponseID="10.250.23.22. 1111141685076") konnte vom SP (RSA FIM) nicht fehlerfrei geparst werden. Daraufhin wurde der SSO-Prozess vom SP mit folgender Fehlermeldung abgebrochen:

The server encountered the following unexpected condition: Error in RSA Federated Identity Manager:

Error encountered in Relying Party servlet: com.rsa.csf.common.exceptionbase.CsfApplicationException:

Error in Relying Party while processing Asserting Party response: ; nested exception is:

org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: '10.250.23.22.1111141685076' is not a valid

value for 'NCName'.

Die SAML-Spezifikation 1.1 fordert xsd:ID als Typformat für das Attribut ResponseID. Die genaue Definition für dieses Attribut kann unter [SAMLProt] Abschnitt 1.2.3 gefunden werden. Der Typ xsd:ID ist abgeleitet vom Typ xsd:NCName [RelaxSchema]:

<xsd:simpleType name="ID" id="ID">

<xsd:restriction base="xsd:NCName"/>

</xsd:simpleType>

Ein String vom Typ xsd:NCName muss mit einem Buchstaben oder einem Unterstrich ('_') beginnen. Ansonsten ist der String nicht konform bzgl. des Typs xsd:NCName [XMLName].

Diese Regel wurde jedoch - wie oben ersichtlich - vom Assertion-Generator des Netegrity Siteminders (ResponseID="10.250.23.22.1111141685076") verletzt, d.h., auch hier ist die SAML-Autorität des Netegrity Siteminders 6.0 SP1 nicht konform zur SAML Spezifikation 1.1.

Lösung: Um dieses Problem zu beheben, wurde die Kommunikation zwischen dem IdP und dem

SP auf SAML 1.0 (anstatt SAML 1.1) umgestellt. Die SAML-Spezifikation 1.0 fordert für das Attribut ResponseID anstatt xsd:ID den Typ

IDType. Die Definition ist folgendermaßen [SAMLCore10]:

<simpleType name="IDType">

<restriction base="string"/>

</simpleType>

Dieser Typ erlaubt somit auch Strings, welche mit einer Zahl statt einem Buchstaben oder Unterstrich beginnen.

2. Problem: Der Assertion-Generator des Netegrity Siteminders definiert eine Reihe von

Elementen bzw. Attributen innerhalb seiner Authentication-Assertions, die bzgl. der SAML-Spezifikation 1.0 nicht konform sind. Deshalb war die SAML-Autorität des RSA Federated Identity Managers nach wie vor nicht in der Lage, eine SAML-Assertion


102

(ausgestellt vom Netegrity Siteminder) erfolgreich zu parsen. Das RSA Produkt löste dabei folgende Fehlermeldung aus:

The server encountered the following unexpected condition: Error in RSA Federated Identity Manager:

Error encountered in Relying Party servlet: com.rsa.csf.common.exceptionbase.CsfApplicationException:

Error in Relying Party while processing Asserting Party response: ; nested exception is:

java.lang.NullPointerException

Ursache für diese Fehlermeldung war das Attribut Format innerhalb des Elements <saml:NameIdentifier>. Netegrity Siteminder übertrug für dieses Attribut folgenden ungültigen Wert: Format=''urn:oasis:names:tc:SAML:1.0:assertion".

Die SAML-Spezifikation 1.0 erlaubt jedoch nur folgende Werte [SAMLCore10 Abschnitt 2.4.2.1]:

● urn:oasis:names:tc:SAML:1.0:assertion#emailAddress ● urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName ● urn:oasis:names:tc:SAML:1.0:assertion#WindowsDomainQualifiedName

Lösung: Die Lösung dieses Problems erforderte einen erheblichen Aufwand. Es musste eigens ein

Java-Plugin (vgl. Anhang A.1) geschrieben und an den Assertion-Generator des Netegrity Siteminders angebunden werden. Dieses Plugin war in der Lage, ausgehende SAML-Assertions, welche standardmäßig von der SAML-Autorität des Netegrity Siteminders ausgestellt wurden, abzuändern, bevor diese über einen SOAP-Kanal an den Service Provider verschickt wurden. Das Plugin wurde immer dann aufgerufen, wenn eine SAML-Assertion vom Netegrity Siteminder generiert wurde. Diese Standard-Assertion wurde in Form eines Java-DOM-Baums [DOM] an das Plugin übergeben. Aus Gründen der Performanz wurde für jeden einzelnen Plugin-Aufruf ein eigener Document-Handler initialisiert.

Das selbstgeschriebene Netegrity Assertion-Generator-Plugin führte folgende Änderungen an dem übergebenen DOM-Baum durch:

● Abänderung des Attributs Format auf den OASIS-konformen Wert

''urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName''. ● Hinzufügen eines <saml:SubjectConfirmation>-Elements und eines

<saml:ConfirmationMethod>-Elements mit dem Wert ''urn:oasis:names:tc: SAML:1.0:cm:artifact-01'' [SAMLCore10 Abschnitt 2.4.2.3]. ● Abänderung des Attributs AuthenticationMethod auf den URI-Wert

''urn:oasis:names:tc:SAML:1.0:am:password''.


103

Nach der Beendigung aller oben genannten Tätigkeiten gab das Java-Plugin die geänderte SAML-Assertion als String zurück. Dieser konnte nun von der zuständigen Siteminder-Komponente über den Back-Channel an den Service Provider weitergeleitet werden.

Nach der Behebung aller bisher erwähnten Probleme (Umstellung auf SAML 1.0; Integration eines Java-Plugins) konnte der SP (RSA Cleartrust & FIM 2.5) die - in der SAML-Assertion übergebene - UserID (z.B. Admin) extrahieren und erfolgreich auf einen lokalen Datenbankeintrag abbilden (1:1 Mapping). Dieser Teilschritt konnte somit erfolgreich abgeschlossen werden. Schritt 6: Generierung von SSO-Cookies Trotz der erfolgreichen Authentifizierung des Nutzers in Schritt 5 konnte dieser nicht mit seinem Browser auf die Ressource protected.php zugreifen (Error 404). Die RSA Webagent Logdatei meldete einen Fehler bei der Validierung des erstellten SSO-Cookies. Dieses Problem konnte durch die zwei folgenden Maßnahmen behoben werden:

● Hinzufügen der Zeile "cleartrust.aserver.token_version=1" in die Konfigurationsdatei des RSA Authorization Servers. Der RSA Cleartrust 5.5 stellt - verglichen mit der Vorgängerversion - ein neues Token-Format zu Verfügung, welches standardmäßig verwendet wird. Da der verwendete RSA Webagent 2.5 dieses neue Format nicht unterstützt, musste eine Umstellung auf das alte Token-Format (Version 1) vorgenommen werden.

● Abänderung der Zeile "cleartrust.agent.cookie_ip_check=Yes" auf "cleartrust.agent.cookie_ip_check=No" innerhalb der RSA Webagent Konfigurationsdatei. In einem erstellten SSO-Cookie wird u.a. die IP-Adresse derjenigen Partei gespeichert, welche dieses Cookie generiert hat. Der RSA Webagent 2.5 überprüft nun standardmäßig, ob das erstellte SSO-Cookie von einer vertrauenswürdigen Partei ausgestellt wurde. Dazu überprüft der Webagent unter anderem auch die IP-Adresse, welche in diesem Cookie gespeichert ist. Die Support-Abteilung von RSA Security wies jedoch darauf hin, dass in manchen Systemumgebungen diese IP-Kontrolle einen Fehler bei der Validierung des erstellten SSO-Cookies auslösen kann. In diesen Fällen wird empfohlen, die IP-Überprüfung zu deaktivieren.

Nach der Durchführung dieser beiden Maßnahmen konnte das RSA SSO-Cookie erfolgreich in den Browser des Nutzers abgelegt werden. Dieser hatte damit vollen Zugriff auf die geschützte Ressource protected.php des Service Providers. Anwendungsfall: Föderierter Attribut-Austausch Basierend auf den oben genannten Lösungsansätzen konnte die implizite Übertragung von Nutzerattributen erfolgreich getestet werden. Da die standardmäßigen Attributelemente einer


104

Netegrity SAML-Assertion jedoch nicht konform zur OASIS SAML-Spezifikation waren, mussten am Java-Plugin, welches in den Netegrity Assertion-Generator integriert wurde, folgende Erweiterungen vorgenommen werden:

● Methode zur Entfernung des Attributs xmlns:SM aus dem Header einer SAML-Assertion.

● Methode zur Umwandlung aller proprietären <SM:NVpair>-Elemente (innerhalb des Tags <saml:AttributeStatement>) in OASIS-konforme Attributelemente <saml:Attribute>.

Nach der Durchführung dieser Änderungen konnten Attribute eines Nutzers - kompatibel zum SAML-Standard - in einer Attribute-Assertion (zusammen mit einer Authentification-Assertion) an den Service Provider (RSA Federated Identity Manager 2.5) übermittelt werden. Nach der Authentifizierung des Nutzers konnte die RSA SAML-Autorität die Attribute extrahieren und diese als Header-Variablen seinen Webapplikationen zur Verfügung stellen. In der verwendeten Testumgebung wurde der beschriebene Anwendungsfall getestet, indem das Attribut businesscategory für den Nutzer Admin bzw. JDoe erfolgreich innerhalb des Elements <saml:AttributeStatement> an den RSA Federated Identity Manager übermittelt werden konnte (siehe Anhang A.3.2). Dieses Attribut konnte von der Testapplikation protected.php angezeigt werden. Eine explizite Übertragung von Nutzerattributen auf Anfrage wurde in diesem Testszenario nicht unterstützt. Der RSA Federated Identity Manager bietet zwar die Möglichkeit, mittels eines SAML Attribute-Requests (enthält <saml:AttributeQuery>) eine explizite Attributanforderung an einen IdP zu stellen, jedoch wird eine solche Anfrage vom Netegrity Siteminder nicht unterstützt (vgl. 5.1.2 Anwendungsfall: Föderierter Attributaustausch). Anwendungsfall: Lokale Autorisierung Die Umsetzung dieses Testfalls war nahezu problemlos möglich. Beide Fälle (vgl. Kapitel 4.3) wurden vom RSA Produkt (RSA Cleartrust 5.5 bzw. Federated Identity Manager 2.5) erfolgreich unterstützt. Damit eine lokale Autorisierung ausgeführt werden konnte, mussten sog. SmartRules [RSAAdmin] innerhalb des RSA Cleartrust Systems definiert werden. Diese Regeln konnten verwendet werden, um einen User - anhand seiner Attribute bzw. Attributwerte - für eine Ressource zu autorisieren.

Beispiel einer SmartRule: Erlaube Zugriff, wenn das Attribut businesscategory eines Nutzers x gleich dem Wert ''Gold'' ist (businesscategory=''Gold'').

In der Testumgebung wurde genau dieses Beispiel umgesetzt. Ein Benutzer (authentifiziert beim SP mittels einer SAML-Assertion) erhält Zugriff auf die Applikation protected.php,


105

wenn dieser ein Attribut businesscategory mit dem Wert ''Gold'' besitzt. Dieser Test wurde sowohl für den Nutzer Admin (businesscategory=''Gold'') als auch für den Nutzer JDoe (businesscategory=''Bronze'') durchgeführt. Wie beabsichtigt, erhielt der Nutzer Admin Zugriff auf die Ressource protected.php. Dem Benutzer JDoe hingegen wurde der Zugriff aufgrund mangelnder Berechtigung verweigert. Der Fall ''1:1 Account-Linking zwischen IdP und SP'' wurde somit erfolgreich getestet. Wie zu Beginn bereits angekündigt, wurde auch der zweite Fall (''Übertragung von Autorisierungsinformationen an den SP'') in dieser Testumgebung unterstützt. Dazu musste das geforderte Attribut businesscategory vom Netegrity Siteminder innerhalb einer SAML Attribute-Assertion an den RSA Federated Identity Manager übertragen werden (vgl. Kapitel 5.2.2 Anwendungsfall: Föderierter Attributaustausch). Dieses übertragene Attribut wurde dann von der RSA SAML-Autorität extrahiert und der Authentifizierungsstelle des RSA Cleartrusts übergeben. Der Rest verlief analog zum Fall ''1:1 Account-Linking zwischen IdP und SP''. Anwendungsfall - Entfernte (Remote) Autorisierung Dieser Testfall konnte nicht getestet werden, da weder der Netegrity Siteminder 6.0 SP1 noch der RSA Federated Identity Manager 2.5 die Verwendung von Authorization-Assertions unterstützt. Im Zuge der Unterstützung von SAML 2.0 hat RSA jedoch angekündigt, den Austausch und die Anfrage von SAML Authorization-Assertions in der nächsten Version des Federated Identity Managers zu ermöglichen. Anwendungsfall: Föderiertes Single Logout Der Netegrity Siteminder unterstützt den Testfall Single Logout ausschließlich in Kombination mit dem hauseigenen Produkt SAML Affiliate Agent. Ein Single Logout in Verbindung mit dem RSA Produkt war somit - bei Einsatz des SAML-Protokolls - nicht möglich. Eine Möglichkeit, diesen Use Case dennoch umzusetzen, wäre der Umstieg auf das Liberty ID-FF Protokoll (anstatt SAML 1.0/1.1). Der Einsatz dieses Protokolls wurde jedoch im Rahmen dieser Diplomarbeit nicht getestet, da dieses von der aktuellen Version des RSA FIM 2.5 nicht unterstützt wird. 5.2.3 Fazit Wie die obige Analyse der einzelnen Anwendungsfälle zeigt, ist eine Interoperabilität zwischen den Produkten Netegrity Siteminder 6.0 SP1 und dem RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5 zu weiten Teilen gegeben (3 von 5 Testfällen werden unterstützt). Es hat sich jedoch gezeigt, dass dies nicht, wie oft von den Softwareherstellern behauptet, ohne Probleme und Aufwand möglich war. Als Hauptquelle für die aufgetretenen Probleme konnte ganz klar der Netegrity Siteminder 6.0 SP1 ausgemacht werden. Besonders


106

problematisch war dabei die unausgereifte SAML-Autorität dieses Produkts. Im Laufe der Tests konnten zahlreiche Inkompatibilitäten bzgl. der OASIS SAML-Standards festgestellt werden. Um diese Fehlerquellen zu beseitigen, war teilweise ein erheblicher Aufwand nötig (wie z.B. die Integration eines umfangreichen Java-Plugins in den Assertion Generator des Netegrity Siteminders). Im Vergleich dazu hat der RSA Federated Identity Manager 2.5 in diesem Testszenario nur wenige Probleme bereitet. Zudem bot das RSA Produkt mit der Definition von SmartRules eine einfache Möglichkeit, entfernte Benutzer, deren Identität innerhalb einer SAML-Assertion übertragen wurde, feingranular - basierend auf Nutzerattributen - zu autorisieren. 5.3 Testszenario Netegrity Siteminder 6.0 (IdP) – IBM TAM 5.1 & TFIM 6.0 (SP) Wie in den beiden vorangegangenen Testszenarios fungierte der Netegrity Siteminder 6.0 SP1 auch hier als Identity Provider (Host: itacpi29.testeurope1.bmwgroup.com). Als Service Provider wurden diesmal die IBM Produkte Tivoli Access Manager 5.1 und Tivoli Federated Identity Manager 6.0 (Beta) eingesetzt (Host: itahpi14.testeurope1.bmwgroup.com). 5.3.1 Konfiguration der Testumgebung Die Beta-Version des Tivoli Federated Identity Managers 6.0 unterstützt momentan ausschließlich SAML 1.0. Aus diesem Grund musste der SAML 1.0 Standard als Basis für das vorliegende Testszenario verwendet werden. Die SAML-Autorität des Identity Providers (Netegrity Siteminder) wurde dementsprechend konfiguriert. In Tabelle 13 werden wie gewohnt die SAML-Fähigkeiten der beiden verwendeten Produkte gegenübergestellt, um gemeinsame Schnittmengen erkennen zu können.

Siteminder 6.0 SP1 IBM Tivoli FIM 6.0




SAML BPP (Browser Post Profile) Nein Ja








Tabelle 13: SAML-Features Netegrity Siteminder vs. IBM TFIM


107

Tabelle 14 zeigt die verwendeten Einstellungen bzgl. der Testumgebung „Netegrity Siteminder – IBM TFIM“.

Hostadresse SP itahpi14.testeurope1.bmwgroup.com


Artifact Receiver Service URL https://itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/login



SP Demo Website URL http://itacpi14.testeurope1.bmwgroup.com/protected.jsp



Subject Name Qualifier http://www.netegrity.com/SiteMinder

Tabelle 14: Einstellungen Netegrity Siteminder & IBM TFIM

Der SOAP Binding Service URL des Netegrity Siteminders wurde durch einen Client-Zertifikat-Mechanismus geschützt. Ein Schutz dieses URLs mittels des Authentifizierungstyps Basic-Authentication war in diesem Testszenario nicht möglich. Der Tivoli Federated Identity Manager unterstützt als Service Provider ausschließlich eine Authentifizierung über Client-Zertifikate. Die Authentifizierungsmethode Basic Authentication wird nur dann unterstützt, wenn das IBM-Produkt als Identity Provider auftritt. 5.3.2 Test der Anwendungsfälle In dieser Testumgebung wurde der Netegrity Siteminder 6.0 SP1 als Identity Provider und der IBM Tivoli Access Manager 5.1 & Federated Identity Manager als Service Provider eingesetzt. Tabelle 15 zeigt einen Überblick bzgl. der Testergebnisse.

Use Cases Erfolgreich gestestet

Föderierte Authentifizierung/Föderiertes Single Sign-On Nein

Föderierter Attribut-Austausch Nein




Tabelle 15: Testergebnisse - Netegrity Siteminder (IdP) & IBM TFIM (SP)


108

Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Eine vollständige Umsetzung dieses Testfalls war nicht erfolgreich. Da alle nachfolgenden Use-Cases von diesem elementaren Anwendungsfall abhingen, konnten auch diese nicht erfolgreich getestet werden. Die Gründe hierfür werden in der folgenden Analyse detailliert dargelegt. Um die Ursachen für das Scheitern dieses Use Cases erläutern zu können, wurde der Testfall wieder Schritt für Schritt analysiert (vgl. Kapitel 4.1): Schritt 1: Aufbau des SAML-Artefakts Das SAML-Artefakt (generiert vom Netegrity Siteminder) entsprach den Anforderungen der SAML-Spezifikation. Dieser Test war somit erfolgreich bestanden. Schritt 2: Übertragung des generierten SAML-Artefakts an den Service Provider Bevor dieser Teilschritt erfolgreich gestestet werden konnte, musste ein Problem auf der Seite des Service Providers (IBM Federated Identity Manager) behoben werden. Nach der Übermittlung des SAML-Artefakts, wurde der SSO-Prozess beim SP mit folgender Fehlermeldung unterbrochen: FBTSML004E The request received an artifact with succinct ID: AAG4GEUmEKDqQxv/ad00au7/gxKLavQXWyLiWENOYGuPvq3e8kAYQd5R, which did not match a known partner identity provider.

Dies bedeutete, dass die SourceID - gewonnen aus dem übermittelten SAML-Artefakt - dem SP unbekannt war. Die Lösung dieses Problems erforderte eine manuelle Bearbeitung der Konfigurationsdatei feds.xml des TFIMs. In dieser Datei musste an entsprechender Stelle (Element <SAML.PartnerSuccinctID>) die SourceID des Identity Providers (Netegrity Siteminder) eingetragen werden. Dadurch konnte das Problem gelöst und die Übertragung des SAML-Artefakts fehlerfrei vollzogen werden. Der Artifact Receiver Service des Tivoli Federated Identity Managers empfing erfolgreich einen SAML-Artefakt (generiert und übermittelt vom Netegrity Siteminder). Darüber hinaus zeigte der übergebene Parameter TARGET auf die gewünschte Ressource (http://itahpi14.testeurope1.bmwgroup.com/protected.jsp) beim Service Provider. Auch dieser Teil des Anwendungsfalls war damit erfolgreich abgeschlossen. Schritt 3: Anfordern der SAML-Assertion Dieser Teilschritt konnte nicht erfolgreich getestet werden. Der eingehende SAML-Request wurde vom Identity Provider (Netegrity Siteminder) nicht akzeptiert. In der Logdatei affwebservices.log fand sich folgende Fehlermeldung:

Mai 18, 2005 1:42:53.235 PM[16291471:I] Here's the information on the request for the Assertion:

Mai 18, 2005 1:42:53.235 PM[16291471:I] Requesting Host: itahpi14.muc

Mai 18, 2005 1:42:53.235 PM[16291471:I] Requesting Host IP: 10.250.21.78


109

Mai 18, 2005 1:42:53.235 PM[16291471:I] Request protocol: HTTP/1.1

Mai 18, 2005 1:42:53.250 PM[16291471:E] Affiliate User Name not found. Affiliate user name could not be

retrieved from the HTTP request object.

Dieser Fehler tritt gewöhnlich dann auf, wenn die REMOTE_USER-Variable nicht korrekt beim Netegrity Siteminder gesetzt wurde. Der SP sendet einen HTTP-Authorization-Header bei dem Versuch, auf den SOAP Endpoint des Identity Providers (Netegrity Siteminder) zuzugreifen. Dieser versucht daraufhin, den REMOTE_USER Header auszulesen, um sicherzustellen, dass genau der SP die generierte SAML-Assertion erhält, für den sie bestimmt ist. Der IdP generiert die Fehlermeldung „Affiliate User Name not found“, wenn der REMOTE_USER-Header nicht ausgelesen werden kann. Auf Vorschlag der Support-Abteilung von Computer Associates wurden folgende Maßnahmen unternommen, um dieses Problem zu beseitigen: Es wurde sichergestellt, dass die Variable RemoteUserVar im entsprechenden Agent Configuration Object des Netegrity Siteminders auf Yes gesetzt war. Zusätzlich wurde überprüft, ob die Account Security Settings des verwendeten Microsoft IIS Webservers entsprechend den Vorgaben der Netegrity Siteminder Konfiguration eingestellt war. Leider konnte keiner der oben genannten Lösungsvorschläge dieses Problem beheben. Dies hatte zur Folge, dass keiner der nachfolgenden Schritte dieses Anwendungsfalls getestet werden konnte. Aus diesem Grund konnte eine Zusammenarbeit der verwendeten Softwareprodukte für diesen Testfall nicht verifiziert werden. Anwendungsfall: Föderierter Attribut-Austausch Da es nicht gelang, SAML-Assertions zwischen den verwendeten Sicherheitslösungen auszutauschen, konnte dieser Anwendungsfall nicht getestet werden. Dass ein föderierter Austausch von Attributen jedoch theoretisch möglich ist, zeigt das Testszenario „Netegrity Siteminder 6.0 SP1 (IdP) – RSA Cleartrust 5.5 & RSA FIM 2.5 (SP)“ (siehe Kapitel 5.2.2). Anwendungsfall : Lokale Autorisierung Aus denselben Gründen wie beim obigen Anwendungsfall konnten auch hier keine Tests durchgeführt werden. Wie die Versuche in Kapitel 5.5 zeigen, ist der IBM Federated Identity Manager jedoch potentiell in der Lage, diesen Testfall vollständig zu unterstützen. Dies bedingt jedoch einen erfolgreichen Austausch von SAML-Assertions. Anwendungsfall : Entfernte (Remote) Autorisierung Unabhängig von dem bisherigen Testverlauf wird eine entfernte Autorisierung in dieser Systemumgebung nicht unterstützt, da sowohl der Netegrity Siteminder als auch der Tivoli Federated Identity Manager keine Möglichkeit bieten, Authorization-Assertions bzw. entsprechende Anfragen auszutauschen.


110

Anwendungsfall : Föderierter Single Logout Analog zum Testszenario „Netegrity Siteminder 6.0 SP1 (IdP) – RSA Cleartrust 5.5 & RSA FIM 2.5“ (vgl. Kapitel 5.2.2). 5.3.3 Fazit Wie die obige Analyse zeigt, konnte eine Interoperabilität zwischen den Produkten Netegrity Siteminder und IBM Tivoli Access Manager bzw. Tivoli Federated Manager im Rahmen dieser Diplomarbeit nicht bestätigt werden. Keiner der in Kapitel 4 definierten Use-Cases konnte in der Umgebung erfolgreich umgesetzt werden. Dieses Ergebnis soll jedoch keinesfalls implizieren, dass die verwendeten Produkte keinen der Anwendungsfälle in ihrer SAML-Implementierung unterstützen. Die hier durchgeführten Tests sollen lediglich zeigen, dass eine föderierte Zusammenarbeit zwischen dem CA- und dem IBM-Produkt aufgrund eines ungelösten Problems (siehe Kapitel 5.2.2 Anwendungsfall „Föderierte Authentifizierung/Föderiertes Single-Sign-On“) nicht erfolgreich umgesetzt werden konnte. Falls dieses Problem behoben werden kann (z.B. durch die Bereitstellung eines Hotfixes für den Netegrity Siteminder), besteht jedoch die berechtigte Hoffnung, dass eine Interoperabilität zwischen den Produkten bzgl. der Mehrzahl der vorgestellten Use-Cases erreicht werden kann. Trotzdem wird ein erfolgreicher Austausch von SAML-Assertions aller Voraussicht nach nur unter Zuhilfenahme des in Kapitel 5.2.2 entworfenen Netegrity Assertion-Generator-Plugins (vgl. Kapitel 5.2.2) möglich sein. 5.4 Testszenario RSA Cleartrust 5.5 & FIM 2.5 (IdP) – Netegrity Siteminder 6.0 (SP) In diesem Szenario wurde das Produkt RSA Cleartrust 5.5 & FIM 2.5 als Identity Provider eingesetzt (Host: itacpi09.testeurope1.bmwgroup.com). Auf der Seite des Service Providers befand sich eine komplette Netegrity Siteminder 6.0 SP1 Installation (Host: itacpi29.testeurope1.bmwgroup.com). 5.4.1 Konfiguration der Testumgebung Aufgrund der Probleme mit SAML 1.1 in den vorangegangenen Tests (vgl. Kapitel 5.2), wurde auch hier SAML 1.0 als Austauschformat für die Kommunikation zwischen den beiden Parteien festgelegt.

Federated Identity Manager 2.5 Siteminder 6.0 SP1




SAML BPP (Browser Post Profile) Ja Ja


111




SAML Attribute Request Ja Nein

SAML Attribute Response Ja Nein



Tabelle 16: SAML-Features RSA FIM vs. Netegrity Siteminder

Tabelle 17 zeigt die wichtigsten Einstellungen für die föderierte Testumgebung „RSA Cleartrust & FIM (IdP) – Netegrity Siteminder (SP)“.



Artifact Receiver Service URL https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/public/samlcc

SOAP Binding Service URL http://itacpi09.testeurope1.bmwgroup.com:7001/samlassertingparty/services/Sam

lRequest


SP Demo Website URL http://itacpi29.testeurope1.bmwgroup.com/protected.asp

BAP SourceID (Hex) ba4a61beb309a7152f38292d188b855602582295

Issuer _2fedf960dc60d9134f9161d88e0bc03d9a413e77

Subject Name Qualifier www.rsa.com

Tabelle 17: Einstellungen RSA FIM & Netegrity Siteminder

Der SOAP Binding Service URL des RSA Federated Identity Managers wurde durch den Authentifizierungstyp Basic Authentication geschützt. Ein Schutz des URLs auf Basis von Client-Zertifikaten wäre jedoch auch möglich gewesen. 5.4.2 Test der Anwendungsfälle

In dieser Testumgebung wurde der RSA Cleartrust 5.5 in Kombination mit dem RSA Federated Identity Manager 2.5 als Identity Provider und der Netegrity Siteminder 6.0 SP1 als Service Provider eingesetzt. Tabelle 18 zeigt einen Überblick bzgl. der ermittelten Testergebnisse.

Use Cases Erfolgreich gestestet



112





Tabelle 18: Testergebnisse - RSA FIM (IdP) & Netegrity Siteminder (SP)

Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Ähnlich dem vorangegangen Testszenario (vgl. Kapitel 5.3) konnte auch hier der primäre Anwendungsfall „Föderierte Authentifizierung/Föderiertes Single Sign-On“ nicht erfolgreich getestet werden. Da alle anderen nachfolgenden Use Cases von diesem elementaren Anwendungsfall abhängen, konnten auch diese nicht umgesetzt werden. Die Ursachen für das Scheitern wird im folgenden dargelegt. Dazu werden die Schritte (vgl. Kapitel 4.1), die nötig sind, um den kompletten Testfall erfolgreich umzusetzen, einzeln analysiert: Schritt 1: Aufbau des SAML-Artefakts Dieser Teilschritt konnte erfolgreich getestet werden. Nach dem Aufruf des Inter-Site Transfer URLs wurde das SAML-Artefakt (generiert vom RSA Federated Identity Manager) an den Service Provider übermittelt. Dieses Artefakt entsprach den Anforderungen der SAML-Spezifikation 1.0. Schritt 2: Übertragung des generierten SAML-Artefakts an den Service Provider Die Übertragung des SAML-Artefakts und des TARGET-Parameters an den Artifact Receiver URL des Netegrity Siteminders war ohne Probleme möglich. Des Weiteren konnte die SourceID (enthalten im SAML-Artefakt) dem entsprechenden IdP erfolgreich zugeordnet werden. Schritt 3: Anfordern der SAML-Assertion Das in Schritt 2 übertragene SAML-Artefakt wurde erfolgreich - verpackt in einen SAML-Request - an den Assertion Retriever/SOAP Binding Service URL des RSA Federated Identity Managers gesendet. Dieser SAML-Request war vollständig konform zur OASIS SAML-Spezifikation 1.0 (vgl. Anhang A.3.3). Alle Anforderungen dieses Teilschrittes wurden somit erfüllt. Schritt 4: Übertragung der SAML-Assertion Der erhaltene SAML-Request wurde von der SAML-Autorität des RSA Federated Identity Managers mit einer SAML-Assertion- bzw. SAML-Response-Nachricht geeignet beantwortet. Diese wurde über den aufgebauten SOAP Back-Channel an den Netegrity Siteminder erfolgreich übermittelt. Die empfangene SAML-Response-Nachricht (vgl. Anhang A.3.3) enthielt dabei alle erforderlichen Elemente und Attribute.


113

Schritt 5: Verarbeitung der empfangenen SAML-Assertion Bei der Verarbeitung der SAML-Assertion durch den Netegrity Siteminder traten mehrere Probleme auf: 1. Problem: Ähnlich dem Testszenario “Netegrity Siteminder 6.0 (IdP) – RSA Cleartrust 5.5

& FIM 2.5 (SP)” trat auch hier ein Problem mit dem übermittelten Zeitformat auf (vgl. Kapitel 5.2). Folgende Fehlermeldung wurde auf der Seite des Service Providers (Netegrity Siteminder) ausgegeben:

März 16, 2005 3:05:48.23 PM[25229676:E] SAML_ParseException occured while trying to parse the

SAML-Response received. Exception: java.text.ParseException: Unparseable date: "2005-03-

16T13:57:55Z".

März 16, 2005 3:05:48.23 PM[25229676:ASSR_RETRIEVAL_TRACE] The following assertion has been

retrieved: null

März 16, 2005 3:05:48.23 PM[25229676:E] Error occured while trying to retrieve the assertion from the

SAML producer site.

März 16, 2005 3:05:48.23 PM[25229676:I] Ending the request processing with the HTTP response code:

500

Lösung: Die Ursache und die Lösung dieses Fehlers werden in Kapitel 5.2.2 ausführlich

beschrieben.

2. Problem: Obwohl die übermittelte SAML-Response-Nachricht des RSA-Produkts konform zur SAML-Spezifikation 1.0 war, konnte die zuständige Komponente des Netegrity Siteminders das XML-Dokument nicht erfolgreich parsen. Die Logdatei affwebservices.log des Netegrity Siteminders enthielt dabei folgende Fehlermeldung:

März 18, 2005 11:07:52.185 AM[14445175:E] Parsing Error: Line:1 Column:1: The markup in the

document preceding the root element must be well-formed.

März 18, 2005 11:07:52.185 AM[14445175:ASSR_RETRIEVAL_TRACE] The following assertion has

been retrieved: null

März 18, 2005 11:07:52.185 AM[14445175:I] Ending the request processing with the HTTP response

code: 500

Die SAML-Response-Nachricht begann mit dem syntaktisch korrektem Tag <?xml

version="1.0" encoding="UTF-8" ?>. Die obige Fehlermeldung legt die Vermutung nahe, dass die zuständige Komponente des Netegrity Siteminders 6.0 SP1 nicht in der Lage war, dieses Element erfolgreich zu parsen bzw. zu verarbeiten. Bei einem Vergleich der übermittelten SAML-Response Nachricht (ausgestellt vom RSA FIM) mit einer SAML-Response Nachricht (ausgestellt vom Netegrity Siteminder) fällt auf, dass die SAML-Response-Nachricht von Netegrity kein Anfangselement <?xml…?> beinhaltet.

Ein Lösungsansatz wäre demnach eine Entfernung dieses Elements auf der Seite des RSA Federated Identity Managers. Ähnlich wie beim Netegrity Siteminder wird auch hier die Möglichkeit angeboten, ein eigenes Java-Plugin zu integrieren. Da mit einem solchen


114

Plugin jedoch ausschließlich die Elemente bzw. Attribute einer SAML-Assertion, nicht jedoch das Anfangselement <?xml…?> bearbeitet werden konnten, war es unmöglich, diesen Ansatz umzusetzen.

Die Durchführung dieses und aller nachfolgenden Teilschritte schlug demnach fehl. Ein erfolgreicher Test des SSO-Prozesses war damit nicht möglich.

Anwendungsfall: Föderierter Attribut-Austausch Aufgrund des Scheiterns des vorangegangenen Anwendungsfalls konnte dieser Testfall nicht getestet werden. Für den Fall, dass die Hersteller (allem voran Computer Associates) eine Lösung (z.B. Hotfix) für das obige Problem anbieten, ist mit sehr großer Wahrscheinlichkeit davon auszugehen, dass der föderierte Austausch von Attributen zwischen den Produkten von RSA und CA kein Problem darstellen wird. Anwendungsfall : Lokale Autorisierung Obwohl dieser Anwendungsfall nicht getestet wurde (siehe obige Begründung), ist der Netegrity Siteminder - vorausgesetzt der SSO-Prozess mit dem RSA Produkt funktioniert - in der Lage, eine lokale Autorisierung eines entfernten Benutzers vorzunehmen. Sowohl eine lokale Autorisierung über ein 1:1 Account-Linking als auch eine lokale Autorisierung mittels übertragener Autorisierungsinformationen (innerhalb einem <saml:AttributeStatement>) ist potentiell möglich. Anwendungsfall : Entfernte (Remote) Autorisierung Dieser Testfall wird, unabhängig von den bisherigen Ergebnissen, nicht unterstützt. Die Begründung ist analog dem Testszenario „Netegrity Siteminder 6.0 SP1 (IdP) – RSA Cleartrust 5.5 & FIM 2.5 (SP)“ (vgl. Kapitel 5.2.2). Anwendungsfall : Föderierter Single Logout Analog zum gleichnamigen Anwendungsfall in Kapitel 5.2.2. 5.4.3 Fazit Die vorangegangen Testszenarios, an denen der Netegrity Siteminder als Identity Provider beteiligt war, ließen vermuten, dass dieses Produkt auch in der Funktion eines Service Providers bzgl. der Interoperabilität mit den anderen Produkten nicht gut abschneiden würde. Dieses Testszenario zeigt, dass alle Befürchtungen in diese Richtung berechtigt waren. Obwohl die von der SAML-Autorität des RSA Federated Identity Managers ausgestellten SAML-Nachrichten vollständig konform zur OASIS SAML-Spezifikation 1.0 waren, kam es


115

zu erheblichen Parsing-Problemen auf der Seite des Netegrity Siteminders. Die Interoperablität zwischen dem RSA Federated Identity Manager 2.5 (IdP) und dem Netegrity Siteminder 6.0 (SP) konnte damit für keinen der Anwendungsfälle bestätigt werden. 5.5 Testszenario RSA Cleartrust 5.5 & FIM 2.5 (IdP)–IBM TAM 5.1 & TFIM 6.0 (SP) Der RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5 fungierte als Identity Provider (Host: itacpi09.testeurope1.bmwgroup.com) und das Produkt IBM Tivoli Access Manager 5.1 und Tivoli Federated Identity Manager 6.0 übernahm die Funktion des Service Providers (Host: itahpi14.testeurope1.bmwgroup.com). 5.5.1 Konfiguration der Testumgebung Der domänenübergreifende Austausch von Identitätsinformationen erfolgte auch in dieser Testumgebung über Assertions der SAML-Version 1.0. Der Standard SAML 1.1 wird von der Beta-Version des Tivoli Federated Identity Managers 6.0 momentan nicht unterstützt. Tabelle 19 vergleicht - analog zu den vorangegangenen Testszenarios - die jeweiligen SAML-Fähigkeiten der beiden verwendeten Sicherheitslösungen.

RSA FIM 2.5 IBM TFIM 6.0




SAML BPP (Browser Post Profile) Ja Ja




SAML Attribute Request Ja Nein

SAML Attribute Response Ja Nein



Tabelle 19: SAML-Features RSA FIM vs. IBM TFIM

Tabelle 20 zeigt Einstellungen der Testumgebung „RSA Cleartrust & RSA FIM – IBM TAM & IBM TFIM“.



Artifact Receiver Service URL https:// itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/login


116

SOAP Binding Service URL http://itacpi09.testeurope1.bmwgroup.com:7001/samlassertingparty/services/Sam

lRequest


SP Demo Website URL http://itahpi14.testeurope1.bmwgroup.com/protected.jsp


Issuer _2fedf960dc60d9134f9161d88e0bc03d9a413e77

Subject Name Qualifier www.rsa.com

Tabelle 20: Einstellungen RSA FIM & IBM TFIM

Die Absicherung des SOAP Binding Services basierte auf der Übermittlung eines Client-Zertifikats durch den beteiligten SP. Ein Schutz dieses Dienstes auf Basis von Basic Authentication war in diesem Testszenario nicht möglich. 5.5.2 Test der Anwendungsfälle Der RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5 wurde als Identity Provider und der IBM Tivoli Access Manager 5.1 & IBM Tivoli Federated Identity Manager 6.0 als Service Provider konfiguriert. Tabelle 21 zeigt einen Überblick bzgl. der ermittelten Testergebnisse.







Tabelle 21: Testergebnisse - RSA FIM (IdP) & IBM TFIM (SP)

Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Dieser Anwendungsfall konnte erfolgreich getestet werden. Alle Probleme, die während der Umsetzung dieses Testfalls aufgetreten sind, konnten ohne große Schwierigkeiten behoben werden. Die Bemühungen, die nötig waren, damit dieser Use Case erfolgreich umgesetzt werden konnte, werden im Folgenden detailliert erläutert. Dazu soll die Umsetzung des Testfalls Schritt für Schritt analysiert werden (vgl. Kapitel 4.1):


117

Schritt 1: Aufbau des SAML-Artefakts Das SAML-Artefakt (generiert vom RSA Federated Identity Manager) genügte – wie auch schon im vorangegangenen Testszenario – allen Anforderungen der SAML-Spezifikation. Der erste Schritt im SSO-Prozess war somit erfolgreich bestanden. Schritt 2: Übertragung des generierten SAML-Artefakts an den Service Provider Das in Schritt 1 generierte SAML-Artefakt wurde erfolgreich – durch einen Aufruf des Inter-Site Transfer Services - an den SP (IBM TFIM 6.0) übermittelt. Der TARGET-Parameter zeigte auf die gewünschte Ressource (http://itahpi14.testeurope1.bmwgroup.com/protected .jsp) beim Service Provider. Schritt 3: Anfordern der SAML-Assertion Mit Hilfe der entsprechenden SourceID konnte der SP einen SAML-Request an den SOAP Binding Service des Identity Providers schicken. Dieser SAML-Request war konform zum OASIS SAML-Standard 1.0. Innerhalb des Tags <saml:AssertionArtifact> wurde das SAML-Artefakt (vgl. Schritt 2) übertragen. Schritt 4: Übertragung der SAML-Assertion Bevor dieser Teilschritt erfolgreich umgesetzt werden konnte, musste ein Problem behoben werden. Nach dem Empfang des SAML-Requests durch den RSA Federated Identity Manager wurde von diesem folgender Fehler ausgelöst:

Error 500 - Internal Server Error The server encountered the following unexpected condition: Error in RSA

Federated Identity Manager: ; nested exception is: com.rsa.csf.techservice.saml.opensaml.SAMLException:

SAML-Requester error: null (wrapped: Invalid SAML-Request: SAML-Request IssueInstant is too far in the

future to be valid)

Der SAML-Request konnte vom Identity Provider nicht verarbeitet werden, da der Ausstellungszeitpunkt der Anfrage, im Vergleich zur lokalen Systemzeit des Servers, in der Zukunft lag. Zur Lösung dieses Problems mussten die Systemzeiten der beiden beteiligten Testserver synchronisiert werden. Nach dieser Maßnahme konnten SAML Authentication-Assertions an den Service Provider erfolgreich übermittelt werden. Schritt 5: Verarbeitung der empfangenen SAML-Assertion Die übertragene SAML-Assertion war konform zur SAML-Spezifikation 1.0 und konnte ohne Probleme vom IBM Tivoli Access Manager bzw. Tivoli Federated Identity Manager geparst und verarbeitet werden. Im ersten Schritt wurde die empfangene SAML-Assertion an die Trust-Service Komponente des TFIM-Produkts übergeben. Dort wurden die Nutzerdaten extrahiert und auf einen lokalen Nutzer abgebildet (1:1 Mapping). Die Umsetzung dieses Teilschrittes war damit erfolgreich.


118

Schritt 6: Generierung von SSO-Cookies Nach der erfolgreichen Authentifizierung des (entfernten) Benutzers wurden die benötigten SSO-Cookies im Browser des Benutzers abgelegt. Der SSO-Prozess konnte damit für dieses Testszenario erfolgreich abgeschlossen werden. Der Nutzer war – ohne erneute Authentifizierung – berechtigt, auf die Ressource http://itahpi14.testeurope1.bmwgroup.com/ protected.jsp des Service Providers zuzugreifen. Anwendungsfall: Föderierter Attribut-Austausch Die Umsetzung einer impliziten Übertragung von Nutzerattributen (<saml:AttributeStatement> innerhalb einer SAML Attribute-Assertion) konnte erfolgreich getestet werden. Eine explizite Übertragung von Attributen auf Anfrage war indes nicht möglich, da der Tivoli Identity Manager 6.0 keine Attributanfragen in Form eines <saml:AttributeQuery>-Elements unterstützt. Eine implizite Übertragung wurde in der vorliegenden Testumgebung sowohl für den Benutzer mit UserID Admin als auch für den Benutzer mit UserID JDoe getestet. Beide Male wurde das Attribut businesscategory - jeweils mit unterschiedlichen Werten - an den Service Provider übertragen. Die erhaltenen Werte wurden vom Tivoli Federated Identity Manager extrahiert und vom WebSeal Reverse Proxy innerhalb eines HTTP-Headers an die geschützte Webapplikation protected.jsp weitergereicht. Dort konnten die Attributwerte ausgelesen und auf der Webseite angezeigt werden. Anwendungsfall: Lokale Autorisierung Die Umsetzung dieses Testfalls war mit etwas Aufwand möglich. Beide Fälle (vgl. Kapitel 4.3) wurden erfolgreich vom IBM Produkt (IBM TAM 5.1 & IBM TFIM 6.0) unterstützt. Damit eine lokale Autorisierung durchführt werden konnte, mussten Access Manager Authorization-Rules [AMAdmin Kapitel 12] definiert werden. Diese Authorization-Rules basieren – ähnlich wie die SmartRules des RSA Cleartrusts 5.5 – auf Boolescher Logik. Zur Auswertung dieser Regeln wurden bestimmte Access-Decision-Informations (ADI) [AMWebseal] verwendet. Diese Informationen (z.B. Attribute) konnten aus den Profilen der Testnutzer gewonnen werden. Eine lokale Autorisierung, basierend auf 1:1 Account Linking zwischen IdP und SP (vgl. Kapitel 4.3), war dadurch möglich. Wurden jedoch Autorisierungsinformationen verwendet, die in Form von Attributen innerhalb einer SAML-Assertion vom IdP an den SP übertragen wurden, so war der Ablauf etwas komplexer. In der Testumgebung wurde eine entfernte Autorisierung der Testnutzer (UserID Admin bzw. JDoe) auf Basis des Attributs businesscategory durchgeführt. Dazu musste eine Authorization-Rule definiert werden. Diese Regel erlaubte den Zugriff auf die Ressource protected.jsp für den Fall, dass der anfragende Nutzer ein Attribut businesscategory mit dem Wert „Gold“ besaß. Bei anderen Werten wurde der Zugriff hingegen verweigert.


119

Der Ablauf der lokalen Autorisierung durch den IBM TAM 5.1 in Verbindung mit einem WebSeal Reverse Proxy wird in Abb. 24 gezeigt. Anhand dieses Autorisierungsablaufs wird deutlich, dass sich die Architektur des IBM Tivoli Access Managers 5.1 grundlegend von der Architektur des RSA Cleartrust-Systems (vgl. Kapitel 5.2.2) unterscheidet.

Abbildung 24: Lokale Autorisierung durch den IBM TAM 5.1

1. Der WebSeal Reverse Proxy empfing eine SAML-Assertion von einem Benutzer bzw. Identity Provider. Diese SAML-Assertion enthielt eine UserID (<saml:NameIdentifier>) und ein Attribut businesscategory (<saml:AttributeAttributeName="businesscategory">).

2. Diese SAML-Assertion wurde an die Trust Service Komponente des Tivoli Federated Identity Managers übergeben.

3. Der Trust Service erstellte aus den Daten der SAML-Assertion (UserID, Attribute etc.) ein Access Manager Credential (Nutzer-Profil). Das Attribut businesscategory wurde dabei der Attributliste (xattrlist) des Access Manager Credentials hinzugefügt.

4. Das Access Manager Credential wurde an den WebSeal Reverse Proxy übergeben und dort gespeichert.

5. Der Benutzer wurde nach einer erfolgreichen Authentifizierung auf die geschützte Ressource protected.jsp umgeleitet.

6. Der Webseal Reverse Proxy rief die Authorization-Engine auf und übergab dieser das gespeicherte Nutzer-Profil (Access Manager Credential).

7. Die Authorization-Engine extrahierte die benötigten Access-Decision-Informations (hier: Attribut businesscategory) aus dem übergeben Nutzer-Profil, um die vorhandene

Auswertung einer Authorization-Rule (7)

Zugriff auf die Resource erlauben bzw. verweigern (9)

Benutzer WebSeal Reverse Proxy

Trust Service Authorization- Engine

Übergabe der SAML-Assertion (2)

Erstellung eines Access Manager Credentials (3)

Übergabe des AM Credentials (4)

HTTP-Redirect (5)

Aufruf & Übergabe des AM Credentials (6)

Übergabe von Access_Allowed bzw. Access_Denied (8)

SAML-Assertion vom IdP (1)


120

Authorization-Rule auszuwerten. 8. Die Authorization-Engine übergab daraufhin Access_Allowed bzw. Access_Denied an

den WebSeal Reverse Proxy. 9. Der WebSeal gewährte bzw. verweigerte den Zugriff auf die Webapplikation

protected.jsp. Der oben beschriebene Ablauf wurde sowohl für den Benutzer Admin (businesscategory= ''Gold'') als auch für den Benutzer JDoe (businesscategory=''Bronze'') durchgeführt. Wie zu erwarten war, wurde dem Nutzer Admin der Zugriff auf die Ressource protected.jsp gestattet. Dem Nutzer JDoe hingegen wurde der Zugang auf die Ressource aufgrund mangelnder Berechtigung verwehrt. Damit konnte dieser Testfall erfolgreich abgeschlossen werden. Anwendungsfall: Entfernte (Remote) Autorisierung Eine entfernte Autorisierung wurde sowohl vom RSA Federated Identity Manager 2.5 als auch vom IBM Tivoli Federated Identity Manager 6.0 nicht unterstützt (vgl. Kapitel 5.3.2 bzw. 5.4.2). Anwendungsfall: Föderiertes Single Logout Dieser Anwendungsfall wurde in Verbindung mit SAML 1.0 ebenfalls nicht unterstützt. 5.5.3 Fazit

In drei der fünf getesteten Anwendungsfälle konnte eine Interoperabilität zwischen dem RSA- (IdP) und dem IBM-Produkt (SP) nachgewiesen werden. Alle in diesem Testszenario ausgetauschten SAML-Nachrichten (SAML-Requests bzw. SAML-Responses) waren konform zur SAML-Spezifikation 1.0. Der Aufbau einer föderierten Identitätsumgebung zwischen diesen Produkten war deshalb ohne große Probleme möglich. 5.6 Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP)–RSA Cleartrust 5.5 & FIM 2.5 (SP) In diesem Testszenario wurden die Rollen getauscht. Das Produkt IBM TAM 5.1 & TFIM 6.0 fungierte diesmal als Identity Provider (Host: itahpi14.testeurope1.bmwgroup.com). RSA Cleartrust 5.1. & FIM 2.5 übernahm die Funktion des Service Providers (Host: itacpi09.testeurope1.bmwgroup.com). 5.6.1 Konfiguration der Testumgebung Der Austausch von Identitätsinformationen basierte wie auch im vorangegangenen Testszenario auf SAML 1.0, da die SAML-Autorität des Tivoli Federated Identity Managers


121

ausschließlich SAML-Assertions dieser Version generieren konnte. Als Profil wurde wieder das Browser/Artifact-Profile verwendet.

IBM TFIM 6.0 RSA FIM 2.5


Syntax SAML 1.1 Nein Ja

SAML BAP (Browser/Artifact Profile) Ja Ja

SAML BPP (Browser/Post Profile) Ja Ja




SAML Attribute Request Nein Ja

SAML Attribute Response Nein Ja



Tabelle 22: SAML-Features IBM TFIM vs. RSA FIM

Tabelle 23 zeigt die SAML-Konfiguration der Testumgebung „IBM TAM & IBM TFIM – RSA Cleartrust & RSA FIM“.



Artifact Receiver Service URL http://itacpi09.testeurope1.bmwgroup.com:7001/samlrelyingparty/RP

SOAP Binding Service URL https:// itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/soap

IdP Portal Website URL http://itahpi14.testeurope1.bmwgroup.com/protected/portal.jsp

SP Demo Website URL http://itacpi09.testeurope1.bmwgroup.com/protected.php

BAP SourceID (Hex) 5ccd6dca73b24bc98e3076224f1c2e0394c1387a

Issuer http://itahpi14.testeurope1.bmwgroup.com

Subject Name Qualifier www.ibm.com

Tabelle 23: Einstellungen IBM TFIM & RSA FIM

Der SOAP Binding Service des Tivoli FIMs 6.0 wurde in diesem Testszenario durch die Authentifizierungsart Basic Authentication geschützt. Eine Absicherung über Client-Zertifikate wäre jedoch auch möglich gewesen.


122

5.6.2 Test der Anwendungsfälle Wie in den vorangegangenen Testszenarios wurde auch hier die Interoperabilität der beteiligten Softwareprodukte anhand von fünf Testfällen überprüft. Eine Übersicht über die erzielten Testergebnisse zeigt Tabelle 24.







Tabelle 24: Testergebnisse - IBM TFIM (IdP) & RSA FIM (SP)

Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Die Interoperablität der Produkte konnte für diesen Testfall erfolgreich getestet werden. Die Teilschritte 1-4 dieses Anwendungsfalls konnten ohne Probleme umgesetzt werden. Nach dem Aufruf des Inter-Site Transfer Service URLs und der anschließenden Übertragung des SAML-Artefakts konnte der RSA FIM erfolgreich einen SAML-Request an den Identity Provider (TFIM 6.0) schicken. Bei der Verarbeitung der daraufhin übermittelten SAML-Response-Nachricht durch den Service Provider traten jedoch zwei Fehler auf, die behoben werden mussten: 1. Problem: Die SAML-Assertion wurde vom RSA Federated Identity nicht akzeptiert, da

das Element <saml: NameIdentifier> kein Attribut mit dem Namen NameQualifier [SAMLCore10] enthielt. Obwohl die Verwendung dieses Attributs gemäß der SAML-Spezifikation optional ist, wurde dieses vom RSA Federated Identity Manager für eine erfolgreiche Authentifizierung eines entfernten Benutzers benötigt.

Lösung: Der im TFIM verwendeten XSLT Identity-Mapping-Datei musste ein sog. ''STS Universal User Attribute'' hinzugefügt werden. Die Attributliste der XSLT-Datei wurde dabei um folgenden Eintrag ergänzt:

<stsuuser:Attribute name="NameQualifier" type="urn:oasis:names:tc:SAML:1.0:assertion"> <stsuuser:Value>www.ibm.com</stsuuser:Value> </stsuuser:Attribute>

Bei der erneuten Ausstellung einer SAML-Assertion durch den TFIM 6.0 wurde dem Element <saml: NameIdentifier> ein Attribut NameQualifier mit dem Wert ''www.ibm.com'' hinzugefügt.


123

2. Problem: Die SAML-Assertion konnte weiterhin vom Service Provider nicht erfolgreich geparst werden. Der Grund hierfür war diesmal das fehlende Element <saml: ConfirmationMethod>. Dieses befindet sich gewöhnlich innerhalb des Tags <saml: SubjectConfirmation> [SAMLCore10]. Die übermittelte IBM-Assertion enthielt lediglich folgenden Abschnitt:

<saml:SubjectConfirmation> <saml:SubjectConfirmationData> urn:oasis:names:tc:SAML:1.0:cm:artifact-01 </saml:SubjectConfirmationData> </saml:SubjectConfirmation>

Dieser Abschnitt war jedoch nicht konform zur SAML-Spezifikation 1.0. Wird ein Element <saml: SubjectConfirmation> in einer Assertion verwendet, so muss dieses mindestens ein <saml: ConfirmationMethod>-Tag enthalten. Ein Vorkommen des Elements <saml:SubjectConfirmationData> ist hingegen optional.

Lösung: Die Verantwortlichkeit für diesen Bug lag beim SAML-Assertion-Token Modul des

Tivoli Federated Identity Managers. Da keine Möglichkeit bestand, an diesem Modul Veränderungen vorzunehmen, musste dieser Fehler an den zuständigen Support von IBM weitergereicht werden. Dort wurde umgehend ein Hotfix für diesen Bug erstellt. Nach der Installierung dieses Hotfixes verschwand das Problem. Die SAML-Assertions des IBM-Produkts waren damit vollständig konform zur SAML-Spezifikation 1.0.

Nach Lösung der oben geschilderten Probleme, konnte die SAML-Assertion erfolgreich vom SP verarbeitet werden. Die anschließende Generierung der SSO-Cookies durch den RSA Federated Identity Manager lief fehlerfrei ab. Anwendungsfall: Föderierter Attribut-Austausch Eine implizite Übertragung von Nutzerattributen konnte für beide Testnutzer (Admin bzw. JDoe) erfolgreich umgesetzt werden. Das Attribut businesscategory wurde dabei, wie in der SAML-Spezifikation gefordert, innerhalb des Tags <saml:AttributeStatement> an den RSA Federated Identity Manager übertragen. Dort wurden die Attribute wie gewohnt extrahiert, um diese der gewünschten Applikation (hier: protected.php) über den HTTP-Header mitzuteilen. Eine explizite Anfrage von Attributen in Form eines <saml:AttributeQuery>-Elements scheiterte am IBM TFIM. Momentan werden durch dieses Produkt keine dynamischen Attributanfragen unterstützt.


124

Anwendungsfall: Lokale Autorisierung Auch dieser Testfall konnte erfolgreich getestet werden. Die Umsetzung erfolgte analog zum gleichnamigen Anwendungsfall in Kapitel 5.2.2. Anwendungsfall: Entfernte (Remote) Autorisierung Entsprechend allen bisherigen Testszenarios konnte die entfernte Autorisierung auch hier nicht getestet werden, da keines der eingesetzten Produkte die Verwendung von Authorization-Assertions unterstützt. Anwendungsfall: Föderiertes Single Logout Analog zum gleichnamigen Anwendungsfall in Kapitel 5.5.2 5.6.3 Fazit Die Testergebnisse zeigen, dass die Produkte von IBM (IdP) bzw. RSA (SP) im Bereich Federated Identity Management weitgehend harmonieren. Eine Zusammenarbeit konnte für drei der fünf Anwendungsfälle erfolgreich getestet werden. Die SAML-Assertions - generiert von der SAML-Autorität des Tivoli Federated Identity Managers 6.0 – waren anfangs nicht vollständig konform zur OASIS SAML-Spezifikation 1.0. Diese Unzulänglichkeit konnte jedoch unverzüglich von IBM durch die Bereitstellung eines Hotfixes behoben werden. Der Aufbau einer funktionierenden föderierten Identitätsumgebung mit dem RSA Federated Identity Manager war damit möglich. Die Ergebnisse in diesem und dem vorangegangenen Testszenario zeigen, dass eine Interoperablität zwischen den beiden Produkten sowohl für die Kombination „ IBM (IdP) – RSA (SP)“ als auch für die Kombination „RSA (IdP) – IBM (SP)“ gegeben ist. 5.7 Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP) – Netegrity Siteminder 6.0 (SP) In diesem Szenario fungierte IBM TAM 5.1 & TFIM 6.0 wieder als Identity Provider (Host: itahpi14.testeurope1.bmwgroup.com). Im Gegensatz zum letzten Kapitel übernahm diesmal der Netegrity Siteminder 6.0 die Funktion des Service Providers (Host: itacpi29.testeurope1.bmwgroup.com). 5.7.1 Konfiguration der Testumgebung Der Austausch von Identitätsinformationen basierte abermals auf SAML 1.0 und dem dazugehörigen Browser/Artifact-Profile.


125

IBM TFIM 6.0 Siteminder 6.0 SP1


Syntax SAML 1.1 Nein Ja

SAML BAP (Browser/Artifact Profile) Ja Ja

SAML BPP (Browser/Post Profile) Ja Nein








Tabelle 25: SAML-Features IBM TFIM vs. Netegrity Siteminder

Tabelle 26 zeigt die Einstellungen, die vorgenommen wurden, um einen funktionierenden Austausch von SAML-Requests bzw. SAML-Responses in der Testumgebung zu gewährleisten.



Artifact Receiver Service URL https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/public/samlcc

SOAP Binding Service URL https:// itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/soap

IdP Portal Website URL http://itahpi14.testeurope1.bmwgroup.com/protected/portal.jsp

SP Demo Website URL http://itacpi29.testeurope1.bmwgroup.com/protected.asp


Issuer http://itahpi14.testeurope1.bmwgroup.com

Subject Name Qualifier www.ibm.com

Tabelle 26: Einstellungen IBM TFIM & Netegrity Siteminder

Zum Schutz des SOAP Binding Service URLs des Identity Providers wurde bei den Tests das Authentifizierungsverfahren Basic Authentication verwendet. 5.7.2 Test der Anwendungsfälle Auch in diesem Testszenario wurden wieder fünf föderierte Anwendungsfälle überprüft, um festzustellen, ob diese umgesetzt werden konnten. Tabelle 27 zeigt die erzielten Testergebnisse.


126







Tabelle 27: Testergebnisse - IBM TFIM (IdP) & Netegrity Siteminder(SP)

An dieser Stelle ist zu bemerken, dass auf den verwendeten Softwareprodukten bereits alle aktuellen Hotfixes installiert waren. Anwendungsfall: Föderierte Authentifizierung/Föderiertes Single Sign-On Eine Interoperablität der Softwareprodukte bzgl. des gegebenen Testszenarios konnte für diesen Anwendungsfall nicht nachgewiesen werden. Die Schritte 1-4 dieses Testfalls konnten problemlos umgesetzt werden. Schwierigkeiten ergaben sich jedoch bei der Verarbeitung der empfangenen SAML-Response durch den Service Provider. Der Netegrity Siteminder war nicht in der Lage, den in der SAML-Assertion übermittelten Benutzer zu authentifizieren. Dabei ergab sich folgende Fehlermeldung:

April 25, 2005 11:56:10.201 AM[7566193:authentication] result code from AgentAPI login call: 2

April 25, 2005 11:56:10.201 AM[7566193:authentication] session id is:

April 25, 2005 11:56:10.201 AM[7566193:authentication] session spec is:

April 25, 2005 11:56:10.201 AM[7566193:E] SAML-Assertion based user authentication failed.

April 25, 2005 11:56:10.201 AM[7566193:authentication] Response Attributes:

April 25, 2005 11:56:10.201 AM[7566193:I] Ending the request processing with the HTTP response code: 500

Trotz erheblicher Anstrengungen bzgl. einer geeigneten Anpassung der Identity-Mapping Regeln (XPath-Ausdrücke) innerhalb des Netegrity Siteminders konnte dieses Problem nicht behoben werden. Die Ursache für diesen Fehler liegt bei Applikation „Federation Web-Services“ des Netegrity Siteminders. Diese Applikation ignoriert in einigen Systemumgebungen die Web-Agent Parameter CookieDomain und CookieDomainScope. Aus diesem Grund konnten die nötigen Cookies nicht ordungsgemäß Webbrowser des Testnutzers abgelegt werden. Dieser Umstand verursachte ein Scheitern des Authentifizierungsvorgangs.

Eine Anfrage beim zuständigen Support von CA ergab, dass dieser Bug in der neuen Version des Siteminder OptionPacks (Option Pack vQMR 2) behoben wurde. Ob eine Integration dieser neuen Version das Problem in der Testumgebung beseitigt, konnte jedoch im Rahmen dieser Diplomarbeit nicht mehr festgestellt werden, da die Installation dieses neuen OptionPacks eine komplett neue Aufsetzung des Siteminder-Systems erfordert hätte.


127

Anwendungsfall: Föderierter Attribut-Austausch Aufgrund des Scheiterns des vorangegangen Testfalls konnte der föderierte Austausch von Attributen zwischen dem IBM- und CA-Produkt nicht getestet werden. Anwendungsfall: Lokale Autorisierung Siehe gleichnamiger Anwendungsfall in Kapitel 5.4.2. Anwendungsfall: Entfernte (Remote) Autorisierung Wie alle vorangegangenen Testszenarios zeigen, wird dieser Use Case von keiner SAML-Autorität der drei verwendeten Produkte unterstützt. Eine Umsetzung dieses Anwendungsfalls war damit auch hier unmöglich. Anwendungsfall: Föderiertes Single Logout Siehe gleichnamiger Anwendungsfall in Kapitel 5.2.2. 5.7.3 Fazit Auch in diesem Testszenario schnitt der Netegrity Siteminder 6.0 SP1 schlecht ab. Genau wie bei den Untersuchungen in Kapitel 5.4 konnte keiner der Anwendungsfälle erfolgreich getestet werden. Die Ursache für das Scheitern der Testfälle lag abermals auf der Seite des Netegrity Siteminders. Dies legt den Schluss nahe, dass in einer heterogenen föderierten Identitätsumgebung von einem Einsatz des Netegrity Siteminders 6.0 SP1 in der Funktion des Service Providers abgesehen werden sollte. Ob die aktuellste Version des CA-Produkts (Netegrity Siteminder 6.0 SP2 + OptionPack QMR2), welche vor kurzem veröffentlicht wurde, bessere Ergebnisse liefert, müsste mit der Durchführung einer neuen Testreihe untersucht werden. 5.8 OpenSAML-Autorität der BMW Group Bei der BMW Forschung und Technik wurde auf Basis der frei verfügbaren OpenSAML-Bibliotheken [OpenSAML] des Internet2-Konsortiums eine eigene SAML-Autorität implementiert. Diese kann Assertions und Artefakte auf Wunsch generieren und verwalten. Zur Speicherung der Nutzerdaten bzw. SAML-Assertions wird eine MySQL-Datenbank verwendet. In der Abbildung 21 wird das Klassendiagramm dieser SAML-Autorität dargestellt. Die Hauptkomponente ist die Klasse SAMLAuthorityService. Dieser Klasse sind die Hilfsklassen AssertionFactory (Klasse zum Aufbau einer SAML-Assertion) und


128

IdTokenFactory (Klasse zur Verschlüsselung von Artefakten) zugeordnet. Auf die genaue Funktionsweise dieser Klassen soll an dieser Stelle nicht näher eingegangen werden. Im Rahmen dieser Diplomarbeit war es nun interessant, die Interoperablität zwischen den kommerziellen IAM-Produkten und dieser SAML-Autorität zu evaluieren. Leider konnten diesbezüglich nur sehr eingeschränkte Tests durchgeführt werden, da die SAML-Autorität der BMW Group als Kommunikationsschnittstelle SOAP RPC verwendet. Aus diesem Grund war die SAML-Autorität nicht kompatibel zu den SAML-Implementierungen der kommerziellen IAM-Produkte, die für den Nachrichtenaustausch SOAP DOCUMENT verwenden.

Abbildung 25: Klassendiagramm OpenSAML-Autorität (BMW Forschung &Technik)

Da voraussichtlich noch in diesem Jahr die SAML-Autorität der BMW Group auf SOAP DOCUMENT umgestellt wird, wurden im Rahmen dieser Diplomarbeit dennoch erste Interoperabilitätstest durchgeführt, die feststellen sollten, ob der Aufbau von Föderationen mit dem Netegrity Siteminder 6.0, dem RSA FIM 2.5 und dem IBM TFIM 6.0 potentiell möglich ist. Dazu wurde getestet, ob die ausgestellten SAML-Assertions der jeweiligen kommerziellen Produkte von der OpenSAML-Autorität geparst und verarbeitet werden konnten. Die erfolgten Tests waren für alle drei IAM-Produkte erfolgreich, d.h., die SAML-Assertions aller drei Produkte konnten ohne Probleme von der OpenSAML-Autorität geparst werden. Zudem war die SAML-Autorität in der Lage, alle Nutzerdaten, welche in den Assertions enthalten waren, zu extrahieren. Eine Interoperablität zu den SAML-Assertions des Netegrity Siteminders 6.0 war jedoch nur möglich, nachdem das Assertion-Generator Java-Plugin verwendet wurde (vgl. Anhang A.1).


129

Um eine tatsächliche Anbindung der SAML-Autorität an die kommerziellen Sicherheits-lösungen zu ermöglichen, muss neben der Umstellung auf SOAP DOCUMENT und der Bereitstellung eines Artifact Receiver Services bzw. SOAP Binding Services, die Klasse SAMLAuthorityService um eine Reihe von Methoden erweitert werden. Die zwei wichtigsten sind:

• Methode, die nach dem Aufruf des Artifact Receiver Service URLs das übergebene SAML-Artefakt in eine SAML-Request-Nachricht verpackt und diese über einen SOAP-Channel an den Föderationspartner verschickt. Diese Methode wird benötigt, wenn die BMW SAML-Autorität in einer heterogenen Systemumgebung als Service Provider auftreten soll.

• Methode, die nach dem Aufruf des SOAP Binding Service URLs das SAML-Artefakt aus einer übermittelten SAML-Request-Nachricht auspackt und mittels diesem nach einer passenden SAML-Assertion in der angebundenen SQL-Datenbank sucht. Ist eine solche Assertion vorhanden, muss diese in Form einer SAML-Response-Nachricht über einen aufgebauten SOAP Back-Channel an den Föderationspartner geschickt werden. Diese Methode wird benötigt, wenn die BMW SAML-Autorität in einer heterogenen Systemumgebung als Identity Provider auftreten soll.

Neben dem Hinzufügen neuer Methoden ist es zudem erforderlich, die angebundene SQL-Datenbank um eine Datenstruktur zu erweitern, die es ermöglicht, wichtige Informationen (z.B. SOAP Binding Service URL, Artifact Receiver Service URL, IssuerID, SourceID etc.) bzgl. eines vertrauenswürdigen Föderationspartners zu speichern. Nach der erfolgreichen Umsetzung der oben genannten Maßnahmen steht dem Aufbau einer föderierten SSO-Umgebung mit dem Netegrity Siteminder, dem RSA FIM und dem IBM TFIM nichts mehr im Wege.

Kapitel 6: Zusammenfassung und Ausblick

130

6. Zusammenfassung und Ausblick Im Rahmen dieser Diplomarbeit wurde die Interoperabilität dreier unterschiedlicher Identity- und Access-Management-Softwareprodukte im Bereich Federated Identity Management ausführlich analysiert und evaluiert. Dies waren 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 Tivoli Federated Identity Manager 6.0 (Beta-Version). Mit Hilfe dieser Produkte ist es möglich, Vertrauensbeziehungen (Föderationen) zu anderen (entfernten) Domänen aufzubauen. Dadurch können sich Benutzer - nach einer einmaligen Authentifizierung in ihrer Heimdomäne – übergangslos, d.h. ohne eine erneute Authentifizierung zwischen den jeweiligen Domänen bewegen (Federated Single Sign-On). Dazu müssen Sicherheitsinformationen (z.B. Authentifizierungsdaten eines Benutzers) ausgetauscht werden. Als Austauschformat für diese Informationen wurde der Standard SAML (Security Assertion Markup Language) 1.0/1.1 verwendet. Momentan existieren mehrere unterschiedliche Föderationstandards, die den sicheren Austausch von Identitätsinformationen über Domänengrenzen hinweg ermöglichen. Die wichtigsten sind SAML, WS-Federation und Liberty ID-FF. Im Rahmen dieser Diplomarbeit wurden diese teilweise recht unterschiedlichen Spezifikationen vorgestellt und auf ihre Fähigkeiten und Unterschiede hin untersucht. Die historische Entwicklung bei anderen großen Protokollen wie z.B. HTTP oder TCP zeigt jedoch, dass sich auf Dauer keine zwei oder mehr konkurrierenden Standards in der Praxis halten können. Aktuell sieht es so aus, als könne SAML in Verbindung mit den Protokollen der Liberty Alliance im Standard-Wettstreit die Oberhand gewinnen [FedFuture]. Dies zeigt auch die Veröffentlichung des SAML 2.0 Standards im März dieses Jahres. SAML 2.0 wurde in Zusammenarbeit mit dem OASIS Konsortium, der Liberty Alliance und der Shibboleth-Gruppe entworfen mit dem Ziel, die verschiedenen existierenden Standards zu einem einzigen zu vereinigen. Nach der Meinung vieler Experten ist SAML 2.0 ein maßgeblicher Schritt in Richtung einer vollständigen Konvergenz der verschiedenen Federated Identity Standards. Deshalb haben bereits nahezu alle namhaften Hersteller von Sicherheitsprodukten angekündigt, noch innerhalb dieses Jahres SAML 2.0 in ihre Produkte zu implementieren. Ob SAML 2.0 jedoch die hohen Erwartungen, die in diesen Standard gelegt werden, erfüllen kann, muss die Zukunft zeigen. Dazu muss sich der neue Standard zuallererst in der Praxis bewähren. Das Hauptaugenmerk in dieser Diplomarbeit lag deshalb auf den Vorgängerversionen von SAML 2.0 (SAML 1.0/1.1). Diese(r) Standard(s) bildete(n) die Grundlage für die durchgeführte Produktevaluierung. Dazu wurde im Rahmen dieser Diplomarbeit die Interoperabilität dreier unterschiedlicher Identity/Access-Management-Lösungen im Bereich Federated Identity ausführlich analysiert und evaluiert. Die Ergebnisse dieser Diplomarbeit zeigen, dass in ca. 50 % der aufgestellten Testszenarios ein föderierter Austausch von Identitätsinformationen erfolgreich möglich war. Die Hauptursache für das Scheitern einiger Testfälle war stets auf eine mangelhafte Konformität der ausgestellten SAML-Assertions bezüglich der OASIS SAML 1.0/1.1


131

Spezifikation(en) zurückzuführen. Hier schnitt vor allem der Netegrity Siteminder 6.0 SP1 schlecht ab. Die Assertions dieses Produkts entsprachen in manchen Teilen nicht den Anforderungen der SAML-Spezifikation. Deshalb musste speziell für dieses Produkt ein Assertion-Generator Java-Plugin geschrieben und integriert werden. Dieses Plugin war in der Lage, die ausgehenden Netegrity Assertions entsprechend den Regeln der SAML Spezifikation 1.0 abzuändern. Dadurch war es dem CA Produkt erfolgreich möglich, gegenüber dem RSA Cleartrust- & FIM-System, welches als Service Provider fungierte, als Identity Provider aufzutreten. In der Funktion des Service Providers konnte der Netegrity Siteminder 6.0 SP1 in keinem der untersuchten Szenarios erfolgreich getestet werden. In der Praxis sollte deshalb von einem Einsatz des Netegrity Siteminders 6.0 SP1 in der Funktion des SPs abgesehen werden. Vollständig ohne Probleme konnte der Netegrity Siteminder ausschließlich in Verbindung mit dem hauseigenen Produkt SAML Affiliate Agent verwendet werden. Eine mögliche Verbesserung bzgl. der Interoperablität mit den Produkten anderer Hersteller bietet eventuell die neue Version des Netegrity Siteminders (Netegrity Siteminder SP2 + OptionPack QMR2). Laut den Aussagen von Computer Associates wurde die SAML-Autorität in dieser Version in einigen entscheidenden Punkten überarbeitet. Dies umfasst insbesondere die Beseitigung der vorhandenen proprietären Tags innerhalb der generierten SAML-Assertions. In der Diplomarbeit wurde dieses Problem durch den Einsatz eines Java-Plugins gelöst. Eine Möglichkeit, die Interoperabilitätsprobleme des CA Produkts komplett zu beheben, wäre der Einsatz des RSA Federated Identity Managers 2.5 in Verbindung mit dem Netegrity Siteminder. Da RSA FIM 2.5 als standalone Komponente konzipiert wurde, welche unabhängig von der verwendeten Identity/Access Management Lösung agieren kann, besteht die Möglichkeit, diese auch in Kombination mit dem Netegrity Siteminder zu verwenden. Der Netegrity Siteminder würde dann ausschließlich Authentifizierungs- bzw. Autorisierungsfunktionen übernehmen. Der Austausch von SAML-Nachrichten wäre dann Aufgabe des RSA FIMs. Bessere Ergebnisse als das Netegrity Produkt (Hersteller Computer Associates) lieferte sowohl die Softwarelösung von RSA als auch die Softwarelösung von IBM. Beide Produkte erstellten weitgehend konforme SAML-Assertions, wobei zu beachten ist, dass die Beta-Version des IBM Federated Identity Managers 6.0 ausschließlich den Austausch von SAML 1.0-Nachrichten unterstützte. Der RSA Federated Identity Manager 2.5 bot mit einem kleinen Vorsprung vor dem IBM Federated Identity Manager die beste SAML-Autorität. Die ausgestellten SAML-Request-/Response-Nachrichten dieser Autorität waren stets konform zu den SAML 1.0/1.1- Spezifikationen. Deshalb bereitete das RSA Produkt während der Interoperablitätsanalyse nur wenige Probleme. Nahezu alle Testszenarios, an denen dieses Produkt beteiligt war (außer dem Testfall RSA (IdP) – Netegrity (SP)), konnten erfolgreich umgesetzt werden. Ein Grund für dieses hervorragende Abschneiden ist sicherlich auch der Umstand, dass die RSA SAML-Autorität auf den öffentlich zugänglichen APIs von OpenSAML basiert.


132

Der IBM Tivoli Access Manager 5.1 & Tivoli Federated Identity Manager 6.0 war das komplexeste Produkt in der Testumgebung. Der Aufbau der Architektur war im Vergleich zu den anderen getesteten Produkten aufwändiger und zeitintensiver. Teile der Konfiguration konnten trotz der Bereitstellung einer grafischen Benutzerschnittstelle (IBM ISC) nur über Konsolenbefehle durchgeführt werden. Hierbei muss jedoch berücksichtigt werden, dass der Federated Identity Manager 6.0 zur Zeit der Tests ausschließlich in einer Beta-Version vorlag. Eine offizielle Veröffentlichung dieses Produkts wurde für das 2.Quartal 2005 angekündigt. Die SAML-Assertions der IBM SAML-Autorität waren nach der Installation eines bereitgestellten Hotfixes vollständig konform zum SAML Standard 1.0. Neben SAML unterstützt das IBM Produkt zudem die Föderationstandards Liberty ID-FF 1.1 und WS-Federation. Der Tivoli Federated Identity Manager 6.0 ist damit eine der wenigen aktuellen SAML-Implementierungen, welche den Standard WS-Federation unterstützt. Zur Absicherung des domänenübergreifenden Informationsaustausches ermöglicht der Federation Manager zudem den Einsatz von WS-Security. Abbildung 26 zeigt eine Übersicht der Interoperablitätsergebnisse, die im Rahmen dieser Diplomarbeit ermittelt wurden

Abbildung 26: Ergebnisse der Interoperablitätsanalyse

Netegrity SiteMinder 6.0 + Hotfixes

IBM TAM 5.1 & Federated Identity Mgr.

6.0 + Hotfix

RSA ClearTrust 5.5 + Federated Identity Mgr.

2.5

Identity Provider

Identity Provider

Identity Provider

Identity Provider

Legende:

Interoperabilitätsanalyse in mindestens einem Anwendungsfall erfolgreich

Interoperabilitätsanalyse in keinem Anwendungsfall erfolgreich

Identity Provider

Identity Provider

Entwurf und Integration eines Java-Plugins

Interoperabilität nicht definitiv feststellbar


133

Abschließend muss jedoch bemerkt merken, dass keines der vorgestellten Produkte die SAML Spezifikation(en) 1.0 bzw. 1.1 vollständig implementiert. Obwohl im SAML Standard spezifiziert, unterstützt - mit Ausnahme des RSA Federated Identity Managers - keines der anderen Produkte explizite bzw. dynamische Attributanfragen (basierend auf SAML Attribute-Request bzw. SAML Attribute-Responses). Ein Austausch von Attributen ist beim Netegrity Siteminder 6.0 SP1 und beim IBM Tivoli Federated Identity Manager 6.0 deshalb nur statisch innerhalb von SAML Attribute-Assertions möglich. Eine entfernte Autorisierung, beruhend auf SAML Authorization-Assertions, wird sogar von keinem der drei Produkte unterstützt. Gerade dieser Use Case ist jedoch in der Praxis sehr relevant (z.B. das Abfragen der Kreditwürdigkeit eines Benutzers). Es wäre deshalb wünschenswert, wenn die Hersteller bei den zukünftigen Versionen ihrer Föderationsprodukte diesen Anwendungsfall berücksichtigen würden.

Anhang

134

A. Anhang

A.1 Quellcode Assertion Generator Plugin (Netegrity Siteminder 6.0 SP1) Der folgende Java-Quellcode zeigt das Assertion-Generator-Plugin, das im Rahmen dieser Diplomarbeit programmiert werden musste, um die Netegrity SAML 1.0-Assertions konform zu den Anforderung der OASIS SAML 1.0-Spezifikation abzuändern (vgl. Kapitel 5.2.2). package com.netegrity.assertiongenerator;

import com.netegrity.policyserver.smapi.*;

import java.io.*;

import java.util.*;

import javax.xml.parsers.DocumentBuilder;

import org.w3c.dom.Node;

import org.w3c.dom.Element;

import org.w3c.dom.Document;

import org.w3c.dom.NodeList;

import org.w3c.dom.NamedNodeMap;

import org.w3c.dom.Attr;

import org.w3c.dom.traversal.NodeIterator;

import org.xml.sax.InputSource;

import org.apache.xpath.XPathAPI;

import org.apache.xerces.dom.*;

import org.apache.xerces.parsers.*;

import org.apache.xml.serialize.XMLSerializer;

import org.apache.xml.serialize.OutputFormat;

/**

* MyAssertion

*

* This Assertion Generator Plugin modifies assertion :

* - Remove Namespace "xmlns:SM" attribute from header

* - Change wrong URI "urn:oasis:names:tc:SAML:1.0:assertion" to SAML 1.0

* conform URI "urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName"

* - Change attributes from "<SM:NVpair>" to "<saml:Attribute>"

* - Change value of Attribute "AuthenticationMethod" within Element

* <AuthenticationStatement> from "unspecified" to "password"

* - Add <SubjectConfirmation>-Tag if not available

* - Change position of Element <AttributeStatement>

**/

public class MyAssertion implements AssertionGeneratorPlugin {

[...] public int customizeAssertion(APIContext apiContext, UserContext

userContext,String pluginParam, String inputAssertion,

Anhang

135

final StringBuffer outputAssertion) throws Exception {

if (inputAssertion == null || inputAssertion.equals("")) {

// Indicates non-zero for an error.

return -1;

}

apiContext.trace("Sample Assertion Plugin", "Entering

customizeAssertion");

// Initialize a new handler for each call.

AssertionDocumentHandler handler = initDocumentHandler(apiContext,

userContext);

// Parse the assertion

Document assertionDoc = handler.parseAssertion(inputAssertion);

if (assertionDoc == null) {

apiContext.trace("Sample Assertion Plugin", "Failed to parse

the assertion");

return 1;

}

apiContext.trace("Sample Assertion Plugin", "Input assertion

parsed");

// Remove "SM" namespace from root node

if (!handler.RemoveSMNamespace(assertionDoc)) {

apiContext.trace("Sample Assertion Plugin", "Failed to remove

'xmlns:SM'");

return 2;

}

apiContext.trace("Sample Assertion Plugin", "'xmlns:SM' removed");

//Change URI "urn:oasis:names:tc:SAML:1.0:assertion" to

//"urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName"

if (!handler.ChangeFormatInNameIdentifier(assertionDoc))

{

apiContext.trace("Sample Assertion Plugin", "Change of

Format URI Failed");

return 3;

}

apiContext.trace("My Assertion Plugin", "Changed Format URI within

<NameIdentifier>");

// Change attributes from namespace "SM" to namespace "saml"

if (!handler.ChangeAttributes(assertionDoc)) {

apiContext.trace("Sample Assertion Plugin", "Failed to change

attributes");

return 4;

Anhang

136

}

apiContext.trace("Sample Assertion Plugin", "SAML attributes

changed");

// Changing value of Attribute "AuthenticationMethod" within

//Element <AuthenticationStatement> ("unspecified" ->"password")

if (!handler.changeAuthenticationMethod(assertionDoc)) {


Element <AuthenticationStatement>");

return 7;

}

apiContext.trace("Sample Assertion Plugin", "Element

<AuthenticationStatement> changed");

/** Add <SubjectConfirmation> Tag if not already existent */

if (!handler.addSubjectConfirmation(assertionDoc)) {

apiContext.trace("Sample Assertion Plugin", "Failed to add

Element <SubjectConfirmation>");

return 8;

}

apiContext.trace("Sample Assertion Plugin", "Element

<SubjectConfirmation> added");

/** Change position of Element <AttributeStatement>, so that Tag

<AuthenticationStatement> is placed before <AttributeStatement>

otherwise RSA FIM 2.5 can not parse Assertion) */

if (!handler.RemoveAttributeStatement2(assertionDoc)) {


position of Element <Attributestatement>");

return 5;

}

apiContext.trace("Sample Assertion Plugin", "Position of

<AttributeStatements> changed");

// Save SAML-Assertion

String strOut = handler.saveAssertion(assertionDoc);

if (0 == strOut.length()) {

apiContext.trace("Sample Assertion Plugin", "Failed to create

an output assertion");

return 6;

}

apiContext.trace("Sample Assertion Plugin", "Assertion saved to a

string");

outputAssertion.append(strOut);

apiContext.trace("Sample Assertion Plugin", "Done

customizeAssertion");

Anhang

137

// return "success"

return 0;

}

[...] /**

* Each plugin will only have one instance running per SiteMinder

* Policy Server.

* This class provides a handler for each plugin call so that the

* plugin can be stateless and re-enteriable.

*/

class AssertionDocumentHandler {

[...] /**

* Parse the input assertion into a XML DOM document.

*/

protected Document parseAssertion(String sAssertion) throws

Exception {

DOMParser domParser = new DOMParser();

InputSource inSource = new InputSource(new

ByteArrayInputStream(sAssertion.getBytes()));

// Parse the Assertion XML message body

domParser.parse(inSource);

return domParser.getDocument();

}

/** Change Format of NameIdentifier from

"urn:oasis:names:tc:SAML:1.0:assertion" to

"urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName"

*/

protected boolean ChangeFormatInNameIdentifier(Document

assertionDoc) {

//Get document root Element

Element xRoot = assertionDoc.getDocumentElement();

// Get all Elements "NameIdentifier" within the Assertion

NodeList listNameIdentifier =

xRoot.getElementsByTagName("saml:NameIdentifier");

if(listNameIdentifier.getLength()==0)

{

apiContext.trace("My Assertion Plugin", " Couldn’t find

NameIdentifier Tag ");

}

for (int i = 0; i < listNameIdentifier.getLength(); ++i) {

Anhang

138

Element nameId = (Element)listNameIdentifier.item(i);

nameId.setAttribute("Format","urn:oasis:names:tc:SAML:1.0:a

ssertion#X509SubjectName");

}

return true;

}

/** Remove Elements <AttributeStatement> from the beginning

of the Assertion and append it to the end of the Assertion

*/

protected boolean RemoveAttributeStatement2(Document assertionDoc)

{ //Get document root Element


//Get node "saml:Assertion"

Node nodeSamlAssertion = assertionDoc.getFirstChild();

// Get all Elements "AttributeStatement" within the Assertion

NodeList listAttributeStatements =

xRoot.getElementsByTagName("saml:AttributeStatement");

if(listAttributeStatements.getLength()==0)

{

apiContext.trace("My Assertion Plugin", "Couldn’t find

AtrributeStatement Tag");

}

for (int i = 0; i < listAttributeStatements.getLength(); ++i)

{

Node attributeStatement = listAttributeStatements.item(i);

Node temp = nodeSamlAssertion.removeChild(attributeStatement);

Node temp2 =nodeSamlAssertion.appendChild(attributeStatement);

}

return true;

}

/**Change Attribute AuthenticationMethod within Element

AuthenticationStatement(from "unspecified" to "password")

*/

protected boolean changeAuthenticationMethod(Document assertionDoc)

{

//Get document root Element


// Get all Element "AuthenticationStatement" within Assertion

NodeList listAuthenticationStatement =

xRoot.getElementsByTagName("saml:AuthenticationStatement");

if(listAuthenticationStatement.getLength()==0)

{

Anhang

139


AuthenticationStatement Tag");

}

for (int i = 0; i < listAuthenticationStatement.getLength();

++i) {

Element authSt =

(Element)listAuthenticationStatement.item(i);

authSt.setAttribute("AuthenticationMethod","urn:oasis:na

es:tc:SAML:1.0:am:password");

}

return true;

}

/** Add Element <SubjectConfirmation> to Assertion if not

already existent*/

protected boolean addSubjectConfirmation(Document assertionDoc)

{ //Get document root Element


//Create new <SubjectConfirmation> Element

Element subconf =

assertionDoc.createElement("saml:SubjectConfirmation");

//Create new <ConfirmationMethod> Element

Element confmeth =

assertionDoc.createElement("saml:ConfirmationMethod");

//Create new Text Node and add to <ConfirmationMethod>

confmeth.appendChild(assertionDoc.createTextNode("urn:oasis:nam

es:tc:SAML:1.0:cm:artifact-01"));

//Add <ConfirmationMethod> to <SubjectConfirmation> Element

subconf.appendChild(confmeth);

// Get all Elements "AttributeStatement" within the Assertion

NodeList listSubjects =

xRoot.getElementsByTagName("saml:Subject");

if(listSubjects.getLength()==0)

{


Subject Tag");

}

for (int i = 0; i < listSubjects.getLength(); ++i)

{

Node subject = listSubjects.item(i);

subject.appendChild(subconf);

}

return true;

}

/** Remove "SM" namespace from root node*/

protected boolean RemoveSMNamespace(Document assertionDoc) {

Anhang

140

// Get root node "saml:Assertion"

Node nodeSamlAssertion = assertionDoc.getFirstChild();

// Get Attributes of Node

NamedNodeMap nnm = nodeSamlAssertion.getAttributes();

// Remove "Format" attribute within NameIdentifier Element

nnm.removeNamedItem("xmlns:SM");

return true;

}

[...] /**

* Generic method to create Saml Attribute.

*/

protected Node createSamlAttr(Document assertionDoc, String

sAttrName, String sAttrNameSpace, String sValue) {

Element elemValue =

assertionDoc.createElement("saml:AttributeValue");

elemValue.appendChild(assertionDoc.createTextNode(sValue));

Element elemRoot =

assertionDoc.createElement("saml:Attribute");

elemRoot.appendChild(elemValue);

elemRoot.setAttribute("AttributeName", sAttrName);

elemRoot.setAttribute("AttributeNamespace", sAttrNameSpace);

return elemRoot;

}

[...] /**Output the modified assertion document in a String.*/

protected String saveAssertion(Document assertionDoc) throws

Exception {

OutputFormat outputFormat = new OutputFormat(assertionDoc);

outputFormat.setPreserveSpace(true);

outputFormat.setOmitXMLDeclaration(true);

StringWriter writerOut = new StringWriter();

XMLSerializer xmlSerializer = new XMLSerializer(writerOut,

outputFormat);

xmlSerializer.serialize(assertionDoc);

writerOut.flush();

return writerOut.toString();

}

}

}

Anhang

141

A.2 Beispiele zum Liberty ID-FF 1.2 Protokoll Das folgende XML-Dokument zeigt ein Beispiel für einen Liberty ID-FF 1.2 Authentication-Request (lib:authnRequest). <lib:AuthnRequest RequestID="RPCUk2ll+GVz+t1lLURp51oFvJXk" MajorVersion="1" MinorVersion="2" consent="urn:liberty:consent:obtained" IssueInstant="2001-12-17T21:42:4Z" xmlns:lib="urn:liberty:iff:2003-08">

<ds:Signature> ... </ds:Signature> <lib:ProviderID>http://ServiceProvider.com</lib:ProviderID> <lib:NameIDPolicy>federate</lib:NameIDPolicy> <lib:ForceAuthn>false</lib:ForceAuthn> <lib:IsPassive>false</lib:IsPassive> <lib:ProtocolProfile>http://projectliberty.org/profiles/brws-post</lib:ProtocolProfile> <lib:RequestAuthnContext> <lib:AuthnContexClassRef> http://projectliberty.org/schemas/authctx/classes/Password-ProtectedTransport </lib:AuthnContextClassRef> <lib:AuthnContextComparison>exact</lib:AuthnContextComparison> </lib:RequestAuthnContext> <lib:RelayState>R0lGODlhcgGSALMAAAQCAEMmCZtuMFQxDS8b</lib:RelayState> <lib:Scoping> <lib:ProxyCount>1</lib:ProxyCount> </lib:Scoping> </lib :AuthnRequest> Das folgende XML-Dokument zeigt ein mögliches Beispiel für eine Liberty ID-FF 1.2 Authentication-Response (lib:authnResponse). <lib:AuthnResponse ResponseID="hhuuja1bc744hGJn5Q9A5yvEIgS" InResponseTo="Zon3WjJ2KL7j+bJu7MuIr4Ptgo5" MajorVersion="1" MinorVersion="2" consent="urn:liberty:consent:obtained" IssueInstant="2002-10-31T21:55:41Z "> <samlp:Status><samlp:StatusCodeValue="samlp:Success" /></samlp:Status>

<lib:Assertion MajorVersion="1" MinorVersion="2" AssertionID="e06e5a28-bc80-4ba6-9ecb-712949db686e" Issuer="http://IdentityProvider.com" IssueInstant="2001- 12-17T09:30:47Z" InResponseTo="4e7c3772-4fa4- 4a0f-99e8-7d719ff6067c">

<saml:Conditions NotBefore="2001-12-17T09: 30:47Z" NotOnOrAfter="2001-12-17T09:35:47Z">

<saml :AudienceRestrictionCondition > <saml:Audience>http://ServiceProvider.com</saml:Audience> </saml:AudienceRestrictionCondition> </saml:Conditions>

<lib:AuthenticationStatement AuthenticationInstant="2001-12-17T09:30:47Z" SessionIndex="3 " ReauthenticateOnOrAfter="200 1-12-17T11:30:47Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">

<lib:Subject> <saml:NameIdentifier NameQualifier="http://ServiceProvider.com" Format="urn:liberty:iff:nameid:federated"> 342ad3d8-93ee-690 4c68-be35-cc9e7db39e2b

Anhang

142

</saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> <IDPProvidedNameIdentifier NameQualifier="http://ServiceProvider.com" Format="urn:liberty:iff:nameid:federated"> 342ad3d8-93ee- 698 4c68-be35-cc9e7db39e2b </IDPProvidedNameIdentifier> </lib:Subject> </lib:AuthenticationStatement> <ds:Signature>...</ds:Signature> </lib:Assertion> <lib:ProviderID>http://IdentityProvider.com</lib:ProviderID> <lib:RelayState>R0lGODlhcgGSALMAAAQCAEMmCZtuMFQxDS8b</lib:RelayState> </lib:AuthnResponse> A.3 SAML-Requests & SAML-Responses Die folgenden SAML-Nachrichten wurden in der Umsetzungs- & Testphase (vgl. Kapitel 5) von den verschiedenen Sicherheitslösungen (Netegrity Siteminder 6.0 SP1, RSA Federated Identity Manager 2.5, IBM Tivoli Federated Identity Manager 6.0) ausgestellt. A.3.1 Testszenario Netegrity Siteminder 6.0 – SAML Affiliate Agent 6.x QMR2 SAML-Request (SAML Affiliate Agent 6.x): <samlp:Request xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="0" RequestID="112.112.1.12.1028670652906" IssueInstant="2002-08-06T21:50:52.906Z">

<samlp:AssertionArtifact> AAG4GEUmEKDqQxv/ad00au7/gxKLakNjY1IwSW1FT3VVMVhvSjhEd0hBd2xZSTRRTT06YTI0NWMwZmQyYzJlNTU2Mw==

</samlp:AssertionArtifact> </samlp:Request> SAML-Response (Netegrity Siteminder 6.0 ohne Plugin): <samlp:Response InResponseTo="SM10.250.21.53.1109951920942" IssueInstant="2005-03-04T15:58:57.238Z" MajorVersion="1" MinorVersion="0" ResponseID="10.250.23.22.1109951937238" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:Status xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:StatusCode Value="samlp:Success"/> </samlp:Status> <saml:Assertion AssertionID="SM10.250.23.22.1109951920503" IssueInstant="2005-03-

04T15:58:40.503Z" Issuer="http://www.netegrity.com/SiteMinder" MajorVersion="1"

Anhang

143

MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:Conditions NotBefore="2005-03-04T15:58:10.487Z" NotOnOrAfter="2005-03-04T16:25:50.487Z"></saml:Conditions>

<saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion"

NameQualifier="www.netegrity.com"> uid=admin,ou=Administrators,o=NetscapeRoot </saml:NameIdentifier>

</saml:Subject> <saml:Attribute AttributeName="SMContent"

AttributeNamespace="http://www.netegrity.com/SiteMinder"> <saml:AttributeValue> <SM:SMContent xmlns:SM="http://www.netegrity.com/SiteMinder"> <SM:SMsession> <SM:SessionID>

R0RXZawjNPY6O7ovk6bSQLvLRVk= </SM:SessionID>

<SM:startTime>1109951920</SM:startTime> <SM:idleTimeout>3600</SM:idleTimeout> <SM:maxTimeout>7200</SM:maxTimeout> </SM:SMsession> <SM:SMprofile> <SM:NVpair>cookie:userid=admin</SM:NVpair> <SM:NVpair>cookie:businesscategory=Gold</SM:NVpair> </SM:SMprofile> </SM:SMContent> </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> <saml:AuthenticationStatement AuthenticationInstant="2005-03-04T15:58:40.000Z"

AuthenticationMethod="Unspecified"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion"

NameQualifier="www.netegrity.com"> uid=admin,ou=Administrators,o=NetscapeRoot

</saml:NameIdentifier> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> A.3.2 Testszenario Netegrity Siteminder 6.0 – RSA Cleartrust & RSA FIM 2.5 SAML-Request (RSA FIM 2.5): <samlp:Request IssueInstant="2005-05-27T10:42:44Z" MajorVersion="1" MinorVersion="0" RequestID="_1487908810a884fe8cd5958e15a4b84b356ba2b5"xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

Anhang

144

<samlp:AssertionArtifact> AAG4GEUmEKDqQxv/ad00au7/gxKLasBSMedIN/4qTuRVUEwcIZLLF+yK

</samlp:AssertionArtifact> </samlp:Request>

SAML-Response (Netegrity Siteminder 6.0 mit Plugin): <samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="_07aea8f44cba5acdbee807aaef24b4edab6b5aa8" IssueInstant="2005-05-27T11:14:21Z" MajorVersion="1" MinorVersion="0" Recipient="" ResponseID="10.250.23.22.1117192461657">

<samlp:Status> <samlp:StatusCode Value="samlp:Success"></samlp:StatusCode>

</samlp:Status> <saml:Assertion AssertionID="SM10.250.23.22.1117192456313" IssueInstant="2005-05-27T11:14:36Z" Issuer="http://www.netegrity.com/SiteMinder" MajorVersion="1" MinorVersion="0">

<saml:Conditions NotBefore="2005-05-27T11:13:46Z" NotOnOrAfter="2005-05-27T11:15:46Z"></saml:Conditions> <AuthenticationStatement AuthenticationInstant="2005-05-27T11:14:11Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">

<Subject xmlns="urn:oasis:names:tc:SAML:1.0:assertion"> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName" NameQualifier="http://www.netegrity.com/SiteMinder">

uid=admin,ou=Administrators,o=NetscapeRoot </saml:NameIdentifier> <SubjectConfirmation>

<ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact-01

</ConfirmationMethod> </SubjectConfirmation>

</Subject> </AuthenticationStatement> <saml:AttributeStatement>

<saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName" NameQualifier="http://www.netegrity.com/SiteMinder">

uid=admin,ou=Administrator,o=NetscapeRoot </saml:NameIdentifier>

</saml:Subject> <saml:Attribute AttributeName="businesscategory" AttributeNamespace="header">

<saml:AttributeValue>gold</saml:AttributeValue> </saml:Attribute>

</saml:AttributeStatement> </saml:Assertion>

</samlp:Response>

Anhang

145

A.3.3 Testszenario RSA Cleartrust & RSA FIM 2.5 – Netegrity Siteminder 6.0 SAML-Request (Netegrity Siteminder 6.0): <samlp:Request IssueInstant="2005-03-16T13:57:49Z" MajorVersion="1" MinorVersion="0" RequestID="10.250.23.22.1117197899957" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:AssertionArtifact> AAG6SmG+swmnFS84KS0Yi4VWAlgilU3mZn61Qxv9sPQ+Ixp0Ce96pwUM

</samlp:AssertionArtifact> </samlp:Request>

SAML-Response (RSA FIM 2.5): <samlp:Response InResponseTo="10.250.23.22.1117201803404" IssueInstant="2005-03-16T13:57:55Z" MajorVersion="1" MinorVersion="0" Recipient="http://itacpi29.testeurope1.bmwgroup.com" ResponseID="_ebdc30fbe383a07780afd796a6fcea784716cefc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:Status><samlp:StatusCode Value="samlp:Success"/></samlp:Status> <saml:Assertion AssertionID="_f06224aa7db4d9124c4e173657b367814ea4e8b4" IssueInstant="2005-05-27T13:50:09Z" Issuer="_2fedf960dc60d9134f9161d88e0bc03d9a413e77" MajorVersion="1" MinorVersion="0"> <saml:Conditions NotBefore="2005-05-27T13:45:03Z" NotOnOrAfter="2005-05-27T14:00:03Z"/> <saml:AuthenticationStatement AuthenticationInstant="2005-05-27T13:50:00Z" 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="www.rsa.com">

uid=admin </saml:NameIdentifier> <saml:SubjectConfirmation>

<saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact-01

</saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject>

</saml:AuthenticationStatement> </saml:Assertion>

</samlp:Response> A.3.4 Testszenario IBM TAM 5.1 & TFIM 6.0 – RSA Cleartrust 5.5 & FIM 2.5 SAML-Request (RSA FIM 2.5): <samlp:Request IssueInstant="2005-05-27T12:50:44Z" MajorVersion="1" MinorVersion="0" RequestID="_1458697809874tfe8tz7858e15a4b19dt6578uk64"xmlns:ds="http://www.w3.org/2000/09/xmldsig

Anhang

146

#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:AssertionArtifact> AAG4GEULOKDuIz/ls01au7/rtDLlkLKUedIN/7pTuRVUEwvBgTERF+Lo </samlp:AssertionArtifact>

</samlp:Request> </soapenv:Body>

</soapenv:Envelope> SAML-Response (IBM TFIM 6.0): <samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2005-05-27T12:49:58Z" MajorVersion="1" MinorVersion="0" ResponseID="FIMRSP_1df1456c-0104-f6fd-4248-802c7617b9b2"> <samlp:Status>

<samlp:StatusCode Value="samlp:Success"/> </samlp:Status> <saml:Assertion AssertionID="Assertion-uuid1df143c6-0104-fa1b-6c52-802c7617b9b2" IssueInstant="2005-05-27T12:49:57Z" Issuer="http://itahpi14.testeurope1.bmwgroup.com" MajorVersion="1" MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

<saml:Conditions NotBefore="2005-05-27T12:36:57Z" NotOnOrAfter="2005-05-27T12:52:57Z"> <saml:AudienceRestrictionCondition>

<saml:Audience> http://itacpi09.testeurope1.bmwgroup.com:7001/samlrelyingparty/RP

</saml:Audience> </saml:AudienceRestrictionCondition>

</saml:Conditions> <saml:AuthenticationStatement AuthenticationInstant="2005-05-27T12:47:27Z" 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="www.ibm.com">

uid=admin </saml:NameIdentifier>

<saml:SubjectConfirmation> <saml:ConfirmationMethod>

urn:oasis:names:tc:SAML:1.0:cm:artifact-01 </saml:ConfirmationMethod>

</saml:SubjectConfirmation> </saml:Subject>

</saml:AuthenticationStatement> <saml:AttributeStatement>

<saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName" NameQualifier="www.ibm.com">



Anhang

147


</saml:SubjectConfirmation> </saml:Subject> <saml:Attribute AttributeName="businesscategory" AttributeNamespace="header">

<saml:AttributeValue>bronze</saml:AttributeValue> </saml:Attribute>

</saml:AttributeStatement> </saml:Assertion> </samlp:Response>

A.3.5 Testszenario IBM TAM 5.1 & TFIM 6.0 – Netegrity Siteminder 6.0 SAML-Request (Netegrity Siteminder 6.0): <samlp:Request IssueInstant="2005-05-27T12:05:20.176Z" MajorVersion="1" MinorVersion="0" RequestID="10.250.23.22.1117195520176" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">

<samlp:AssertionArtifact> AAFczW3Kc7JLyY4wdiJPHC4DlME4el53ZQGocarcYLxqhLNEwSrLzJ3Y

</samlp:AssertionArtifact> </samlp:Request> SAML-Response (IBM TFIM 6.0): <samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2005-05-27T12:05:39Z" MajorVersion="1" MinorVersion="0" ResponseID="FIMRSP_3ol4489c-6798-f3e4-4248-345f2617d8f9i"> <samlp:Status>

<samlp:StatusCode Value="samlp:Success"/> </samlp:Status> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="0" AssertionID="Assertion-uuid1e0b18df-0104-f9b3-a807-802c7617b9b2" Issuer="http://itahpi14.testeurope1.bmwgroup.com" IssueInstant="2005-05-27T12:05:40.000Z">

<saml:Conditions NotBefore="2005-05-27T12:04:40.000Z" NotOnOrAfter="2005-05-27T12:10:40.000Z">

<saml:AudienceRestrictionCondition> <saml:Audience>

http://itacpi29.testeurope1.bmwgroup.com/affwebservices/public/samlcc </saml:Audience>

</saml:AudienceRestrictionCondition> </saml:Conditions> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant="2005-05-27T12:05:40.000Z" >

<saml:Subject> <saml:NameIdentifier NameQualifier="www.ibm.com" Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName">


Anhang

148



</saml:SubjectConfirmation> </saml:Subject>

</saml:AuthenticationStatement> <saml:AttributeStatement>

<saml:Subject> <saml:NameIdentifier NameQualifier="www.ibm.com" Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName">

uid=admin </saml:NameIdentifier> <saml:SubjectConfirmation>

<saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact-01

</saml:ConfirmationMethod> </saml:SubjectConfirmation>

</saml:Subject> <saml:Attribute AttributeName="businesscategory" AttributeNamespace="header">

<saml:AttributeValue>bronze</saml:AttributeValue> </saml:Attribute>

</saml:AttributeStatement> </saml:Assertion>

Abkürzungsverzeichnis

149

Abkürzungsverzeichnis ACL Access Control List AP Asserting Party ARS Artifact Receiver Service BAP Browser/Artifact-Profile BPP Browser/Post-Profile CORBA Common Object Request Broker Architecture DN Distinguished Name FF Federation Framework FIM Federated Identity Management/Federated Identity Manager GSKit Global Security Kit HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HTTPS HyperText Transfer Protocol Secure IAM Identity und Access Management ID Identity/Identifier IdP Identity Provider IETF Internet Engineering Task Force ISC Integrated Solutions Console ISX Inter-Site Transfer Service IP Internet Protocol IT Informationstechnik J2EE Java 2 Enterprise Edition JNDI Java Naming and Directory Interface JRE Java-Runtime-Environment JSP Java Server Page LDAP Lightweight Directory Access Protocol MS Microsoft MSO Multiple Sign-On OASIS Organization for the Advancement of Structured Information Standards ODBC Open Database Connectivity PDP Policy-Decision-Point PEP Policy-Enforcement-Point PGP Pretty Good Privacy PUID Passport User ID RBAC Role-Based Access Control RDN Relative Distinguished Name RMI Remote Method Invocation RP Relying Party SAML Security Assertion Markup Language SIS Services Interfaces Specifications SMTP Simple Mail Transfer Protocol SOA Service Oriented Architecture SOAP Simple Object Access Protocol SP Service Provider SPS SSO Protocol Service SQL Structured Query Language SSI Single Sign-In SSL Secure-Sockets-Layer

Abkürzungsverzeichnis

150

SSO Single Sign-On TAM Tivoli Access Manager TFIM Tivoli Federated Manager TC Technical Committee TCP Transmission Control Protocol TLS Transport Layer Security UDDI Universal Description, Discovery and Integration URI Uniform Resource Identifier URL Uniform Resource Locator UTC Universial Time Coordinated W3C World Wide Web Consortium WPM Web Portal Manager WS Web-Services WSDL Web-Services Definition Language WSF Web-Service Framework XML Extensible Markup Language XrML Extensible Rights Markup Language XSD XML Schema Definition XSL Extensible Stylesheet Language

Literaturverzeichnis

151

Literaturverzeichnis [AMAdmin] IBM Tivoli Access Manager for e-business (Version 5.1): “Base Installation

Guide”, 2003, http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1362-00/en_US/PDF/am51_install.pdf

[AMWebseal] IBM Tivoli Access Manager for e-business (Version 5.1): “WebSEAL Administrator Guide”, 2003, http://publib.boulder.ibm.com/infocenter/

tiv2help/topic/com.ibm.itame2.doc_5.1/am51_webseal_guide.pdf

[AuthWeb] Blum, T. : “Untersuchung von Authentifizierungsverfahren für verteilte Web-Systeme zur Integration und sicheren Nutzung angebotener Dienste”, Fernuniversität Hagen, 2003, http://www.fernunihagen.de/etit/Forschung/

ForBer2-2003_blum.pdf

[BurtonFIM] Blum, D., Lewis, J.: “Toward Federated Identity Management: The Journey Continues”, Burton Group Research Report, 2003

[CA] Computer Associates, http://www.ca.com/

[CORBA] Object Management Group: “Catalog of CORBA/IIOP Specifications”, 2005 http://www.omg.org/technology/documents/corba_spec_catalog.htm

[DefAuth] Galileo Computing: “Glossar – Authentifizierung”, 2005, http://www.galileo

computing.de/glossar/gp/anzeige9037?GalileoSession=18247303A10Rk8MP0.o

[DefAuz] ComputerBase-Lexikon: “Autorisierung”, 2005, http://www.computerbase.

de/lexikon/Autorisierung

[DefID] Universität Magdeburg, Fakultät Informatik: “Definition Identität”, 2004, http://www.cs.uni-magdeburg.de/~nenglisc/definitionidentitaet.html

[DefIF] Lexias Inc. : “Glossary of Terms (4) – Identification”, 2005, http://www.lexias.com/2.0/glossary4.html

[DOM] W3C Document Object Model (DOM), 2005, http://www.w3.org/DOM/

[FedFuture] Neuenschwander, M., Blum, D. : “Federating a Distributed World: Asserting Next-Generation Identity Standards”, Version 1.0, Burton Group Research Report, 2005

[FedSSO] Siew, T. P. : “OASIS: Functional Elements Specification”, Working Draft 02, 2004, http://xml.coverpages.org/FWSI-FEGuidelinesV03-10253.pdf

[FedTrend] Neuenschwander, M., Blum, D. et al. : “VantagePoint 2005-2006 Enterprise Trends in Identity and Privacy”, Version 2.0, Burton Group Research Overview, 2005

[FIM] Metzger, S. : “Föderiertes Identity Management bei der BMW Group”, Technische Universität München, 2004


152

[FIMReq] VeriSign Whitepaper: ”Trusted Federated Identity Solution Architecture – Business Requirements”, 2004, http://www.verisign.com/static/016556.pdf

[IBM] IBM, http://www.ibm.com/

[IBMFIM] Harry, J., Salmon, A. : “IBM Tivoli Federated Identity Manager 6.0 ESP Cookbook – Federated Single Sign-On (FSSO)”, 2005

[IBMPreq] Harry, J., Salmon, A. : “IBM Tivoli Federated Identity Manager 6.0 Early Support Program – Prerequisite Installation Guide for Windows 2003 Server”, 2005

[IBMRed] Buecker, A., Filip, W. et al. : “IBM Redbook – Federated Identity Management with IBM Tivoli Security Solutions”, 2004

[IETF] Internet Engineering Task Force, http://www.ietf.org/

[INQ] Farrell, N. :” Microsoft gives up Passport world domination wheeze”, The Inquirer, 2004, http://www.theinquirer.net/?article=19227

[ITSec] Ostler, U. : “Federated Identity Management erteilt digitale Passierscheine”, 2004, http://www.silicon.de/cpo/hgr-itsecurity/detail.php?nr=17781

[Kerb] MIT Kerberos, http://web.mit.edu/kerberos/www/

[LibAll] Liberty Alliance, http://www.projectliberty.org/

[LibArch] Wason, T. : “Liberty ID-FF Architecture Overview (Version 1.2)”, 2003, http://www.projectliberty.org/specs/liberty-idff-arch-overview-v1.2.pdf

[LibBind] Cantor, S., Kemp, J. et al. : “Liberty ID-FF Bindings and Profiles Specification”, Liberty Alliance Standard, Version 1.2, 2004

[LibID] Liberty Alliance ID-FF 1.2 Specifications, http://www.projectliberty.org/

resources/specifications.php#box1

[LibSIS] Liberty Alliance ID-SIS 1.0 Specifications, http://www.projectliberty.org/


[LibWSF] Liberty Alliance ID-WSF 2.0 Specifications, http://www.projectliberty.org/


[LibWSFOv] Tourzan, J., Yuzo, K.: “Liberty ID-WSF Web-Services Framework Overview”, Version 1.0, 2004, http://www.projectliberty.org/specs/draft-liberty-idwsf-overview-1.0-errata-v1.0.pdf

[MIME] Internet Mail Consortium, http://www.imc.org/smime-pgpmime.html

[MS] Microsoft Corporation, http://www.microsoft.com/

[MSInf] Nitschke, R., Weiß, J. : “Identifikation als Dienstleistung – Der Wert des registrierten Kunden”, 2002, http://www.novosec.com/documents/

eCommerce_IdentifikationAlsDienstleistung.pdf


153

[MSTech] Microsoft Technet: “Leitfaden Identitäts- und Zugriffsverwaltung: Grundlegende Konzepte – Kapitel 2: Terminologie und Initiativen”, 2004, http://www.microsoft.com/germany/technet/datenbank/articles/900321.mspx

[NeteAff] Computer Associates: “Netegrity Siteminder - SAML Affiliate Agent Guide v6.0”, 2004

[NeteFed] Computer Associates: “Netegrity Siteminder - Federation Security Services Guide v6.0”, 2004

[NETPass] Microsoft .NET Passport, http://www.passport.com/

[NeteWhite] Computer Associates: “Netegrity Technical White Paper - Netegrity Siteminder 6.0”, 2004

[OASIS] OASIS Group, http://www.oasis-open.org/

[OASISTC] OASIS Security Services (SAML) TC, http://www.oasis-open.org/

committees/tc_home.php?wg_abbrev=security

[OpenSAML] OpenSAML 1.0.1, http://www.opensaml.org

[OpenSSO] Open Group, Security Forum: “Single Sign-On”, 2001, http://www.opengroup.org/security/l2-sso.htm

[PassTrouble] Slemko, M.: “Microsoft Passport to Trouble”, 2001, http://alive.znep.com/~marcs/passport/index.html

[PingID] Norlin, E., Durand, A. : “PingID Whitepaper - Federated Identity Management”, Seite 7, 2002, http://pingid.net/downloads/Whitepaper_

Identity_Federation.pdf

[PGP] PGPi Project, http://www.pgpi.org/

[RelaxSchema] Vlist, E. : “Relax NG – A Simpler Schema Language for XML“, Seiten 425-427, O'Reilly Verlag, Köln, 2003

[RMI] Sun Microsystems: “Java Remote Method Invocation (Java RMI)”, http://java.sun.com/products/jdk/rmi/

[RSA] RSA Security, http://www.rsasecurity.com/

[RSAAdmin] RSA Security: “RSA Cleartrust 5.5 – Administrator’s Guide”, 2003

[RSAFIM] RSA Security: “RSA Federated Identity Manager 2.5 : Planning and Installation Guide”, 2004

[RSAGuide] RSA Security: “RSA Cleartrust 5.5 Planning Guide”, 2003

[RSAInstall] RSA Security: “RSA Cleartrust 5.5 – Servers Installation and Configuration Guide”, 2003

[RSAPress] RSA Security Press Release: “RSA Security stellt neues Produkt vor: RSA Federated Identity Manager”, 2004, http://www.rsasecurity.com/press_

release.asp?doc_id=4235&id=2678


154

[RSATech] RSA Security: “RSA Federated Identity Manager – A Technical Overview”, 2005, http://www.rsasecurity.com/products/FIM/pdf/FIMTO_TB_0405.pdf

[SAML10] OASIS SAML 1.0 Specifications, http://www.oasis-open.org/committees/

download.php/2290/oasis-sstc-saml-1.0.zip

[SAML11] OASIS SAML 1.1 Specifications, http://www.oasis-open.org/committees/

download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip

[SAML20] OASIS SAML 2.0 Specifications, http://docs.oasis-open.org/security/saml/

v2.0/saml-2.0-os.zip

[SAMLArch] Manish, V. : “XML Security: Ensure portable trust with SAML - The objectives, architecture, and basic concepts of Security Assertion Markup Language”, 2004, http://www-128.ibm.com/developerworks/xml/library/x-seclay4/

[SAMLBind] Maler, E., Prateek, M. et al. : “Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 1.1, 2003

[SAMLConf] Maler, E., Prateek, M. et al. : “Conformance Program Specification Considerations for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 1.1, 2003

[SAMLCore10] Hallam-Baker, P., Maler, E. et al.: “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 1.0, 2002

[SAMLDef] OASIS Security Assertion Markup Language (SAML), http://xml.coverpages.org/saml.html

[SAMLGlos] Maler, E., Philpott, R. et al. : “Glossary for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 1.1, 2003.

[SAMLOv20] OASIS SAML 2.0 Executive Overview, 2005, http://www.oasis-open.org/

committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf

[SAMLProt] Maler, E., Mishra, P. et al. : “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 1.1, 2003

[SAMLProt2] Maler, E., Philpott, R. et al. : “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 2.0, 2005

[SAMLSec] Maler, E., Philpott, R. et al. : “Security and Privacy Considerations for the OASIS Security Assertion Markup Language (SAML)”, OASIS Standard, Version 1.1, 2003

[Shibb] Internet2 Shibboleth Projekt, http://shibboleth.internet2.edu/

[SOA] Barry & Associates, Inc. : “Service-oriented architecture (SOA) definition”, 2004, http://www.service-architecture.com/web-services/articles/service oriented_architecture_soa_definition.html


155

[SOAP12] Gudgin, M., Hadley, M. et al. : “SOAP Version 1.2 Part 1: Messaging Framework”, W3C Recommendation, 2003, http://www.w3.org/TR/soap12-part1/

[SOAPAdj] Gudgin, M., Hadley, M. et al. : “SOAP Version 1.2 Part 2: Adjuncts”, W3C Recommendation, 2003, http://www.w3.org/TR/2003/REC-soap12-part2-20030624/

[SOAPSec] Nadalin, A., Kaler, C. et al.: “Web-Services Security – SOAP Message Security 1.0 (WS-Security 2004)“, OASIS Standard, Version 1.0, 2004, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[SSL3] Netscape: “SSL 3.0 Specification”, 1996, http://wp.netscape.com/eng/ssl3/

[SSOTele] Weyl, B. : "Single Sign-On and Web-Services Security for an Open Telematics Market", Technische Universität München, 2003

[SUN] Sun Microsystems, http://www.sun.com/

[TAMRed] Buecker, A., Friell, C. et al. : “IBM Redbook – Enterprise Business Portals with IBM Tivoli Access Manager”, 2002

[TecChannel] Schroth, B. : “OASIS: SAML 1.1 freigegeben“, TecChannel, 2003, http://www.tecchannel.de/news/internet/13073/

[TowFIM] Durand A. : “Towards Federated Identity”, Ping Identity Corporation, 2002, http://discuss.andredurand.com/stories/storyReader$320

[UDDI2] Bellwood, T. : “UDDI Version 2.04 API Specification”, OASIS Standard, Version 2.04, 2002, http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm

[ValIM] PricewaterhouseCoopers, META Group White Paper: “The Value of Identity Management - How securing identity management provides value to the enterprise”, 2002, http://www.pwc.com/images/gx/eng/about/svcs/grms/

valueofimwhitepaper.pdf

[W3C] World Wide Web Consortium, http://www.w3.org

[W3CSchema] Biron, P., Malhotra, A. : “XML Schema Part 2: Datatypes Second Edition”, W3C Recommendation, 2004, http://www.w3.org/TR/xmlschema-2/

[WSBasics] Wolter, R. : “XML Web Service Basics”, Microsoft Corporation, 2001,

http://msdn.microsoft.com/library/default.asp?url=/library/enus/Dnwebsrv/html/webservbasics.asp

[WSDL11] Christensen, E., Curbera, F. et al. : “Web Services Description Language (WSDL) 1.1”, W3C Note, Version 1.1, 2001, http://www.w3.org/TR/wsdl

[WS-Fed] Bajaj, S., Della-Libera, G. et al. : “Web Services Federation Language (WS-Federation)”, 2003, http://www128.ibm.com/developerworks/webservices/

library/ws-fed/


156

[WS-FedAct] Bajaj, S., Della-Libera, G. et al. : “WS-Federation: Active Requestor Profile”, 2003, http://www.106.ibm.com/developerworks/webservices/

library/ws-fedact/

[WS-FedPass] Bajaj, S., Dixon, B. : “WS-Federation: Passive Requestor Profile”, 2003, http://www-106.ibm.com/developerworks/webservices/library/ws-fedpass/

[WS-Road] Della-Libera, G., Kaler, C., Nadalin, A. et al .: “Security in a Web-Services World: A Proposed Architecture and Roadmap - A Joint White Paper from IBM Corporation and Microsoft Corporation”, Version 1.0, 2002

[WS-Sec] Nadalin, A., Kaler, C. et al. : “Web Services Security - SOAP Message Security (WS-Security 2004)”, OASIS Standard, 2004, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[WSSGrund] Seely, S. : “Grundlegendes zu WS-Security”, Microsoft Corporation, 2004, http://www.microsoft.com/germany/msdn/library/security/GrundlegendesZuWSSecurity.mspx

[WSSTC] OASIS Web-Services Security (WSS) TC, http://www.oasis-open.org/

committees/wss

[X509] Public-Key Infrastructure (X.509), http://www.ietf.org/html.charters/pkix-charter.html

[XMLDec] Hughes, M., Imamura T. et al. : “Decryption Transform for XML Signature”, W3C Recommendation, 2002, http://www.w3.org/TR/xmlenc-decrypt

[XMLEnc] Imamura, T., Dillaway, B. et al. : “XML Encryption Syntax and Processing”, W3C Recommendation, 2002, www.w3.org/TR/xmlenc-core/

[XMLName] Bray, T., Hollander, D. et al. : “Namespaces in XML”, W3C Recommendation, 1999, http://www.w3.org/TR/1999/REC-xml-names-1999

0114/

[XMLSig] Bartel, M., Boyer, J. et al. : “XML-Signature Syntax and Processing”, W3C Recommendation, 2002, http://www.w3.org/TR/xmldsig-core/

[ZDNet] Lemos, R., Müller, D. : “Ebay sagt nein zu Passport”, ZDNet News, 2004, http://www.zdnet.de/news/tkomm/0,39023151,39129069,00.htm

institut fÜr informatik - pms.ifi.lmu.de · hiermit versichere ich, dass ich die vorliegende...

Documents