Authentifizierung und Autorisierung

Authentifizierung und Autorisierung 

Jacob Kuypers 

Beim Zugriff auf Patientendaten spielen Autorisierung und Authentifizierung eine zentrale 

Rolle. Um die Einhaltung von Datenschutzgesetzen zu gewährleisten muss sichergestellt werden, 

dass nur berechtigte Personen wie Heilberufler sowie der Patient selbst Zugang haben. Dies 

bringt eine Reihe von sicherheitstechnischen Problemen mit sich, welche bei der Einführung der 

elektronischen Gesundheitskarte berücksichtigt werden mussten. So wurde parallel zu der Gesundheitskarte 

der Heilberufsausweis entwickelt, welcher zum Beispiel die Identität und Befugnis 

eines Arztes authentisieren kann. Gleichzeitig wurden in den letzten Jahren unabhängige Projekte 

mit ähnlichen Zielsetzungen basierend auf ähnlichen oder gleichen Technologien gestartet. 

Im Folgenden wird ein Überblick über den Heilberufsausweis, dessen technologische Umgebung 

sowie Autorisierungs- und Authentifizierungssysteme im Allgemeinen geschaffen. 

Categories and Subject Descriptors: K.6.5 [Management of Computing and Information 

Systems]: Security and Protection—Authentication 

Additional Key Words and Phrases: Authentifizierung, Autorisierung, Heilberufsausweis, Single 

Sign-On 

1. EINLEITUNG 

Authentifizierung bezeichnet den Nachweis einer behaupteten Eigenschaft durch 

eine Partei. So kann zum Beispiel eine Person ihre Identität oder ein Dokument 

seine Echtheit nachweisen. 

Eine Identität kann mit bestimmten Befugnissen assoziiert sein, welche anderen 

Identitäten möglicherweise nicht zugeteilt werden. Die Vergabe dieser Befugnisse 

an eine Identität welche erfolgreich authentifiziert wurde, wird als Autorisierung 

bezeichnet. 

Bei natürlichen Personen wird zur Verifizierung ihrer Identität nach Anhaltspunkten 

gesucht welche einzeln oder zusammen nur dieser Person zugeordnet werden 

können. Diese werden in Besitz, Wissen und biometrische Merkmale unterteilt. 

Beispiele, in selber Reihenfolge, wären ein Schlüssel, ein Passwort und ein Fingerabdruck. 

Im Gesundheitswesen spielen Authentifizierung und Autorisierung eine besondere 

Rolle, da sichergestellt werden muss dass nur qualifizierte Fachkräfte Zugang 

zu Patientendaten haben und Behandlungen durchführen. Der Zugriff auf Patientendaten 

ist gesetzlich geregelt und muss hohe Sicherheitsstandards erfüllen. Mit 

dem Gesundheitsmodernisierungsgesetz von 2003 wurde der informationstechnische 

Aspekt dieser Aufgabe nun stark aufgewertet. 

Die folgenden Abschnitte beleuchten elektronische Authentifizierung und Autorisierung 

im Rahmen der Einführung der elektronischen Gesundheitskarte und des 

elektronischen Heilberufsausweises, sowie verwandte Entwicklungen ausserhalb des 

Gesundheitswesens. 

Seminar Kommunikationsstandards in der Medizintechnik, SoSe 2010

2 · Kommunikationsstandards in der Medizintechnik 

2. ELEKTRONISCHE AUTHENTIFIZIERUNG 

Elektronische Authentifizierung ermöglicht die Verifizierung der Identität von natürlichen 

Personen, kann aber auch informationstechnische Dienste authentifizieren. 

Will eine Person auf geschützte Daten zugreifen, kann dies zu verschiedenen 

Formen der Authentifizierung mit mehreren Paaren von Kommunikationspartnern 

führen. 

Ein Beispiel: Eine Person besitzt eine Chipkarte, welche sie in einen geeigneten 

Kartenleser einführt. Sie muss sich gegenüber der Chipkarte authentifizieren, indem 

sie eine PIN eingibt, welche vom Kartenleser an die Karte weitergeleitet wird. Wenn 

die PIN von der Chipkarte akzeptiert wurde, autorisiert sie den Kartenleser (und 

somit auch die Person) zur Verwendung der auf ihr gespeicherten Informationen um 

eine gesicherte Verbindung zum Server aufzubauen und sich dort zu authentifizieren. 

Bei Erfolg autorisiert der Server den Kartenleser zum Abruf von Daten, welche dem 

Inhaber der Karte zugeordnet werden. 

Neben Personen und Geräten können auch Daten authentifiziert werden. In diesem 

Fall wird anhand einer digitalen Signatur nachgewiesen, dass die Daten aus 

einer bestimmten Quellen stammen. 

2.1 Public-Key-Infrastruktur 

Oft ist es notwendig mit Parteien zu kommunizieren, deren Vertrauenswürdigkeit 

nicht im Voraus bekannt ist und erst abgeleitet werden muss. Weiterhin ist das Ziel 

