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

(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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dokumentation MOA-ID Single Sign-On

Dokumentation MOA-ID Single Sign-On 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 Dokumentation MOA-ID Single Sign-On Erweiterung von MOA-ID für bereichsübergreifendes

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

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

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

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

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

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

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

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

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

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

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

Von der Testumgebung zum produktiven Einsatz von Shibboleth

Von der Testumgebung zum produktiven Einsatz von Shibboleth Authentifizierung, Autorisierung und Rechteverwaltung Von der Testumgebung zum produktiven Einsatz von Shibboleth 3. Shibboleth-Workshop Freiburg, 10. Oktober 2006 Bernd Oberknapp, UB Freiburg E-Mail:

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

Dezentrales Identity Management für Web- und Desktop-Anwendungen

Dezentrales Identity Management für Web- und Desktop-Anwendungen Dezentrales Identity Management für Web- und Desktop-Anwendungen Sebastian Rieger, Thorsten Hindermann srieger1@gwdg.de, thinder@gwdg.de Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen,

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

Social Login mit Facebook, Google und Co.

Social Login mit Facebook, Google und Co. IAM EXCELLENCE OAuth 2.0 und OpenID Connect Social Login mit Facebook, Google und Co. Stefan Bohm www.ic-consult.com Geschützte Ressourcen = Userattribute + Steuerung des Logins + Information über Login

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

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

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor.

Cloud Computing bereitet sich für den breiten Einsatz im Gesundheitswesen vor. Cloud Computing im Gesundheitswesen Cloud Computing ist derzeit das beherrschende Thema in der Informationstechnologie. Die Möglichkeit IT Ressourcen oder Applikationen aus einem Netz von Computern zu

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

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

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber

Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick. Dr. Joachim Gerber Technologien und Organisationskonzepte digitaler Identitäten Ein Überblick Dr. Joachim Gerber INFORA-Kompetenzteam Informationssicherheit & Id-Management München, 14.06.2010 Agenda 1. Identität Begriff

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

Secure Messaging. Ihnen? Stephan Wappler IT Security. IT-Sicherheitstag. Sicherheitstag,, Ahaus 16.11.2004

Secure Messaging. Ihnen? Stephan Wappler IT Security. IT-Sicherheitstag. Sicherheitstag,, Ahaus 16.11.2004 Secure Messaging Stephan Wappler IT Security Welche Lösung L passt zu Ihnen? IT-Sicherheitstag Sicherheitstag,, Ahaus 16.11.2004 Agenda Einleitung in die Thematik Secure E-Mail To-End To-Site Zusammenfassung

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

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

Elektronische Identitäten: Das alltägliche Datenschutzproblem

Elektronische Identitäten: Das alltägliche Datenschutzproblem Elektronische Identitäten: Das alltägliche Datenschutzproblem Walter Hötzendorfer Arbeitsgruppe Rechtsinformatik, Universität Wien walter.hoetzendorfer@univie.ac.at Europa-Tagung Von Jägern, Sammlern und

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

Integration von MOA-ID in Online-Applikationen

Integration von MOA-ID in Online-Applikationen 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 Integration von MOA-ID in Online-Applikationen Version 1.1, 08. August

Mehr

Authentication im Web

Authentication im Web Authentication im Web Weiterführende Themen zu Internet- und WWW-Technologien 11.07.2011, Kai Fabian Inhalt 2 1. Begriffsabgrenzung 2. HTTP Basic Authentication (RFC 2617) 3. Single Sign-on-Techniken 3.1.

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

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

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

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

Dokumentation MOAs in der Cloud

Dokumentation MOAs 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 Dokumentation MOAs in der Cloud Version 1.0, 11. Juli 2012 Bernd Zwattendorfer

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

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

E-Mail Verschlüsselung

E-Mail Verschlüsselung E-Mail Verschlüsselung S/MIME Standard Disclaimer: In der Regel lässt sich die Verschlüsselungsfunktion störungsfrei in den E-Mail-Programmen einrichten. Es wird aber darauf hingewiesen, dass in einigen

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

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

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

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

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

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

Die neuen Cloud-Zertifizierungen nach ISO 27018 und ISO 20000-9. DI Herfried Geyer Fachhochschule St. Pölten, CIS-Auditor

Die neuen Cloud-Zertifizierungen nach ISO 27018 und ISO 20000-9. DI Herfried Geyer Fachhochschule St. Pölten, CIS-Auditor Die neuen Cloud-Zertifizierungen nach ISO 27018 und ISO 20000-9 DI Herfried Geyer Fachhochschule St. Pölten, CIS-Auditor ISO/IEC 27013 Information technology - Security techniques - Guidance on the integrated

Mehr

Secure E-Mail der Suva

Secure E-Mail der Suva Secure E-Mail der Suva Informationsbroschüre für Entscheidungsträger und IT-Verantwortliche SEM_Informationsbroschuere_06-2013_de / WasWoShop: 2979/1.D 1 Inhaltsverzeichnis Secure E-Mail der Suva auf einen

Mehr

Glossar zum S.A.F.E. Feinkonzept

Glossar zum S.A.F.E. Feinkonzept Glossar zum S.A.F.E. Feinkonzept Thema: Verantwortlich: Secure Access to Federated E-Justice/E-Government Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in der Justiz Version.Release:

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

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage. RAM empfohlen. RAM maximal

Lösungen zu 978-3-8045-5387-3 Informations- und Telekommunikationstechnik Arbeitsheft, 3. Auflage. RAM empfohlen. RAM maximal 1. HANDLUNGSSCHRITT Aufgabe 13 Betriebssystem Prozessortakt RAM empfohlen RAM maximal Installationsgröße SMP Anzahl Prozessoren Windows 7 Ultimate 2008 Web 2008 Standard 2008 Enterprise 2008 Datacenter

Mehr

Single Sign-On Step 1

Single Sign-On Step 1 Single Sign-On Step 1 Novell Tour 2006 Stefan Stiehl Senior Technology Specialist sstiehl@novell.com Holger Dopp Senior Consultant hdopp@novell.com Was ist Single Sign-On? Eine Befugnisverwaltungstechnologie,

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

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

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Programmierhandbuch SAP NetWeaver* Sicherheit

Programmierhandbuch SAP NetWeaver* Sicherheit Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit

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

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Das Problem Die Abkündigungen seitens Microsoft von Forefront Threat Management Gateway (TMG) und

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Compass Security AG [The ICT-Security Experts]

Compass Security AG [The ICT-Security Experts] Compass Security AG [The ICT-Security Experts] Live Hacking: Cloud Computing - Sonnenschein oder (Donnerwetter)? [Sophos Anatomy of an Attack 14.12.2011] Marco Di Filippo Compass Security AG Werkstrasse

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

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung

SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Ergebnisse der TeleTrusT-AG "SOA" SOA Security in der Praxis Entwurfsmuster für eine sichere Umsetzung Arbeitsergebnisse des SOA Security AKs Anfang 2009 - Themenfindung für das Dokument Mitte 2009 Vorgehenskonzept

Mehr

Projekt bwidm Vereinfachter Zugang zu Landesdiensten

Projekt bwidm Vereinfachter Zugang zu Landesdiensten Projekt bwidm Vereinfachter Zugang zu Landesdiensten Vortragender: Michael Simon (KIT) Projektleiter: Martin Nußbaumer (KIT) Vision Motivation: Beobachtbarer Trend zu verteilten Diensten in Baden-Württemberg

Mehr

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr

Flexagon CLOUD Plattform für den Anbieterwechsel, und für weitere Order- und Entstör Schnittstellen

Flexagon CLOUD Plattform für den Anbieterwechsel, und für weitere Order- und Entstör Schnittstellen Flexagon CLOUD Plattform für den Anbieterwechsel, und für weitere Order- und Entstör Schnittstellen Seite 1 Vorteile der F-TBOX Cloud Plattform Die F-TBOX Cloud existiert seit 2006 für verschiedene Partnerschnittstellen

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

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

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Metadaten. Organisationsstrukturen und Sicherheit in Shibboleth. Authentifizierung, Autorisierung und Rechteverwaltung

Metadaten. Organisationsstrukturen und Sicherheit in Shibboleth. Authentifizierung, Autorisierung und Rechteverwaltung Authentifizierung, Autorisierung und Rechteverwaltung Metadaten Organisationsstrukturen und Sicherheit in Shibboleth 3. Shibboleth-Workshop Freiburg, 10. Oktober 2006 Bernd Oberknapp, UB Freiburg E-Mail:

Mehr

Bildungsportal-Verbund

Bildungsportal-Verbund Bildungsportal-Verbund BPVP Bildungsportal-Verbund Protokoll Kurzspezifikation Für weitere technische Details nehmen kontaktieren Sie bitte: Robert.kristoefl@bmbwk.gv.at Thomas.menzel@bmbwk.gv.at Version

Mehr

ISSS Security Lunch - Cloud Computing

ISSS Security Lunch - Cloud Computing ISSS Security Lunch - Cloud Computing Technische Lösungsansätze Insert Andreas Your Kröhnert Name Insert Technical Your Account Title Manager Insert 6. Dezember Date 2010 The Cloud Unternehmensgrenzen

Mehr

Zugang zu Föderationen aus Speicher-Clouds mit Hilfe von Shibboleth und WebDAV

Zugang zu Föderationen aus Speicher-Clouds mit Hilfe von Shibboleth und WebDAV Zugang zu Föderationen aus Speicher-Clouds mit Hilfe von Shibboleth und WebDAV Sebastian Rieger Yang Xiang (Rechenzentrum Garching) Harald Richter (Technische Universität Clausthal)

Mehr

Secure Socket Layer V.3.0

Secure Socket Layer V.3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer V.3.0 (SSLv3) Zheng Yao 05.07.2004 1 Überblick 1.Was ist SSL? Bestandteile von SSL-Protokoll, Verbindungherstellung

Mehr

Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel

Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel Organisationsübergreifendes Single Sign On mit shibboleth Tobias Marquart Universität Basel Überblick Einordnung von Shibboleth, Abgrenzung zu OpenID Organisatorische und technische Komponenten einer Federation

Mehr

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling Identity Management Nutzen Konzepte Standards Dr. Oliver Stiemerling ecambria systems GmbH Hospeltstr. 35a 50825 Köln Tel.: 0221 595527-0 Fax.: 0221 595527-5 os@ecambria-systems.com http://www.ecambria-systems.com

Mehr

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen

SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen SWITCHaai Die Authentifizierungs- und Autorisierungs- Infrastruktur der Schweizer Hochschulen Thomas Lenggenhager thomas.lenggenhager@switch.ch Bern, 11. Juni 2010 Übersicht Die Shibboleth basierte SWITCHaai

Mehr

Die Idee des Jahres 2013: Kommunikation verschlüsseln

Die Idee des Jahres 2013: Kommunikation verschlüsseln Die Idee des Jahres 2013: Kommunikation verschlüsseln Kommunikationsschema bei Email MailServer MailServer Internet PC PC Sender Empfänger Verschlüsselung ist... immer eine Vereinbarung zwischen zwei Kommunikationspartnern:

Mehr

FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION. Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht

FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION. Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht INHALTSÜBERSICHT Risiken für die Sicherheit von Kommunikation und die Freiheit

Mehr