Federated Identity as a Service

Größe: px
Ab Seite anzeigen:

Download "Federated Identity as a Service"

Transkript

1 Dokumentation Federated Identity as a Service Version 1.0, Bernd Zwattendorfer Zusammenfassung: In diesem Projekt wird ein neues Identitätsmanagement- Modell 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 und Identity 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 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 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 n 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 Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung Cloud Identitätsmanagement-Modelle Identitätsmanagement in der Cloud Identitätsmanagement zur Cloud Identitätsmanagement von der Cloud Cloud Identity Broker-Modell Föderiertes Cloud Identity Broker-Modell Implementierung Anforderungen Komponenten Kommunikationsschnittstellen Prozessfluss Vorbedingungen Authentifizierungsablauf Evaluierung und Diskussion Fazit und Ausblick 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 Abbildung 7 - Implementierungs-Architektur Abbildung 8 - Sequenz-Diagramm des Authentifizierungsablaufs Einleitung 2

3 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 E- Government spielt beispielsweise die österreichische Bürgerkarte bzw. Handy- Signatur 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, ein Service, und eine Benutzerin bzw. ein Benutzer als Stakeholder involviert sind [BeTa11]. Der Service 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 möglichst gering zu halten, wird diese Funktion an den Identity ausgelagert. Der Identity verwaltet dabei die Benutzerkonten bzw. die digitale Identität der Benutzerin bzw. des Benutzers. Zusätzlich regelt der Identity auch die Identifizierung und Authentifizierung von Benutzerinnen und Benutzern. Der Identity übernimmt also alle Funktionen zur Regelung des Zugriffsschutzes für den Service. Der Service erhält im Rahmen eines Identifizierungs- und Authentifizierungsprozesses nur mehr die Identitäts- und Authentifizierungsdaten einer Benutzerin bzw. eines Benutzers vom Identity. Basierend auf diesen Daten kann der Service 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 und MOA-ID dem Identity. 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 SAML 1 -Assertion [LCR+08] oder gemäß OpenID Connect [SBJ+14] in einem JSON 2 Web Token) an die Online Applikation weiter, womit die Daten bei der Online Applikation entsprechend weiter verarbeitet werden können. 1 Security Assertion Markup Language 2 JavaScript Object Notation Einleitung 3

4 Identity (IdP) Identitätsdaten- Transfer Service (SP) 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ätsmanagement- Modelle sowie die Entwicklung eines neuen Identitätsmanagement-Modell für die Cloud, welches einerseits die Vorteile des Cloud Computing ausnützt, und anderseits dessen Schwachstellen speziell im Bereich des Datenschutzes entsprechend berücksichtigt. Dieses Modell und 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

5 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, z.b. Google, sowohl den Identity als auch die Applikation, die die schützenswerten Daten bereithält (Service ). Im Prinzip verschmelzen Identity und Service in diesem Modell in der Cloud. Abbildung 2 illustriert dieses Modell. Cloud Service Identity Service 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 für seine Applikationen bereitgestellte, verwenden können. Um die Speicherung und das Management der Identitätsdaten kümmert sich der Cloud Service. Nachteil ist natürlich, dass nur jene Daten verwendet werden können, die der Cloud Service auch unterstützt. Außerdem liegt die Kontrolle des Identitätsmanagementsystems (Identity ) komplett beim Cloud Service. Eine Migration oder Synchronisierung externer Identitätsdaten zum Cloud Cloud Identitätsmanagement-Modelle 5

6 Service ist in diesem Modell nicht vorgesehen. D.h., Benutzerinnen und Benutzer müssen sich beim Cloud Service 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 empfängt nur Identitätsdaten von einem externen Identity. Der Unterschied zum vorherigen Modell ist, dass der Identity 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 hostet in diesem Fall nur die Applikation, an der eine Authentifizierung notwendig ist. Der Datentransfer zwischen dem externen Identity 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 Identity Service 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 transferiert werden muss und die eigene Organisation die Kontrolle behalten kann. Die Identifizierung und Authentifizierung erfolgt beim externen Identity, Identitäts- und Authentifizierungsdaten werden nur über eine entsprechende Schnittstelle an den Cloud Service 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 s als auch Seiten des externen Identity s auftreten können. Außerdem werden in diesem Modell nicht die vollen positiven Cloud Eigenschaften ausgenützt, da der Identity nicht in der Cloud betrieben wird. Cloud Identitätsmanagement-Modelle 6

7 2.3 Identitätsmanagement von der Cloud In diesem Modell werden sowohl der Identity als auch der Service in der Cloud betrieben. Wesentlicher Unterschied zum Identitätsmanagement in der Cloud -Modell ist, dass der Identity und der Service von zwei unterschiedlichen Cloud Service n betrieben werden. D.h., ein Cloud Service hostet den Identity und ein anderer Cloud Service die Applikation. Diese Trennung spiegelt auch die generelle Architektur aus Abbildung 1 wider, nur dass beide (Identity und Service ) in der Cloud betrieben werden, was die Vorteile des Cloud Computing effizient ausnützt. Abbildung 4 zeigt dieses Modell. Cloud Service Cloud Service Identitäts daten Identity Service 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 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 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 wird ein sogenannter Identity Broker [CSA11] in der Cloud betrieben. Ein Identity Broker ist Cloud Identitätsmanagement-Modelle 7