sicherer Kommunikation die Vertraulichkeit, Integrität, Authentizität und Nichtabstreitbarkeit 

von Nachrichten. Unter diesen Gesichtspunkten wurde die sog. Public- 

Key-Infrastruktur als umfassendes Sicherheitsmodell entwickelt. 

Eine PKI ist ein System zum Ausstellen, Verteilen und Überprüfen von digitalen 

Zertifikaten, welche zur Signierung und Verschlüsselung von Nachrichten verwendet 

werden. 

Der Nachrichtenaustausch findet zwischen zwei Parteien statt. Jede Partei besitzt 

jeweils zwei kryptographische Schlüssel welche ein zusammengehöriges Paar bilden. 

Ein Schlüssel ist geheim und nur dem Besitzer bekannt, der andere Schlüssel ist 

öffentlich und wird dem Kommunikationspartner zugänglich gemacht. Verschlüsseln 

ist mit dem privaten wie auch dem öffentlichen Schlüssel möglich, die Entschlüsselung 

muss immer mit dem jeweiligen Gegenstück erfolgen. 

Wenn A eine geheime Nachricht an B schickt, wird sie zunächst von A mit dem 

öffentlichen Schlüssel von B verschlüsselt. Anschließend kann B die Nachricht mit 

dem privaten Schlüssel entschlüsseln. 

Zum Signieren einer Nachricht wird diese von A mit dem privaten Schlüssel 

verschlüsselt und von B mit dem öffentlichen Schlüssel entschlüsselt. Falls dieser 

Vorgang erfolgreich ist, hat B nachgewiesen dass die Nachricht von A stammt. 

Ein digitales Zertifikat ist ein signiertes Datum welches zum Nachweis einer Identität 

verwendet werden kann. Die Gültigkeit und Vertrauenswürdigkeit eines Zertifikats 

hängt davon ab, ob das Zertifikat von einer vertrauenswürdigen Partei ausgestellt 

wurde. 

Es gibt verschiedene Modelle welche regulieren, wie Vertrauen, Zertifikate und 

zertifizierende Parteien in Zusammenhang gebracht werden. Das folgende Modell 

ist hierarchisch: Ein Aussteller von Zertifikaten (Certificate Authority, CA) wird 


Authentifizierung und Autorisierung · 3 

Fig. 1. PKI - http://upload.wikimedia.org/wikipedia/commons/3/34/Public-Key- 

Infrastructure.svg 

selbst als vertrauenswürdig betrachtet, wenn er von einer vertrauenswürdigen CA 

zertifiziert wurde. Ausgangspunkt ist eine sog. Root-CA, also ein Aussteller welcher 

ohne weitere Zertifizierung als vertrauenswürdig gilt. Dies würde als ” 

streng 

hierarchische PKI“ bezeichnet werden. Alternativ ist ein System mit mehreren, sich 

gegenseitig zertifizierenden Root-CAs als ” 

Cross-Zertifizierung“ bekannt. 

Um ein Zertifikat ausgestellt zu bekommen meldet sich der ” 

Subscriber“ (Inhaber 

eines Zertifikates in der PKI) bei der Registrierungsstelle (Registration Authority, 

RA) und stellt dort einen Antrag. Die RA prüft die Richtigkeit der Daten und 

verifiziert die Identität des Antragstellers in angemessener Weise. Bei Erfolg wird 

der Antrag zusammen mit dem Public Key des Subscribers bei der CA registriert, 

welche ihm ein Zertifikat ausstellt. 

Die Validierung von Zertifikaten wird von der Validation Authority (VA) übernommen. 

Sie hält von CAs bezogene Zertifikate sowie eine Zertifikatssperrliste (Certificate 

Revocation List, CRL) mit Zertifikaten welche vor Ablauf ihrer Gültigkeit 

zurückgezogen wurden. 

Als ” 

Participant“ wird der Nutzer eines Zertifikates bezeichnet, welcher einen 

Subscriber authentisieren will.[Wikipedia 2010d] 

3. DIE ELEKTRONISCHE GESUNDHEITSKARTE 

3.1 Konzeption 

Die am 1. Januar 1995 eingeführte Krankenversicherungskarte sollte ursprünglich 

am 1. Januar 2006 durch die elektronische Gesundheitskarte (eGK) ersetzt werden. 

Durch eine Zeitplanänderung verzögert sich die Einführung voraussichtlich auf das 



Jahr 2011. 

Ziel ist eine einheitliche elektronische Speicherung, Verarbeitung und Nutzung 

von Patientendaten mit Hilfe einer eigens dafür entwickelten Telematikinfrastruktur 

welche die Authentifizierung von Patienten und Ärzten sowie die Autorisierung des 

Datenzugriffs regelt. 

Die eGK wird als Lichtbildausweis des Versicherten verwendet, welcher neben 

32 kB Speicher auch Funktionen zur Authentifizierung besitzt. Lokal gespeicherte 

Daten sind Name und Vorname des Versicherten, Geburtsdatum, Geschlecht, 

Anschrift, die Kennung der ausstellenden Krankenkasse und der zuständigen Kassenärztlichen 

Vereinigung, Krankenversichertennummer, Versichertenstatus, Zuzahlungsstatus, 

Daten des Beginns und Ablaufs des Versicherungsschutzes sowie ärztliche 

Verordnungen (elektronisches Rezept, bzw. eRezept). 

Zusätzlich unterstützt die eGK Anwendungen welche folgende Daten erheben, 

verarbeiten oder nutzen: Der elektronische Arztbrief, Notfallversordungsdaten, Daten 

zur Prüfung der Arzneimitteltherapiesicherheit, die elektronische Patientenakte 

sowie in Anspruch genommene Leistungen und deren vorläufige Kosten. 

Ein Teil des Speicherplatzes kann für Daten verwendet werden welche vom Versicherten 

selbst oder von der Versicherung stammen, aber keine Bedeutung im Sinne 

der Spezifikation haben. 

Die Patientendaten werden auf die eGK selbst und auf Server der Telematikinfrastruktur 

aufgeteilt. Der Zugriff muss dabei das Bundesdatenschutzgesetz sowie 

EU-Richtlinien befolgen und wird auf den Versicherten selbst, Ärzte, Zahnärzte, 

Apotheker und deren Gehilfen sowie sonstige Erbringer ärztlich verordneter Leistungen 

beschränkt. Zu diesem Zweck wurden verschiedene technische Vorkehrungen 

entwickelt welche eine den jeweiligen Daten angemessene Authentifizierung und Autorisierung 

ermöglichen. So wird für die meisten Daten eine doppelte Autorisierung 

benötigt: Der Versicherte authentifiziert sich mit seiner eGK sowie einer PIN und 

autorisiert seinen Arzt, welcher einen elektronischen Heilberufsausweis (HBA) mit 

entsprechend qualifizierter digitaler Signatur verwendet. Die Notfalldaten erfordern 

nur einen HBA zur Zugriffsautorisierung, da der Versicherte in einer Notfallsituation 

möglicherweise nicht zur Autorisierung in der Lage ist. Zugriff auf das eRezept 

erfordert einen gesicherten Berufsausweis oder ein vom Versicherten autorisiertes 

technisches Verfahren. Um Missbrauch erkennen und belegen zu können, werden 

die letzten 50 Zugriffe protokolliert. 

Nachdem die Einführung der eGK zum 1. Januar 2006 gescheitert war wurde ein 

mehrstufiges Verfahren beschlossen welches die Karte in ausgewählten Regionen 

testweise einführt.[Wikipedia 2010a] 

3.2 Elektronischer Heilberufsausweis 

Der elektronische Heilberufsausweis (HBA, auch Health Professional Card oder 

HPC) ist das das heilberufliche Gegenstück zur elektronischen Gesundheitskarte. 

Funktionen der Chipkarte sowie lokal gespeicherte Daten werden im Dokument 

” German Health Professional Card and Security Module Card ” spezifiziert. 

Zu den Einsatzgebieten gehört das Signieren der elektronischen Versionen der 

Arzneimitteldokumentation, des Arztbriefes und des Rezeptes. Der HBA kann den 

Arzt auch in Einweiserportalen von Kliniken authentisieren und als normaler Sichtausweis 

verwendet werden. Beim Zugriff auf Patientendaten auf der eGK oder in 



Fig. 2. gematik: Gesamtarchitektur V1.5.0, S. 28 

einem Fachdienst aus der Telematikinfrastruktur wird ein vom Versicherten autorisierter 

und durch seine Rolle qualifizierter HBA benötigt. 

Technisch existiert nur ein HBA, äußerlich wird er in spezialisierten Ausführungen 

für den jeweiligen Heilberuf ausgeliefert. Ausstellung wird von der jeweiligen Landesärztekammer, 

Landeszahnärztekammer oder Landesapothekerkammer übernommen 

welche auch für die Konnektoren und Kartenlesegeräte zuständig ist.[Wikipedia 

2010b; Bundesaerztekammer 2010] 

3.3 Telematikinfrastruktur der Gesundheitskarte 

Die Telematikinfrastruktur ist die Gesamtheit aller Komponenten, Dienste und 

Kommunikationsdienste welche im Rahmen der Einführung der eGK implementiert 

werden und dabei die Grundlage für die geplanten Telematikanwendungen 

darstellen. 

Die Anwendungen werden aufgeteilt in Pflichtanwendungen wie die Verwaltung 

von administrativen Daten und das elektronische Rezept, sowie die freiwilligen Anwendungen 

wie Notfalldatensatz und elektronische Patientenakte, welche erst später 

umgesetzt werden. 

In Abb. 2 wird die Gesamtarchitektur dargestellt welche hier kurz beschrieben 

werden soll. 

Die Primärsysteme (roter Bereich) sind diejenigen Komponenten, welche Anwendungsprogramme 

für Leistungserbringer und Versicherte zur Verfügung stel- 



len. Leistungserbringer nutzen Primärsysteme wie Praxisverwaltungssysteme für 

niedergelassene Ärzte und Zahnärzte, Krankenhausinformationssysteme und Apothekenverwaltungssysteme. 

Vorhandene Anwendungen deren Funktionalität nicht 

komplett durch die von den Kartenterminals (für eGK und HBA) abgedeckt werden 

müssen für die von der Gesundheitstelematik angebotenen Schnittstellen angepasst 

werden. Um dem Versicherten den Zugriff auf die eigenen Gesundheitsdaten von 

zu Hause aus oder an speziellen, nicht an Arztpraxen gebundenen Terminals zu 

ermöglichen werden die Primärsysteme eKiosk und Versicherter@Home angeboten. 

Die Telematikinfrastruktur (gelber Bereich) wird in dezentrale Komponenten, 

Netzwerk-gateways und Anwendungsgateways aufgeteilt. 

Die dezentralen Komponenten sind der Konnektor und die Kartenterminals für 

eGK und HBA. 

Der Konnektor schließt ein Primärsystem an das Telematiknetzwerk an und führt 

Zugriffe auf Chipkarten über die Kartenterminals durch. Es existieren dazu Schnittstellen 

für die Kommunikation mit eGK und HBA, aber auch die Security Module 

Card (SMC) welche zur Authentisierung eines Kartenterminals verwendet wird. 

Eine SMC wird auch in dem Konnektor selbst verwendet, da z.B. die eGK und 

der HBA beim Aufbau einer Verbindung mit dem Konnektor diesen auch zum 

Zugriff auf die auf ihnen gespeicherten Daten sicher autorisieren müssen. Zur Telematikinfrastruktur 

hin existieren Schnittstellen für das Telematik-VPN sowie für 

die Broker Services, welche den einzigen Zugang zu den eigentlichen Fachdiensten 

darstellen. Der Konnektor wird funktional in den Anwendungskonnektor und 

den Netzkonnektor unterteilt. Der Anwendungskonnektor ist administrativ für den 

Datenzugriff zuständig, bereitet Daten auf und enthält weitere anwendungsspezifische 

Schnittstellen. Der Netzkonnektor bringt den Konnektor in die Netzwerke 

der Leistungserbringer und der Telematikinfrastruktur ein. Ein VPN-Client baut 

einen sicheren Kommunikationskanal über das Zugangsnetz zur Kommunikationsinfrastruktur 

auf. 

VPN-Gateways stellen sicher dass nur authentifizierte, zugelassene Konnektoren 

Zugang zur Kommunikationsinfrastruktur erhalten. 

Broker Services sind Dienste welche den Zugang zu serverbasierten Anwendungsservices 

steuern und somit Anwendungsgateways darstellen. Konnektoren bauen 

keine direkten Verbindungen mit Fachdiensten auf, sondern stellen ihre Anfragen 

an einen Broker Service. Dies erlaubt es Konnektoren und Fachdienste in verschiedenen 

Netzen anzusiedeln, Ausfallsicherheit zu erhöhen und Zugriffe zu anonymisieren. 

Anonymisierung erfolgt zum Beispiel beim Zugriff eines Heilberuflers auf 

Patientendaten. Dazu verifiziert der Broker Service die Signatur der eingehenden 

Nachricht, ersetzt sie durch seine eigene Dienstsignatur und übergibt nur die relevanten, 

nicht personenbezogenen Informationen (wie Beruf bzw. Rolle) an den 

jeweiligen Fachdienst. 

Weitere Dienste innerhalb der Telematikinfrastruktur sind Zeitservices, PKI- 

Services und DNS-Lokalisierungsservices. 

Die Fachdienste (grüner Bereich) werden aufgeteilt in Pflichtanwendungen und 

freiwillige Anwendungen. 

Das Versichertenstammdatenmanagement ist eine Pflichtanwendung zur schnellen 

Überprüfung des Versichertenstatus. Das Verordnungsdatenmanagement ver- 



waltet die Erstellung und Weitergabe des eRezeptes. Alle Pflichtanwendungen müssen 

dabei die Wahrnehmung der Versichertenrechte ermöglichen. Dazu muss der 

Versicherte in der Lage sein einzusehen, welche Gesundheitsdaten über ihn aufgenommen, 

gelöscht oder einem Leistungserbringer zugänglich gemacht wurden. Er 

muss auch hier den Zugriff auf seine Daten individuell autorisieren können. Diese 

Funktionen werden in den hier nur teilweise aufgezählten Diensten realisiert und 

werden nicht einem eigenständigen Fachdienst zugeordnet. 

Die freiwilligen Anwendungen welche nicht bereits zum Zeitpunkt der offiziellen 

Einführung der Gesundheitskarte vorhanden sein müssen sind Dienste zur Verwaltung 

von Notfalldaten, der Arzneimitteltherapiesicherheitsprüfung sowie der elektronischen 

Patientenakte. 

Mehrwertanwendungen (grauer Bereich) sind Anwendungen welche im Bezug auf 

die Telematikinfrastruktur nicht gesetzlich geregelt sind, welche jedoch mit dessen 

Komponenten kommunizieren können. Sie können zum Beispiel von einer Versicherung 

bereitgestellt oder für eine bestimmte Nutzergruppe einen Nutzwert darstellen. 

Die Anwendungen können dabei auch auf Funktionen wie das Signieren mit einem 

Konnektor zugreifen, welche selbst zur festen Telematikinfrastruktur gehören. 

Auch die Daten und Funktionen des HBA können in dieser Weise verwendet werden.[gematik 

2008] 

Der elektronische Heilberufsausweis wird primär zur elektronischen Signierung 

von Dokumenten, zur Authentifizierung des Inhabers sowie zur ver- und Entschlüsselung 

von Nachrichten verwendet. 

Er enthält eine Reihe von Zertifikaten welche in X.509-Zertifikate und Card- 

Verifiable Zertifikate (CV-Zertifikate oder CVC) aufgeteilt werden. 

Die X.509-Zertifikate werden von zwei CAs vergeben. Die Root-CA der Bundesnetzagentur 

vergibt das Signaturzertifikat und das Attributzertifikat (welches das 

jeweilige Heilberufsattribut authentisiert). Die Root-CA der Bundesärztekammer 

vergibt das Authentifizierungszertifikat und das Verschlüsselungszertifikat. Zum Ermitteln 

aktueller Sperrinformationen für X.509-Zertifikate werden innerhalb der 

Telematikinfrastruktur OCSP-Responder verwendet. 

Das CV-Zertifikat authentifiziert den HBA gegenüber anderen Karten wie dem 

eGK und der sich im Konnektor sowie im HBA-Kartenterminal befindenden SMC. 

Im Gegensatz zu den X.509-Zertifikaten ist hiermit nur eine offline-Verifikation 

möglich, also können Zertifikate nicht vorzeitig zurückgezogen werden. Die Cardto-Card-Authentisierung 

(C2C-Authentisierung) stellt sicher dass nur authentische 

Karten miteinander kommunizieren.[Bundesaerztekammer 2008; Fankhauser et al. 

2007] 

4. INTERNET-TECHNOLOGIEN ZUR AUTHENTIFIZIERUNG UND AUTORISIE- 

RUNG 

4.1 TLS 

Transport Layer Security (TLS) ist ein Protokoll zwischen der Transport- und 

der Anwendungsschicht zur verschlüsselten Übertragung von Daten. Der IETF- 

Standard ist die Weiterentwicklung des Secure Sockets Layer-Protokolls (SSL). 

TLS wird in zwei weitere Schichten aufgeteilt: das TLS Record Protocol und 

eine übergeordnete Schicht mit Protokollen wie dem TLS Handshake Protocol und 



Application Data Protocol. 

Das TLS Record Protocol unterstützt den verschlüsselten Datenaustausch mittels 

symmetrischer Verschlüsselung. Dafür kann ein Algorithmus wie DES, Triple DES 

oder AES verwendet werden. Weiterhin wird die Integrität und Authentizität von 

Nachrichten durch Bildung einer kryptographischen Prüfsumme über Verfahren wie 

SHA-1 oder MD5 sichergestellt. Unverschlüsselte Übertragung ist ebenfalls möglich. 

Das TLS Handshake Protocol setzt auf dem TLS Record Protocol auf und wird 

verwendet um die Kommunikationspartner auf Basis asymmetrischer Verschlüsselungsverfahren 

gegenseitig zu authentifizieren. Im Normalfall authentifiziert sich 

nur der Server gegenüber dem Client mittels X.509-Zertifikat. Der Handshake wird 

dazu verwendet, kryptographische Algorithmen auszuhandeln und Schlüssel für die 

symmetrische Verschlüsselung im TLS Record Protocol auszutauschen. 

TLS und die vorhergehenden SSL-Versionen sind weit verbreitet und werden vor 

Allem im Rahmen einer PKI zur Authentifizierung von Webseiten verwendet.[IETF 

1999] 

4.2 SAML 

SAML ist XML-basierter Standard vom OASIS Security Services Technical Committee. 

Es ermöglicht die strukturierte Beschreibung und den Austausch von Authentifizierungs- 

und Autorisierungsinformationen. Anwendung findet es vor allem im 

Bereich Single Sign-On (SSO), bei der Autorisierung von verteilten Transaktionen 

und in Autorisierungsdiensten. 

Es wird dabei zwischen dem User, dem Identity Provider und dem Service Provider 

unterschieden. 

Der User ist die Partei welche eine Identität annimmt und in ihrem Namen Aktionen 

mit Hilfe des Service Providers durchführt. Der Service Provider ist ein Dienst 

welcher die Authentisierung einer Identität erfordert um Aufgaben auszuführen. 

Der Identity Provider erstellt und verwaltet Identitäten. 

Es wird davon ausgegangen dass die genannten Parteien bereits vorhanden bzw. 

implementiert sind. SAML beschreibt nur die möglichen Interaktionen zwischen 

ihnen und liefert Protokolle zum Datenaustausch. 

Die verwendeten Standards zur Beschreibung von Informationen sind XML, XML 

Schema, XML Signature und XML Encryption. Zur Kommunikation sind HTTP 

und SOAP vorgesehen. 

SAML besteht aus Assertions, Protocols, Bindings und Profiles. 

SAML Assertions enthalten Aussagen über Authentifizierungen unter bestimmten 

Bedingungen (authentication statements), über Paare aus Namen und Werten 

(attribute statements), sowie über Autorisierungsentscheidungen zu bestimmten 

Parteien und Aktionen (authorization decision statements). 

SAML Protocols beschreiben in welcher Form Elemente angefordert und zurückgegeben 

werden. Analog zu SAML Assertions wird hier wieder nach Authentication 

Protocols, Attribute Protocols und Authorization Protocols unterschieden. 

SAML Bindings ordnen SAML-Nachrichten einem bestimmten Nachrichtenformat 

oder Kommunikationsprotokoll zu. Unter Anderem existiert das SAML SOAP 

Binding für Nachrichtenübertragung mit dem SOA Protokoll und das HTTP Redirect 

Binding (für den HTTP GET-Befehl) sowie das HTTP POST Binding für 

Übertragungen über HTTP. 



SAML Profiles beschreiben wie Assertions, Protocols und Bindings in einem bestimmten 

Anwendungsfall (zum Beispiel Single Sign-On in einem Browser) kombiniert 

werden.[VeriSign et al. ] 

4.3 OpenID 

OpenID ist ein offener Standard und ein dezentrales Authentifizierungssystem für 

Webseiten und andere webbasierte Dienste. 

Motivation war die Realisierung einer Single Sign-On-Funktion sowie der Auslagerung 

von Authentifizierungslogik, welche bisher meistens von den Entwicklern 

einer Webseite selbst programmiert wurde. Für OpenID existieren Open-Source- 

Implementierungen für viele Plattformen in verschiedenen Programmiersprachen. 

Eine Identität hat in OpenID die Form einer URL und wird von einem OpenID- 

Provider bereitgestellt. Üblicherweise besteht die URL aus einer Domain des Providers 

sowie dem Namen des Benutzers. 

Der Benutzer meldet sich selbst nur beim Provider mit Benutzername und Passwort 

an. Bei einer Webseite oder einem Dienst welcher auf die Identität des Benutzers 

zugreifen will muss nur die OpenID-URL sowie der OpenID-Provider (welcher 

oftmals aus der URL heraus ermittelt werden kann) hinterlegt werden. Die Authentifizierung 

erfolgt dann ohne Benutzereingabe. 

Viele große Web-Dienste wie Google und Yahoo! können bereits als OpenID- 

Provider verwendet werden. Die Authentifizierung wird vor Allem bei Blogs und 

anderen Webseiten mit Kommentarfunktion verwendet, bei denen die Einrichtung 

eines eigenen Benutzerkontos überflüssig erscheinen kann.[Recordon and Reed 2006] 

4.4 OAuth 

OAuth ist ein offener Standard und ein API-Autorisierungssystem. Es wird häufig 

in Verbindung mit OpenID verwendet, wenn ein komplettes Autorisierungs- und 

Authentifizierungssystem benötigt wird. 

Ziel ist es, dem Benutzer einer Webanwendung direkten Zugriff auf private Ressourcen 

zu ermöglichen, welche von einer anderen Webanwendung verwaltet werden, 

ohne dabei Informationen wie Benutzername und Passwort preisgeben zu müssen. 

OAuth definiert User, Consumer, Service Provider, Protected Resources und Token. 

Der User ist der Eigentümer von Informationen welche er freigeben möchte. 

Der Consumer ist eine Anwendung, welche für den Zugriff auf die Informationen 

des Users autorisiert werden soll. 

Der Service Provider ist eine Webanwendung bei welcher der User seine Informationen 

hinterlegt hat. Es ist nicht notwendig, dass der Service Provider gleichzeitig 

Identity Provider ist. 

Protected Resources sind Informationen, für deren Zugriff der User den Consumer 

autorisiert. Dies können private Daten, aber auch der Zugriff auf eine URL sein. 

Ein Token ist eine Zeichenkette welche Benutzername-Passwort-Kombinationen 

ersetzt. 

OAuth basiert auf HTTP und REST.[IETF 2010] 



4.5 U-Prove 

U-Prove ist ein Open Source Identity Management Framework von Microsoft welches 

als Grundlage für Autorisierungs- und Authentifizierungssysteme verwendet 

werden kann. 

Grundidee ist die Maximierung von Privatsphäre und Sicherheit durch Beschränkung 

der bei einer Transaktion jeweils sichtbaren Information auf die minimal benötigte 

Menge, auf der höchstmöglichen Abstraktionsebene. 

U-Prove definiert Issuer, Prover und Verifier als beteiligte Parteien sowie ein 

Token als Menge von geschützten Informationen . 

Der Issuer ist eine Autorität welche kryptographisch geschützte Informationen 

des Benutzers hält bzw. ausstellt. 

Als Prover wird der Benutzer bezeichnet, bzw. dessen lokale Anwendung welche 

auf das U-Prove-System zugreift. Der Prover bekommt vom Issuer ein Token 

ausgestellt und erhält Rechte über die dort enthaltenen Informationen. 

Der Verifier ist der Konsument eines Tokens. Über ein Präsentationsprotokoll 

kann der Prover bestimmen, welche Informationen in welcher Form preisgegeben 

werden dürfen, während der Verifier trotzdem in der Lage ist, die Echtheit des 

Tokens zu verifizieren.[Brands 2010] 

4.6 OpenSSO 

OpenSSO ist eine Access Management Plattform welche von Sun Microsystems 

entwickelt wurde und aktuell von ForgeRock unter dem Namen OpenAM“ weiterentwickelt 

wird. 

” 

OpenSSO ist in Java implementiert und verwendet SAML über HTTP. Es wird 

Single Sign-On Funktionalität für Unternehmens-IT bereitgestellt, wobei Identitäten 

sicher über Unternehmensgrenzen hinweg ausgetauscht werden können. 

Administratoren können innerhalb einer OpenSSO-Installation mehrere Identity 

Provider anlegen, welche zusammen mit den zugreifenden Anwendungen einen 

Circle of Trust“ bilden. Die Anwendung erhält für Aktionen wie Sign-in, Signout 

und Passwortänderung URLs, über die mit Hilfe von HTTP-Redirects und 

” 

SAML Tokens Authentifizierung durchgeführt wird. Dabei liegt die Initiative beim 

Browser des Benutzers, welcher von der Anwendung zum Identity Provider und bei 

erfolgreicher Anmeldung wieder zurückgeleitet wird.[Wikipedia 2010c] 

4.7 Shibboleth 

Shibboleth ist eine Identity Management Middleware von Internet2. 

Ähnlich wie in OpenSSO wird SAML und HTTP verwendet, um Single Sign-On 

zu implementieren. Primärer Anwendungsfall ist jedoch der allgemeine Austausch 

von Ressourcen zwischen Organisationen mit unterschiedlichen Authentifizierungsund 

Autorisierungssystemen. 

Es existiert eine Open Source Implementierung welche unter der Apache 2 Lizenz 

verfügbar ist.[Wikipedia 2010e] 

5. VERGLEICH DER VORGESTELLTEN TECHNOLOGIEN 

Es wurden drei offene Standards vorgestellt zu denen jeweils freie Implementierungen 

existieren. Die Standards werden in der Regel von Konsortien verabschiedet 



deren Teilnehmer sich jeweils dazu verpflichtet haben, keine Patentansprüche für 

jegliche Teile des Standards zu erheben. 

SAML OpenID OAuth 

Typ Standard Standard Standard 

Entwickler OASIS OpenID Foundation OAuth Community 

Lizenz Non- 

Non-Assertion Non-Assertion 

Assertion 

Technologien XML, XSD, HTTP, XML, XRDS HTTP, REST 

SOAP, 

HTTP 

Authentifizierung Ja Ja, SSO Nein 

Autorisierung Ja Nein Ja 

Identity Provider Nein Ja Nein 

Weiterhin wurden drei Frameworks vorgestellt, mit denen sich Autorisierungsund 

Authentifizierungssysteme implementieren lassen. 

U-Prove Shibboleth OpenSSO 

Typ Framework Framework Framework 

Entwickler Microsoft Internet2 Sun Microsystems 

Lizenz Open Spec. Promise Apache 2 CDDL 

Technologien - SAML, HTTP SAML, HTTP 

Authentifizierung Ja Ja, SSO Ja, SSO 

Autorisierung Ja Ja Ja 

Identity Provider Ja Nein Ja 

Die hier verwendeten Protokolle und Beschreibungssprachen kommen zusammen 

mit anderen weit verbreiteten Technologien auch in der Gesundheitstelematik zum 

Einsatz. 

Der Primärsystem-Konnektor setzt beispielsweise TLS in dem Teil des lokalen 

Netzwerkes voraus, in welchem sich auch die Kartenterminals befinden. Auch hier 

werden X.509-Zertifikate verwendet, wobei hier jeder Kommunikationspartner ein 

Zertifikat vorweisen muss. 

Der Konnektor verwendet WS Security bei der Kommunikation mit dem Broker 

auf Anwendungsebene. Konnektor, Broker und Fachdienste verwenden SOAP zur 

Formatierung von Nachrichten und zur Beschreibung von Webservices.[Fankhauser 

et al. 2007] 

6. ZUSAMMENFASSUNG 

Autorisierung und Authentifizierung umfasst ein breites Themenfeld welches in den 

letzten Jahren viele neue Technologien hervorgebracht hat. Grund dafür ist in erster 

Linie die Notwendigkeit zur Sicherung von stark vernetzten Informationssystemen 

in welchen Benutzer verschiedene Rollen annehmen, je nach Rolle auf verschiedene 

