Dokumentation zu Federated Identity as a Service

Dokumentation
Federated Identity as a
Service
Version 1.0, 29.09.2014
Bernd Zwattendorfer – [email protected]
Zusammenfassung: In diesem Projekt wird ein neues IdentitätsmanagementModell für die Cloud vorgestellt. Im Gegensatz zum einfachen und zentralen
„Cloud Identity Broker“-Modell, wo ein Identity Broker in der Cloud als
Intermediär für unterschiedliche Service Provider und Identity Provider agiert,
setzt das neue Identitätsmanagement-Modell auf eine Föderation von Cloud
Identity Brokern. Dies hat den Vorteil, dass Benutzerinnen bzw. Benutzer und
Service Provider nicht von ein und demselben zentralen Cloud Identity Broker
bei einer Authentifizierung abhängig sind. Im sogenannten „Föderierten
Cloud Identity Broker“-Modell entfällt diese Abhängigkeit, da Benutzerinnen
bzw. Benutzer und Service Provider ihren favorisierten Cloud Identity Broker
selbst
wählen
können.
Zusätzlich
wird
der
Datenschutz
durch
die
Verwendung entsprechender kryptographischer Technologien gegenüber
Cloud Service Providern erhöht. Das „Föderierte Cloud Identity Broker“-Modell
wurde prototypisch implementiert und somit dessen Anwendbarkeit gezeigt.
E-Government
Innovationszentrum
Inffeldgasse 16/a, A-8010 Graz
Tel.
+43 316 873 5514
Fax.
+43 316 873 5520
E-Mail [email protected]
www.egiz.gv.at
Das E-Government Innovationszentrum ist eine gemeinsame
Einrichtung des Bundeskanzleramtes und der TU-Graz
Inhaltsverzeichnis
1 Einleitung .............................................................................................................................. 3
2 Cloud Identitätsmanagement-Modelle .......................................................................... 5
2.1 Identitätsmanagement in der Cloud ........................................................................ 5
2.2 Identitätsmanagement zur Cloud ............................................................................. 6
2.3 Identitätsmanagement von der Cloud..................................................................... 7
2.4 Cloud Identity Broker-Modell ...................................................................................... 7
3 Föderiertes Cloud Identity Broker-Modell ...................................................................... 10
4 Implementierung ............................................................................................................... 13
4.1 Anforderungen ........................................................................................................... 13
4.2 Komponenten ............................................................................................................. 14
4.3 Kommunikationsschnittstellen ................................................................................... 17
4.4 Prozessfluss ................................................................................................................... 18
4.4.1 Vorbedingungen............................................................................................. 18
4.4.2 Authentifizierungsablauf ................................................................................ 19
5 Evaluierung und Diskussion .............................................................................................. 23
6 Fazit und Ausblick .............................................................................................................. 25
Abbildungsverzeichnis
Abbildung 1 - Identitätsmanagement-Architektur ............................................................ 4
Abbildung 2 - „Identitätsmanagement in der Cloud“-Modell ........................................ 5
Abbildung 3 - „Identitätsmanagement zur Cloud“-Modell ............................................. 6
Abbildung 4 - „Identitätsmanagement von der Cloud“-Modell .................................... 7
Abbildung 5 – „Cloud Identity Broker”-Modell ................................................................... 8
Abbildung 6 – „Föderiertes Cloud Identity Broker“-Modell ............................................ 10
Abbildung 7 - Implementierungs-Architektur ................................................................... 13
Abbildung 8 - Sequenz-Diagramm des Authentifizierungsablaufs................................ 20
Einleitung
2
1 Einleitung
Identitätsmanagement umfasst im Wesentlichen die sichere Verwaltung von
Identitäten bzw. Benutzerkonten, die Verwaltung zugehöriger Attribute, sowie die
sichere Identifizierung und Authentifizierung von Benutzerinnen und Benutzern an
Applikationen [BeTa11]. Identitätsmanagement und insbesondere ein sicheres
Identitätsmanagement ist ein wesentlicher Kernaspekt bei der Entwicklung bzw.
beim Schutz von Zugriffen auf eine Online Applikation. Im österreichischen EGovernment spielt beispielsweise die österreichische Bürgerkarte bzw. HandySignatur eine zentrale Rolle für eine sichere Identifizierung und Authentifizierung von
Bürgerinnen und Bürgern.
Die meisten Identitätsmanagementkonzepte verfolgen dabei alle einen ähnlichen
architektonischen Ansatz, wobei ein Identity Provider, ein Service Provider, und eine
Benutzerin bzw. ein Benutzer als Stakeholder involviert sind [BeTa11]. Der Service
Provider stellt dabei schützenswerte Daten oder Ressourcen über eine Applikation
zur Verfügung, auf die eine Benutzerin bzw. ein Benutzer zugreifen möchte. Um den
Aufwand für einen Zugriffsschutz für einen Service Provider möglichst gering zu
halten, wird diese Funktion an den Identity Provider ausgelagert. Der Identity
Provider verwaltet dabei die Benutzerkonten bzw. die digitale Identität der
Benutzerin bzw. des Benutzers. Zusätzlich regelt der Identity Provider auch die
Identifizierung und Authentifizierung von Benutzerinnen und Benutzern. Der Identity
Provider übernimmt also alle Funktionen zur Regelung des Zugriffsschutzes für den
Service Provider. Der Service Provider erhält im Rahmen eines Identifizierungs- und
Authentifizierungsprozesses nur mehr die Identitäts- und Authentifizierungsdaten
einer Benutzerin bzw. eines Benutzers vom Identity Provider. Basierend auf diesen
Daten kann der Service Provider dann den Zugriff auf die geschützte Ressource
gewähren
oder
verweigern.
Abbildung
1
zeigt
diese
typische
Identitätsmanagement-Architektur.
Im Rahmen des österreichischen E-Governments wird diese Architektur z.B. bei
Online Applikationen verwendet, bei denen der Zugriffsschutz über einen
Bürgerkaten-Login geregelt wird. In diesem Fall entspricht die Online Applikation
dem Service Provider und MOA-ID dem Identity Provider. Eine Bürgerin bzw. ein
Bürger identifiziert und authentifiziert sich dabei mittels Bürgerkarte bei MOA-ID, und
MOA-ID leitet anschließend die Identifizierungs- und Authentifizierungsdaten der
Bürgerin bzw. des Bürgers in strukturierter Form (in einer sogenannten SAML1-Assertion
[LCR+08] oder gemäß OpenID Connect [SBJ+14] in einem JSON2 Web Token) an die
Online Applikation weiter, womit die Daten bei der Online Applikation entsprechend
weiter verarbeitet werden können.
1
2
Security Assertion Markup Language
JavaScript Object Notation
Einleitung
3
Identity
Provider
(IdP)
Service
Provider
(SP)
IdentitätsdatenTransfer
Identifizierung und
Authentifizierung
Zugriff auf geschütze
Ressource
Benutzerin bzw. Benutzer
Abbildung 1 - Identitätsmanagement-Architektur
Aufgrund der immer und stetig steigenden Anzahl von Cloud Applikationen ist ein
sicheres Identitätsmanagement auch ein essentielles Thema im Rahmen von Cloud
Computing. Existierende Identitätsmanagement-Modelle sind jedoch nicht ad-hoc
im Cloud Computing anwendbar, da im Rahmen von Cloud Computing zusätzliche
Anforderungen (z.B. Datenschutz [PeBe10]) berücksichtigt werden müssen. Einige
Identitätsmanagement-Modelle sind jedoch bereits für die Cloud und deren
Eigenschaften und Anforderungen entwickelt worden. Ein paar dieser Modelle
werden in Abschnitt 2 genauer vorgestellt.
Ziel dieses Projekts war die Verbesserung aktueller Cloud IdentitätsmanagementModelle sowie die Entwicklung eines neuen Identitätsmanagement-Modell für die
Cloud, welches einerseits die Vorteile des Cloud Computing ausnützt, und
anderseits
dessen
entsprechend
Schwachstellen
berücksichtigt.
speziell
Dieses
im
Modell
Bereich
und
des
Datenschutzes
eine
prototypische
Implementierung werden in den Abschnitten 3 und 4 genauer beschrieben. Das
beschriebene Modell wird anschließend in Abschnitt 5 entsprechend diskutiert.
Abschließend wird in Abschnitt 6 ein Fazit gezogen und ein Ausblick für mögliche
weiterführende Tätigkeiten gegeben.
Einleitung
4
2 Cloud Identitätsmanagement-Modelle
Identitätsmanagement und im Speziellen ein sicheres Identitätsmanagement
spielen auch im Cloud Computing eine wichtige Rolle. Die Idee der Verwendung
von Identitätsmanagement-Konzepten auch in der Cloud ist nicht neu, da viele
Unternehmen und Organisationen ihre Applikationen in die Cloud migrieren, um
beispielsweise die Kostenvorteile oder die höhere Skalierbarkeit und Dynamik einer
Cloud voll ausschöpfen zu können. [Gopa09][Goul10][Cox12] haben bereits
unterschiedliche Identitätsmanagement-Modelle in der Cloud klassifiziert. Basierend
auf deren Arbeiten werden im Folgenden einige dieser Modelle vorgestellt.
2.1 Identitätsmanagement in der Cloud
Das „Identitätsmanagement in der Cloud“-Modell ist das einfachste Modell. In
diesem Modell betreibt ein Cloud Service Provider, z.B. Google, sowohl den Identity
Provider als auch die Applikation, die die schützenswerten Daten bereithält (Service
Provider). Im Prinzip verschmelzen Identity Provider und Service Provider in diesem
Modell in der Cloud. Abbildung 2 illustriert dieses Modell.
Cloud Service Provider
Identity
Provider
Service
Provider
Identitäts
daten
Datentransfer
Benutzerin bzw. Benutzer
Abbildung 2 - „Identitätsmanagement in der Cloud“-Modell
Der
Vorteil
dieses
Modells
ist,
dass
Unternehmen
bereits
ein
fix
fertiges
Identitätsmanagement, nämlich das vom Cloud Service Provider für seine
Applikationen bereitgestellte, verwenden können. Um die Speicherung und das
Management der Identitätsdaten kümmert sich der Cloud Service Provider. Nachteil
ist natürlich, dass nur jene Daten verwendet werden können, die der Cloud Service
Provider
auch
unterstützt.
Außerdem
liegt
die
Kontrolle
des
Identitätsmanagementsystems (Identity Provider) komplett beim Cloud Service
Provider. Eine Migration oder Synchronisierung externer Identitätsdaten zum Cloud
Cloud Identitätsmanagement-Modelle
5
Service Provider ist in diesem Modell nicht vorgesehen. D.h., Benutzerinnen und
Benutzer müssen sich beim Cloud Service Provider neu registrieren, wenn sie
entsprechende Cloud Services nutzen möchten.
2.2 Identitätsmanagement zur Cloud
In diesem Modell (siehe Abbildung 3) ist die Verwendung eines externen
Identitätsmanagementsystems möglich, d.h. der Cloud Provider empfängt nur
Identitätsdaten von einem externen Identity Provider. Der Unterschied zum
vorherigen Modell ist, dass der Identity Provider nicht in der Cloud betrieben wird,
sondern in einem klassischen Rechenzentrum unter vollständiger Kontrolle jener
Organisation, die auch die Identitätsdaten bereitstellt und verwaltet. Der Cloud
Provider hostet in diesem Fall nur die Applikation, an der eine Authentifizierung
notwendig ist. Der Datentransfer zwischen dem externen Identity Provider und der
Cloud Applikation erfolgt üblicherweise über standardisierte Schnittstellen und
Identitätsprotokolle,
wie
z.B.
SAML
oder
OAuth
[Hardt12].
Google
und
Salesforce.com sind zwei Vertreter, die dieses Modell unterstützen.
Cloud Service Provider
Identity
Provider
Service
Provider
Identitäts
daten
Datentransfer
Benutzerin bzw. Benutzer
Abbildung 3 - „Identitätsmanagement zur Cloud“-Modell
Der Vorteil dieses Modells ist, dass die Kontrolle über die Identitätsdaten nicht zum
Cloud Provider transferiert werden muss und die eigene Organisation die Kontrolle
behalten kann. Die Identifizierung und Authentifizierung erfolgt beim externen
Identity Provider, Identitäts- und Authentifizierungsdaten werden nur über eine
entsprechende Schnittstelle an den Cloud Service Provider und dessen Applikation
übertragen. Diese Schnittstelle stellt auch den größten Nachteil dieses Modells dar,
da Interoperabilitätsprobleme bei der Implementierung sowohl auf Seiten des Cloud
Service Providers als auch Seiten des externen Identity Providers auftreten können.
Außerdem werden in diesem Modell nicht die vollen positiven Cloud Eigenschaften
ausgenützt, da der Identity Provider nicht in der Cloud betrieben wird.
Cloud Identitätsmanagement-Modelle
6
2.3 Identitätsmanagement von der Cloud
In diesem Modell werden sowohl der Identity Provider als auch der Service Provider
in der Cloud betrieben. Wesentlicher Unterschied zum „Identitätsmanagement in
der Cloud“-Modell ist, dass der Identity Provider und der Service Provider von zwei
unterschiedlichen Cloud Service Providern betrieben werden. D.h., ein Cloud
Service Provider hostet den Identity Provider und ein anderer Cloud Service Provider
die Applikation. Diese Trennung spiegelt auch die generelle Architektur aus
Abbildung 1 wider, nur dass beide Provider (Identity Provider und Service Provider) in
der Cloud betrieben werden, was die Vorteile des Cloud Computing effizient
ausnützt. Abbildung 4 zeigt dieses Modell.
Cloud Service Provider
Identitäts
daten
Identity
Provider
Cloud Service Provider
Service
Provider
Identitäts
daten
Datentransfer
Benutzerin bzw. Benutzer
Abbildung 4 - „Identitätsmanagement von der Cloud“-Modell
Neben den klassischen Vorteilen des Cloud Computing ist der wesentliche Vorteil
dieses Modells, dass sich eine Organisation den Identity Provider in der Cloud, dem
sie vertrauen möchte, aussuchen kann. Dies ist von besonderer Wichtigkeit, da die
Identitätsdaten der Organisation vollkommen vom Cloud Service Provider verwaltet
werden, und nicht wie bei beim „Identitätsmanagement zur Cloud“-Modell in einem
externen, von der Organisation kontrollierbaren Rechenzentrum. Dies ist allerdings
auch zugleich der größte Nachteil, da Identitätsdaten und somit sensible Daten in
der Cloud gespeichert werden. Insbesondere der Datenschutz ist hier gefährdet, da
Datenschutz eines der Hauptprobleme im Bezug zum Cloud Computing, im
Besonderen in der Public Cloud, darstellt [PeBe10].
2.4 Cloud Identity Broker-Modell
Dieses Modell stellt im Prinzip eine Erweiterung des „Identitätsmanagement von der
Cloud“-Modell dar. Im Gegensatz zu einem einzelnen Identity Provider wird ein
sogenannter Identity Broker [CSA11] in der Cloud betrieben. Ein Identity Broker ist
Cloud Identitätsmanagement-Modelle
7
eine Art Hub zwischen ein oder mehreren Service Providern und ein oder mehreren
Identity Providern. In anderen Worten, über einen Identity Broker kann ein Service
Provider unterschiedliche Identity Provider unterstützen und eine Benutzerin bzw. ein
Benutzer kann sich bei einer Authentifizierung den gewünschten Identity Provider
aussuchen. Ein Projekt, welches auf diesen „Cloud Identity Broker“-Ansatz basiert, ist
SkIDentity [HSW+12]. Abbildung 5 veranschaulicht das „Cloud Identity Broker“Modell.
Cloud Service Provider
Identity
Provider
Identity
Provider
Identitäts
daten
Identitäts
daten
Cloud Service Provider
Identity Broker
Benutzerin bzw. Benutzer
Datentransfer
Cloud Service Provider
Service
Provider
Service
Provider
Abbildung 5 – „Cloud Identity Broker”-Modell
Der Vorteil dieses Modells ist, dass die Komplexität einzelner Identity Provider vom
Identity Broker gegenüber dem Service Provider „versteckt“ wird. Der Service
Provider wird im Wesentlichen von den einzelnen Identity Providern entkoppelt. D.h.
in weiterer Folge, dass nur mehr eine starke Beziehung zwischen dem Service
Provider und dem Cloud Identity Provider existiert anstatt vielen einzelnen
Beziehungen zwischen Service Provider und Identity Providern, wenn mehrere
Identity Provider vom Service Provider unterstützt werden. Ein Service Provider, der
mehrere Identity Provider für eine Benutzerinnen- bzw. Benutzer-Authentifizierung
unterstützen möchte, braucht in diesem Modell jedoch nicht alle Schnittstellen zu
den
einzelnen
Identity
Providern
implementieren,
sondern
es
reicht
die
Implementierung der Schnittstelle zum Identity Broker. Auf organisatorischer Ebene
muss der Service Provider nur mehr dem Cloud Identity Broker vertrauen und nicht
jedem einzelnen Identity Provider, der Cloud Identity Broker bündelt in diesem Fall
diese einzelnen Vertrauensverhältnisse.
Cloud Identitätsmanagement-Modelle
8
Ein Nachteil dieses Modells ist jedoch, dass sowohl Benutzerinnen bzw. Benutzer als
auch der Service Provider ein und demselben Identity Broker in der Cloud vertrauen
müssen, um unterschiedliche Identity Provider nutzen zu können. Das heißt auch,
dass Benutzerinnen bzw. Benutzer und Service Provider von der offerierten
Funktionalität des Identity Brokers abhängig sind. Möchte beispielsweise eine
Benutzerin bzw. ein Benutzer sich bei einem Identity Provider authentifizieren,
welcher vom Cloud Identity Broker nicht unterstützt wird, so ist eine Anmeldung
schlicht und einfach nicht möglich. Ein weiterer Nachteil eines zentralen Cloud
Identity Providers ist, dass – wenn der Cloud Identity Broker ausfallen sollte –
Benutzerinnen bzw. Benutzer von einer Anmeldung bei allen unterschiedlichen
Identity Providern abgeschnitten sind. Des Weiteren können sich bei einem zentralen
Cloud
Service,
wie
es
ein
einzelner
Cloud
Identity
Broker
darstellt,
Datenschutzproblematiken ergeben, da einerseits der Cloud Provider gespeicherte
und verarbeitete Daten einsehen und andererseits das Nutzerverhalten verfolgen
kann.
Cloud Identitätsmanagement-Modelle
9
3 Föderiertes Cloud Identity Broker-Modell
In diesem Abschnitt wird ein neues Cloud Identitätsmanagement-Modell vorgestellt,
welches auf Basis des „Cloud Identity Broker“-Modells entwickelt wurde. Dieses
sogenannte „Föderierte Cloud Identity Broker“-Modell setzt nicht auf einen
einzelnen zentralen Identity Broker in der Cloud, sondern föderiert unterschiedliche
Cloud Identity Broker miteinander, die eine gemeinsame Vertrauensbeziehung
besitzen. Durch die Verwendungsmöglichkeit und Föderation von unterschiedlichen
Cloud Identity Brokern müssen Benutzerinnen bzw. Benutzer und Service Provider
nicht mehr ein und demselben Cloud Identity Broker vertrauen, sondern können
ihren
favorisierten
unterschiedlichen
und
vertrauten
Cloud
Identity
Broker
kontaktieren.
Die
Cloud
Identity
Broker
können
auch
jeweils
die
auf
unterschiedlichen individuellen Bedürfnisse von Benutzerinnen bzw. Benutzern oder
von Service Providern eingehen. Beispiele für solche Bedürfnisse wären nationale
Regulierungen oder Gesetze. Obwohl kein direktes Vertrauensverhältnis mit ein und
demselben Cloud Identity Broker für Benutzerinnen bzw. Benutzer und dem Service
Provider wie im Abschnitt 2.4 vorgestellten Modell besteht, so können sich durch
Föderation der Cloud Identity Broker Benutzerinnen bzw. Benutzer trotzdem am
Service Provider anmelden. Zusätzlich wird durch die Verwendung geeigneter
kryptographischer Technologien der Datenschutzproblematik gegenüber Cloud
Service Providern entgegengewirkt. Abbildung 6 veranschaulicht dieses „Föderierte
Cloud Identity Broker“-Modell.
Organisation
Cloud Service Provider
Cloud Service Provider
Attribute
Provider
Identity
Provider
Identitätsdaten
verschlüsselt für die
Organisation
Identitätsdaten
verschlüsselt für
die Benutzerin
bzw. den
Benutzer
Cloud Service Provider
Identity
Provider
Identity
Provider
Identitäts
daten
Identitäts
daten
Cloud Service Provider
Home Broker
SP Broker
(Identity Broker 1)
(Identity Broker 2)
Benutzerin bzw.
Benutzer
Prozessfluss der
Identiätsdaten
Bereitstellung
verschlüsselter
Identitätsdaten
Cloud Service Provider
Service
Provider
Cloud Service Provider
Service
Provider
Service
Provider
Service
Provider
Abbildung 6 – „Föderiertes Cloud Identity Broker“-Modell
Föderiertes Cloud Identity Broker-Modell
10
In diesem föderierten Ansatz ist es möglich, dass der Service Provider eine
Vertragsbeziehung mit dem Identity Broker 2 (SP Broker) besitzt, während die
Benutzerin bzw. der Benutzer hingegen eine Vertragsbeziehung mit dem Identity
Broker
1
(Home
Broker)
hat.
Beide
Identity
Broker
haben
ebenfalls
ein
entsprechendes Vertrauensverhältnis bzw. eine Vertragsbeziehung untereinander.
Betrachtet man den Prozessfluss der Identitätsdaten aus Abbildung 6 etwas genauer,
so kontaktiert eine Benutzerin bzw. ein Benutzer in einem ersten Schritt jenen Service
Provider, von dem sie bzw. er eine geschützte Ressource oder Service nutzen
möchte. Für den Zugriff auf die geschützte Ressource wird von der Benutzerin bzw.
dem Benutzer eine entsprechende Authentifizierung benötigt. Die Identifizierung
und
Authentifizierung
wird
wie
in
den
meisten
anderen
Cloud
Identitätsmanagement-Modellen an einen Identity Provider, in diesem Fall aber
zuerst an einen Cloud Identity Broker, ausgelagert. In diesem Beispiel besitzt der
Service Provider ein Vertragsverhältnis mit dem Identity Broker 2 (SP Broker), an den
die
Identifizierung
und
Authentifizierung
von
Benutzerinnen
und
Benutzern
ausgelagert wird. Im Gegensatz zu dem im Abschnitt 2.4 beschriebenen „Cloud
Identity Broker“-Modell, hat die Benutzerin bzw. der Benutzer in diesem föderierten
Modell kein Vertragsverhältnis mit demselben Identity Broker wie der Service
Provider (Identity Broker 2 bzw. SP Broker), sondern mit Identity Broker 1 (Home
Broker). Dieser unterstützt im Gegensatz zum Identity Broker 1 (Home Broker) jenen
Identity
Provider,
den
die
Benutzerin
bzw.
der
Benutzer
auch
für
eine
Authentifizierung bei dem ausgewählten Service Provider nutzen möchte. Um
diesen Identity Provider auch nutzen zu können, wird die Benutzerin bzw. der
Benutzer an Identity Broker 1 (Home Broker) weitergeleitet. Danach initiiert der
Identity Broker 1 (Home Broker) den Identifizierungs- und Authentifizierungsprozess
mit dem gewünschten Identity Provider. Die Benutzerin bzw. der Benutzer
authentifiziert sich dabei beim Identity Provider mit ihrem bzw. seinem gewünschten
Authentifizierungsmechanismus. War der Authentifizierungsvorgang erfolgreich, so
werden entsprechende Identitäts- und Authentifizierungsdaten der Benutzerin bzw.
des Benutzers an den Identity Broker 1 (Home Broker) übermittelt. Anschließend leitet
Identity Broker 1 (Home Broker) die Daten an den Identity Broker 2 (SP Broker) weiter,
welcher sie schlussendlich an den Service Provider transferiert. Basierend auf den
empfangenden Daten erlaubt bzw. verbietet der Service Provider den Zugriff auf
die
geschützte
Ressource.
Kommunikationskanäle,
wo
Im
Prinzip
gibt
Identitätsdaten
es
in
diesem
ausgetauscht
Modell
werden,
zwischen:
1. Identity Provider und Home Broker
2. Home Broker und SP Broker
3. SP Broker und Service Provider
Föderiertes Cloud Identity Broker-Modell
11
drei
nämlich
Für den Kommunikationskanal zwischen Identity Provider und Identity Broker 1 bzw.
Identity
Broker
2
und
Service
Provider
können
einfach
existierende
Identitätsprotokolle wie z.B. SAML [LCR+08] oder OAuth [Hardt12] verwendet
werden.
Obwohl das bisher beschriebene Modell gegenüber den anderen Modellen
prinzipiell Datenschutz-freundlicher ist, besteht trotzdem die Gefahr, dass ein Cloud
Provider sensible Identitätsdaten mitlesen und somit ein Benutzerinnenprofil bzw. ein
Benutzerprofil erstellen kann. Solange die Daten – auch wenn sie verschlüsselt zum
Cloud Service Provider übertragen werden – im Klartext beim Cloud Service Provider
gespeichert werden, besteht diese Gefahr. Nachdem Cloud Service Provider ihre
gespeicherten Daten üblicherweise auf verschiedene Serverfarmen und auch
Länder verteilen können, besteht in so einem Fall auch kein entsprechender
Rechtsschutz, wenn Daten bei einem Provider außerhalb der EU abgelegt werden.
So sagt beispielsweise der US Patriot Act [US-PA01], dass beliebige Daten, sofern sie
von einem US-stämmigen Unternehmen gespeichert werden, von Behörden aus
den USA auf Verlangen inspiziert und eingesehen werden können.
Um keine sensiblen Daten im Klartext bei solch einer ungewollten Inspizierung
preiszugeben und um den Datenschutz für Benutzerinnen bzw. Benutzer gegenüber
Cloud Service Providern wahren zu können, werden in diesem föderierten Cloud
Identity Broker-Modell die Daten nur mehr verschlüsselt transferiert bzw. gespeichert.
Als Verschlüsselungsalgorithmus wird dabei Proxy Re-Encryption [AFGH06] eingesetzt.
Proxy Re-Encryption ermöglicht es einem Proxy Daten, welche für eine Partei A und
dessen Public Key(A) verschlüsselt sind, unter zu Hilfenahme eines so-genannten ReEncryption Keys(A→B) die Daten so umzuschlüsseln, dass sie anschließend von einer
Partei B und dessen Private Key(B) entschlüsselt werden können. Der Proxy erhält
dabei weder Zugriff die Private Keys von A und B noch auf den Klartext der
verschlüsselten Daten. D.h., die Umschlüsselung erfolgt direkt auf den verschlüsselten
Daten, eine Entschlüsselung der Daten am Proxy ist nicht notwendig. Für die
Erstellung des Re-Encryption Keys(A→B) wird der Private Key von A und der Public Key
von B benötigt.
Die Grundlage für die Anwendung des Konzepts von Proxy Re-Encryption zur
vertraulichen Verarbeitung von Daten ist, dass persönliche Identitätsdaten beim
Identity Provider bereits verschlüsselt gespeichert sind, bevor sie weiterverarbeitet
werden. Dabei können die Identitätsdaten entweder für die Benutzerin bzw. den
Benutzer oder aber für eine Organisation, die für die Verwaltung der Identitätsdaten
zuständig ist, verschlüsselt sein. In weiterer Folge dieses Dokuments wird nur mehr
der Fall betrachtet, dass die Daten für die Benutzerin bzw. den Benutzer selbst
verschlüsselt sind. Aus Datenschutz-Perspektive hat in diesem Fall eine Benutzerin
Föderiertes Cloud Identity Broker-Modell
12
bzw. ein Benutzer die größte Kontrolle über ihre bzw. seine Daten, da nur sie bzw. er
die Daten entschlüsseln bzw. einen Re-Encryption Key generieren kann.
Föderiertes Cloud Identity Broker-Modell
13
4 Implementierung
Der folgende Abschnitt beschreibt eine prototypische Implementierung des
„Föderierten Cloud Identity Broker“-Modells unter Verwendung von Proxy ReEncryption. Die Implementierung wurde so umgesetzt, dass ein Identifizierungs- und
Authentifizierungsprozess über das vorgestellte Modell ohne unnötige Offenlegung
von Daten gegenüber einem Cloud Service Provider möglich ist. Dabei wurden die
folgenden Komponenten gemäß den in Abschnitt 3 vorgestellten Modell umgesetzt
(Identity Provider, Attribute Provider, Home Broker,
SP Broker, Service Provider).
Abbildung 7 zeigt die Komponenten der prototypischen Implementierung des
„Föderierten Cloud Identity Broker“-Modells.
OpenID
Provider
Verschlüsselte
Identitätsdaten
Attribute
Provider
Identitätsdaten
Twitter
Verschlüsselte
Identitätsdaten
Broker
Authority
Encryption Service
Cloud Service Provider
Cloud Service Provider
Online Kommunikation
Home Broker
SP Broker
Offline Kommunikation
Re-EncryptionKey Generator
Benutzerin bzw.
Benutzer
Demo Service
Provider
BenutzerDomäne
Abbildung 7 - Implementierungs-Architektur
4.1 Anforderungen
Während des Design-Prozesses des „Föderierten Cloud Identity Broker“-Modells
wurden
die
folgenden
Anforderungen
ausgearbeitet,
die
von
einer
Implementierung dieses Modells berücksichtigt werden müssen.

Individuelle Auswahl des Cloud Identity Brokers
Wie die Idee des Föderierten Cloud Identity Broker Modell es bereits vorgibt,
sollen eine Benutzerin bzw. ein Benutzer und der Service Provider ihren
bevorzugten Cloud Identity Broker individuell auswählen können.
Implementierung
14

Vertrauen
Ein Service Provider oder ein Identity Provider ist voll vertrauenswürdig, sofern er
nicht in der Cloud betrieben wird. Einem Cloud Service Provider und im
speziellen dadurch einem Cloud Identity Broker wird nur teilweise vertraut, d.h. es
wird angenommen, dass der Cloud Service Provider korrekt arbeitet, jedoch
Einsicht in verarbeitete Daten nehmen kann.

Datenschutz
Nachdem die Identity Broker in der Cloud betrieben werden, ist die Wahrung des
Datenschutzes
eine
besondere
Anforderung.
Im
Speziellen
sollen
die
Datenschutz-Aspekte der Benutzer-Zentriertheit (eine Benutzerin bzw. ein
Benutzer hat immer die volle Kontrolle, welche Daten welcher Entität zur
Verfügung gestellt werden) sowie der Datenminimierung (eine Benutzerin bzw.
ein Benutzer kann die Menge der Datenoffenlegung bestimmen) umgesetzt
werden. Zusätzlich sollen die Daten gegenüber einem Cloud Service Provider
vertraulich behandelt werden können.

Benutzerfreundlichkeit
Eine Identifizierung und Authentifizierung in diesem Modell soll für eine Benutzerin
bzw. einen Benutzer komfortabel und ohne große Hürden durchführbar sein.

Einfache Integration in existierende Infrastrukturen
Komponenten des „Föderierten Cloud Identity Broker“-Modells sollen einfach in
bestehende Infrastrukturen integriert werden können. Im Besonderen heißt das,
dass existierende Service Provider oder Identity Provider einfach an einen Cloud
Identity Broker angebunden werden können.
4.2 Komponenten
Im Folgenden werden die Komponenten der Implementierung sowie drei zusätzliche
Komponenten (in Abbildung 7 gelb hervorgehoben), deren Einführung für ein
Erfüllen der in Abschnitt 4.1 definierten Anforderungen notwendig war, kurz
beschrieben:

Demo Service Provider:
Der Demo Service Provider hat eigentlich keine bestimmte Funktionalität, er
benötigt nur eine ausreichende Identifizierung und Authentifizierung. Um den
Datenschutz von Benutzerinnen und Benutzern zu gewährleisten und die
übertragene Menge von personenbezogenen Daten gering zu halten, kann der
Demo Service Provider nur bestimmte Attribute und nicht nur die komplette
Identität für eine Identifizierung abfragen. Zusätzlich kann der Service Provider
ein bestimmtes Authentifizierungslevel fordern. Die in der Implementierung
Implementierung
15
verwendeten Authentifizierungslevel sind an die vier-stufigen Level von STORK
[HLE09] bzw. ISO/IEC 29115 [ISO29115] angelehnt.

SP Broker:
Der SP Broker wurde vom Service Provider organisatorisch ausgewählt und
kontaktiert, und somit besitzen sie ein gegenseitiges Vertrauensverhältnis. Der SP
Broker
kommuniziert
mit
dem
Home
Broker
und
leitet
entsprechende
Authentifizierungsanfragen an den Home Broker weiter. Im Weiteren stellt der SP
Broker ein User Interface bereit, bei der eine Benutzerin bzw. ein Benutzer ihren
bzw. seinen gewünschten Home Broker deklarieren kann.

Home Broker:
Der Home Broker wird durch eine benutzerdefinierte URL angegeben, die auf
den gewünschten Home Broker zeigt und einen Benutzernamen der Benutzerin
bzw. des Benutzers beim Home Broker beinhaltet. Das URL-Format ist dabei
ähnlich zu jenem, welches im OpenID
3
-Protokoll verwendet wird. Diese
benutzerdefinierte URL ist jedoch nicht persistent und kann von einer Benutzerin
bzw. von einem Benutzer jeder Zeit geändert werden. Bevor eine Benutzerin bzw.
ein Benutzer die Funktionalität eines Home Brokers benutzen kann, muss sie bzw.
er sich beim Home Broker registrieren. Der Home Broker benötigt bei einer
Registrierung unter anderem Informationen z.B. mit welchen Identity Provider
bzw. Attribute Providern die Benutzerin bzw. der Benutzer eine Affiliation besitzt
und wohin der Broker sich somit verbinden kann.
Der Home Broker kommuniziert mit Identity Providern und Attribute Providern
während eines Identifizierungs- und Authentifizierungsvorganges, wobei er der
Benutzerin bzw. des Benutzers eine Auswahlseite anzeigt, wo sie bzw. er sich
authentifizieren möchten und woher zusätzliche Attribute bezogen werden
sollten. Werden persönliche Attribute von unterschiedlichen Quellen bezogen, so
übernimmt der Home Broker auch das semantische Mapping zu den vom
Service Provider angeforderten Attributen.

OpenID Provider:
In dieser prototypischen Implementierung wurde ein OpenID Provider selbst
gehostet. Der Grund war, dass – um die persönlichen Daten zu schützen –
Attribute nur so verschlüsselt beim OpenID Provider abgelegt werden können. In
diesem Prototypen werden daher alle persönlichen Attribute von der Benutzerin
bzw. vom Benutzer für sich unter Verwendung eines persönlichen privaten
Schlüssels verschlüsselt und beim OpenID Provider sicher gespeichert. Somit hat
3
http://openid.net/
Implementierung
16
nur die Benutzerin bzw. der Benutzer Zugriff auf ihre bzw. seine persönlichen
Daten. Die einzige Information, die der OpenID Provider in Klartext erhält, ist der
bei der Anmeldung am OpenID Provider verwendete OpenID Identifikator der
Benutzerin bzw. des Benutzers.

Attribute Provider:
Für den Attribute Provider wird derselbe Ansatz wie für den OpenID Provider
verwendet, d.h. persönliche Attribute werden beim Attribute Provider nur für die
Benutzerin bzw. den Benutzer verschlüsselt gespeichert. Das einzige Attribut, das
der Attribute Provider lesen kann, ist ein Identitfikator der die verschlüsselten
Attribute einer Benutzerin bzw. einem Benutzer zuordnet. Beim Attribute Provider
ist keine explizite Authentifizierung der Benutzerin bzw. des Benutzers notwendig.

Twitter:
In der prototypischen Umsetzung wird Twitter als weiterer Identity Provider
verwendet, da Twitter bei der Registrierung persönliche Attribute speichert.

Broker Authority:
Die
Broker
Authority
ist
eine
vertrauenswürdige
Instanz,
die
die
Vertrauensverhältnisse zwischen den Brokern regelt. Im Speziellen verteilt sie
öffentliche Schlüssel und Zertifikate zum Signieren von zwischen zwei Brokern
ausgetauschten
Nachrichten,
um
einen
sicheren
und
authentischen
Kommunikationskanal garantieren zu können.

Re-Encryption Key Generator:
Der Re-Encryption Key Generator ist im Wesentlichen ein Stück Software, welche
direkt am Client der Benutzerin bzw. des Benutzers läuft. Dadurch wird
vermieden, dass private Schlüssel der Benutzerin bzw. des Benutzers die Domäne
der Benutzerin bzw. des Benutzers verlassen. In der Implementierung erlaubt eine
Benutzerin
bzw.
ein
Benutzer
die
Umschlüsselung
von
persönlichen
Identitätsdaten für einen Service Provider. Für die Umschlüsselung wird ein
sogenannter Re-Encryption Key benötigt, der sich aus dem privaten Schlüssel der
Benutzerin bzw. des Benutzers und dem öffentlichen Schlüssel des Service
Providers ableiten lässt. Der Re-Encryption Key Generator berechnet also den
Re-Encryption Key(Benutzerin bzw. Benutzer→Service Provider).

Encryption Service:
Das Encryption Service ist ein zusätzliches Service, das die Verschlüsselung von
Daten vornimmt, sofern sie beim Identity Provider nicht schon verschlüsselt
gespeichert wurden. In diesem Fall werden die Daten konkret nach einer
Implementierung
17
Authentifizierung von Twitter mittels Encryption Service für die Benutzerin bzw.
den Benutzer verschlüsselt, bevor sie an den Home Broker übertragen werden.
4.3 Kommunikationsschnittstellen
Nachdem zwischen den unterschiedlichen Komponenten Daten ausgetauscht
werden, wird nun kurz beschrieben, welche Protokolle in der Implementierung zum
Einsatz kommen. Dabei wird die Schnittstelle bzw. das Protokoll zwischen jeweils zwei
Komponenten beschrieben. Alle Schnittstellen sind zusätzlich mit SSL/TLS geschützt,
was in den einzelnen Beschreibungen daher nicht mehr explizit erwähnt wird.