8 eine Art Hub zwischen ein oder mehreren Service n und ein oder mehreren Identity n. In anderen Worten, über einen Identity Broker kann ein Service unterschiedliche Identity unterstützen und eine Benutzerin bzw. ein Benutzer kann sich bei einer Authentifizierung den gewünschten Identity 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 Identity Identity Identitäts daten Identitäts daten Cloud Service Identity Broker Benutzerin bzw. Benutzer Datentransfer Cloud Service Service Service Abbildung 5 Cloud Identity Broker -Modell Der Vorteil dieses Modells ist, dass die Komplexität einzelner Identity vom Identity Broker gegenüber dem Service versteckt wird. Der Service wird im Wesentlichen von den einzelnen Identity n entkoppelt. D.h. in weiterer Folge, dass nur mehr eine starke Beziehung zwischen dem Service und dem Cloud Identity existiert anstatt vielen einzelnen Beziehungen zwischen Service und Identity n, wenn mehrere Identity vom Service unterstützt werden. Ein Service, der mehrere Identity für eine Benutzerinnen- bzw. Benutzer-Authentifizierung unterstützen möchte, braucht in diesem Modell jedoch nicht alle Schnittstellen zu den einzelnen Identity n implementieren, sondern es reicht die Implementierung der Schnittstelle zum Identity Broker. Auf organisatorischer Ebene muss der Service nur mehr dem Cloud Identity Broker vertrauen und nicht jedem einzelnen Identity, der Cloud Identity Broker bündelt in diesem Fall diese einzelnen Vertrauensverhältnisse. Cloud Identitätsmanagement-Modelle 8

9 Ein Nachteil dieses Modells ist jedoch, dass sowohl Benutzerinnen bzw. Benutzer als auch der Service ein und demselben Identity Broker in der Cloud vertrauen müssen, um unterschiedliche Identity nutzen zu können. Das heißt auch, dass Benutzerinnen bzw. Benutzer und Service von der offerierten Funktionalität des Identity Brokers abhängig sind. Möchte beispielsweise eine Benutzerin bzw. ein Benutzer sich bei einem Identity 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 s ist, dass wenn der Cloud Identity Broker ausfallen sollte Benutzerinnen bzw. Benutzer von einer Anmeldung bei allen unterschiedlichen Identity n 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 gespeicherte und verarbeitete Daten einsehen und andererseits das Nutzerverhalten verfolgen kann. Cloud Identitätsmanagement-Modelle 9

10 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 nicht mehr ein und demselben Cloud Identity Broker vertrauen, sondern können ihren favorisierten und vertrauten Cloud Identity Broker kontaktieren. Die unterschiedlichen Cloud Identity Broker können auch jeweils auf die unterschiedlichen individuellen Bedürfnisse von Benutzerinnen bzw. Benutzern oder von Service n 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 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 anmelden. Zusätzlich wird durch die Verwendung geeigneter kryptographischer Technologien der Datenschutzproblematik gegenüber Cloud Service n entgegengewirkt. Abbildung 6 veranschaulicht dieses Föderierte Cloud Identity Broker -Modell. Organisation Cloud Service Cloud Service Identity Attribute Identity Identity Identitätsdaten verschlüsselt für die Benutzerin bzw. den Benutzer Identitätsdaten verschlüsselt für die Organisation Identitäts daten Identitäts daten Cloud Service Cloud Service Home Broker (Identity Broker 1) SP Broker (Identity Broker 2) Benutzerin bzw. Benutzer Prozessfluss der Identiätsdaten Bereitstellung verschlüsselter Identitätsdaten Cloud Service Cloud Service Service Service Service Service Abbildung 6 Föderiertes Cloud Identity Broker -Modell Föderiertes Cloud Identity Broker-Modell 10