Ressourcen zugreifen dürfen, Daten selektiv oder anonymisiert weitergeben und 

selber Dienste mit ähnlichen Rechten ausstatten. 



In der Wirtschaft und bei privaten Anwendern wurden aus dieser Motivation heraus 

Lösungen entwickelt welche im Bereich der Web Services neue Komponenten 

bereitstellen oder neue Infrastrukturen definieren. Vor allem die sichere und standardisierte 

Verbindung bestehender, unterschiedlicher Architekturen stellt eine aktuelle 

Herausforderung dar. So sollen Identitäten über mehrere Sicherheitsdomänen 

(wie zum Beispiel Firmennetze) hinweg existieren, oft ohne zentrale Anlaufstelle 

für deren Authentifizierung. Konzepte wie Single Sign-On erleichtern dem Benutzer 

die Arbeit, müssen aber in vielen unterschiedlichen Systemen implementiert 

werden bevor der Vorgang transparent wird. Neben Authentifizierung und Identitätenmanagement 

wird auch Autorisierung zu einer immer komplexeren Aufgabe. 

So wird nicht nur der Zugriff auf Daten nach Identität und Rolle geregelt, auch 

können diese Attribute die autorisierte Abstraktionsebene einschränken (wie in U- 

Prove vorgestellt). Insgesamt ist zu beobachten, dass sich vermehrt offene Standards 

herausbilden, welche (Teil-)Lösungen für aktuelle Probleme bieten ohne bisher ein 

übergreifendes Konzept darzustellen. 

Im Gegensatz dazu wurde im Zuge der Einführung der elektronischen Gesundheitskarte 

eine umfassende Gesamtarchitektur entwickelt welche insbesondere Datenschutzaspekte 

beachtet. Viele etablierte Standards und Techniken wie TLS, 

X.509, IPsec, VPN und SOAP werden verwendet um Identitäten zu verifizieren 

und Übertragungen auf allen Ebenen abzusichern. Dem Versicherten werden zudem 

mehrere Möglichkeiten geboten, auf seine Daten zuzugreifen und fremden Zugriff 

auf diese Daten detailliert zu regulieren. 

REFERENCES 

Brands, S. 2010. U-Prove Technology Overview. https://connect.microsoft.com/site642/ 

Downloads/DownloadDetails.aspx?DownloadID=26953. 

Bundesaerztekammer. 2008. Zertifikatsprofile fuer X.509 Basiszertifikate Version 0.9.2. 

Bundesaerztekammer. 2010. e-Arztausweis und Telematik. http://www.bundesaerztekammer. 

de/page.asp?his=1.134. 

Fankhauser, F., Grechenig, T., Huehnlein, D., and Lohmaier, M. 2007. Die Basiskonzepte 

der Sicherheitsarchitektur bei der Einfuehrung der eGK. Tech. rep., DACH Security. 

gematik. 2008. Einfuehrung der Gesundheitskarte - Gesamtarchitektur. 

IETF. 1999. The TLS Protocol Version 1.0. http://datatracker.ietf.org/doc/rfc2246/. 

IETF. 2010. The oauth 1.0 protocol. http://tools.ietf.org/html/rfc5849. 

Recordon, D. and Reed, D. 2006. OpenID 2.0: a platform for user-centric identity management. 

In Proceedings of the second ACM workshop on Digital identity management. ACM, 16. 

VeriSign, P., Entrust, T., Entrust, C., Oblix, C., Jamcracker, D., Sun, E., Baltimore, I., 

Oblix, J., Tivoli, M., Packard, N., et al. Security Assertions Markup Language. 

Wikipedia. 2010a. Elektronische Gesundheitskarte — Wikipedia, Die freie Enzyklopaedie. 

http://de.wikipedia.org/w/index.php?title=Elektronische_Gesundheitskarte&oldid= 

74883630. 

Wikipedia. 2010b. Elektronischer Heilberufsausweis — Wikipedia, Die freie Enzyklopaedie. 

http://de.wikipedia.org/w/index.php?title=Elektronischer_Heilberufsausweis&oldid= 

75563097. 

Wikipedia. 2010c. OpenSSO — Wikipedia, The Free Encyclopedia. http://en.wikipedia.org/ 

w/index.php?title=OpenSSO&oldid=366479677. 

Wikipedia. 2010d. Public-Key-Infrastruktur — Wikipedia, Die freie Enzyklopaedie. http://de. 

wikipedia.org/w/index.php?title=Public-Key-Infrastruktur&oldid=76190568. 

Wikipedia. 2010e. Shibboleth (Internet2) — Wikipedia, The Free Encyclopedia. http://en. 

wikipedia.org/w/index.php?title=Shibboleth_(Internet2)&oldid=351893993. 



List of Figures 

1 PKI - http://upload.wikimedia.org/wikipedia/commons/3/34/Public- 

Key-Infrastructure.svg . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2 gematik: Gesamtarchitektur V1.5.0, S. 28 . . . . . . . . . . . . . . . 5

Authentifizierung und Autorisierung

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?