Service Provider ↔ SP Broker:
Im
Prinzip
kann
jedes
beliebige
Identifizierungs-
und
Authentifizierungsprotokoll verwendet werden, sofern es beide Komponenten
unterstützen. In der prototypischen Umsetzung wurde eine leicht modifizierte
Version des SAML AuthnRequest/Response Protokolls und das SAML HTTPPOST Binding verwendet. Das verwendete Kommunikationsprotokoll ist
ähnlich dem von STORK4 spezifizierten SAML-Profil, es waren jedoch kleinere
Anpassungen notwendig, da STORK z.B. die Übertragung von einzelnen
verschlüsselten Attributen nicht unterstützt.
Die Vertrauensstellung basiert auf digitalen Zertifikaten. Es ist keine explizite
Governance-Struktur
notwendig,
da
die
Vertrauensstellung
bilateral
ausgehandelt werden kann.

SP Broker ↔ Home Broker:
Für diesen Kommunikationspfad wird ebenfalls das adaptierte SAML-Protokoll
verwendet. Auch hier werden digitale Zertifikate zur Vertrauensbildung
verwendet, jedoch sind in diesem Fall die Zertifikate von der Broker Authority
ausgestellt. Dadurch wird gewährleistet, dass nur vertrauenswürde Cloud
Identity Broker miteinander kommunizieren können.

Home Broker ↔ OpenID Provider:
Für diese Schnittstelle wurde das OpenID 2.0 Protokoll verwendet.

Home Broker ↔ Twitter:
Für
diesen
Kommunikationspfad
Kommunikationspfad
unterbrochen,
4
wird
welches
wurde
jedoch
OpenID
durch
Benutzerinnen
bzw.
das
1.0
verwendet.
Encryption
Benutzern
Implementierung
Service
erlaubt
https://www.eid-stork.eu/
18
Der
ihre
Identitätsdaten
zu
verschlüsseln,
bevor
sie
an
den
Home
Broker
weitergegeben werden.

Home Broker ↔ Attribute Provider:
Hier wurde eine einfache proprietäre Web Service-Schnittstelle verwendet.
Der Request zum Attribute Provider enthält die angeforderten Attribute sowie
einen Identifikator der Benutzerin bzw. des Benutzers, die Response beinhaltet
dann die korrespondierenden verschlüsselten Attribute.

Home Broker ↔ Re-Encryption Key Generator:
Die Kommunikation basiert auf dem SAML Attribute Query/Response Protokoll.
Der Request enthält dabei den öffentlichen Schlüssel des Service Providers.
Aus dem öffentlichen Schlüssel des Service Providers zusammen mit dem
privaten Schlüssel der Benutzerin bzw. des Benutzers wird durch den ReEncryption Key Generator ein Re-Encryption Key(Benutzerin bzw. Benutzer→Service Provider)
generiert.

Broker Authority ↔ Home/SP Broker:
Der Austausch von Zertifikaten zwischen der Broker Authority und dem Cloud
Identity Broker (Home oder SP Broker) ist ein Offline Prozess. Die Sicherheit
dieses Prozesses wird durch organisatorische Mechanismen gewährleistet.
4.4 Prozessfluss
Im Folgenden Unterabschnitt wird ein Identifizierungs- und Authentifizierungsprozess
einer Benutzerin bzw. eines Benutzers auf Basis der Implementierung und unter
Verwendung des OpenID und Attribute Providers illustriert.
4.4.1 Vorbedingungen
Vor dem Start eines Identifizierungs- und Authentifizierungsprozesses müssen die
folgenden Vorbedingungen erfüllt sein:

Es wird angenommen, dass eine Benutzerin bzw. ein Benutzer dem Service
Provider, Twitter, dem Encryption Service, und dem Re-Encryption Key Generator
(läuft auf dem Client der Benutzerin bzw. des Benutzers) vertraut. Es wird weiters
angenommen, dass die Cloud Identity Broker (Home und SP Broker), der OpenID
Provider, und der Attribute Provider zwar korrekt arbeiten, aber aufgrund ihres
Betriebs in der Cloud hinsichtlich Datenschutz als nicht voll vertrauenswürdig
eingestuft werden.

Die Broker Authority hat die Vertrauenswürdigkeit der beiden Cloud Identity
Broker (Home und SP Broker) überprüft und ihnen entsprechende Zertifikate zum
Signieren von ausgetauschten Nachrichten ausgestellt.
Implementierung
19

Ein bilaterales Vertrauensverhältnis zwischen dem Service Provider und dem SP
Broker wurde ausgehandelt. Entsprechende Zertifikate und Signaturschlüssel
wurden zwischen beiden Identitäten entsprechend ausgetauscht. Zusätzlich
besitzt der Service Provider ein entsprechendes Schlüsselpaar zum Ver- und
Entschlüsseln von Daten.

Bilaterale Vertrauensverhältnisse existieren zwischen dem Home Broker und den
einzelnen Identity Providern (OpenID Provider und Twitter). Das Überprüfen dieser
Vertrauensverhältnisse ist abhängig vom verwendeten Protokoll.

Die Benutzerin bzw. der Benutzer besitzt ein geeignetes Schlüsselpaar zum Verund Entschlüsseln von Daten. Die Benutzerin bzw. der Benutzer hat bereits
persönliche Daten verschlüsselt beim OpenID Provider und dem Attribute
Provider abgelegt.