11 In diesem föderierten Ansatz ist es möglich, dass der Service 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, 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, in diesem Fall aber zuerst an einen Cloud Identity Broker, ausgelagert. In diesem Beispiel besitzt der Service 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 (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, den die Benutzerin bzw. der Benutzer auch für eine Authentifizierung bei dem ausgewählten Service nutzen möchte. Um diesen Identity 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. Die Benutzerin bzw. der Benutzer authentifiziert sich dabei beim Identity 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 transferiert. Basierend auf den empfangenden Daten erlaubt bzw. verbietet der Service den Zugriff auf die geschützte Ressource. Im Prinzip gibt es in diesem Modell drei Kommunikationskanäle, wo Identitätsdaten ausgetauscht werden, nämlich zwischen: 1. Identity und Home Broker 2. Home Broker und SP Broker 3. SP Broker und Service Föderiertes Cloud Identity Broker-Modell 11

12 Für den Kommunikationskanal zwischen Identity und Identity Broker 1 bzw. Identity Broker 2 und Service 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 sensible Identitätsdaten mitlesen und somit ein Benutzerinnenprofil bzw. ein Benutzerprofil erstellen kann. Solange die Daten auch wenn sie verschlüsselt zum Cloud Service übertragen werden im Klartext beim Cloud Service gespeichert werden, besteht diese Gefahr. Nachdem Cloud Service 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 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 n 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 Re- Encryption 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 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

13 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

14 4 Implementierung OpenID Verschlüsselte Identitätsdaten Twitter Identitätsdaten Attribute Verschlüsselte Identitätsdaten Broker Authority Encryption Service Online Kommunikation Offline Kommunikation Cloud Service Home Broker Cloud Service SP Broker Benutzerin bzw. Benutzer Benutzer- Domäne Der folgende Abschnitt beschreibt eine prototypische Implementierung des Föderierten Cloud Identity Broker -Modells unter Verwendung von Proxy Re- Encryption. 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 möglich ist. Dabei wurden die folgenden Komponenten gemäß den in Abschnitt 3 vorgestellten Modell umgesetzt (Identity, Attribute, Home Broker, SP Broker, Service ). Abbildung 7 zeigt die Komponenten der prototypischen Implementierung des Föderierten Cloud Identity Broker -Modells. Re-Encryption- Key Generator Demo Service 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 ihren bevorzugten Cloud Identity Broker individuell auswählen können. Implementierung 14

15 Vertrauen Ein Service oder ein Identity ist voll vertrauenswürdig, sofern er nicht in der Cloud betrieben wird. Einem Cloud Service und im speziellen dadurch einem Cloud Identity Broker wird nur teilweise vertraut, d.h. es wird angenommen, dass der Cloud Service 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 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 oder Identity 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 : Der Demo Service 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 nur bestimmte Attribute und nicht nur die komplette Identität für eine Identifizierung abfragen. Zusätzlich kann der Service ein bestimmtes Authentifizierungslevel fordern. Die in der Implementierung Implementierung 15

16 verwendeten Authentifizierungslevel sind an die vier-stufigen Level von STORK [HLE09] bzw. ISO/IEC [ISO29115] angelehnt. SP Broker: Der SP Broker wurde vom Service 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 bzw. Attribute n die Benutzerin bzw. der Benutzer eine Affiliation besitzt und wohin der Broker sich somit verbinden kann. Der Home Broker kommuniziert mit Identity n und Attribute n 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 angeforderten Attributen. OpenID : In dieser prototypischen Implementierung wurde ein OpenID selbst gehostet. Der Grund war, dass um die persönlichen Daten zu schützen Attribute nur so verschlüsselt beim OpenID 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 sicher gespeichert. Somit hat 3 Implementierung 16

17 nur die Benutzerin bzw. der Benutzer Zugriff auf ihre bzw. seine persönlichen Daten. Die einzige Information, die der OpenID in Klartext erhält, ist der bei der Anmeldung am OpenID verwendete OpenID Identifikator der Benutzerin bzw. des Benutzers. Attribute : Für den Attribute wird derselbe Ansatz wie für den OpenID verwendet, d.h. persönliche Attribute werden beim Attribute nur für die Benutzerin bzw. den Benutzer verschlüsselt gespeichert. Das einzige Attribut, das der Attribute lesen kann, ist ein Identitfikator der die verschlüsselten Attribute einer Benutzerin bzw. einem Benutzer zuordnet. Beim Attribute ist keine explizite Authentifizierung der Benutzerin bzw. des Benutzers notwendig. Twitter: In der prototypischen Umsetzung wird Twitter als weiterer Identity 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. 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 s ableiten lässt. Der Re-Encryption Key Generator berechnet also den Re-Encryption Key(Benutzerin bzw. Benutzer Service ). Encryption Service: Das Encryption Service ist ein zusätzliches Service, das die Verschlüsselung von Daten vornimmt, sofern sie beim Identity nicht schon verschlüsselt gespeichert wurden. In diesem Fall werden die Daten konkret nach einer Implementierung 17

18 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 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 HTTP- POST Binding verwendet. Das verwendete Kommunikationsprotokoll ist ähnlich dem von STORK 4 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 : Für diese Schnittstelle wurde das OpenID 2.0 Protokoll verwendet. Home Broker Twitter: Für diesen Kommunikationspfad wurde OpenID 1.0 verwendet. Der Kommunikationspfad wird jedoch durch das Encryption Service unterbrochen, welches Benutzerinnen bzw. Benutzern erlaubt ihre 4 https://www.eid-stork.eu/ Implementierung 18

19 Identitätsdaten zu verschlüsseln, bevor sie an den Home Broker weitergegeben werden. Home Broker Attribute : Hier wurde eine einfache proprietäre Web Service-Schnittstelle verwendet. Der Request zum Attribute 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 s. Aus dem öffentlichen Schlüssel des Service s zusammen mit dem privaten Schlüssel der Benutzerin bzw. des Benutzers wird durch den Re- Encryption Key Generator ein Re-Encryption Key(Benutzerin bzw. Benutzer Service ) 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 s illustriert 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, 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, und der Attribute 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

20 Ein bilaterales Vertrauensverhältnis zwischen dem Service und dem SP Broker wurde ausgehandelt. Entsprechende Zertifikate und Signaturschlüssel wurden zwischen beiden Identitäten entsprechend ausgetauscht. Zusätzlich besitzt der Service ein entsprechendes Schlüsselpaar zum Ver- und Entschlüsseln von Daten. Bilaterale Vertrauensverhältnisse existieren zwischen dem Home Broker und den einzelnen Identity n (OpenID 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 und dem Attribute 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 und Attribute er registriert ist und welche er im Zuge einer Authentifizierung auch nutzen möchte Authentifizierungsablauf Das Sequenz-Diagramm in Abbildung 8 veranschaulicht einen Identifizierungs- und Authentifizierungsprozess unter Verwendung des OpenID und Attribute s. Im Folgenden werden die einzelnen Schritte genauer beschrieben. Implementierung 20

eid und Sicherheit in der Cloud

eid und Sicherheit in der Cloud www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria eid und Sicherheit in der Cloud Version 1.0, 20. Dezember 2012 Bernd

Mehr

Anonymous Credentials Claim-based authentication

Anonymous Credentials Claim-based authentication Dokumentation Anonymous Credentials Claim-based authentication Version 1.0, 04.12.2013 Bernd Zwattendorfer bernd.zwattendorfer@egiz.gv.at Zusammenfassung: Anonymous Credentials vermeiden einerseits die

Mehr

MOA-ID Hands-On Workshop

MOA-ID Hands-On Workshop MOA-ID Hands-On Workshop Architektur und Neuerungen Wien, 27.05.2014 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Neuerungen Datenbankbasierte

Mehr

Kernkomponenten in der Cloud

Kernkomponenten in der Cloud Dokumentation E-Government Kernkomponenten in der Cloud Version 1.0, 04.12.2013 Bernd Zwattendorfer bernd.zwattendorfer@egiz.gv.at Zusammenfassung: Cloud Computing ist seit Jahren eines der dominanten

Mehr

!"#$"%&'()*$+()',!-+.'/',

!#$%&'()*$+()',!-+.'/', Soziotechnische Informationssysteme 7. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 4(5,12316,7'.'0,!.80/6,9*$:'0+$.;.,&0$'0, 3, Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung!

Mehr

(c) 2014, Peter Sturm, Universität Trier

(c) 2014, Peter Sturm, Universität Trier Soziotechnische Informationssysteme 6. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 1 Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung Nachweis einer behaupteten

Mehr

Mozilla Persona. Hauptseminar Web Engineering. Vortrag. an identity system for the web. 10.12.2012 Nico Enderlein

Mozilla Persona. Hauptseminar Web Engineering. Vortrag. an identity system for the web. 10.12.2012 Nico Enderlein Mozilla Persona an identity system for the web Hauptseminar Web Engineering Vortrag 10.12.2012 Nico Enderlein 1 PASSWORT??? BENUTZERNAME??? 2 Idee IDEE Protokoll & Implementierung Voost ( Kalender für

Mehr

Identity Management und Web-Sockets

Identity Management und Web-Sockets Dokumentation Identity Management und Web-Sockets Version 1.0, 11.12.2014 Bernd Zwattendorfer bernd.zwattendorfer@egiz.gv.at Zusammenfassung: Identity Management (Identitätsmanagement) ist eines der Kernkonzepte

Mehr

Identitätsmanagement der nächsten Generation

Identitätsmanagement der nächsten Generation Identitätsmanagement der nächsten Generation mit der österreichischen Handy-Signatur Dr. Eisenstadt, 03.06.2014 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen

S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen S.A.F.E. Beate Schulte Koordinierungsstelle für IT-Standards (KoSIT) XÖV-Anwenderkonferenz 2011, Bremen Herzlichen Dank! Projektleitung S.A.F.E.: Meinhard Wöhrmann (meinhard.woehrmann@olg-duesseldorf.nrw.de)

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Positionspapier: Portalverbund und ehealth

Positionspapier: Portalverbund und ehealth Positionspapier: Portalverbund und ehealth e-government Arbeitsgruppe Integration und Zugänge (AG-IZ) Dr. Wilfried Connert Franz Hoheiser-Pförtner, MSc Rainer Hörbe Peter Pfläging Juli 2009 Inhalt Zielsetzung

Mehr

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

smis_secure mail in der srg / pflichtenheft /

smis_secure mail in der srg / pflichtenheft / smis_secure mail in der srg / pflichtenheft / Dok.-Nr: Version: 1.1 PH.002 Status: Klassifizierung: Autor: Verteiler: Draft Erik Mulder, Thanh Diep Erik Mulder, Thanh Diep Pflichtenheft, Seite 2 / 2 Änderungskontrolle

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

VERTRAUENSWÜRDIGE IDENTITÄTEN FÜR DIE CLOUD

VERTRAUENSWÜRDIGE IDENTITÄTEN FÜR DIE CLOUD VERTRAUENSWÜRDIGE IDENTITÄTEN FÜR DIE CLOUD Dr. Detlef Hühnlein, Johannes Schmölz ecsec GmbH, Sudetenstraße 16, D96247 Michelau Zusammenfassung 1 Einleitung che Schwachstellen enthalten. 44 FraunhoferGesellschaft

Mehr

Projekt Smart Web Grid

Projekt Smart Web Grid Projekt Smart Web Grid Eine übergreifende Smart Grid Informationsplattform für alle Teilnehmer Thomas Leber Institut für Computertechnik: Energy&IT Research 17. Juni, Wien Computer Technology /12 Das Smart

Mehr

E-Mail-Verschlüsselung

E-Mail-Verschlüsselung E-Mail-Verschlüsselung In der Böllhoff Gruppe Informationen für unsere Geschäftspartner Inhaltsverzeichnis 1 E-Mail-Verschlüsselung generell... 1 1.1 S/MIME... 1 1.2 PGP... 1 2 Korrespondenz mit Böllhoff...

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Konzepte von Betriebssystem-Komponenten Schwerpunkt Authentifizierung. Das Kerberos-Protokoll

Konzepte von Betriebssystem-Komponenten Schwerpunkt Authentifizierung. Das Kerberos-Protokoll Konzepte von Betriebssystem-Komponenten Schwerpunkt Authentifizierung Das Kerberos-Protokoll Guido Söldner guido@netlogix.de. Überblick über das Kerberos-Protokoll Ein Standardvorgang in der Computersicherheit

Mehr

Föderiertes Identity Management

Föderiertes Identity Management Föderiertes Identity Management 10. Tagung der DFN-Nutzergruppe Hochschulverwaltung Berlin, 09.05.-11.05.2011 Peter Gietz, CEO, DAASI International GmbH Peter.gietz@daasi.de 1 von 23 (c) Mai 2011 DAASI

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

Identitätskonzepte. Hauptseminar Web Engineering Vortrag. OpenID, WebID und OAuth. Robert Unger

Identitätskonzepte. Hauptseminar Web Engineering Vortrag. OpenID, WebID und OAuth. Robert Unger Identitätskonzepte OpenID, WebID und OAuth Hauptseminar Web Engineering Vortrag Robert Unger WS 12/13 07.12.2012 Inhalt Einführung OpenID WebID OAuth Fazit Quellen TU-Chemnitz - Hauptseminar Web Engineering

Mehr

Starke Authentifizierung für den sicheren Zugriff auf IT-Ressourcen in Föderationen

Starke Authentifizierung für den sicheren Zugriff auf IT-Ressourcen in Föderationen Starke Authentifizierung für den sicheren Zugriff auf IT-Ressourcen in Föderationen forflex-tagung 2011 27.05.2011 Dipl.-Wirtsch.Inf. Christian Senk Dipl.-Wirtsch.Inf. Christian Senk Agenda 1. Problemstellung

Mehr

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel

Bernd Blümel. Verschlüsselung. Prof. Dr. Blümel Bernd Blümel 2001 Verschlüsselung Gliederung 1. Symetrische Verschlüsselung 2. Asymetrische Verschlüsselung 3. Hybride Verfahren 4. SSL 5. pgp Verschlüsselung 111101111100001110000111000011 1100110 111101111100001110000111000011

Mehr

Identity Management mit OpenID

Identity Management mit OpenID Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München Identity Management mit OpenID Innovative Internet Technologien und Mobilkommunikation WS2008/2009 Verfasser:

Mehr

Neuigkeiten bestehender Komponenten

Neuigkeiten bestehender Komponenten Neuigkeiten bestehender Komponenten EGIZ Inside Out Thomas Lenz Andreas Fitzek Wien, 06.06.2016 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 15.07.2013 Dokumentenart: Anwenderbeschreibung Version: 3.2 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Verschlüsselte E-Mails: Wie sicher ist sicher?

Verschlüsselte E-Mails: Wie sicher ist sicher? Verschlüsselte E-Mails: Wie sicher ist sicher? Mein Name ist Jörg Reinhardt Linux-Administrator und Support-Mitarbeiter bei der JPBerlin JPBerlin ist ein alteingesessener Provider mit zwei Dutzend Mitarbeitern

Mehr

STORK. Secure IdenTity AcrOss BoRders LinKed. Bernd Zwattendorfer Wien, 15.03.2012

STORK. Secure IdenTity AcrOss BoRders LinKed. Bernd Zwattendorfer Wien, 15.03.2012 STORK Secure IdenTity AcrOss BoRders LinKed Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Bernd Zwattendorfer Wien, 15.03.2012 Inhalt Motivation

Mehr

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG

Portalverbundprotokoll Version 2. S-Profil. Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG 1 Portalverbundprotokoll Version 2 S-Profil Konvention PVP2-S-Profil 2.1.2 Ergebnis der AG Kurzbeschreibung Das S-Profil von PVP2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser.

Mehr

IT-Sicherheit Kapitel 5 Public Key Infrastructure

IT-Sicherheit Kapitel 5 Public Key Infrastructure IT-Sicherheit Kapitel 5 Public Key Infrastructure Dr. Christian Rathgeb Sommersemester 2014 1 Einführung Problembetrachtung: Alice bezieht den Public Key von Bob aus einem öffentlichen Verzeichnis, verschlüsselt

Mehr

MOA-ID Workshop. Anwendungsintegration, Installation und Konfiguration. Klaus Stranacher Graz, 25.06.2013

MOA-ID Workshop. Anwendungsintegration, Installation und Konfiguration. Klaus Stranacher Graz, 25.06.2013 MOA-ID Workshop Anwendungsintegration, Installation und Konfiguration Graz, 25.06.2013 Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Überblick»

Mehr

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit

SZENARIO BEISPIEL. Implementation von Swiss SafeLab M.ID mit Citrix. Redundanz und Skalierbarkeit SZENARIO BEISPIEL Implementation von Swiss SafeLab M.ID mit Citrix Redundanz und Skalierbarkeit Rahmeninformationen zum Fallbeispiel Das Nachfolgende Beispiel zeigt einen Aufbau von Swiss SafeLab M.ID

Mehr

Identity as a Service

Identity as a Service Identity as a Service Michael Seeger Siemens IT Solutions and Services CISM. Identity as a Service Geschichtlicher Abriss Technik oder the gory details Voraussetzungen Business case Referenzen und Links

Mehr

MOA-Workshop. Ausländische BürgerInnen (STORK) Bernd Zwattendorfer Wien, 28. Juni 2012

MOA-Workshop. Ausländische BürgerInnen (STORK) Bernd Zwattendorfer Wien, 28. Juni 2012 MOA-Workshop Ausländische BürgerInnen (STORK) Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU Graz Bernd Zwattendorfer Wien, 28. Juni 2012 Motivation

Mehr

Elektronische Vollmachten - Demonstrator

Elektronische Vollmachten - Demonstrator www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten - Demonstrator Version 1.0.0, 09.01.2007 DI

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause

1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management. Deckblatt. Harald Krause 1 Dataport 12.Juli 2007 Internationale Standards zu Identity Management Deckblatt Bremen, E-Government in medias res, 12. Juli 2007 Internationale Standards zu Identity Management 3 Dataport 12.Juli 2007

Mehr

Inhaltsverzeichnis. Open-Xchange Authentication & Sessionhandling

Inhaltsverzeichnis. Open-Xchange Authentication & Sessionhandling Open-Xchange Authentication & Sessionhandling Version Date Author Changes 1.0 28.08.2006 Stephan Martin Initiale Version 1.1 29.08.2006 Marcus Klein Details Authentication via JSON 1.2 04.09.2006 Stephan

Mehr

Java Applet Alternativen

Java Applet Alternativen White Paper Java Applet Alternativen Version 1.0, 21.01.2014 Tobias Kellner tobias.kellner@egiz.gv.at Zusammenfassung: Aufgrund diverser Meldungen über Sicherheitslücken in Java haben in letzter Zeit Browser-Hersteller

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

Identitäts-Protokolle für MOA-ID

Identitäts-Protokolle für MOA-ID Dokumentation Identitäts-Protokolle für MOA-ID Version 1.0, 26.09.2013 Bernd Zwattendorfer bernd.zwattendorfer@egiz.gv.at Zusammenfassung: Identitätsprotokolle dienen im Allgemeinen dem sicheren Austausch

Mehr

Reporting Services Dienstarchitektur

Reporting Services Dienstarchitektur Reporting Services Dienstarchitektur Reporting Services Dienstarchitektur In Reporting Services wird ein Berichtsserver als ein Windows - Dienst implementiert, der aus unterschiedlichen Featurebere i-

Mehr

BeamYourScreen Sicherheit

BeamYourScreen Sicherheit BeamYourScreen Sicherheit Inhalt BeamYourScreen Sicherheit... 1 Das Wichtigste im Überblick... 3 Sicherheit der Inhalte... 3 Sicherheit der Benutzeroberfläche... 3 Sicherheit der Infrastruktur... 3 Im

Mehr

Modernes Identitätsmanagement für das Gesundheitswesen von morgen

Modernes Identitätsmanagement für das Gesundheitswesen von morgen Modernes Identitätsmanagement für das Gesundheitswesen von morgen Berlin, 26.04.2012 Dr. Detlef Hühnlein, ecsec GmbH 2012 ID4health Copyright 2010 ecsec GmbH, All Rights Reserved. Agenda Ausgangssituation

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

Elektronische Identität im grenzüberschreitenden europäischen Kontext

Elektronische Identität im grenzüberschreitenden europäischen Kontext Elektronische Identität im grenzüberschreitenden europäischen Kontext Bernd Zwattendorfer E-Government Konferenz 2011 Salzburg Zentrum für sichere Informationstechnologie - Austria Inhalt Motivation EU

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen

Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen Senden von strukturierten Berichten über das SFTP Häufig gestellte Fragen 1 Allgemeines Was versteht man unter SFTP? Die Abkürzung SFTP steht für SSH File Transfer Protocol oder Secure File Transfer Protocol.

Mehr

Shibboleth IdP-Erweiterungen an der Freien Universität Berlin

Shibboleth IdP-Erweiterungen an der Freien Universität Berlin Steffen Hofmann (Dipl.-Inf.) ZEDAT, Identity and Customer Management (ICM) Shibboleth IdP-Erweiterungen an der Freien Universität Berlin Informative Login-Webseiten, JAAS-Login- Module, Login-Handler,

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp

Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp Sicheres Single Sign-On mit dem SAML Holder-of-Key Web Browser SSO Profile und SimpleSAMLphp Andreas Mayer Adolf Würth GmbH & Co. KG Künzelsau-Gaisbach Prof. Dr. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

Mehr

Wiederholung: Informationssicherheit Ziele

Wiederholung: Informationssicherheit Ziele Wiederholung: Informationssicherheit Ziele Vertraulichkeit: Schutz der Information vor unberechtigtem Zugriff bei Speicherung, Verarbeitung und Übertragung Integrität: Garantie der Korrektheit (unverändert,

Mehr

Kolloquium zur Diplomarbeit

Kolloquium zur Diplomarbeit Kolloquium zur Diplomarbeit Konzeption und prototypische Umsetzung von Authentifizierungsverfahren und Kommunikationsschnittstellen für das Identity-Management-System CIDAS unter besonderer Berücksichtigung

Mehr

GecMeGUI. Eine SSO-enabled Cloud WebGUI mit clientseitiger Schlüsselgenerierung

GecMeGUI. Eine SSO-enabled Cloud WebGUI mit clientseitiger Schlüsselgenerierung GecMeGUI Eine SSO-enabled WebGUI mit clientseitiger Schlüsselgenerierung Hochschule Furtwangen Frank Dölitzscher 04.04.2011 Agenda Web GUI 1. Einführung 2. Absicherung des Service Zugangs 3. Web GUI Sicherung

Mehr

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof

Authentifizierung. Benutzerverwaltung mit Kerberos. Referent: Jochen Merhof Authentifizierung Benutzerverwaltung mit Kerberos Referent: Jochen Merhof Überblick über Kerberos Entwickelt seit Mitte der 80er Jahre am MIT Netzwerk-Authentifikations-Protokoll (Needham-Schroeder) Open-Source

Mehr

Wie wird nun aus einem Zertifikat eine Signatur?

Wie wird nun aus einem Zertifikat eine Signatur? DIGITALE SIGNATUR IN DER PRAXIS ODER WIE WIRD AUS EINEM ZERTIFIKAT EINE (SICHERE) SIGNATUR? Der folgende Beitrag befaßt sich besonders mit dem Zusammenspiel von Zertifizierungsdiensteanbieter (ZDA) einerseits

Mehr

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur.

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur. Referat im Proseminar Electronic Commerce Thema: Anwendungen von Kryptographie für E-Commerce Betreuer: Michael Galler Stoffsammlung/Grobgliederung Problem der Sicherheit des E-Commerce - nötig für Sicherheitsgarantie:

Mehr

Thema: Web Services. Was ist ein Web Service?

Thema: Web Services. Was ist ein Web Service? Willkommen zum Component Ware Seminar Thema: Achim Grimm & Fabian Unterschütz Folie 1 Was ist ein Web Service? Web Services sind selbstbeschreibende, modulare Softwarekomponenten im Internet, die sich

Mehr

Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur.

Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur. MIKOGO SICHERHEIT Inhaltsverzeichnis Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur Seite 2. Im Einzelnen 4 Komponenten der Applikation

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Thomas Blasek Betreuer: Stefan Wild

Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Thomas Blasek Betreuer: Stefan Wild Herzlich Willkommen! Seminar Web Engineering: Vortrag Thema: Federated Identity Management Systems Von: Betreuer: Stefan Wild Einleitung Federated System -> Verbund von Teilnehmern Austausch von Identitätseigenschaften

Mehr

OpenID und der neue, elektronische Personalausweis

OpenID und der neue, elektronische Personalausweis OpenID und der neue, elektronische Personalausweis Über sichere Identitäten im Internet CeBIT 2010, Hannover Linux Media AG Open Source Forum 05.03.2010 Sebastian Feld feld @ internet-sicherheit. de Institut

Mehr

Internet Datasafe Sicherheitstechnische Herausforderungen

Internet Datasafe Sicherheitstechnische Herausforderungen ERFA-Tagung 14.9.2010 Internet Datasafe Sicherheitstechnische Herausforderungen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften

Mehr

Authentication as a Service (AaaS)

Authentication as a Service (AaaS) Authentication as a Service (AaaS) Abendseminar «Innovative Alternativen zum Passwort» 26.10.2010, Hotel Novotel, Zürich Anton Virtic CEO, Clavid AG Information Security Society Switzerland 1 Agenda Cloud

Mehr

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 mit den eingetragenen Materialnummern Inhalt Inhalt... 2 1 Vorwort... 3 2 Allgemeines zur Verschlüsselung...

Mehr

Public Key Infrastruktur. Georg Gruber & Georg Refenner 26.Jänner 2009 ITTK 09

Public Key Infrastruktur. Georg Gruber & Georg Refenner 26.Jänner 2009 ITTK 09 Public Key Infrastruktur Georg Gruber & Georg Refenner 26.Jänner 2009 ITTK 09 Grundlagen Symmetrische Verschlüsselung Asymmetrische Verschlüsselung Hybridverschlüsselung Hashverfahren/Digitale Signaturen

Mehr

Flowy Apps erzählt eine kurze Geschichte über REDS. Remotely Encrypted Distributed Storage

Flowy Apps erzählt eine kurze Geschichte über REDS. Remotely Encrypted Distributed Storage Flowy Apps erzählt eine kurze Geschichte über REDS Remotely Encrypted Distributed Storage Heute wird alles im Internet, auch bekannt als die Cloud, gemacht. Web-Entwickler platzieren ihre Webapps in der

Mehr

Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur

Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur Stefan Marienfeld Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze Stefan Marienfeld Gliederung

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

Informatik für Ökonomen II HS 09

Informatik für Ökonomen II HS 09 Informatik für Ökonomen II HS 09 Übung 5 Ausgabe: 03. Dezember 2009 Abgabe: 10. Dezember 2009 Die Lösungen zu den Aufgabe sind direkt auf das Blatt zu schreiben. Bitte verwenden Sie keinen Bleistift und

Mehr

Wie verwende ich Twitter in MAGIC THipPro

Wie verwende ich Twitter in MAGIC THipPro Wie verwende ich Twitter in MAGIC THipPro Konfigurationsanleitung Version: V1-10. August 2015 by AVT Audio Video Technologies GmbH Registrierung der Social Media Option Stellt die Social Media Option allen

Mehr

Betriebssysteme und Sicherheit Sicherheit. Signaturen, Zertifikate, Sichere E-Mail

Betriebssysteme und Sicherheit Sicherheit. Signaturen, Zertifikate, Sichere E-Mail Betriebssysteme und Sicherheit Sicherheit Signaturen, Zertifikate, Sichere E-Mail Frage Public-Key Verschlüsselung stellt Vertraulichkeit sicher Kann man auch Integrität und Authentizität mit Public-Key

Mehr

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0.

Testbed II GDI NRW. Geodateninfrastruktur Nordrhein-Westfalen. Web Authentication & Authorization Service. Dokumentation Version 1.0. GDI NRW Geodateninfrastruktur Nordrhein-Westfalen Testbed II Web Authentication & Authorization Service Februar Dezember 2002 Dokumentation Version 1.0 Teilnehmer AED Graphics con terra FhG ISST GIA GIUB

Mehr

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird.

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Auch die Unternehmensgruppe ALDI Nord steht mit einer Vielzahl

Mehr

Endpoint Security. Where trust begins and ends. SINN GmbH Andreas Fleischmann Technischer Leiter. www.s-inn.de

Endpoint Security. Where trust begins and ends. SINN GmbH Andreas Fleischmann Technischer Leiter. www.s-inn.de Endpoint Security Where trust begins and ends SINN GmbH Andreas Fleischmann Technischer Leiter www.s-inn.de Herausforderung für die IT Wer befindet sich im Netzwerk? Welcher Benutzer? Mit welchem Gerät?

Mehr

Single Sign-On / Identity Management

Single Sign-On / Identity Management Single Sign-On / Identity Management Ein Überblick Michael Jäger 9. Januar 2011 1 / 54 Inhalt 1 Begriffe Web Single Sign-On Identität und Web-SSO SSO Szenarien SSO und SOA Ziele 2 Identitätsverwaltungssysteme

Mehr

Verschlüsselung im Cloud Computing

Verschlüsselung im Cloud Computing Verschlüsselung im Cloud Computing Michael Herfert Fraunhofer-Institut für Sichere Informationstechnologie SIT Darmstadt Sicherheitsmanagement Enterprise & Risk Management Wien 17. Februar 2015 Inhalt

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Authentisierung für die Cloud mit dem neuen Personalausweis

Authentisierung für die Cloud mit dem neuen Personalausweis Authentisierung für die Cloud mit dem neuen Personalausweis Berlin, Omnicard, 16.01.2013 Dr. Detlef Hühnlein (ecsec GmbH) Copyright 2010 ecsec GmbH, All Rights Reserved. Agenda Einleitung Authentisierung

Mehr

Sichere Authentifizierung im egovernment

Sichere Authentifizierung im egovernment Sichere Authentifizierung im egovernment 5. Alte Kongresshalle, 15.-16. Oktober 2013 Dr. Michael Stecher Bayerisches Landesamt für Steuern Agenda 1 Das Projekt AUTHEGA 2 Das Produkt authega 3 Prinzip und

Mehr

Datenschutzerklärung und Informationen zum Datenschutz

Datenschutzerklärung und Informationen zum Datenschutz Datenschutzerklärung und Informationen zum Datenschutz Informationen zum Datenschutz in den Produkten TAPUCATE WLAN Erweiterung Stand: 04.06.2015 Inhaltsverzeichnis 1) Vorwort 2) Grundlegende Fragen zum

Mehr

Sebastian Rieger sebastian.rieger@gwdg.de

Sebastian Rieger sebastian.rieger@gwdg.de Integration bestehender IP-basierter Autorisierung und Abrechnung in Shibboleth-basierte basierte Föderationen Sebastian Rieger sebastian.rieger@gwdg.de de Gesellschaft für wissenschaftliche Datenverarbeitung

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Single Sign-On / Identity Management

Single Sign-On / Identity Management Ein Überblick Michael Jäger 15. Juni 2010 1 / 55 Inhalt 1 Begriffe Web Single Sign-On Identität und Web-SSO SSO Szenarien Föderative Identitätsverwaltung SSO und SOA 2 Identitätsverwaltungssysteme Überblick

Mehr

E-Mail-Verschlüsselung Vorrausetzungen

E-Mail-Verschlüsselung Vorrausetzungen E-Mail-Verschlüsselung Vorrausetzungen Datum: 09.08.2011 Dokumentenart: Anwenderbeschreibung Version: 2.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3 2. Voraussetzungen...4

Mehr

Analyse von Sicherheitaspekten in Service-orientierten Architekturen

Analyse von Sicherheitaspekten in Service-orientierten Architekturen Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung

Mehr

Neuerungen bei Shibboleth 2

Neuerungen bei Shibboleth 2 Neuerungen bei Shibboleth 2 Shibboleth-Workshop BW Stuttgart, 7. Februar 2008 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Aktueller Status Kommunikation IdP

Mehr

Community Zertifizierungsstelle. Digitale Identität & Privatsphäre. SSL / S/MIME Zertifikate

Community Zertifizierungsstelle. Digitale Identität & Privatsphäre. SSL / S/MIME Zertifikate Community Zertifizierungsstelle für Digitale Identität & Privatsphäre SSL / S/MIME Zertifikate www.cacert.org 2010 / ab OSS an Schulen, Zürich, 2010-05-29, Folie 1 Agenda Identität und Vertrauen WoT und

Mehr

Transaktionskosten senken mit dem Wirtschaftsportalverbund

Transaktionskosten senken mit dem Wirtschaftsportalverbund Transaktionskosten senken mit dem Wirtschaftsportalverbund Rainer Hörbe Leiter Arbeitskreis WPV 8. März 2013 1 1 Identifikation + Berechtigung + Sicherheitsmaßnahmen Problemstellung: Vertrauen im Internet?

Mehr

KvBK: Authentifizierung und Autorisierung im Web: BasicAuth, DigestAuth, OAuth

KvBK: Authentifizierung und Autorisierung im Web: BasicAuth, DigestAuth, OAuth KvBK: Authentifizierung und Autorisierung im Web: BasicAuth, DigestAuth, OAuth Julian Reisser 21. Juli 2010 Inhaltsverzeichnis 1 Authentifizierung und Autorisierung im Web 2 2 Basic Authentication 2 3

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr