Interoperabilitätsanalyse föderierter Identitätsmanagement

Transcription

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ätsmanagementSoftwareprodukten 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) plattformund 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.
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
2.1.2
2.1.3
2.1.4
Zugang zu Ressourcen..................................................................................................................... 7
Multiple Sign On vs. Single Sign On .............................................................................................. 8
Federated Identity Single Sign-On .................................................................................................. 9
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
3.1.2
3.1.3
3.1.4
Funktionalitäten ............................................................................................................................. 52
Architektur..................................................................................................................................... 53
Federated Identity Management .................................................................................................... 57
Installation ..................................................................................................................................... 58
3.2 RSA Cleartrust 5.5 & RSA Federated Identity Manager 2.5.................................................... 60
3.2.1
3.2.2
3.2.3
3.2.4
Architektur..................................................................................................................................... 62
Installation ..................................................................................................................................... 65
3.3 IBM Tivoli Access Manager 5.1 & Tivoli Federated Identity Manager 6.0............................. 67
3.3.1
3.3.2
3.3.3
3.3.4
Architektur..................................................................................................................................... 68
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
i
82
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.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.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.3 Fazit ............................................................................................................................................. 124
5.7 Testszenario IBM TAM 5.1 & TFIM 6.0 (IdP) – Netegrity Siteminder 6.0 (SP) .................. 124
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
ii
Abkürzungsverzeichnis
149
Literaturverzeichnis
151
iii
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
iv
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
v
Kapitel 1: Einleitung
1. Einleitung
1.1 Motivation
Die heutige E-Business-Landschaft bietet Unternehmen und Organisationen zahlreiche
Möglichkeiten für eine Zusammenarbeit weit über die eigenen Standorte hinaus. Da immer
mehr Dienstleistungen heute als Web-Service angeboten werden, müssen Unternehmen neben
stark steigenden Nutzerzahlen auch eine stetig steigende Anzahl von Geschäftsbeziehungen
verwalten können. Vor allem Interaktionen mit externen Nutzern innerhalb moderner
Business-to-Business (B2B), Business-to-Customer (B2C), Business-to-Employee (B2E) oder
kombinierten B2B/B2C Umgebungen treten zunehmend in den Vordergrund. Die Folge
dieser Entwicklung bedeutet für ein einzelnes Unternehmen oft Millionen, wenn nicht sogar
Milliarden von potentiellen Nutzern und zugehörigen Speichersätzen.
Identitäten müssen nun nicht mehr nur innerhalb interner Applikationen, sondern auch
innerhalb Systemen und Diensten jenseits der Grenzen eines Unternehmens (Cross-Domain)
verwaltet werden [TowFIM]. Diese Entwicklung führt dazu, dass Firmen ihre bisherigen
Sicherheits- und Informations-Architekturen überdenken bzw. erweitern müssen, um den
zukünftigen Anforderungen gerecht zu werden.
Schnell wurde klar, dass diese neuen Herausforderungen mit Hilfe von herkömmlichen
Identity Management Systemen nur schwer zu lösen sind. Kaum ein Unternehmen ist bereit,
seinen Partnerunternehmen Zugriff auf die eigenen Nutzerdatenbanken zu gewähren. Die
andere Alternative, eine vielfache Abspeicherung der gleichen Informationen innerhalb der
verschiedenen Identitätsdomänen stellt ebenso keine zufriedenstellende Lösung dar.
Ein aussichtsreicher neuer Ansatz, der Unternehmen hilft, diese Schwierigkeiten zu
bewältigen, wird unter dem Begriff Federated Identity Management zusammengefasst:
The agreements, standards, and technologies that make identity and entitlements
portable across autonomous domains.
-Burton Group [BurtonFIM]
Dieses neue Konzept kann das Kosten- und Komplexitätsproblem der
domänenübergreifenden Benutzerverwaltung nachhaltig lösen. Federated Identity
Management dient als Rahmenwerk, um verteilte Benutzerdaten verwalten zu können.
Identitäten und werden dabei in Zukunft nicht mehr vollständig zentral, sondern dezentral
verwaltet, d.h., es existiert am Ende keine zentrale Stelle mehr, bei der alle für ein
Unternehmen relevante Identitäten gespeichert sind. Bedingung hierfür ist jedoch eine
Vertrauensbeziehung zwischen den Unternehmen, d.h., die Teilnehmer einer Föderation
müssen sich gegenseitig kennen und vertrauen. Ansonsten sind alle ausgetauschten
Informationen (z.B. Authentifizierungsinformationen) wertlos. Der Begriff Föderation betrifft
dabei eine Gruppe von Unternehmen bzw. Organisationen, die Vereinbarungen getroffen
haben, um gegenseitig Nutzer- und Ressourceninformationen austauschen zu können
1
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ätenManagements sind Standards. Momentan gibt es mehrere, zum Teil parallel verlaufende
Bemühungen, die versuchen, diesen Anforderungen gerecht zu werden (siehe Kapitel 2.4).
Die momentan wichtigsten sind SAML, das Liberty Alliance Projekt und WS-Federation.
Diese Föderationsstandards definieren einen Mechanismus, um Identitätsinformationen über
mehrere Domänen hinweg, plattformunabhängig, austauschen zu können.
Service
Consumers
Vertrauensbeziehung
Benutzer Identifikation
Authentifizierung
Zugriffskontrolle
Austausch von Identitäts- und
Attributinformationen
Identity Lifecycle Management
Abbildung 2: Identity Lifecycle Management
2
Service
Providers
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 EMail, Online-Banking, Instant-Messaging, Spiele-Download sowie Location-Based Services
zu nutzen [ITSec]. Auch der Mobilfunkhersteller Nokia arbeitet aktuell daran, das
Föderationsframework der Liberty Alliance in seine mobile Service-Infrastruktur zu
integrieren [FedFuture].
Die Vorteile eines konsequenten Federated Identity Managements sind für Unternehmen und
Nutzer enorm. Dass sich heute die meisten größeren Unternehmen des Konzeptes und der
potentiellen Möglichkeiten dieser neuen Technologie bewusst sind, ist unbestritten. Nahezu
jeder IT-Experte hat heutzutage schon einmal etwas von den Federated Identity Standards
Security Assertion Markup Language (siehe Kapitel 2.4.2), Liberty Alliance (siehe Kapitel
2.4.4) und WS-Federation (siehe Kapitel 2.4.6) gehört. Jedoch besteht in diesen Kreisen
3
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 SAMLAnwendungsfälle definiert, die in einer komplexen föderierten Identitätsumgebung unbedingt
umgesetzt werden sollten. In der Evaluierungsphase soll dann festgestellt werden, inwieweit
sich diese Use-Cases von den SAML-Implementierungen der verschiedenen Hersteller
realisieren lassen. Insbesondere soll dabei die Konformität der Softwareprodukte zum OASIS
4
SAML 1.0/1.1 Standard überprüft werden. Für eventuell auftauchende Inkompatibilitäten
zwischen den Produkten sollen sinnvolle Lösungsansätze entworfen und - wenn möglich umgesetzt werden.
Anhand der Testergebnisse soll festgestellt werden, ob es für Unternehmen, wie z.B. die
BMW Group, möglich und sinnvoll ist, Föderationen mit Partner- und
Dienstleistungsunternehmen
aufzubauen.
Eine
funktionierende
Zusammenarbeit
unterschiedlicher FIM-Produkte ist für Unternehmen wie die BMW AG maßgeblich für ein
verstärktes Engagement im Bereich Federated Identity Management, da Partner- und
Dienstleistungsunternehmen oftmals nicht die gleichen Sicherheitsprodukte verwenden.
1.3 Aufbau und Gliederung der Arbeit
Die vorliegende Arbeit umfasst sechs Kapitel. Diese werden im Folgenden kurz vorgestellt.
Im ersten Kapitel wird die Motivation und das Ziel der Diplomarbeit vorgestellt. Dabei wird
auch der Begriff Federated Identity Management eingeführt.
Das zweite Kapitel beschäftigt sich mit den Grundlagen, die für den Aufbau einer föderierten
Identitätsumgebung unerlässlich sind. Neben der Vorstellung und Erklärung fundamentaler
Konzepte, wie der föderierten Authentifizierung und Autorisierung von Nutzern, umfasst
dieses Kapitel vor allem die Einführung und den Vergleich anerkannter Föderationsstandards.
Diese bilden die Basis für einen standardisierten Austausch von Identitätsinformationen in
einem heterogenen Netzwerk. Das Hauptaugenmerk liegt dabei auf der OASIS SAML
(Security Assertion Markup Language) 1.0/1.1 Spezifikation. Dieser XML-Dialekt bietet die
Möglichkeit, Identitätsinformationen (wie z.B. Authentifizierungsdaten eines Benutzers)
zwischen unterschiedlichen Domänen auszutauschen.
In Kapitel 3 werden die drei verwendeten Identity/Access-Management-Produkte vorgestellt,
mittels derer eine föderierte und heterogene Systemumgebung simuliert wird. Insbesondere
wird an dieser Stelle detailliert auf die Federated Identity Management Fähigkeiten dieser
Produkte eingegangen. Abschließend wird die komplette Systemarchitektur vorgestellt, die
das technologische Fundament für die durchgeführten Interoperablitätsanalysen bildet.
Um eine umfassende und nachvollziehbare Interoperablitätsevaluierung zu gewährleisten,
werden in Kapitel 4 wichtige SAML-Anwendungsfälle definiert. Grundlage für diese
Testfälle bilden die föderierten Dienste (föderierte Authentifizierung, Autorisierung und
Attributsauskünfte). Anhand dieser Use-Cases wird die Interoperablitätsanalyse umgesetzt.
In Kapitel 5 werden die in Kapitel 4 definierten Anwendungsfälle auf die aufgebaute
Testumgebung angewendet. Dabei wird jedes Produkt einer genauen Interoperablitätsanalyse
5
unterzogen. Insbesondere wird dabei jedes der verwendeten Produkte bzgl. seiner
Konformität zum SAML Standard überprüft.
Die Ergebnisse dieser Evaluierung sollen aufzeigen, ob die getesteten Sicherheitslösungen
den Ansprüchen einer komplexen heterogenen Föderation genügen.
Das letzte Kapitel gibt eine Zusammenfassung der wichtigsten Ergebnisse dieser
Diplomarbeit wieder und endet mit einem Ausblick.
6
Kapitel 2: Grundlagen des Federated Identity Managements
2.
Grundlagen des Federated Identity Managements
2.1
Identifikation in einem Computer Netzwerk
Einer der Hauptgründe für den Einsatz heutiger moderner Computer Netzwerke ist die
Möglichkeit, auf entfernte Ressourcen bzw. Objekte lokal zuzugreifen und diese nutzen zu
können. Zunehmend möchten Organisationen ihren Mitarbeitern, aber auch ihren Partnern
und Kunden, einen sicheren und einfachen Zugriff auf Ressourcen bieten und dabei das
Firmenwachstum gewährleisten, die Zugriffskosten senken, die Sicherheit verbessern und
behördlichen Anforderungen gerecht werden. Der Begriff Ressource ist dabei eine
Abstraktion von z.B. Daten, Computerprogrammen, Netzwerkdruckern etc.. Um Missbrauch
zu verhindern, ist es jedoch wichtig, dass die unterschiedlichen Ressourcen vor unerlaubten
Zugriff geschützt werden. Dieses Problem führt uns zur Identifikation und Authentifizierung
von Nutzern bzw. Entitäten.
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]
7
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.
8
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 SignOn (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
9
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
10
benötigt er noch eine Unterkunft. Dazu folgt Bob einem Link auf der Webseite der Fluglinie
und wird daraufhin - per Single Sign-On-Mechanismus - auf die Webseite der Hotelkette
umgeleitet. Dort kann er nun sofort ein Hotel seiner Wahl buchen. Die Buchung eines
Mietwagens erfolgt analog.
Airline, Inc.
TravellsUs.com
CarRentals.com
Identity Store
CheapHotel, Inc.
Bob
Abbildung 4: B2C Szenario – Beispiel Reiseindustrie [FIMReq]
Im diesem Szenario ist der Identity Provider gewöhnlich eine Portal-Seite (TravelsUs.com),
welche an der Föderation beteiligt ist.
B2E (Business-to-Employee): Outsourcing von Dienstangeboten
In diesem Beispiel ermöglicht ein Arbeitgeber seinen Angestellten, ausgelagerte Dienste
(engl. Benefits) zu nutzen. Diese werden von externen Dienstleistungsunternehmen erbracht.
Die angebotenen Dienste betreffen beispielsweise die medizinische Vorsorge,
Rentenvorsorge, Angebote von kostengünstigen Versicherungen, Pläne für die Geldanlage
etc.
Arbeitgeber und Dienstanbieter bilden wieder einen Circle of Trust. Innerhalb dieser
Geschäftbeziehung fungiert der Arbeitgeber als IdP, d.h., er authentifiziert seine Angestellten
und leitet auf Wunsch die Authentifizierungs-/Autorisierungsinformationen an die externen
Dienstleistungsunternehmen weiter.
Abbildung 5 zeigt ein Beispiel für eine solche B2E-Umgebung. Dabei ist Jane eine neue
Angestellte. Für sie wird sowohl auf Arbeitgeberseite als auch auf Seite der Dienstanbieter ein
Nutzer-Konto erstellt. Im Fachjargon wird die Verknüpfung dieser Konten Account Linking
genannt. Mit Account Linking können Anwender Konten, die sie bei verschiedenen Webseiten
bzw. Unternehmen haben, miteinander verbinden, sobald die Dienste eine Zusammenarbeit
erlauben. Das Sign-On auf verlinkte Konten ist dann nur einmal notwendig.
Will Jane nun ihre Rentenversicherungsbeiträge verwalten, so wird sie mittels SSO von der
Intranet-Seite des Arbeitgebers auf die Seite des zuständigen Dienstproviders weitergeleitet.
11
Geht Jane fünf Jahre später in Ruhestand, so müssen die Account-Verbindungen zwischen
den Benefits-Providern und dem Arbeitgeber gelöst werden, damit Jane nicht mehr die
Möglichkeit hat, von der Webseite ihres ehemaligen Arbeitgebers aus auf die Dienstangebote
zuzugreifen.
Employee Portal
Jane’s Employer
Benefits Provider
Identity Store
401k Provider
Jane
Abbildung 5: B2B Szenario - Beispiel Outsourcing von Dienstangeboten [FIMReq]
Da Jane jedoch immer noch auf ihr Rentenkonto zugreifen soll und darf, übernimmt in diesem
Fall der Benefits-Provider sowohl die Aufgabe des IdPs als auch die des SPs.
B2B (Business-to-Business): Management einer Wertschöpfungskette
Im Bereich eines B2B-Umfeldes ist es interessant, heutige logistische Wertschöpfungsketten
von Unternehmen zu betrachten. Aufgrund der bestehenden Konkurrenzsituationen ist gerade
in diesen Szenarios Sicherheit von enormer Bedeutung. Deshalb ist es innerhalb solcher
Geschäftsbeziehungen nicht ungewöhnlich, dass jeder Teilnehmer der Föderation sowohl als
IdP als auch als SP auftritt. Dieser Umstand erlaubt es Unternehmen als IdP für seine eigenen
Angestellten und als SP für die Mitarbeiter von den Partnern der Föderation aufzutreten.
Abbildung 6 zeigt ein Beispiel für eine B2B-Umgebung. Dabei ist Bob ein Einkaufsleiter,
welcher die Aufgabe bekommen hat, für seine Firma eine größere Menge von Produkten
(engl. widgets) zu bestellen. Dem Unternehmen von Bob stehen dabei mehrere
Zuliefererfirmen für dieses Produkt zur Auswahl. Bob authentifiziert sich nun auf der
Plattform seines Arbeitgebers und kann dann per SSO auf den Zulieferer seiner Wahl
zugreifen und die Bestellung durchführen.
Wichtig ist, dass Bob nur auf die Dienste der Partnerunternehmen zugreifen darf, für die
innerhalb der Geschäftsbeziehung eine Berechtigung ausgehandelt wurde. Er darf keinesfalls
Zugriff auf alle Daten und Ressourcen besitzen.
12
Widget Provider A
Bob’s Employer
Identity Store
Widget Provider C
Widget Provider B
Bob
Abbildung 6: B2B Szenario – Aufbau von Wertschöpfungsketten [FIMReq]
2.2
Konzepte einer Föderation
Dieser Abschnitt führt vier wesentliche Konzepte ein, die föderierte Identitäts-Umgebung
unterstützen sollten:
Single Sign-On
Siehe Kapitel 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 OnlineBuchhandlung (UserID BücherWurmAlice). Damit das Versandhaus Identitätsinformationen
vom Bankinstitut empfangen und zudem Anfragen bezüglich der Kreditwürdigkeit stellen
kann, müssen die beiden Unternehmen ihre Account-Identifier aufeinander abbilden, d.h., das
Versandhaus muss wissen, dass die ID „Alice123” der Identität „AliceBücherWurm”
entspricht. Aus Gründen der Sicherheit und des Datenschutzes wird beim Account Linking
statt des tatsächlichen Usernamens meist ein Pseudonym (Alias) verwendet. In Abbildung 7
werden beispielsweise statt der tatsächlichen Nutzernamen „AliceBücherWurm” bzw.
„Alice123” die Pseudonyme „PEIIKD889“ bzw. „JKR67HY“ zwischen den beteiligten
Parteien ausgetauscht. Neben der dadurch gewährleisteten Anonymität verhindert der Einsatz
13
von Pseudonymen darüber hinaus Namenskonflikte zwischen verschiedenen Service
Providern.
Attributaustausch
Das Konzept der Föderierung von Identitäten bedeutet mehr als ausschließlich die Fähigkeit,
eine Single Sign-On Umgebung aufbauen zu können. Es sollte auch den sicheren
domänenübergreifenden Austausch individueller Attribute wie z.B. Kontonummer,
Rollenbezeichnungen oder Standort eines Nutzers beinhalten. Die Übertragung von Attributen
- zusammen mit der Identität eines Nutzers - soll Applikationen die Möglichkeit geben, dem
Benutzer personalisierte Dienste und Ressourcen anbieten zu können. Zudem besteht die
Möglichkeit, anhand übersendeter Attributwerte feingranulare Zugriffsentscheidungen
(Autorisierung) zu treffen.
Buchhandel
Bankinstitut
Local User: AliceBücherWurm
Alias
: PEIIKD889
Local User: Alice123
Alias
: JKR67HY
Mapping:
JKR67HY = BücherWurmAlice
Mapping:
PEIIKD889 = Alice123
Abbildung 7: Beispiel Account Linking
Im obigen Beispiel wäre es zum Beispiel sinnvoll, wenn das Versandhaus berechtigt wäre,
vom Bankinsitut die Kreditkartennummer von Alice in Form eines Attribut/Werte-Paares zu
erhalten. Dadurch müsste Alice bei einer Online-Bestellung nicht jedes Mal ihre
Kreditkartennummer neu angeben.
Datenschutz
Innerhalb einer Föderation, in der Nutzerkonten miteinander verbunden und Attribute
ausgetauscht werden, spielt der Datenschutz eine besondere Rolle. Dabei müssen
personenbezogene Daten, neben starken Sicherheitsvorkehrungen bezüglich der Protokolle
und der Transportschicht, unbedingt vor einem unerlaubten Zugriff geschützt werden. Auch
die Anonymität eines Nutzers spielt eine große Rolle. Aus diesen Gründen darf eine
Verbindung von Nutzerkonten nur durchgeführt werden, wenn der Benutzer sein
ausdrückliches Einverständnis dafür gegeben hat. Welche Attribute dabei mit wem
14
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 LoginMasken oder ähnlichen Schwachstellen bei der Erkennung und Authentifizierung von
Benutzern. Web-Services stellen dabei Funktionen von Anwendungen nach außen zur
Verfügung. Sie verhalten sich dabei nicht anders als Schnittstellen für CORBA oder Java
RMI, nur eben einfacher und auch in heterogenen Umgebungen nutzbar. Anwendungen
können Web-Services dynamisch nutzen. Die Idee von SOAs (Service Oriented
Architectures) [SOA] sieht vor, dass Anwendungen Prozesse definieren, mit denen
verschiedene Web-Services im Unternehmen und außerhalb miteinander verbunden werden.
Anwendungen nutzen also Funktionen anderer Programme über Web-Services und verbinden
diese miteinander. Der Web-Service ist dabei eine Schnittstelle. Google hat eine solche
15
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-MailVerschlü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 TransportEbene bieten können, reichen also alleine nicht aus. Deswegen wurden Standards geschaffen
die die Sicherheit auch auf Anwendungsebene gewährleisten sollen. Die wichtigsten
16
Standards dieser Ebene sind WS-Security (siehe Kapitel 2.4.5) und SAML (siehe Kapitel
2.4.2). [WSBasics]
SOAP-Envelope
SOAP-Header
Headerblock
Headerblock
SOAP-Body
Nachrichten -Body
Abbildung 8: Struktur einer SOAP-Nachricht [SOAP12]
2.4
Sicherheitsstandards in einer Identity Federation
Standards spielen in einer Identity Federation eine wichtige Rolle, indem sie die grundlegende
Syntax, Semantik und die grundlegenden Verarbeitungsregeln definieren mit dem Ziel, eine
Zusammenarbeit verschiedener heterogener Systemumgebungen zu erlauben. Diese Standards
bilden die Basis für ein föderiertes Identitätsmanagement.
Dieses Kapitel beschreibt die grundlegenden Standards bzw. Industrie-Initiativen, welche sich
dem komplexen Problem der Identity Federation widmen:
•
•
•
•
Microsoft Passport
Security Assertion Markup Language (SAML)
Liberty Alliance Identity Federation Framework
WS-Security bzw. WS-Federation
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.
17
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.
18
• 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-WebService 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 Microsoft19
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 ITFirmen noch keine Verwendung findet, beschränkt sich diese Diplomarbeit auf den Standard
SAML 1.0 bzw.1.1.
Vorteile des SAML-Standards:
• Plattformunabhängig – SAML trennt das Sicherheits-Framework von den konkreten
Implementierungen und Architekturen verschiedener Hersteller.
• Lose Koppelung von Nutzerdatenbanken – SAML ermöglicht eine verteilte
Speicherung von Nutzerdaten. Die verschiedenen Benutzerverzeichnisse müssen nicht
synchronisiert werden.
• Bedienungsfreundlichkeit für den End-Nutzer – SAML Authentication-Assertions
ermöglichen Single Sign-On.
• Reduzierung der administrativen Kosten für Service Provider – Verwendung von
SAML reduziert innerhalb einer Federated Identity Umgebung die Kosten für den
20
Service Provider (SP), da die Verwaltung von Nutzerinformationen vom Identity
Provider (IdP) übernommen wird.
• Risiko Übertragung – SAML ermöglicht es, das Risiko für eine sichere Verwaltung
der Nutzerdaten vom SP an den IdP zu übertragen.
Die Spezifikation SAML alleine reicht jedoch nicht aus, um das gesamte Spektrum der
Funktionalitäten abzudecken, die für einen Aufbau einer komplexen föderierten Identitätsumgebung nötig sind. Die Regelungen bzgl. eines Vertrauensverhältnisses zwischen zwei
Partnern, wie Benutzerverwaltung und Datenschutz, bleiben außerhalb der SAMLSpezifikation.
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 WebService 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-TokenFormat, um einen sicheren und anonymen Zugriff auf Web-Services zu gewährleisten.
Attribut-basierte Autorisation
Ähnlich dem Web SSO-Szenario kommunizieren im Attribut-basierten AutorisierungsModell zwei unterschiedliche Webseiten miteinander, um Identitätsinformationen
auszutauschen. Jedoch, anders als im SSO Szenario, wird keine Authentication-Assertion,
sondern eine Attribute-Assertion ausgetauscht. Diese Assertion enthält bestimmte Attribute
(z.B. die Rolle eines Nutzers innerhalb eines B2B Szenarios), die einem Benutzer zugeordnet
werden können. Mittels dieser übermittelten Attribute kann eine feingranularere
Autorisierung bzgl. bestimmter Ressourcen vorgenommen werden als dies mit reinen
Authentication-Assertions möglich wäre.
21
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 SicherheitsModellen, ermöglicht den Austausch sicherheitsrelevanter Informationen zur
Authentifizierung und Autorisierung, basiert darüber hinaus auf Standards und ist plattformund herstellerunabhängig.
Konzeptionell unterteilt sich die SAML-Spezifikation 1.1 in folgende Hauptbestandteile
[SAMLArch]:
• SAML-Assertions: Hier werden Informationen zur Authentifizierung, Autorisierung
sowie weitere Session-Attribute innerhalb eines XML-Dokuments beschrieben.
• SAML-Request- und Response-Protokoll: Hier wird definiert, wie SAML-Assertions
angefordert und übermittelt werden.
• SAML Bindings und Profiles: Hier wird festgelegt, wie SAML-Dokumente
(Assertions) in standardisierte Transport- und Messaging-Frameworks eingebunden
werden.
Die SAML-Assertions sind die Basis, um Informationen über ein Subjekt (z.B. über einen
Benutzer) zwischen einem IdP und einem SP auszutauschen. Das SAML-Request-Protokoll
wird vom SP genutzt, um beim IdP eine SAML-Assertion über einen bestimmten Nutzer
abzufragen. Der IdP wiederum antwortet auf diese Anfrage mit einer SAML-ResponseNachricht, 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 SAMLRequest- 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 SAMLImplementierungen unterschiedlicher Hersteller und Organisationen wird meist nicht
die komplette, sondern nur Teile der OASIS SAML-Spezifikation integriert. Die
Conformance Specifications definieren einen Basis-Standard, welcher unbedingt bei
22
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.
23
MajorVersion
Issuer
MinorVersion
IssueInstant
NotBefore
Assertion
Conditions
AssertionID
NotOnOrAfter
Condition
AudienceRestrictionCondition
Audience
Advice
AttributeStatement
SubjectStatement
AuthenticationStatement
AuthorizationDecisionStatement
ds:Signature
Abbildung 9:Struktur einer SAML-Assertion [SSOTele]
Im Folgenden ein Beispiel für eine SAML Authentication-Assertion:
<?xml version="1.0" encoding="UTF-8"?>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:
AssertionID="abc123" IssueInstant="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>
24
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.
25
<AttributeStatement>
Enthält die Attribut-/Werte-Paare (Eigenschaften), welche einem Subjekt zugeordnet
wurden.
Das folgende Schema Fragment definiert das <saml:Assertion>-Element:
<element name="Assertion" type="saml:AssertionType"/>
<complexType name="AssertionType">
<sequence>
<element ref="saml:Conditions" minOccurs="0"/>
<element ref="saml:Advice" minOccurs="0"/>
<choice maxOccurs="unbounded">
<element ref="saml:Statement"/>
<element ref="saml:SubjectStatement"/>
<element ref="saml:AuthenticationStatement"/>
<element ref="saml:AuthorizationDecisionStatement"/>
<element ref="saml:AttributeStatement"/>
</choice>
< element ref ="ds:Signature" minOccurs ="0"/>
</sequence>
<attribute name="MajorVersion" type="integer" use="required"/>
<attribute name="MinorVersion" type="integer" use="required"/>
<attribute name="AssertionID" type="ID" use="required"/>
<attribute name="Issuer" type="string" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
</complexType>
Element <saml:Conditions>
Das Element <saml:Conditions> kann die folgenden optionalen Elemente und Attribute
enthalten:
NotBefore [optional]
Spezifiziert den frühesten Zeitpunkt, zu dem die Assertion gültig ist. Das Zeitformat ist
analog zum Attribut IssueInstant definiert.
NotOnOrAfter [optional]
Spezifiziert den Zeitpunkt, ab dem die Assertion ungültig ist. Das Zeitformat ist analog
zum Attribut IssueInstant definiert.
<Condition> [beliebige Anzahl]
Dieses Element kann verwendet werden, um mit Hilfe eines Extension-Schemas neue
Bedingungen zu definieren.
<AudienceRestrictionCondition> [beliebige Anzahl]
Spezifiziert, an welche Teilnehmer eine Assertion adressiert werden kann.
<DoNotCacheCondition> [beliebige Anzahl]
Dieses Element legt fest, dass eine Assertion sofort verwendet werden muss, d.h., sie darf
nicht für einen zukünftigen Zeitpunkt aufbewahrt werden.
Wird das <saml:Conditions> Element verwendet, so sind einige Regeln zu beachten:
• Werden innerhalb des <saml:Conditions>-Elements
Subelemente verwendet, so ist die SAML-Assertion gültig.
26
keine
Attribute
oder
• Ist ein Attribut oder Subelement ungültig, so ist die gesamte SAML-Assertion ungültig.
• Kann die Gültigkeit für eines der Attribute bzw. Subelemente nicht evaluiert werden, so
ist die Gültigkeit unbestimmt, d.h., die Gültigkeit der Assertion kann nicht eindeutig
bestimmt werden.
• Sind alle Attribute und Subelemente gültig, so ist die gesamte SAML-Assertion gültig.
Das folgende Schema-Fragment definiert das <saml:Conditions>-Element:
<element name="Conditions" type="saml:ConditionsType"/>
<complexType name="ConditionsType">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="saml:AudienceRestrictionCondition"/>
<element ref=”saml:DoNotCacheCondition”>
<element ref="saml:Condition"/>
</choice>
<attribute name="NotBefore" type="dateTime" use="optional"/>
<attribute name="NotOnOrAfter" type="dateTime" use="optional"/>
</complexType>
Element <saml:SubjectStatement>
Die Elemente <saml:Conditions> sowie <saml:Advice> sind optional. Sie enthalten
Informationen über Annahmen sowie Hinweise für die Bearbeitung dieser Nachricht. Daran
schließen sich eine oder mehrere Aussageelemente (Statements) an. Durch die Verwendung
des <saml:SubjectStatement>-Elements können Subjekte (z.B. ein Benutzer)
beschrieben werden. Dieses Element enthält ein <saml:Subject>-Element, welches die
tatsächliche Identität des Subjekts sowie Informationen für die Durchführung der
Authentifizierung enthält. Dabei kann die Identität in Form von Emailadressen, X509v3Zertifikaten oder aber Namen, die sich an die Windows-Domänen-Namenskonvention halten,
vorkommen.
Das <saml:Subject>-Element enthält entweder eines oder beide der folgenden
Subelemente:
<NameIdentifier>
Identifizierung eines Subjekts durch seinen Namen und seine Sicherheitsdomäne.
<SubjectConfirmation>
Enthält Informationen, damit ein Subjekt authentifiziert werden kann.
Das folgende Schema-Fragment definiert das <saml:Subject>-Element:
<element name="Subject" type="saml:SubjectType"/>
<complexType name="SubjectType">
<choice>
<sequence>
<element ref="saml:NameIdentifier"/>
<element ref="saml:SubjectConfirmation" minOccurs="0"/>
</sequence>
<element ref="saml:SubjectConfirmation"/>
</choice>
</complexType>
27
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
<saml:NameIdentifier>-Element vorgibt.
Format
der
Informationen
vom
Das Schema vom Element <NameIdentifier> sieht folgendermaßen aus:
<element name="NameIdentifier" type="saml:NameIdentifierType"/>
<complexType name="NameIdentifierType">
<simpleContent>
<extension base="string">
<attribute name="NameQualifier" type="string" use="optional"/>
<attribute name="Format" type="anyURI" use="optional"/>
</extension>
</simpleContent>
</complexType>
Das Element <saml:SubjectConfirmation> innerhalb des Elements <saml:Subject>
spezifiziert die Beziehung zwischen dem Subjekt und dem Aussteller (Autor) der SAMLAssertion.
Das Element unterteilt sich in folgende Subelemente:
<ConfirmationMethod> [eins oder mehr]
Speichert eine URI-Referenz, die das Protokoll bezeichnet, welches zur Authentifizierung
des Subjekts benutzt werden soll. Dieses Element ist nicht optional, d.h., es muss
mindestens einmal innerhalb des Elements <saml:SubjectConfirmation>
vorkommen.
<SubjectConfirmationData> [optional]
Dieses optionale Element speichert zusätzliche Authentifizierungsinformationen, die von
einem spezifischen Authentifizierungsprotokoll verwendet werden können.
<ds:KeyInfo> [optional]
Enthält den Zugang für den kryptografischen Schlüssel des Subjekts.
Das folgende Schema-Fragment definiert das <saml:SubjectConfirmation>-Element:
<element name="SubjectConfirmation" type="saml:SubjectConfirmationType"/>
<complexType name="SubjectConfirmationType">
<sequence>
<element ref="saml:ConfirmationMethod" maxOccurs="unbounded"/>
<element ref="saml:SubjectConfirmationData" minOccurs="0"/>
<element ref="ds:KeyInfo" minOccurs="0"/>
</sequence>
</complexType>
<element name="SubjectConfirmationData" type="anyType"/>
<element name="ConfirmationMethod" type="anyURI"/>
28
Element <saml:AuthenticationStatement>
Das <saml:AuthenticationStatement>-Element beinhaltet Informationen darüber, ob
das Subjekt bereits von einer Stelle authentifiziert wurde. Dieses Element speichert Daten, die
angeben, wo und wann diese Authentifizierung mit welchem Verfahren durchgeführt wurde.
Die Basis für das Element stellt der SubjectStatementAbstractType. Folgende
Attribute und Elemente kommen hinzu:
AuthenticationMethod [verpflichtend]
Eine URI-Referenz, welche den Authentifizierungsmechanismus spezifiziert, der zur
Authentifizierung des Subjekts verwendet wurde.
AuthenticationInstant [verpflichtend]
Der Zeitpunkt, zu dem das Subjekt authentifiziert wurde (Format UTC).
<SubjectLocality> [optional]
Die DNS-Domäne und die IP-Adresse der Autorität, bei der das Subjekt authentifiziert
wurde.
<AuthorityBinding> [beliebige Anzahl]
Referenz auf eine Instanz, bei der ggf. weitere Informationen bzgl. des Subjekts abfragbar
sind.
Das folgende Schema definiert das <saml:AuthenticationStatement>-Element:
<element name="AuthenticationStatement" type="saml:AuthenticationStatementType"/>
<complexType name="AuthenticationStatementType">
<complexContent>
<extension base="saml:SubjectStatementAbstractType">
<sequence>
<element ref="saml:SubjectLocality" minOccurs="0"/>
<element ref="saml:AuthorityBinding"minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute name="AuthenticationMethod"
type="anyURI"use=”required”/>
<attribute name="AuthenticationInstant"
type="dateTime"use=”required”/>
</extension>
</complexContent>
</complexType>
Element <saml:AuthorizationDecisionStatement>
In diesem Element befinden sich Informationen über Autorisierungsentscheidungen bzgl. des
Zugriffs eines Subjekts auf bestimmte Ressourcen. Dabei beschreibt dieses Element die
Ressource, auf die zugegriffen werden soll, die Aktion, die darauf ausgeführt wird und
letztendlich die Entscheidung, ob diese Aktion ausgeführt werden darf oder nicht (z.B. ein
schreibender Zugriff). Die Ressource wird dabei durch eine URI-Referenz identifiziert.
Der Typ SubjectStatementAbstractType wird um folgende Attribute und Elemente
erweitert:
Ressource [verpflichtend]
Eine URI-Referenz, welche die Ressource identifiziert, auf die zugegriffen werden soll.
29
Decision [verpflichtend]
Enthält die Entscheidung der SAML-Autorität. Mögliche Werte sind: Permit, Deny,
Indeterminate.
<Action> [eins oder mehr]
Art der Aktionen, die auf der Ressource ausgeführt werden dürfen.
<Evidence> [optional]
Eine Menge von SAML-Assertions, welche von einer SAML-Autorität herangezogen
wurden, um die Authorization-Assertion zu erstellen.
Das folgende Schema definiert das <saml:AuthorizationDecisionStatement>Element:
<element name="AuthorizationDecisionStatement"
type="saml:AuthorizationDecisionStatementType"/>
<complexType name="AuthorizationDecisionStatementType">
<complexContent>
<sequence>
<element ref="saml:Action" maxOccurs="unbounded"/>
<element ref="saml:Evidence" minOccurs="0"/>
</sequence>
<attribute name="Resource" type="anyURI" use="required"/>
<attribute name="Decision" type="saml:DecisionType"
use="required"/>
</extension>
</complexContent>
</complexType>
Element <saml:AttributeStatement>
Dieses Element enthält die Eigenschaften bzw. Attribute, welche einem Subjekt zugeordnet
wurden. Die SAML-Autorität beglaubigt mit der Generierung eines Attribute-Statements die
Eigenschaften eines Subjekts.
Der SubjectStatementAbstractType wird um folgendes Element erweitert:
<Attribute> [verpflichtend]
Spezifiziert ein Attribut für ein Subjekt. Das Element muss mindestens einmal in einem
<saml:AttributeStatement> vorkommen.
Das folgende Schema-Fragment definiert das <saml:AttributeStatement>-Element:
<element name="AttributeStatement" type="saml:AttributeStatementType"/>
<complexType name="AttributeStatementType">
<complexContent>
<sequence>
<element ref="saml:Attribute" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Das Element <saml:Attribute> enthält wiederum mindestens ein Unterelement
<saml:AttributeValue>. Dieses Element speichert den Wert eines Attributs.
30
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.
Identity Provider
(Trusted SAML Authority)
SAML-Request
SAML-Response
SAML
Assertion
SAML Query
Service Provider
(SAML Consumer)
Abbildung 10: Austausch von SAML-Request- & Response-Nachrichten
Das SAML-Request-Protokoll definiert folgende Anfragetypen [SAMLProt]:
•
•
•
•
•
•
SubjectQuery
AuthenticationQuery
AttributeQuery
AuthorizationDecisionQuery
AssertionIDReference
AssertionArtifact
Der Aufbau einer SAML-Response-Nachricht bleibt stets gleich, unabhängig von der Art der
Anfrage.
Im Folgenden wird auf die Art und den Aufbau der SAML-Request-Nachrichten
eingegangen.
RequestAbstractType
Dieser Complex-Type definiert Attribute und Elemente für den allgemeinen Aufbau einer
SAML-Request-Nachricht.
31
Folgende Attribute und Elemente müssen bzw. können in einem SAML-Request vorhanden
sein:
RequestID [verpflichtend]
Eine eindeutige ID für jede Anfrage (xsd:ID).
MajorVersion [verpflichtend]
SAML-Versionsnummer.
MinorVersion [verpflichtend]
SAML-Versionsnummer.
IssueInstant [verpflichtend]
Zeitpunkt, zu dem der SAML-Request generiert wurde (Format UTC).
<RespondWith> [beliebige Anzahl]
Art der Response-Nachricht (z.B. Authentication-Assertion), welche der Empfänger vom
Sender erwartet. Beinhaltet ein SAML-Request kein <RespondWith> Element, so kann
die SAML-Autorität mit einem Statement eines beliebigen Typs (z.B. Attribute-Statement)
antworten.
<ds:Signature> [optional]
XML Signature, um die Anfrage zu authentifizieren.
Element <samlp:Request>
Dieses Element spezifiziert das Root-Tag eines SAML-Requests. Im Folgenden die
Zusammensetzung eines <samlp:Request>-Elements:
<SubjectQuery> [optional]
Eine Erweiterung, die es mittels eines selbstdefinierten Schemas erlaubt, neue
Anfragetypen zu definieren.
<AuthenticationQuery> [optional]
Anfrage nach einer Authentication-Assertion.
<AttributeQuery> [optional]
Anfrage nach einer Attribute-Assertion.
<AuthorizationDecisionQuery> [optional]
Anfrage nach einer Authorization-Assertion.
<AssertionIDReference> [eins oder mehr]
Anfrage nach einer Assertion mittels einer Referenz auf den Wert des Attributs
AssertionID.
<AssertionArtifact>[eins oder mehr]
Anfrage nach einer Assertion mit Hilfe eines Artefakts. Dieses Artefakt ist ein eindeutiger
Zeiger auf eine Assertion, welche von einer SAML-Autorität generiert wurde.
32
Das folgende Schema Fragment definiert das <samlp:Request>-Element:
<element name="Request" type="samlp:RequestType"/>
<complexType name="RequestType">
<complexContent>
<extension base="samlp:RequestAbstractType">
<choice>
<element ref="samlp:Query"/>
<element ref="samlp:SubjectQuery"/>
<element ref="samlp:AuthenticationQuery"/>
<element ref="samlp:AttributeQuery"/>
<element ref="samlp:AuthorizationDecisionQuery"/>
<element ref="saml:AssertionIDReference"
<element ref="samlp:AssertionArtifact"
</choice>
</extension>
</complexContent>
</complexType>
Element <samlp:Response>
Das <samlp:Response>-Element ist das Wurzelelement einer SAML-Response-Nachricht.
Es spezifiziert den Status eines SAML-Requests. Die Antwort kann dabei keine, eine oder
mehrere Assertions enthalten. Der Aufbau einer SAML-Response-Nachricht ist stets gleich,
unabhängig von dem vorangegangenen SAML-Request. Die Basis dieses Elements bildet der
ResponseAbstractType. Die Attribute bzw. Elemente entsprechen im Wesentlichen
denen des RequestAbstractTypes mit der Ausnahme, dass das Attribut RequestID
durch das entsprechende Attribut ResponseID ersetzt wurde. Zudem wurde das Element
<samlp:RespondWith> durch <samlp:Recipient> ausgetauscht. Dieses optionale
Element speichert den beabsichtigten Empfänger der Nachricht in Form einer URI.
ResponseAbstractType wird darüber hinaus durch folgende Elemente erweitert:
<Status> [verpflichtend]
Enthält Statusinformationen bzgl. eines zugehörigen SAML-Requests.
<Assertion> [beliebige Anzahl]
Enthält eine SAML-Assertion eines beliebigen Typs (z.B. Authentication-Assertion).
<element name="Response" type="samlp:ResponseType"/>
<complexType name="ResponseType">
<complexContent>
<extension base="samlp:ResponseAbstractType">
<sequence>
<element ref="samlp:Status"/>
<element ref="saml:Assertion" minOccurs="0"
</sequence>
</extension>
</complexContent>
</complexType>
Das Element <samlp:Status> ist in folgende Subelemente unterteilt:
<StatusCode> [verpflichtend]
Enthält den Code, welcher den Status einer korrespondierenden SAML-Anfrage
repräsentiert.
33
<StatusMessage> [optional]
Nachricht, die an einen Operator zurückgegeben werden kann (z.B. Fehlermeldung).
<StatusDetail> [optional]
Speichert zusätzliche Informationen, um bestimmte Fehlermeldungen genauer zu erläutern.
<element name="Status" type="samlp:StatusType"/>
<complexType name="StatusType">
<sequence>
<element ref="samlp:StatusCode"/>
<element ref="samlp:StatusMessage" minOccurs="0"/>
<element ref="samlp:StatusDetail" minOccurs="0"/>
</sequence>
</complexType>
Das Element <samlp:StatusCode> spezifiziert eine beliebige, möglicherweise
verschachtelte Anzahl von Codes, welche den Status eines zugehörigen SAML-Requests
angeben. Es enthält die folgenden Attribute bzw. Elemente:
Value [verpflichtend]
Der Wert eines Status-Codes. Der Typ dieses Attributs ist QName.
<StatusCode> [optional]
Ein untergeordneter (verschachtelter) Status-Code, um die Fehlermeldung genauer zu
spezifizieren.
In
der
SAML
Spezifikation 1.1 wurden folgende Standardwerte für
<samlp:StatusCode>-Element bzw. für das zugehörige Attribut Value definiert:
das
Success
Die Anfrage war erfolgreich, d.h., die angefragte SAML-Assertion konnte erfolgreich
übermittelt werden.
VersionMismatch
Die SAML-Autorität konnte die Anfrage nicht bearbeiten, da die SAML-Version der
Anfragenachricht nicht korrekt war.
Requester
Aufgrund eines Fehlers auf Seite des Anfragenden (SP) konnte die Anfrage nicht
verarbeitet werden.
Responder
Aufgrund eines Fehlers auf Seite des Antwortenden (IdP) konnte die Anfrage nicht
verarbeitet werden.
RequestVersionTooHigh
Der Aussteller einer SAML-Nachricht kann auf die Anfrage nicht antworten, da die
Protokoll-Version des SAML-Requests zu hoch ist, d.h., der Antwortende unterstützt eine
niedrigere Version.
RequestVersionTooLow
Der Aussteller einer SAML-Nachricht kann auf die Anfrage nicht antworten, da die
Protokoll-Version des SAML-Requests zu niedrig ist.
34
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 SOAPNachricht unabhängig vom darunter liegenden Transportprotokoll ist, muss eine SAMLAutorität als Standard das SOAP über HTTP Binding definieren. Eine genaue Definition
dieses Bindings kann unter [SOAPAdj] gefunden werden.
Ein Beispiel für eine SAML-Anfrage mittels SOAP über HTTP:
POST /SamlService HTTP/1.1
Host: 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>
2.4.3.5 SAML-Profiles
Die SAML-Profiles [SAMLBind] legen fest, wie SAML-Assertions in ein MessageFramework oder ein Protokoll eingebunden und wieder extrahiert werden.
Das OASIS Security Services Technical Committee definiert in SAML 1.1 zwei WebBrowser-Profile, um Single Sign-On (SSO) möglich zu machen:
35
•
•
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 SAMLAssertions verwendet werden können, um eine Web-Service Nachricht abzusichern.
• Das Liberty Alliance Projekt definiert mehrere verschiedene Profile, welche den SAML
Standard erweitern.
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 SAMLArtefakt 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/ArtifactProfile:
Web Browser
Source Site
Destination Site
(1)
(2)
(3)
(4)
(5)
(6)
Abbildung 11: Single Sign-On mit dem Browser/Artifact Profile
(1)
Zugriff auf Inter-Site Transfer Service: Ein Nutzer/Browser versucht per Link, auf
eine Ressource der Destination Site zuzugreifen. Da der Nutzer/Browser der
Zielseite unbekannt ist und die gewünschte Ressource geschützt ist, kann dieser
nicht direkt auf die Ressource zugreifen. Stattdessen ruft der Nutzer/Browser
mittels eines Hyperlinks den sog. Inter-Site Transfer Service (ISX) URL auf. Dieser
URL setzt sich aus folgenden Bestandteilen zusammen:
http(s)://<inter-site transfer host name>?TARGET=<target>
36
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 SAMLAssertion zu erhalten. Existiert eine solche SAML-Assertion, so wird diese von der
Source-Site in Form einer SAML-Response- Nachricht an die Destination Site
geschickt.
(6)
Zugriff auf die gewünschte Ressource: An den Browser des Nutzers wird eine
HTTP-Antwortnachricht geschickt, die angibt, ob der Benutzer auf die gewünschte
Ressource zugreifen darf oder nicht.
Wichtig ist, dass ein SAML-Artefakt nur für eine Anfrage verwendet werden kann (one-timeuse), um Sicherheitsprobleme wie z.B. Replay-Attacken zu vermeiden.
Browser/POST-Profile
Dieses Profil ermöglicht es, Authentifizierungs- bzw. Autorisierungsdaten direkt, ohne die
Verwendung eines SAML-Artefakts, zu übertragen. SAML-Assertions werden dabei durch
ein HTML-Formular zuerst in den Browser des Nutzers geladen, um danach als Teil eines
HTTP Post Payloads an die Destination Site übertragen zu werden.
Die folgende Grafik zeigt einen Single Sign-On Prozess, beruhend auf dem Browser/POSTProfile:
Web Browser
Source Site
Destination Site
(1)
(2)
(3)
(4)
Abbildung 12: Single Sign-On mit dem Browser/POST Profile
37
(1)
(2)
(3)
(4)
Zugriff auf den Inter-Site Transfer Service: analog zu Browser/Artifact-Profile.
Ü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.
Der Browser übermittelt das Formular bzw. Formulardaten an die Destination Site.
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 XMLDokumente 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.
38
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 HTTPRedirect 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.
39
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.
40
• 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-OnVerfahren 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.
41
Im Folgenden ein Überblick über die Konzepte, die durch die Anwendung des Single SignOn- und Federation-Protokolls umgesetzt werden können:
•
•
•
•
•
•
Account Linking/Federation – Ein Principal hat die Möglichkeit, seine Identität
(gespeichert bei einem Identity Provider) mit seiner Identität (gespeichert bei einem
Service Provider) zu verbinden.
Authentication Context – Ein Service Provider kann die Authentifizierungsart (z.B.
Username/Passwort) festlegen, die benutzt werden soll, wenn sich ein Principal
einloggt.
Account Handle – Ein Identity Provider kann für einen Principal, während der
Kommunikation mit einem Service Provider, ein temporäres Pseudonym anstatt seiner
tatsächlichen Identität verwenden.
Dynamic Proxying – Erhält ein IdP eine Authentifizierungsanfrage eines SPs bzgl.
eines Principals, obwohl dieser Nutzer bereits von einem anderen IdP authentifiziert
wurde, so kann der erste IdP die Anfrage an den zweiten IdP weiterleiten.
Identity Provider Introduction – Existiert in einer Domäne mehr als ein IdP, so kann
ein SP nach dem IdP suchen, der für den Principal verantwortlich ist.
Message Exchange Profiles – Der Authentication-Request legt fest, wie Nachrichten
zwischen IdP und SP ausgetauscht werden sollen.
Dabei werden vier unterschiedliche Profile unterstützt [LibBind]:
o Liberty Browser Artifact Profile (basiert auf SAML 1.1 Artefakten bzw.
Assertions)
o Liberty Browser POST Profile (Erweiterung des gleichnamigen SAML 1.1
Profils)
o Liberty WML POST Profile (optimiert für WAP-Browser)
o Liberty Enabled Client and Proxy Profile (Unterstützung von Proxy-Gateways)
Name Registration Protokoll
Dieses Protokoll ermöglicht es einem SP, in Verbindung mit einem IdP einen Namen für
einen gemeinsamen Nutzer zu registrieren. Dabei ist es nicht erforderlich, dass der SP dem
IdP detaillierte Informationen über die vorhandene lokale Identität des Benutzers mitteilt.
Beim Aufbau einer Föderation generiert der IdP einen sog. Opaque Handle (Pseudonym) für
den Principal. Auf der Basis dieses Name Identifiers erfolgt die Kommunikation mit dem SP
(Element <IDPProvidedNameIdentifier>). Der SP kann für den gleichen Principal einen
anderen Opaque Handle definieren (Element <SPProvidedNameIdentifier>).
Federation Termination Protokoll
Das Federation Termination Protokoll benachrichtigt sowohl die Service- als auch die
Identity-Provider über das Ende einer Föderation. Dies hat zur Konsequenz, dass ein SP den
Authentication-Assertions eines IdPs in Zukunft nicht mehr vertraut. Das Protokoll verwendet
für diesen Zweck das Element <FederationTerminationNotification>.
42
Single Logout Protokoll
Dieses Protokoll benachrichtigt sowohl die beteiligten SP als auch den zuständigen IdP, dass
die aktuelle Session für einen Principal beendet werden soll. Für diese Operation wird eine
<LogoutRequest> Nachricht verwendet.
Name Identifier Mapping Protokoll
Hier wird definiert, wie ein SP einen Name Identifier eines Principals erhalten und verstehen
kann, wenn diese ID im Namensraum eines anderen SPs erstellt wurde.
Dazu muss der betroffene SP eine Anfrage an den IdP stellen, der mit beiden Service
Providern ein Account Linking bzgl. dieses Principals besitzt. Auf diese Weise können beide
SP miteinander kommunizieren, ohne dass für den Benutzer eine Identity Federation
zwischen diesen zwei Parteien besteht.
Der Ablauf eines Liberty SSO-Prozesses soll anhand der folgenden Grafik deutlich gemacht
werden:
User/Browser
Service Provider
Identity Provider
1. HTTP Request()
2. Suche passenden IdP
3. HTTP Response mit
AuthnRequest()
4. HTTP Request mit AuthnRequest()
6. HTTP Response mit AuthnResponse oder Artifact()
7. HTTP Request mit AuthnResponse
oder Artifact()
5. Verarbeite AuthnRequest
8. HTTP Request mit
Artifact()
9. HTTP Response mit
Assertion()
10. Verarbeite Assertion
11. HTTP Response()
Abbildung 13: Liberty Alliance SSO-Prozess
Die Schritte 8 und 9 sind nur dann notwendig, wenn das Liberty Browser/Artifact-Profil
verwendet wird. Diese beiden Schritte basieren vollständig auf dem SAML Browser/ArtifactProfil (SAML-Request/Response).
Wie anfangs erwähnt, sind die Liberty ID-FF Protokolle im Wesentlichen eine Erweiterung
der SAML-Spezifikation. Dabei ergänzt der Liberty <lib:AuthnRequest>
den
43
<lib:AuthnResponse>
ist
abgeleitet
vom
samlp:RequestAbstractType;
die
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 SAMLDatenstruktur. Die genauen Schemata der einzelnen Liberty Elemente (wie z.B.
<lib:AuthnRequest>) können unter [LibID] eingesehen werden.
samlp:RequestAbstractType
samlp:ResponseType
lib:AuthnRequest
lib:AuthnResponse
lib: ProviderID
ForceAuth (boolean)
IsPassive (boolean)
Federate (boolean)
lib: ProtocolProfil
lib: AuthnContext
lib: RelayState
lib: AuthnContextComparison
lib: ProviderID
lib: RelayState
attribute: ID
saml: AssertionType
saml:AuthenticationStatementType
lib:AuthenticationStatementType
lib: AuthnContext
lib:AssertionType
attribute: InResponseTo
attribute: ID
attribute: ReAuthenticateOnOrAfter
attribute: SessionIndex
Abbildung 14: Erweiterungen des Liberty ID-FF Protokolls
Ein Beispiel für einen <lib:AuthnRequest> bzw. eine <lib:AuthnResponse> befindet sich im
Anhang A.2 dieser Diplomarbeit.
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]
44
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 BenutzerAnmeldung, 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-zuEnde Verbindung jedoch unerlässlich. Hier kommt WS-Security ins Spiel.
WS-Security setzt auf bereits bestehenden Standards und Spezifikationen auf. Deshalb muss
in WS-Security keine vollständige Sicherheitslösung definiert werden. WS-Security ergänzt
45
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-SecurityHeader 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 SAMLAssertion. 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 WSPolicy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation und WSAuthorization. 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.
46
Das WS-Federation Modell beschreibt, wie die Blöcke der WS-Security- bzw. WS-TrustSpezifikation 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 WSFederation jedoch noch nicht an eine Standardisierungsorganisation weitergeleitet, d.h., WSFederation 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 WebServices, 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
Gemeinsamkeiten
/Überlappungen
Verknüpfung von
Nutzerkonten (Account
Linking)
Vertraulichkeit/Anonymität
Liberty Alliance
Verknüpfung von
Nutzerkonten auf Basis von
Opaque Identifiers
Empfehlungen bzgl. der
Optionale Unterstützung
Bereiche Schutz bzw.
durch Einsatz von WSAnonymität von persönlichen Policy und WS-Privacy.
Daten wurden in die
Spezifikation aufgenommen.
Erweiterung von SAMLAssertions, um
Authentifizierungs- bzw.
Authorisierungstoken
zwischen Providern
austauschen zu können.
Richtlinien bzgl.
Beschäftigt sich mit Fragen
Geschäftsvereinbarungen und des Aufbaus einer
Sicherheitsregeln (Policies) Vertrauens-beziehung (siehe
Business Guidelines und
Authentication Context).
Erweiterung von SAML.
Sicherheitsfragen/DatenSicherheitsfragen können
schutz
mittels der Technologien SSL
und WS-Security gelöst
werden.
Security Tokens
Client Profile
SSO Kontrollfluss (SSO
Control Flow)
WS-Federation
Verknüpfung von
Nutzerkonten unter
Verwendung des
Pseudonym Services
Definition von Profilen
sowohl für Browser als auch
für Smart Clients.
Baut auf verschiedenen
WS-Security Profilen
auf (z.B. X.509v3).
Zusätzlich können auch
SAML Tokens
verwendet werden.
Diese Fragen werden
momentan nicht
abgedeckt.
Basiert auf WS-Trust,
WS-Policy und WSMetadata.
Sicherheitsfragen
können mittels der
Technologien SSL und
WS-Security gelöst
d
Definition
von Profilen
sowohl für Browser als
auch für Smart Clients.
SSO-Ablauf sowohl auf Basis SSO-Ablauf vor allem
der Front- als auch der Back- für den Front-Channel
Channel Technologie.
Mechanismus. Der
Back-Channel
Mechanismus wird
erwähnt, jedoch nicht
empfohlen.
47
Unterschiede
Entwicklung
Fokus
Reifheitsgrad
Implementierungskosten
Entwickelt als offener
Standard unter Teilnahme
von Unternehmen, EndNutzern und Non-ProfitOrganisationen.
Entwickelt von
Microsoft, IBM,
VeriSign, BEA und RSA
Security.
Fokus auf Technologie-,
Geschäfts- und Policyfragen
im Bereich Federated Identity
Management.
Fokus alleine auf der
technologischen
Komponente des
Federated Identity
Managements.
Ausgereifte Spezifikationen,
die über die letzten zwei
Jahre von Unternehmen und
Organisationen entwickelt
wurden. Die Spezifi-kationen
werden aktuell in zahlreichen
Produkten unterstützt.
Noch kein offizieller
Standard. Die Spezifikationen werden aktuell
nur in wenigen
Produkten unterstützt.
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, WebService Anfragen zu stellen bzw. entsprechende Web-Service Antworten zu verarbeiten. Ein
Beispiel für einen aktiven Client ist eine SOAP-Applikation.
WS-Federation Passive hingegen beschäftigt sich mit dem Aufbau von Föderationen bei einer
Teilnahme von passiven Clients. Ein typisches Beispiel für solch einen Client ist ein HTTP
Browser. Dies bedeutet, dass der Austausch von Nachrichten auf den Funktionalitäten von
HTTP 1.1 (GET, POST, Redirects und Cookies) basieren muss.
Da an einer Föderation meist sowohl passive als auch aktive Clients beteiligt sind, müssen
beide Spezifikationen (WS-Federation Passive Client, WS-Federation Active Client) in
föderierten Umgebungen implementiert werden.
WS-Federation unterstützt vier unterschiedliche Security Tokens:
•
•
•
•
X.509v3 Token
Kerberos Token
XrML Token
SAML Token
Diese Tokenformate können verwendet werden, um Identitätsinformationen zwischen
Providern auszutauschen. Obwohl SAML Token von WS-Federation unterstützt werden, ist
jedoch keine vollständige Interoperablität mit dem SAML 2.0 Standard gegeben. Dies zeigt,
dass der Konkurrenzkampf der Föderationstandards untereinander noch nicht beendet ist
[FedTrend].
48
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
WSFederation
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 SPSeite
Account Linking auf Initiative des IdPs
Ja
Ja
Nein
Nein
Nein
Ja
Account Linking auf Initiative des SPs
Nein
Ja
Ja
Erstellung eines Nutzerkontos beim SP auf
Initiative des IdPs (außerhalb des SSOProzesses)
Nein
Nein
Nein
7
8
9
Tabelle 2: Vergleich der SSO-Protokolle
In der obigen Tabelle werden die Begriffe Front-Channel und Back-Channel verwendet. Ein
Front-Channel bezeichnet die Verbindung, die zwischen einem Webbrowser eines Endnutzers
und einem IdP bzw. SP aufgebaut wird. Über diesen Kanal können per HTTP-Redirect
Parameter, wie z.B. ein SAML-Artefakt gesendet werden. Der Back-Channel bezeichnet
hingegen denjenigen Kanal, der zwischen einem IdP und einem SP aufgebaut wird, um
SOAP-Nachrichten auszutauschen.
2.6
Zusammenfassung
Heutige Unternehmen und Organisationen werden zunehmend vor die Herausforderung
gestellt, neben ihren eigenen Mitarbeitern und Kunden auch den Mitarbeitern und Kunden
ihrer Partnerunternehmen den Zugriff auf bestimmte Ressourcen und Dienste zu ermöglichen.
Herkömmliche Identity Management Systeme sind aus Effizienz- und Sicherheitsgründen für
diese neue Entwicklung ungeeignet. Einen Lösungsansatz, um diese Probleme zu beheben,
bieten die Konzepte und Technologien aus dem Bereich Federated Identity Management.
49
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. SAMLAssertions 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 WSSecurity bestehende Standards wie XML Encryption, XML Signature und SAML.
Obwohl sich der SAML Standard bzw. die Standards der Liberty Alliance mit den WS50
Spezifikationen im Bereich Federated Identity (vgl. WS-Federation) teilweise überlappen,
ergänzen sie sich doch in den meisten Bereichen. Sowohl SAML als auch die Standards der
Liberty Alliance bieten beispielsweise die Möglichkeit, WS-Security bei der Übertragung von
Nachrichten einzusetzen. Trotzdem ist der Konkurrenzkampf zwischen den Föderationsstandards noch nicht beendet. WS-Security und WS-Federation sind beispielsweise nach wie
vor nicht vollständig interoperabel bzgl. des SAML-Standards.
51
Kapitel 3: Einrichtung der Testumgebungen
3.
Einrichtung der Testumgebungen
In diesem Kapitel werden die Softwareprodukte vorgestellt, welche in dieser Diplomarbeit
eingesetzt wurden, um - basierend auf der Security Assertions Markup Language SAML eine heterogene Federated Identity Umgebung zu realisieren.
Neben allgemeinen Komponenten, wie z.B. verwendete Webserver oder Datenbanken,
werden hier vor allem die zu testenden Identity- und Access-Management-Produkte
(Netegrity Siteminder, RSA Cleartrust, IBM Tivoli Access Manager) detailliert vorgestellt.
Abschließend wird die komplette System-Architektur erläutert, die aus diesen
Softwarelösungen aufgebaut wurde. Mit Hilfe dieser Systemarchitektur sollen die SAMLAnwendungsfä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
52
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 SAMLImplementierung 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.
53
Abbildung 15 gibt einen Überblick über die Architektur des Netegrity Siteminders.
2
1
Webserver
mit
Siteminder Agent
Geschützte Ressourcen
6
7
3
5
4
Benutzer
User
Datenbank
Siteminder
Policy Server
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..
54
●
●
●
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.
55
Der SAML Affiliate Agent ist eine standalone Komponente, welche auf der Seite des Service
Providers (SP) installiert wird. Diese Seite wird oft auch als Consumer- bzw. Affiliate Site
bezeichnet. Damit jedoch ein domänenübergreifendes Single Sign-On möglich wird, muss auf
der Seite des Identity Providers (Portal-Site) eine vollständige Netegrity Siteminder
Installation vorliegen. An dieser Stelle sind die Daten und Profile der Nutzer, welchen der
Zugriff auf föderierte Dienste gestattet werden soll, gespeichert. Die Affiliate-Site verwaltet
und speichert keine Nutzerinformationen.
Aufgabe des SAML Affiliate Agents ist es, SAML-Nachrichten, welche von einer
vertrauenswürdigen Portal-Site, d.h. von der dort installierten Netegrity SAML-Autorität
geschickt wurden, zu konsumieren und zu validieren. Ist die erhaltene Nachricht gültig bzw.
ist sichergestellt, dass diese von einem bekannten und vertrauenswürdigen IdP kommt, kann
der SAML Affiliate Agent dem entsprechenden Nutzer Zugriff auf die gewünschte Ressource
gewähren.
Der SAML Affiliate Agent besteht aus zwei grundlegenden Komponenten [NeteAff]:
•
Webserver Plugin für die Affiliate Services - Die Konfiguration dieses Plugins erfolgt
durch die Datei AffiliateConfig.xml.
• Affiliate Server - Abhängig vom verwendeten Betriebssystem läuft der Affiliate
Server als Unix-Dämon oder als NT-Service. Konfiguriert wird dieser Server mittels
der Datei affiliateserverconf.properties. Der Affiliate Server kommuniziert im Auftrag
des Webserver Plugins mit der Portal Seite.
Die folgende Abbildung zeigt die Komponenten des SAML Affiliate Agents.
Abbildung 16: Komponenten des SAML Affiliate Agents [NeteAff]
56
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.
57
•
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.
2.
3.
4.
5.
6.
Installation und Konfiguration des Policy Servers
Installation und Konfiguration des Policy Server OptionPacks
Installation und Konfiguration des Webagents
Installation und Konfiguration des Webagent OptionPacks
Konfiguration der Federation Security Services
Konfiguration der Federation Web-Services Applikation
58
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 LDAPServers.
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 PropertiesDateien [NeteFed]:
59
●
●
●
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 SAMLNachrichten 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
Die Web Access Management Software RSA [RSA] Cleartrust 5.5 ist das zweite Produkt,
welches im Rahmen dieser Diplomarbeit eingesetzt wurde, um eine föderierte und heterogene
Identitätsumgebung aufzubauen. In Kombination mit dem externen FIM-Modul RSA
Federated Identity Manager 2.5 implementiert dieses Produkt zu großen Teilen sowohl die
SAML 1.0 als auch die SAML 1.1 Spezifikation. Dabei wird sowohl das Browser/Artifact- als
auch das Browser/POST-Profil unterstützt.
RSA Cleartrust 5.5 ist, wie auch der Netegrity Siteminder von Computer Associates, eine
Softwarelösung, um Webseiten und Webapplikationen vor unautorisiertem Zugriff zu
schützen.
60
Im Folgenden ein kurzer Überblick über die Funktionalitäten von RSA Cleartrust 5.5 und
RSA FIM 2.5 [RSAGuide, RSAFIM]:
Management von Nutzeridentitäten
RSA Cleartrust ermöglicht die Verwaltung und Steuerung der Lebenszyklen von
Benutzeridentitäten. Neben der Erschaffung von Identitäten wird auch eine flexible
Terminierung derselben unterstützt.
Web Zugriff-Management
Cleartrust ermöglicht den Aufbau und die Verwaltung von Policies (Sicherheitsregeln),
welche die Privilegien eines Nutzers prüfen können. Anhand dieser Privilegien kann
entschieden werden, ob ein Nutzer für eine spezifische Online-Ressource autorisiert werden
kann. Mit Hilfe solcher Sicherheitsregeln besteht die Möglichkeit, feingranulare
Zugriffskriterien zu definieren. Diese können sowohl statisch (z.B. Abteilung eines Nutzers)
als auch dynamisch (z.B. Kontostand eines Nutzers) sein.
Authentifizierungsmanagement
Um einen Benutzer zu authentifizieren, können unterschiedliche Authentifizierungsmethoden
verwendet werden.
RSA Cleartrust 5.5 unterstützt folgende Authentifizierungsmechanismen:
•
•
•
•
Basic – Ein Benutzer authentifiziert sich mittels seines Nutzernamens und seines
Passworts.
X.509 Zertifikate – Der Webbrowser eines Nutzers kann konfiguriert werden, so dass
dieser Browser-Zertifikate zur Authentifizierung akzeptiert.
Windows NT – Ein User kann auf Basis seines Windows NT Kontos authentifiziert
werden.
Custom – Die RSA Cleartrust Webagent Erweiterung (WAX) kann genutzt werden,
um neue Authentifizierungsroutinen zu schreiben und in das System zu integrieren.
Diese zahlreichen Authentifizierungsmethoden sorgen dafür, dass ein sicherer Zugriff auf das
Netzwerk auch außerhalb einer Firewall möglich ist.
Verteilte Administration
Administrative Aufgaben können auf verschiedene Geschäftseinheiten aufgeteilt werden.
Diese können sich sowohl innerhalb als auch außerhalb einer Organisation befinden.
Auditing und Reporting
Dieses Feature ermöglicht eine einheitliche Aufzeichnung aller auftretenden Ereignisse in der
Systemumgebung. Im Wesentlichen sind dies Aktionen von Nutzern, Administratoren und
Systemprozessen.
61
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 CleartrustBestandteile.
Benutzer
RSA Cleartrust Server
Key Server
Dispatcher
Webserver
mit
Cleartrust Agent
Authorization Server
User
Datenbank
Entitlements Server
Policy
Datenbank
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.
62
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.
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]:
63
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.
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/AccessManagement-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 WSFederation 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 AdminServer und zum anderen der Managed-Server. Der Admin-Server übernimmt anfallende
Verwaltungsaufgaben (z.B. Kontrolle des Managed-Servers). Der Managed-Server ist das
Herzstück, auf dem die SAML-Autorität des Federated Identity Managers läuft. Diese kann
sowohl als Identity Provider bzw. Asserting Party (Ausstellung von SAML-Assertions) als
auch als Service Provider bzw. Relying Party (Konsumierung von SAML-Assertions)
fungieren.
64
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
65
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 ApplikationsServer ausgeführt werden. Um dies zu erreichen, muss die Datei admingui.war in das Tomcat
webapps-Verzeichnis kopiert werden.
Zu Schritt 5:
Der RSA Apache Webagent 2.5 wurde mit Hilfe des zugehörigen Installationsprogramms in
den Apache 2.0 HTTP-Webserver integriert.
66
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 FIMProdukt 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 LDAPVerzeichnis 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.
Der Tivoli Access Manager stellt Dienste zur Authentifizierung, Autorisierung und zum
Session-Management zur Verfügung. Die Komponenten Authorization- und Policy-Server
bilden dabei den Policy Decision Point (PDP). Als Policy Enforcement Point (PEP) wurde im
Rahmen dieser Diplomarbeit ein HTTP-basierter WebSeal Reverse Proxy verwendet.
Das Modul TFIM 6.0 wird benötigt, um eine Federated Identity Lösung aufbauen zu können.
Die Funktionalitäten des TAMs 5.1 sind im Wesentlichen die gleichen wie die des RSA
Cleartrusts 5.5 und des Netegrity Siteminders 6.0. Auch der TAM 5.1 unterstützt ein
umfassendes Authentifizierungs- und Autorisierungsmanagement, d.h., auch hier können
komplexe Policies zum Schutz von Webressourcen definiert werden.
Im Folgenden eine kurze Zusammenfassung der wichtigsten Funktionalitäten des TAMs 5.1
[TAMRed]:
67
●
●
●
●
●
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]:
68
●
●
●
Policy Server – Dieser Server verwaltet Autorisierungsdatenbank(en) und
Autorisierungsengine(s), um den verschiedenen Applikationen bzw. Ressourcen einen
Autorisierungsdienst anbieten zu können.
PDADMIN Tool – Dieses Tool ermöglicht es dem Systemadministrator, per Konsole
Verwaltungsaufgaben wahrzunehmen (z.B. Hinzufügen von Nutzern oder Policies).
Web Portal Manager – Diese JSP-Applikation erlaubt es dem Systemadministrator, die
Architektur über einen Webbrowser zu verwalten.
Webserver
http(s) Request
http(s) Response
Benutzer
Benutzerverzeichnis
Webseal
Reverse Proxy
Cache
Web Portal
Manager
Policies
Policies
Access Manager
Policy Server
Abbildung 18: Architektur IBM Tivoli Access Manager 5.1
Wie in der Abbildung 18 ersichtlich, wird zusätzlich zu den oben beschriebenen
Komponenten ein Policy Enforcement Point benötigt, welcher Anfragen von Nutzern bzgl.
sicherheitsrelevanter Ressourcen abfängt. Diese Funktion übernimmt ein sog. WebSeal
Reverse Proxy [AMWebseal]. Wie auch die Webagenten der anderen Produkte, wird dieser in
einen Webserver integriert, um dort die HTTP(S)-Ports zu kontrollieren. Jedoch im Gegensatz
zu den Webagenten von RSA und Computer Associates leitet der Reverse Proxy die Anfrage
nicht an einen Policy Server o.ä. weiter, sondern führt die Authentifizierung bzw. die
Autorisierung mittels Benutzerverzeichnis und vorhandener Policies selbstständig durch. Um
dies zu ermöglichen, werden die aktuellen Policies im Cache des WebSeal Reverse Proxies
gehalten. Für die Aktualität dieser Sicherheitsregeln sorgt der Access Manager Policy Server.
Dazu führt dieser - wenn nötig - Updates auf dem WebSeal Cache aus. Zur Authentifizierung
eines Benutzers wendet sich der Reverse Proxy direkt an das zuständige Benutzerverzeichnis.
69
Der IBM Tivoli Federated Identity Manager (TFIM) 6.0, eine modulare J2EE-Komponente,
erweitert die Authentifizierungs- und Autorisierungsautorität Access Manager um Fähigkeiten
des föderierten Identitäten-Managements. Dieses Produkt ermöglicht den Aufbau von
Vertrauensbeziehungen und den domänenübergreifenden Austausch von Authentifizierungsund Attributinformationen. Die SAML-Autorität des TFIMs 6.0 unterstützt momentan im
Gegensatz zu den FIM-Komponenten von RSA und CA ausschließlich die SAML Version 1.0
(inklusive Browser/Artifact- und Browser/POST-Profil). An dieser Stelle muss jedoch
bemerkt werden, dass es sich beim IBM Tivoli Federated Identity Manager 6.0 noch um eine
Beta-Version handelt. Nach Aussagen von IBM besteht die Möglichkeit, dass die endgültige
Verkaufsversion noch um SAML 1.1 erweitert wird.
Neben SAML 1.0 unterstützt TFIM 6.0 außerdem die Spezifikation WS-Federation und das
Liberty Identity Federation Framework (Liberty ID-FF 1.1). Eine hohe Sicherheit und
Vertraulichkeit beim Austausch von Benutzerinformationen kann durch den Einsatz von WSSecurity 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 SignOn-Protokollen verwendet werden. Für jeden Partner in der Föderation kann ein anderer
Alias verwendet werden. Der Einsatz eines Alias soll verhindern, dass die wirkliche Identität
eines Nutzers in einem Netzwerk ausgetauscht wird. Der FIM Alias Service speichert die
Mapping-Informationen eines Alias im Access Manager Benutzerverzeichnis.
70
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/HTTPKommunikation, 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 SSOProtokolle wie SAML 1.0, WS-Federation und Liberty zu unterstützen.
Der WebSeal Proxy in dieser Umgebung verwaltet Sitzungen (Sessions) und Zugriffsrechte
eines Benutzers und führt - wenn nötig - eine Authentifizierung durch. Die Policies, anhand
derer eine Autorisation durchgeführt wird, werden vom Access Manager verwaltet.
Eingehende SSO-Nachrichten werden vom WebSeal zur weiteren Verarbeitung an den SPS
weitergeleitet. Soll selbst ein Single Sign-On-Prozess eingeleitet werden, so leitet der
WebSeal Reverse Proxy den entsprechenden Client an den SPS weiter, damit dieser eine
SSO-Nachricht für den Benutzer erstellen kann.
Der SPS kommuniziert mit den Komponenten der Trust-Infrastruktur, um SSO-Nachrichten
auszustellen bzw. zu konsumieren.
71
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.
ISC
Geschützte
Ressourcen
WebSphere
Key Encryption
Signing Service
Access Manager
WebSeal 5.1
SSO Protocol
Service
TFIM
Konsole
Trust Service
Alias Service
Access Manager 5.1
Policy Server &
LDAP
Benutzerverzeichnis
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 SSLBibliotheken, um eine SSL Daten-Verschlüsselung zu ermöglichen.
72
●
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.
2.
3.
4.
5.
Installation und Konfiguration eines TAM 5.1 Policy Servers.
Konfiguration eines Access Manager Authorization Servers.
Installation und Konfiguration eines TAM Web Portal Managers (WPM).
Installation und Konfiguration eines TAM WebSeal Reverse Proxies.
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
73
Instanzen, die unterschiedliche Aufgaben im System wahrnehmen können. Jede WebSealInstanz 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
Dokumentation
Installationsvorgang
Installationsvorgang einfach
relativ einfach, jedoch
und schnell.
etwas unübersichtlich, da
zahlreiche Komponenten
installiert werden müssen.
Installationsvorgang im
Vergleich zu den anderen
Produkten recht komplex
und zeitintensiv.
Sehr ausführliche
Dokumentationen. Mehr
Beispiele und
Abbildungen wären
jedoch wünschenswert.
Sehr umgangreiche aber gute
Dokumentationen. Es wird
sehr viel Detailwissen
vermittelt.
Gute und verständliche
Dokumentationen, die jedoch
etwas umfangreicher sein
könnten.
74
Die Konfiguration ist
trotz einer grafischen
Benutzeroberfläche eher
schwierig. Das Netegrity
Sicherheitsmodell
erfordert, dass sich der
Administrator mit
zahlreichen neuen
Begriffen auseinander –
setzt.
Die Benutzerschnittstelle
zum Management und zur
Konfiguration des Systems
ist intuitiv und gut
organisiert.
Übersichtliche
Konfiguration des Systems
durch eine grafische
Benutzeroberfläche (ISC).
Manche Konfigurationsschritte müssen jedoch per
Konsole durchgeführt
werden. Dies erfordert eine
Einarbeitung in die
Konsolenbefehle.
Gute Logging &
Reporting Funktionen.
Die Fehlerlogdateien
liefern jedoch nicht immer
den benötigten Detaillevel.
Mittelmäßige Logging &
Reporting Funktionen. Der
Detailgrad der Fehlerlogdateien ist ausreichend (drei
mögliche Abstufungen).
Sehr gute Logging &
Reporting Funktionen.
Der Detailgrad kann beliebig
genau eingestellt werden.
Gute Performanz durch
Redundanz (LoadSharing, Failover).
Gute Performanz.
Problem: Mehrfache
Identity-Speicher werden
nicht direkt unterstützt.
Sehr gute Performanz
(Failover, Load-Balancing).
Hohe Anpassbarkeit
(zahlreiche Programmierschnittstellen).
Sehr hohe Anpassbarkeit (ca.
300 Programmierschnittstellen für Java, C, DCOM,
JAAS, XML, SOAP etc.).
Hohe Anpassbarkeit (Zugriff
auf zahlreiche Java 2-, J2EEund JAAS- Implementierungen).
CA etrust; IBM Directory
Server; Lotus Domino
LDAP; Microsoft Active
Directory; Novell
eDirectory; Oracle
Internet Directory, Oracle
Databases; Sun One
Directory Server; Siemens
DirX.
CA etrust; Calendra; IBM
Tivoli; Microsoft Active
Directory, SQL Server 2000;
OpenLDAP; Novell
eDirectory; Oracle 8.1.7,
Oracle Internet Directory;
Sun One Directory Server;
Sybase 12.5; Radiant Logic
RadiantOne VDS; Siemens
DirX.
IBM Directory Server;
Microsoft Active Directory;
Novell eDirectory; Sun One
Directory Server; Lotus
Domino LDAP.
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Single Sign-On
Ja
Ja
Ja
Personalisierte Webseiten (basierend auf
Nutzer-Attributen)
Ja (Header oder Cookie)
Ja (Header oder Cookie)
Ja (Header)
Management &
Konfiguration
Logging &
Reporting
Hohe Verfügbarkeit
Anpassbarkeit
Identity
Management
Integration von
Datenbanken bzw.
Verzeichnissen
Ausgelagerte
(Delegated)
Administration
Rollen-basierte
Zugriffskontrolle
Attribut-basierter
Zugang
Selbstregistrierung
durch den Nutzer
Zugangskontrolle
75
Real-time access
revocation
Ja
Ja
Ja
Authentifizierungsmethoden
SAML; Smartcards;
X.509 Zertifikate; TwoFactor Tokens; Integrierte
Windows Authentifizierung; RADIUS;
Passwort; Biometrie;
selbstdefinierte Authentifizierungsmethoden;
HTML-Formular
Authentifizierung.
SAML;Passwort; Integrierte
Windows Authentifizierung;
HTML-Formular
Authentifizierung; TwoFactor Authentifizierung
(RSA SecurID & RSA
Mobile); X.509 Zertifikate;
selbstdefinierte
Authentifizierungsmethoden.
SAML; Passwort; HTMLFormular Authentifizierung;
SecurID Token; X.509
Zertifikate; RACF
Authentifizierung; Entrust
TruePass; Biometrie;
Micosoft Passport;
selbstdefinierte Authentifizierungsmethoden; LTPA
Authentifizierung.
Agenten-basiert
Ja
Ja
Ja (Reverse Proxy Ansatz
wird jedoch bevorzugt)
Reverse Proxy
Server-basiert
Ja
Ja (RSA ACM)
Ja (IBM WebSeal)
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 IDFF 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
Federated Identity
Management
Tabelle 3: Vergleich IAM-Softwareprodukte
3.5
Aufbau einer föderierten Systemumgebung
Nach der Beschreibung der verwendeten Produkte soll die föderierte Systemarchitektur
vorgestellt werden, die im Rahmen dieser Diplomarbeit aufgebaut wurde. Das Ziel dieser
Architektur war es, die wechselseitige Interoperablität der Sicherheitslösungen im Bereich
Federated Identity Management zu untersuchen und zu analysieren. Die zwischen den
unterschiedlichen Systemen ausgetauschten Nachrichten basieren auf SAML 1.0/1.1. Die
Liberty Alliance Protokolle bzw. das WS-Federation Protokoll wurde in dieser Diplomarbeit
nicht getestet.
76
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 SAMLRequests und SAML-Responses. Als Protokoll wird hierfür SOAP over HTTP verwendet.
Domäne A
WebServer
mit Webagent
Netegrity Siteminder Server
SUN One
LDAP-Verzeichnis
SAML
Request & Response
Domäne B
HTTP(S) Anfragen
WebServer
mit Webagent
RSA Cleartrust & FIM Server
Microsoft
SQL Server 2000
SAML
Request & Response
Domäne C
WebSeal
IBM TAM & TFIM Server
Abbildung 20: Föderierte heterogene Systemarchitektur
77
Tivoli
Directory Server
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
78
RSA Cleartrust 5.5 & RSA FIM 2.5
http://itacpi09.testeurope1.bmwgroup.com:7001
/samlassertingparty/AP?TARGET=http(s)://we
b-server-host.target-domain/protected-resource
http:// itacpi09.testeurope1.bmwgroup.com:
7001/samlassertingparty/services/SamlRequest
http://itacpi09.testeurope1.bmwgroup.com:7001
/samlrelyingparty/RP
Tabelle 5: SSO-Einstellungen RSA FIM
IBM TAM 5.1 & IBM TFIM 6.0
itahpi14.testeurope1.bmwgroup.com
http://itahpi14.testeurope1.bmwgroup.com/FIM
/sps/samlfed/saml/login?TARGET=http(s)://we
b-server-host.target-domain/protected-resourc
https:// itahpi14.testeurope1.bmwgroup.com/
FIM/sps/samlfed/saml/soap
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 PortalWebseite), 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]:
79
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-ResponseNachrichten (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 SAMLAssertion 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.
80
•
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 SAMLAssertion 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 ClientCertificate). 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.
81
Kapitel 4: Anwendungsfälle
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.
Identity Provider
Benutzer
Service Provider
Authentifizierung (z.B. Passwort)
Zugriff Inter-Site Transfer URL
Inter-Site Transfer Service
Generierung einer SAML
Auth.-Assertion + SAML
Artefakt
HTTP-Redirect
HTTP-GET-Request (Parameter SAMLArt & TARGET)
SAML-Request
SOAP Binding
Service
SAML-Reponse
Gewährung bzw. Verweigerung des Zugriffs auf die gewünschte Ressource
Abbildung 21: Ablauf Föderierte Authentifizierung/Föderiertes Single Sign-On
82
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
Sicherheitsprodukte folgende Schritte implementieren [FIM]:
müssen
die
zu
testenden
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 SAMLRequest folgende Elemente bzw. Attribute enthalten (vgl. Kapitel 2.4.3.3):
●
RequestID
83
●
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.
84
●
●
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 SAMLAssertion enthaltene Benutzeridentität (z.B. UserID) extrahieren, um diese im Anschluss auf
eine lokale Identität in seinem Benutzerverzeichnis abzubilden. Dieser Vorgang wird UserMapping 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.
85
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 Attribut86
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/WertPaare 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 AuthenticationAssertion vom IdP erhalten hat.
Benutzer
Identity Provider
Service Provider
SAML Attribute-Request
SOAP Binding
Service
Attribute-Assertion
SAML Attribute-Response
Autorisierung
des Nutzers
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.
87
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.
88
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 HTTPStatusmeldung.
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 AuthorizationRequest) 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 AuthentificationAssertion vom IdP erhalten hat.
89
Benutzer
Identity Provider
Service Provider
SAML Authorization -Request
SOAP Binding
Service
Autorisierung
des Nutzers
Authorization-Assertion
SAML Authorization-Response
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.
90
Kapitel 5: Umsetzung und Analyse
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 IdPPortalseite.
2. Der Nutzer wird von der Authentifizierungsautorität des IdPs aufgefordert, sich zu
authentifizieren. Die erforderlichen Benutzerdaten speichert der IdP in einem UserVerzeichnis 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.
91
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
92
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
Hostadresse IdP
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.
93
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)
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.
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
94
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.
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.
Da das aktuelle Netegrity Siteminder Produkt (Version 6.0 SP1) weder SAML AuthorizationAssertion-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.
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.
95
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 Affiliateund 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
96
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 AuthorizationAssertions. 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.
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
Syntax SAML 1.0
Ja
Ja
Syntax SAML 1.1
Ja
Ja
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Nein
Nein
97
Nein
Nein
Tabelle 10: SAML-Features Netegrity Siteminder vs. RSA FIM
Tabelle 11 zeigt Einstellungen der Testumgebung „Netegrity Siteminder – RSA Federated
Identity Manager“.
Hostadresse SP
Hostadresse IdP
Artifact Receiver Service URL http://itacpi09.testeurope1.bmwgroup.com:7001/samlrelyingparty/RP
SOAP Binding Service URL
https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/assertionretriever
SP Demo Website URL
http://itacpi09.testeurope1.bmwgroup.com/protected.php
BAP SourceID (Hex)
Issuer
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.
Use Cases
Ja
Ja
Ja
Nein
Nein
Tabelle 12: Testergebnisse – Netegrity Siteminder (IdP) & RSA FIM (SP)
98
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 AssertionGenerator 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):
Das SAML-Artefakt (generiert vom Netegrity Siteminder) entsprach den Anforderungen der
SAML-Spezifikation. Der Test war somit erfolgreich bestanden.
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.
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-0225T11:31:56") innerhalb des übermittelten SAML-Requests konnte nicht erfolgreich
99
vom Netegrity Siteminder geparst werden. Das Siteminder Produkt stoppte den SSOProzess 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-0225T11: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.
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 SSLVerbindungen 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.
100
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
101
(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 SAMLAssertions, 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''.
102
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 SiteminderKomponente ü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.
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 TokenFormat 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.
Basierend auf den oben genannten Lösungsansätzen konnte die implizite Übertragung von
Nutzerattributen erfolgreich getestet werden. Da die standardmäßigen Attributelemente einer
103
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 SAMLAssertion.
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 AuthentificationAssertion) 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).
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,
104
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.
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
105
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).
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
Syntax SAML 1.0
Ja
Ja
Syntax SAML 1.1
Ja
Nein
Ja
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Tabelle 13: SAML-Features Netegrity Siteminder vs. IBM TFIM
106
Tabelle 14 zeigt die verwendeten Einstellungen bzgl. der Testumgebung „Netegrity
Siteminder – IBM TFIM“.
Hostadresse SP
itahpi14.testeurope1.bmwgroup.com
Hostadresse IdP
Artifact Receiver Service URL https://itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/login
https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/assertionretriever
SP Demo Website URL
http://itacpi14.testeurope1.bmwgroup.com/protected.jsp
BAP SourceID (Hex)
Issuer
Tabelle 14: Einstellungen Netegrity Siteminder & IBM TFIM
Der SOAP Binding Service URL des Netegrity Siteminders wurde durch einen ClientZertifikat-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.
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
Nein
Nein
Nein
Nein
Nein
Tabelle 15: Testergebnisse - Netegrity Siteminder (IdP) & IBM TFIM (SP)
107
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):
Das SAML-Artefakt (generiert vom Netegrity Siteminder) entsprach den Anforderungen der
SAML-Spezifikation. Dieser Test war somit erfolgreich bestanden.
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.
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
108
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.
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.
109
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).
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
Syntax SAML 1.0
Ja
Ja
Syntax SAML 1.1
Ja
Ja
Ja
Ja
Ja
Ja
110
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Nein
Nein
Nein
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)“.
Hostadresse SP
Hostadresse IdP
Artifact Receiver Service URL https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/public/samlcc
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
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.
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
Nein
111
Nein
Nein
Nein
Nein
Tabelle 18: Testergebnisse - RSA FIM (IdP) & Netegrity Siteminder (SP)
Ä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:
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.
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.
Das in Schritt 2 übertragene SAML-Artefakt wurde erfolgreich - verpackt in einen SAMLRequest - 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.
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.
112
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
113
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.
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
114
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).
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 SAMLFähigkeiten der beiden verwendeten Sicherheitslösungen.
RSA FIM 2.5
IBM TFIM 6.0
Syntax SAML 1.0
Ja
Ja
Syntax SAML 1.1
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Nein
Nein
Nein
Nein
Tabelle 19: SAML-Features RSA FIM vs. IBM TFIM
Tabelle 20 zeigt Einstellungen der Testumgebung „RSA Cleartrust & RSA FIM – IBM TAM
& IBM TFIM“.
Hostadresse SP
Hostadresse IdP
Artifact Receiver Service URL https:// itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/login
115
http://itacpi09.testeurope1.bmwgroup.com:7001/samlassertingparty/services/Sam
lRequest
SP Demo Website URL
http://itahpi14.testeurope1.bmwgroup.com/protected.jsp
BAP SourceID (Hex)
ba4a61beb309a7152f38292d188b855602582295
Issuer
_2fedf960dc60d9134f9161d88e0bc03d9a413e77
www.rsa.com
Tabelle 20: Einstellungen RSA FIM & IBM TFIM
Die Absicherung des SOAP Binding Services basierte auf der Übermittlung eines ClientZertifikats durch den beteiligten SP. Ein Schutz dieses Dienstes auf Basis von Basic
Authentication war in diesem Testszenario nicht möglich.
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.
Use Cases
Ja
Ja
Ja
Nein
Nein
Tabelle 21: Testergebnisse - RSA FIM (IdP) & IBM TFIM (SP)
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):
116
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.
Das in Schritt 1 generierte SAML-Artefakt wurde erfolgreich – durch einen Aufruf des InterSite 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.
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.
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 AuthenticationAssertions an den Service Provider erfolgreich übermittelt werden.
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.
117
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.
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.
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.
118
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.
SAML-Assertion
vom IdP (1)
Benutzer
WebSeal Reverse
Proxy
Authorization
- Engine
Trust Service
Ü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)
Auswertung einer
Authorization-Rule (7)
Übergabe von Access_Allowed bzw. Access_Denied (8)
Zugriff auf die Resource
erlauben bzw. verweigern (9)
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
119
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.
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).
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:
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
120
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.0
Ja
Ja
Syntax SAML 1.1
Nein
Ja
SAML BAP (Browser/Artifact Profile)
Ja
Ja
SAML BPP (Browser/Post Profile)
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Ja
Nein
Ja
Nein
Nein
Nein
Nein
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“.
Hostadresse SP
Hostadresse IdP
Artifact Receiver Service URL http://itacpi09.testeurope1.bmwgroup.com:7001/samlrelyingparty/RP
https:// itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/soap
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
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 ClientZertifikate wäre jedoch auch möglich gewesen.
121
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.
Use Cases
Ja
Ja
Ja
Nein
Nein
Tabelle 24: Testergebnisse - IBM TFIM (IdP) & RSA FIM (SP)
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 SAMLResponse-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 SAMLSpezifikation 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.
122
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 IBMProdukts 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.
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 HTTPHeader 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.
123
Auch dieser Testfall konnte erfolgreich getestet werden. Die Umsetzung erfolgte analog zum
gleichnamigen Anwendungsfall in Kapitel 5.2.2.
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.
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:
Der Austausch von Identitätsinformationen basierte abermals auf SAML 1.0 und dem
dazugehörigen Browser/Artifact-Profile.
124
IBM TFIM 6.0
Siteminder 6.0 SP1
Syntax SAML 1.0
Ja
Ja
Syntax SAML 1.1
Nein
Ja
SAML BAP (Browser/Artifact Profile)
Ja
Ja
SAML BPP (Browser/Post Profile)
Ja
Nein
Ja
Ja
Ja
Ja
Ja
Ja
Nein
Nein
Nein
Nein
Nein
Nein
Nein
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.
Hostadresse SP
Hostadresse IdP
Artifact Receiver Service URL https://itacpi29.testeurope1.bmwgroup.com:443/affwebservices/public/samlcc
https:// itahpi14.testeurope1.bmwgroup.com/FIM/sps/samlfed/saml/soap
http://itahpi14.testeurope1.bmwgroup.com/protected/portal.jsp
SP Demo Website URL
http://itacpi29.testeurope1.bmwgroup.com/protected.asp
BAP SourceID (Hex)
ba4a61beb309a7152f38292d188b855602582295
Issuer
http://itahpi14.testeurope1.bmwgroup.com
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.
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.
125
Use Cases
Nein
Nein
Nein
Nein
Nein
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.
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 SAMLAssertion ü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.
126
Aufgrund des Scheiterns des vorangegangen Testfalls konnte der föderierte Austausch von
Attributen zwischen dem IBM- und CA-Produkt nicht getestet werden.
Siehe gleichnamiger Anwendungsfall in Kapitel 5.4.2.
Wie alle vorangegangenen Testszenarios zeigen, wird dieser Use Case von keiner SAMLAutorität der drei verwendeten Produkte unterstützt. Eine Umsetzung dieses Anwendungsfalls
war damit auch hier unmöglich.
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 OpenSAMLBibliotheken [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
127
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).
128
Um eine tatsächliche Anbindung der SAML-Autorität an die kommerziellen Sicherheitslö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 SQLDatenbank 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.
129
Kapitel 6: Zusammenfassung und Ausblick
6.
Zusammenfassung und Ausblick
Im Rahmen dieser Diplomarbeit wurde die Interoperabilität dreier unterschiedlicher Identityund 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
130
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
Authentifizierungsbzw.
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 BetaVersion 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.1Spezifikationen. 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 SAMLAutorität auf den öffentlich zugänglichen APIs von OpenSAML basiert.
131
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 WSFederation. 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
Entwurf und Integration
eines Java-Plugins
Netegrity SiteMinder 6.0
+ Hotfixes
Identity Provider
Identity Provider
Identity Provider
Identity Provider
Identity Provider
RSA ClearTrust 5.5
+ Federated Identity Mgr.
2.5
IBM TAM 5.1
& Federated Identity Mgr.
6.0 + Hotfix
Identity Provider
Legende:
Interoperabilitätsanalyse in mindestens einem Anwendungsfall erfolgreich
Interoperabilitätsanalyse in keinem Anwendungsfall erfolgreich
Interoperabilität nicht definitiv feststellbar
Abbildung 26: Ergebnisse der Interoperablitätsanalyse
132
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.
133
Anhang
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,
134
Anhang
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;
135
Anhang
}
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");
136
Anhang
// 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) {
137
Anhang
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)
{
138
Anhang
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) {
139
Anhang
// 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();
}
}
}
140
Anhang
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 AuthenticationRequest (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:200308">
<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-9ecb712949db686e" 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-1217T09: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"
<lib:Subject>
<saml:NameIdentifier NameQualifier="http://ServiceProvider.com"
Format="urn:liberty:iff:nameid:federated">
342ad3d8-93ee-690 4c68-be35-cc9e7db39e2b
141
Anhang
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</saml:ConfirmationMethod>
<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/gxKLakNjY1IwSW1FT3VVMVhvSjhEd0hBd2xZSTRRTT
06YTI0NWMwZmQyYzJlNTU2Mw==
</samlp:AssertionArtifact>
</samlp:Request>
SAML-Response (Netegrity Siteminder 6.0 ohne Plugin):
<samlp:Response InResponseTo="SM10.250.21.53.1109951920942" IssueInstant="2005-0304T15: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-0304T15:58:40.503Z" Issuer="http://www.netegrity.com/SiteMinder" MajorVersion="1"
142
Anhang
MinorVersion="0" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2005-03-04T15:58:10.487Z" NotOnOrAfter="2005-0304T16: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: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">
</saml:Subject>
</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"
143
Anhang
AAG4GEUmEKDqQxv/ad00au7/gxKLasBSMedIN/4qTuRVUEwcIZLLF+yK
</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-0527T11:14:36Z" Issuer="http://www.netegrity.com/SiteMinder" MajorVersion="1" MinorVersion="0">
<saml:Conditions NotBefore="2005-05-27T11:13:46Z" NotOnOrAfter="2005-0527T11:15:46Z"></saml:Conditions>
<AuthenticationStatement AuthenticationInstant="2005-05-27T11:14:11Z"
<Subject xmlns="urn:oasis:names:tc:SAML:1.0:assertion">
NameQualifier="http://www.netegrity.com/SiteMinder">
<SubjectConfirmation>
<ConfirmationMethod>
</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
</AuthenticationStatement>
<saml:Subject>
NameQualifier="http://www.netegrity.com/SiteMinder">
uid=admin,ou=Administrator,o=NetscapeRoot
</saml:Subject>
<saml:Attribute AttributeName="businesscategory" AttributeNamespace="header">
<saml:AttributeValue>gold</saml:AttributeValue>
</saml:Attribute>
</saml:Assertion>
</samlp:Response>
144
Anhang
A.3.3 Testszenario RSA Cleartrust & RSA FIM 2.5 – Netegrity Siteminder 6.0
SAML-Request (Netegrity Siteminder 6.0):
RequestID="10.250.23.22.1117197899957" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
AAG6SmG+swmnFS84KS0Yi4VWAlgilU3mZn61Qxv9sPQ+Ixp0Ce96pwUM
</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"
<samlp:Status><samlp:StatusCode Value="samlp:Success"/></samlp:Status>
<saml:Assertion AssertionID="_f06224aa7db4d9124c4e173657b367814ea4e8b4" IssueInstant="200505-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"
<saml:Subject>
NameQualifier="www.rsa.com">
uid=admin
</saml:Subject>
</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):
RequestID="_1458697809874tfe8tz7858e15a4b19dt6578uk64"xmlns:ds="http://www.w3.org/2000/09/xmldsig
145
Anhang
#" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
AAG4GEULOKDuIz/ls01au7/rtDLlkLKUedIN/7pTuRVUEwvBgTERF+Lo
</samlp:Request>
</soapenv:Body>
</soapenv:Envelope>
SAML-Response (IBM TFIM 6.0):
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:Status>
<saml:Assertion AssertionID="Assertion-uuid1df143c6-0104-fa1b-6c52-802c7617b9b2" IssueInstant="200505-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:Conditions>
<saml:AuthenticationStatement AuthenticationInstant="2005-05-27T12:47:27Z"
<saml:Subject>
NameQualifier="www.ibm.com">
uid=admin
</saml:Subject>
<saml:Subject>
NameQualifier="www.ibm.com">
uid=admin
146
Anhang
</saml:Subject>
<saml:AttributeValue>bronze</saml:AttributeValue>
</saml:Attribute>
</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"
AAFczW3Kc7JLyY4wdiJPHC4DlME4el53ZQGocarcYLxqhLNEwSrLzJ3Y
</samlp:Request>
SAML-Response (IBM TFIM 6.0):
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: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-0527T12:10:40.000Z">
<saml:AudienceRestrictionCondition>
<saml:Audience>
http://itacpi29.testeurope1.bmwgroup.com/affwebservices/public/samlcc
</saml:Audience>
</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">
uid=admin
147
Anhang
</saml:Subject>
<saml:Subject>
<saml:NameIdentifier NameQualifier="www.ibm.com"
Format="urn:oasis:names:tc:SAML:1.0:assertion#X509SubjectName">
uid=admin
</saml:Subject>
<saml:AttributeValue>bronze</saml:AttributeValue>
</saml:Attribute>
</saml:Assertion>
148
ACL
AP
ARS
BAP
BPP
CORBA
DN
FF
FIM
GSKit
HTML
HTTP
HTTPS
IAM
ID
IdP
IETF
ISC
ISX
IP
IT
J2EE
JNDI
JRE
JSP
LDAP
MS
MSO
OASIS
ODBC
PDP
PEP
PGP
PUID
RBAC
RDN
RMI
RP
SAML
SIS
SMTP
SOA
SOAP
SP
SPS
SQL
SSI
SSL
Access Control List
Asserting Party
Artifact Receiver Service
Browser/Post-Profile
Common Object Request Broker Architecture
Distinguished Name
Federation Framework
Federated Identity Management/Federated Identity Manager
Global Security Kit
Hypertext Markup Language
Hypertext Transfer Protocol
HyperText Transfer Protocol Secure
Identity und Access Management
Identity/Identifier
Identity Provider
Internet Engineering Task Force
Integrated Solutions Console
Inter-Site Transfer Service
Internet Protocol
Informationstechnik
Java 2 Enterprise Edition
Java Naming and Directory Interface
Java-Runtime-Environment
Java Server Page
Lightweight Directory Access Protocol
Microsoft
Multiple Sign-On
Organization for the Advancement of Structured Information Standards
Open Database Connectivity
Policy-Decision-Point
Policy-Enforcement-Point
Pretty Good Privacy
Passport User ID
Role-Based Access Control
Relative Distinguished Name
Remote Method Invocation
Relying Party
Security Assertion Markup Language
Services Interfaces Specifications
Simple Mail Transfer Protocol
Service Oriented Architecture
Simple Object Access Protocol
Service Provider
SSO Protocol Service
Structured Query Language
Single Sign-In
Secure-Sockets-Layer
149
SSO
TAM
TFIM
TC
TCP
TLS
UDDI
URI
URL
UTC
W3C
WPM
WS
WSDL
WSF
XML
XrML
XSD
XSL
Single Sign-On
Tivoli Access Manager
Tivoli Federated Manager
Technical Committee
Transmission Control Protocol
Transport Layer Security
Universal Description, Discovery and Integration
Uniform Resource Identifier
Uniform Resource Locator
Universial Time Coordinated
World Wide Web Consortium
Web Portal Manager
Web-Services
Web-Services Definition Language
Web-Service Framework
Extensible Markup Language
Extensible Rights Markup Language
XML Schema Definition
Extensible Stylesheet Language
150
[AMAdmin]
IBM Tivoli Access Manager for e-business (Version 5.1): “Base Installation
Guide”, 2003, http://publib.boulder.ibm.com/tividd/td/ITAME/SC32-136200/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=18247303A10Rk8MP
0.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
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
Siew, T. P. : “OASIS: Functional Elements Specification”, Working Draft
02, 2004, http://xml.coverpages.org/FWSI-FEGuidelinesV03-10253.pdf
[FedSSO]
[FedTrend]
[FIM]
(4)
–
Identification”,
2005,
Neuenschwander, M., Blum, D. et al. : “VantagePoint 2005-2006 Enterprise
Trends in Identity and Privacy”, Version 2.0, Burton Group Research
Overview, 2005
Metzger, S. : “Föderiertes Identity Management bei der BMW Group”,
Technische Universität München, 2004
151
[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/draftliberty-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
152
[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
http://www.opengroup.org/security/l2-sso.htm
Sign-On”,
2001,
[PassTrouble]
Slemko,
M.:
“Microsoft
Passport
to
http://alive.znep.com/~marcs/passport/index.html
Trouble”,
2001,
[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 425427, 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
153
[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/xseclay4/
[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
154
[SOAP12]
Gudgin, M., Hadley, M. et al. : “SOAP Version 1.2 Part 1: Messaging
Framework”, W3C Recommendation, 2003, http://www.w3.org/TR/soap12part1/
[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-part220030624/
[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-messagesecurity-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-Published20020719.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/ht
ml/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 (WSFederation)”, 2003, http://www128.ibm.com/developerworks/webservices/
library/ws-fed/
155
[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.oasisopen.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/GrundlegendesZu
WSSecurity.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/pkixcharter.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
156

Interoperabilitätsanalyse föderierter Identitätsmanagement

Transcription

Similar documents

Rank Gender Nickname LeaderClub Change ChangePercent 1 F

Dell Server

Kernaussagen des EMEA Internet Security Threat Reports

Intellex - American Dynamics