Die Benutzerin bzw. der Benutzer besitzt ein vertragliches Verhältnis mit dem
Home Broker und ist dort registriert. Vom Home Broker wurde ihr bzw. ihm im Zuge
der
Registrierung
ein
Identifikator
(URL-basierend)
zur
Wiedererkennung
zugewiesen. Bei der Registrierung hat die Benutzerin bzw. der Benutzer
angegeben, bei welchen Identity Provider und Attribute Provider er registriert ist
und welche er im Zuge einer Authentifizierung auch nutzen möchte.
4.4.2 Authentifizierungsablauf
Das Sequenz-Diagramm in Abbildung 8 veranschaulicht einen Identifizierungs- und
Authentifizierungsprozess unter Verwendung des OpenID und Attribute Providers. Im
Folgenden werden die einzelnen Schritte genauer beschrieben.
Implementierung
20
Benutzerin bzw.
Benutzer
Service Provider
SP Broker
Home Broker
OpenID Provider
Attribute Provider
Re-Encryption
Key Generator
1. Zugriff auf geschützte Ressource
2. Authentifizierungsrequest
2. Authentifizierungsrequest (inkl. Angeforderte Attribute, Authentifizierungslevel, Öffentlicher Schlüssel des SP)
3. Verifiziere Authentifizierungsrequest
3. Wer ist dein Home Broker?
3. Bereitstellen der Information als URL
4. Weiterleiten des Authentifizierungsrequests
4. Weiterleiten des Authentifizierungsrequests
5. Anzeige der Attribute und Auswahl des Identity und Attribute Providers
5. Auswahl der Attribute, welche vom OpenID und Attribute Provider geholt werden sollen
6. Redirect zum OpenID Provider zur Authentifizierung
6. Redirect zum OpenID Provider zur Authentifizierung
7. Authentifizierung
8. Retourniere verschlüsselte Attribute
8. Retourniere verschlüsselte Attribute
9. Hole angeforderte Attribute
10. Retourniere verschlüsselte Attribute
11. Anfrage zur Erstellung des Re-Encryption Keys (inkl. öffentlicher Schlüssel des SP)
11. Bereitstellen des privaten Schlüssels
12. Erstelle Re-Encryption Key (Benutzer
12. Erstelle Re-Encryption Key (Benutzer
SP)
13. Umschlüsseln der verschlüsselten Attribute für den SP
13. Erstellen und Signieren der Authentifizierungsreponse (SAML Assertion)
14. Retourniere Authentifizierungsreponse
14. Retourniere Authentifizierungsreponse
14. Verifizieren der Authentifizierungsreponse
14. Weiterleiten der Authentifizierungsreponse
14. Weiterleiten der Authentifizierungsreponse
15. Verifizieren der Authentifizierungsreponse und entschlüsseln der Attribute
16. Bereitstellen der geschützen Ressource
Abbildung 8 - Sequenz-Diagramm des Authentifizierungsablaufs
1. Eine Benutzerin bzw. ein Benutzer möchte auf eine geschützte Ressource des
Service Providers zugreifen.
2. Nachdem für den Zugriff beim Service Provider eine Identifizierung und
Authentifizierung notwendig ist, wird die Benutzerin bzw. der Benutzer mit
einem entsprechenden Authentifizierungs-Request an den mit dem Service
Provider affiliierten SP Broker weitergeleitet. Der Authentifizierungsrequest
beinhaltet die vom Service Provider benötigten Attribute, das benötigte
Authentifizierungslevel sowie den öffentlichen Schlüssel des Service Providers
zum Verschlüsseln von Daten. Der Authentifizierungsrequest wird vom Service
Provider entsprechend signiert.
3. Der SP Broker verifiziert die Signatur des Authentifizierungsrequests und bittet
die Benutzerin bzw. den Benutzer, ihren bzw. seinen Home Broker anzugeben.
Dies geschieht durch Eingabe einer URL, z.B. https://user.home-broker.com
Implementierung
21
SP)
4. Der SP Broker sendet anschließend einen weiteren Authentifizierungsrequest,
der dieselben Daten wie der Authentifizierungsrequest aus Schritt 2
beinhaltet, an den Home Broker, den die Benutzerin bzw. der Benutzer
angegeben hat. Der SP Broker signiert den Request entsprechend.
5. Der Home Broker verifiziert den Authentifizierungsrequest. Basierend auf dem
von der Benutzerin bzw. dem Benutzer angegebenen Identifikator wird sie
bzw. er am Home Broker identifiziert. Anschließend wird der Benutzerin bzw.
dem Benutzer eine Webseite präsentiert, auf der ihr bzw. ihm die vom Service
Provider angeforderten Attribute angezeigt werden. Dabei kann die
Benutzerin bzw. der Benutzer auswählen, bei welchem Identity Provider sie
bzw. er sich authentifizieren möchte und von welchem Identity oder Attribute
Provider die angeforderten Attribute bezogen werden sollen. In dem
vorgestellten Szenario wird angenommen, dass die Benutzerin bzw. der
Benutzer sich beim OpenID Provider authentifiziert und dass zusätzliche Daten
vom Attribute Provider geholt werden.
6. Basierend auf dem OpenID Identifikator der Benutzerin bzw. des Benutzers
wird sie bzw. er an den OpenID Provider weitergeleitet.
7. Die Benutzerin bzw. der Benutzer authentifiziert sich am OpenID Provider mit
einem entsprechenden Authentifizierungsmechanismus. Im vorgestellten
Szenario wird ein simpler Benutzername/Passwort-Mechanismus verwendet.
8. Die Attribute, welche zuvor von der Benutzerin bzw. dem Benutzer in Schritt 5
ausgewählt wurden, werden vom OpenID Provider zum Home Broker in
verschlüsselter Form übermittelt.
9. Im vorgestellten Szenario kann nur eine Untermenge an angeforderten
Attributen vom OpenID Provider bereitgestellt werden. Für die restlichen
angeforderten Attribute wird deswegen noch der Attribute Provider
kontaktiert. Die Abfrage von Attributen basiert auf einem zuvor zwischen
Home Broker und Attribute Provider ausgehandelten Access Token, wie es
beispielsweise in OAuth verwendet wird.
10. Die restlichen Attribute werden in verschlüsselter Form vom Attribute Provider
an den Home Broker übertragen.
11. Nun befinden sich alle vom Service Provider angefragten Attribute
gesammelt beim Home Broker. Diese sind jedoch immer noch für die
Benutzerin bzw. den Benutzer verschlüsselt, womit die Benutzerin bzw. der
Benutzer immer noch die volle Kontrolle über ihre bzw. seine Daten besitzt.
Um diese verschlüsselten Attribute auch einem Service Provider zur Verfügung
stellen zu können, müssen sie entsprechend umgeschlüsselt werden. Dafür
wird jedoch ein Re-Encryption Key benötigt. Die Erstellung eines ReEncryption Keys erfolgt dabei durch den Re-Encryption Key Generator,
welcher lokal in der Domäne der Benutzerin bzw. des Benutzers läuft. Ein
entsprechender Request zur Erstellung eines Re-Encryption Keys wird vom
Implementierung
22
Home Broker an den lokalen Re-Encryption Key Generator gesendet. Der
Request enthält dabei den öffentlichen Schlüssel des Service Providers.
12. Die Benutzerin bzw. der Benutzer stellt dem Re-Encryption Key Generator
seinen privaten Schlüssel bereit, und somit kann aus dem privaten Schlüssel
der Benutzerin bzw. des Benutzers und dem öffentlichen Schlüssel des Service
Providers ein geeigneter Re-Encryption Key berechnet werden. Der ReEncryption Key wird anschließend an den Home Broker retourniert.
13. Der Home Broker schlüsselt nun alle Attribute der Benutzerin bzw. des
Benutzers für den Service Provider um. Die umgeschlüsselten Attribute und
das eigentliche Authentifizierungslevel werden anschließend in eine SAML
Nachricht verpackt und signiert.
14. Die SAML Nachricht wird anschließend an den SP Broker gesendet. Der SP
Broker verifiziert die Nachricht und sendet sie darauf weiter an den Service
Provider.
15. Der Service Provider verifiziert die vom SP Broker erhaltene Nachricht,
extrahiert die Attribute und entschlüsselt diese mit Hilfe seines privaten
Schlüssels.
16. Basierend auf den entschlüsselten Attributen und dem Authentifizierungslevel
kann der Service Provider nun entscheiden, ob der Benutzerin bzw. dem
Benutzer Zugriff auf die geschützte Ressource gewährt werden soll oder nicht.
Im Gegensatz zum zuvor beschriebenen Authentifizierungsablauf erlaubt Twitter
kein Speichern verschlüsselter Daten. Wird Twitter als Identity Provider verwendet,
so müssen die Daten zuerst mittels Encryption Service verschlüsselt werden, bevor
sie an den Home Broker übertragen werden.
Wiederholte Authentifizierungen:
Immer wieder den gesamten zuvor beschriebenen Authentifizierungsablauf bei
jeder Anmeldung zu durchlaufen kann für eine Benutzerin bzw. einen Benutzer
durchaus zeitraubend und kompliziert sein. Aus diesem Grund besteht die
Möglichkeit – sofern es die Benutzerin bzw. der Benutzer wünscht – bei der ersten
Authentifizierung
getroffene
Entscheidungen
bei einzelnen
Komponenten
merken zu lassen. So kann beispielsweise in Schritt 3 die Auswahl des Home
Brokers entfallen, da sich der SP Broker die gewählte Entscheidung aus dem
ersten Authentifizierungsprozess merken kann. Auch Schritt 9 kann entfallen,
sofern
die
Benutzerin
bzw.
der
Benutzer
einer
Single
Sign-On
(SSO)
Authentifizierung beim OpenID Provider zustimmt. Zusätzlich können auch die
Schritte zur Generierung eines Re-Encryption Keys entfallen, wenn der Home
Broker den erstellten Re-Encryption Key im Profil der Benutzerin bzw. des
Benutzers speichert.
Implementierung
23
5 Evaluierung und Diskussion
In diesem Abschnitt wird die vorgestellte Implementierung hinsichtlich der in
Abschnitt 4.1 definierten Anforderungen evaluiert und diskutiert.

Individuelle Auswahl des Cloud Identity Brokers
In der vorgestellten Implementierung ist es sowohl der Benutzerin bzw. dem
Benutzer als auch dem Service Provider möglich, ihren bzw. seinen gewünschten
Cloud Identity Broker für eine Authentifizierung auszuwählen. Der Service Provider
braucht nur das entsprechende Kommunikationsprotokoll zum SP Broker zu
implementieren und eine Benutzerin bzw. ein Benutzer nur die mit ihr bzw. ihm
affiliierten Identity und Attribute Provider bei einem anderen Home Broker
registrieren.

Vertrauen
Die individuellen Cloud Identity Broker vertrauen einander aufgrund dem von
der
Broker
Authority
hergestellten
Vertrauensverhältnis.
Die
Vertrauensverhältnisse zwischen Service Provider und SP Broker und zwischen
Home Broker und Identity Provider (OpenID Provider bzw. Twitter) sind bilateral
organisiert.

Datenschutz
Der Datenschutz gegenüber Cloud Service Providern wird speziell gewahrt. Die
Anforderung der Benutzer-Zentriertheit wird dadurch erfüllt, dass persönliche
Daten nur für die Benutzerin bzw. den Benutzer selbst verschlüsselt sind. Die
Benutzerin bzw. der Benutzer besitzt daher immer die volle Kontrolle zum
Entschlüsseln der Daten bzw. zur Erstellung eines Re-Encryption Key. Zusätzlich
wird die Anforderung der Datenminimierung so erfüllt, dass die Benutzerin bzw.
der Benutzer auswählen kann, welche Attribute an den Service Provider
übermittelt werden sollen. Die Vertraulichkeit der Identitätsdaten gegenüber
einem Cloud Service Provider wird insofern gewahrt, da alle Daten nur
verschlüsselt bei einem Cloud Service Provider verarbeitet werden.

Benutzerfreundlichkeit
Zuallererst ist die erhöhte Flexibilität und Benutzerfreundlichkeit dadurch
gegeben, dass sich eine Benutzerin bzw. ein Benutzer den gewünschten Cloud
Identity Broker auswählen kann. Zusätzlich kann eine Benutzerin bzw. ein Benutzer
ihre bzw. seine favorisierten Identity und Attribute Provider bei der Registrierung
am Home Broker angeben. Die Möglichkeit der Auswahl von Attributen erhöht
ebenfalls die Benutzerfreundlichkeit. Letztendlich ergibt sich ein erhöhter Komfort
für
Benutzerinnen
Evaluierung und Diskussion
und
Benutzer,
indem
Benutzerinteraktionen
24
bei
wiederkehrenden Authentifizierungsabläufen gespeichert und somit ausgelassen
werden können.

Einfache Integration in existierende Infrastrukturen
Das „Föderierte Cloud Identity Broker“-Modell kann einfach von Service
Providern aufgegriffen werden. Wenn ein entsprechender SP Broker ausgewählt
wurde, so muss nur ein spezifisches Interface zum SP Broker und nicht viele zu den
einzelnen Identity Providern implementiert werden. Zusätzliche Identity Provider
können leicht integriert werden, hier muss der Home Broker die entsprechenden
Interfaces zu den Identity Providern implementieren.
Evaluierung und Diskussion
25
6 Fazit und Ausblick
In diesem Projekt wurde ein neues Identitätsmanagement-Modell für die Cloud
vorgestellt,
welches
zusammenschließt.
mehrere
Dieses
Cloud
Modell
Identity
wurde
Broker
auch
in
anhand
einer
Föderation
unterschiedlicher
Komponenten prototypisch implementiert.
Das vorgestellte „Föderierte Cloud Identity Broker“-Modell bietet Benutzerinnen bzw.
Benutzern eine größere Flexibilität hinsichtlich der Auswahl eines gewünschten
Cloud Identity Brokers. Die Abhängigkeit von nur einem zentralen Identity Broker wie
im einfachen „Cloud Identity Broker“-Modell ist nicht mehr gegeben. Zusätzlich
bietet dieses Modell entsprechenden Datenschutz in Hinblick auf den Cloud Service
Provider, da alle Daten nur verschlüsselt zwischen den einzelnen Komponenten
ausgetauscht werden. Die Benutzerin bzw. der Benutzer besitzt dabei immer die
volle Kontrolle über ihre bzw. seine Daten, da diese anfänglich nur für sie bzw. ihn
verschlüsselt beim Identity Provider abgelegt wurden. Die Erstellung eines ReEncryption Keys und somit die Umschlüsselung für einen Service Provider erfolgt
ebenfalls nur unter der alleinigen Kontrolle der Benutzerin bzw. des Benutzers.
Letztendlich ist durch die Verwendung von standardisierten Protokollen wie OpenID
oder SAML eine einfache Integration in bestehende Infrastrukturen möglich.
Zukünftige Erweiterungen dieses Modells bzw. der prototypischen Implementierung
können die Integration von weiteren Identity Providern, wie z.B. Facebook oder
Google
betreffen.
Zusätzlich
kann
versucht
werden,
auch
nationale
Identitätsmanagementlösungen wie beispielsweise die österreichische Bürgerkarte
oder das STORK-Rahmenwerk zu integrieren.
Fazit und Ausblick
26
Dokumentenhistorie
Version
Datum
Autor(en)
Anmerkung
0.1
18.09.2014
Bernd
Zwattendorfer
Dokumenterstellung
0.2
19.09.2014
Bernd
Zwattendorfer
Kapitel 1 und 2
0.3
22.09.2014
Bernd
Zwattendorfer
Kapitel 3
0.4
23.09.2014
Bernd
Zwattendorfer
Kapitel 4
0.5
24.09.2014
Bernd
Zwattendorfer
Kapitel 5 und 6
0.6
25.09.2014
Bernd
Zwattendorfer
Finaler Draft
1.0
25.09.2014
Bernd
Zwattendorfer
Finalisierung
Fazit und Ausblick
27
Referenzen
[AFGH06]
[BeTa11]
[Cox12]
[CSA11]
[Gopa09]
[Goul10]
[Hardt12]
[HLE09]
[HSW+12]
[ISO29115]
[LCR+08]
[PeBe10]
[SBJ+14]
[US-PA01]
Fazit und Ausblick
G. Ateniese, K. Fu, M. Green, S. Hohenberger: Improved proxy
re-encryption schemes with applications to secure distributed
storage. ACM Transactions on Information and System Security
(2006), 9(1), 1–30
E. Bertino, K. Takahashi: Identity Management: Concepts,
Technologies, and Systems. Artech House (2011)
P. Cox: How to Manage Identity in the Public Cloud.
InformationWeek (2012)
Cloud Security Alliance (CSA): SECURITY GUIDANCE FOR
CRITICAL AREAS OF FOCUS IN CLOUD COMPUTING V3.0. (2011)
A. Gopalakrishnan: Cloud Computing Identity Management.
SETLabs Briefings (2009), 7(7), 45–55
J. T. Goulding: Identity and access management for the cloud:
CA’s strategy and vision. (2010)
D. Hardt: The OAuth 2.0 Authorization Framework. RFC 6749.
(2012)
B. Hulsebosch, G. Lenzini, H. Eertink: STORK D2.3 - Quality
authenticator scheme. STORK Deliverable, (2009)
D. Hühnlein, J. Schmölz, T. Wich, B. Biallowons, M. Horsch, T.
Hühnlein:
Standards
und
Schnittstellen
für
das
Identitätsmanagement in der Cloud. In: D-A-CH Security 2012,
syssec (2012) 208-218
JTC1/SC27: ISO/IEC 29115 - Information technology - Security
techniques - Entity authentication assurance framework (2013)
H. Lockhart, B. Campbell, N. Ragouzis, J. Hughes, R. Philpott, E.
Maler, T. Scavo: Security Assertion Markup Language (SAML)
V2.0 Technical Overview. (2008)
S. Pearson, A. Benameur: Privacy, Security and Trust Issues
Arising from Cloud Computing. In 2010 IEEE CloudCom (2010).
693–702
N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C.
Mortimore: OpenID Connect Core 1.0. (2014)
Senate of the United States: Uniting and Strengthening
America by Providing Appropriate Tools Required to Intercept
and Obstruct Terrorism (USA PATRIOT ACT) Act of 2001
28