Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen

Dynamische Anlage geschützter Ressourcen

Masterarbeit

Eingereicht von Melanie Eibl

15. Juni 2012

Datenverarbeitungstechnik
Fakultät für Mathematik und Informatik
FernUniversität in Hagen

Betreuer:
Prof. Dr.-Ing. Bernd J. Krämer
Dipl.-Inf. Daniel Schulte

Versicherung der eigenständigen Arbeit

Hiermit erkläre ich, dass ich die vorliegende Abschlussarbeit selbständig verfasst und keine ande-
ren als die angegebenen Hilfsmittel benutzt habe.

Die Stellen der Abschlussarbeit, die anderen Quellen im Wortlaut oder dem Sinn nach entnommen
wurden, sind durch Angaben der Herkunft kenntlich gemacht. Dies gilt auch für Zeichnungen,
Skizzen, bildliche Darstellungen sowie für Quellen aus dem Internet.

Ruppichteroth, 15.06.2012

_____________________________ ________________________

Ort, Datum Unterschrift

Zusammenfassung
Die vorliegende Arbeit beschäftigt sich mit Authentifizierung und Autorisierung in einem verteil-
ten System. Das System soll REST-konform umgesetzt werden und somit ergeben sich Beschrän-
kungen in Bezug auf die Nutzung von HTTP als Übertragungsprotokoll. Zur Sicherung des Trans-
portkanals wird SSL/TLS betrachtet. Anschließend werden vier Szenarien beschrieben und Lö-
sungsmöglichkeiten dargestellt. Hierbei wird zunächst von der Authentifizierung als querschnittli-
che Funktionalität abstrahiert, die in einem eigenen Kapitel ausführlich behandelt wird. Dabei
werden Beschränkungen des OpenID-Protokolls untersucht. Weiterhin soll der Einsatz von OAuth
als Protokoll zur Delegation von Zugriffsrechten evaluiert werden.

INHALTSVERZEICHNIS
1 EINLEITUNG ........................................................................................................................ 1

2 REPRESENTATIONAL STATE TRANSFER – REST .................................................................... 3

2.1 KERNPRINZIPIEN FÜR RESTFUL HTTP NACH TILKOV ..................................................................... 3
2.2 REPRÄSENTATIONSFORMATE .................................................................................................... 5
2.3 HYPERTEXT TRANSFER PROTOCOL HTTP ................................................................................... 6
2.4 HTTP-ANFORDERUNGSMETHODEN (HTTP-VERBEN) ................................................................... 7

3 SICHERHEIT ....................................................................................................................... 11

3.1 VERSCHLÜSSELUNG .............................................................................................................. 12
3.2 ZERTIFIKATE ........................................................................................................................ 12
3.3 TRANSPORT LAYER SECURITY (TLS) / SECURE SOCKETS LAYER (SSL) .............................................. 13
3.4 HTTPS .............................................................................................................................. 14
3.5 FAZIT ................................................................................................................................. 15

4 SZENARIEN ZUR AUTHENTIFIZIERUNG UND AUTORISIERUNG ........................................... 16

4.1 IDENTITÄTSMANAGEMENT ..................................................................................................... 16
4.1.1 Authentifizierung und Autorisierung ....................................................................... 16
4.1.2 Zugriffsberechtigung ............................................................................................... 17
4.1.3 Modellierung von Zugriffsrechten mit der Zugriffskontrollliste (ACL) ..................... 17
4.1.4 Berechtigungsmodelle............................................................................................. 18
4.2 EINFÜHRUNG IN DIE SZENARIEN .............................................................................................. 19
4.2.1 Metadaten der Ressourcen ..................................................................................... 19
4.2.2 Custom Header Fields: ............................................................................................ 20
4.3 SZENARIO 1: ANLAGE UND ANSCHLIEßENDE AUTORISIERTE ANFRAGE EINER GESCHÜTZTEN RESSOURCE . 21
4.3.1 Ausgangssituation................................................................................................... 21
4.3.2 Problem ................................................................................................................... 22
4.3.3 Lösung ..................................................................................................................... 22
4.3.4 Umsetzung .............................................................................................................. 23
4.4 SZENARIO 2: AUFBAU WEITERER VERBINDUNGEN ZU GESCHÜTZTEN RESSOURCEN ............................ 27
4.4.2 Problem ................................................................................................................... 27

I

4.4.3 Lösung ..................................................................................................................... 27
4.4.4 Umsetzung .............................................................................................................. 28
4.5 SZENARIO 3: DELEGATION ..................................................................................................... 29
4.5.2 Problem ................................................................................................................... 29
4.5.3 Lösung ..................................................................................................................... 30
4.5.4 Umsetzung .............................................................................................................. 33
4.6 SZENARIO 4 - MASSENDELEGATION ......................................................................................... 37
4.6.2 Problem ................................................................................................................... 38
4.6.3 Lösung ..................................................................................................................... 38
4.7 FAZIT ................................................................................................................................. 38

5 AUTHENTIFIZIERUNGSPROTOKOLLE.................................................................................. 39

5.1 ZERTIFIKATE ........................................................................................................................ 39
5.2 BASIC- UND DIGEST-AUTHENTIFIZIERUNG ................................................................................. 40
5.3 SINGLE-SIGN-ON ................................................................................................................. 43
5.4 OPENID ............................................................................................................................. 45
5.4.1 Arbeitsweise des OpenID-Protokolls ....................................................................... 46
5.4.2 Nachrichtenfluss am Beispiel von Szenario 1 .......................................................... 48
5.4.3 Einschränkungen des OpenID-Protokolls ................................................................ 53
5.4.4 Mögliche Lösungsansätze ....................................................................................... 54
5.5 FAZIT ................................................................................................................................. 56

6 DELEGATION MIT OAUTH 1.0 ............................................................................................ 59

6.1 OAUTH-ROLLEN UND -BEGRIFFE NACH RFC5849 [HAM10] ....................................................... 59
6.2 OAUTH NACHRICHTENFLUSS .................................................................................................. 61
6.3 DELEGATION MIT OAUTH FÜR SZENARIO 3 ............................................................................... 62
6.4 FAZIT ................................................................................................................................. 67

7 PROTOTYPISCHE IMPLEMENTIERUNG ............................................................................... 68

8 SCHLUSSBEMERKUNG ....................................................................................................... 69

9 LITERATURVERZEICHNIS.................................................................................................... 70

10 ABBILDUNGSVERZEICHNIS ............................................................................................ 73

II

Einleitung

1 Einleitung
Immer mehr Rechnernetze werden zur Unterstützung von Gruppen- und Teamarbeit eingesetzt.
Die rechnergestützte Gruppenarbeit, oder auch Computer Supported Collaborative Work (CSCW),
ist ein interdisziplinäres Forschungsgebiet, welches sich mit der Kooperation zwischen Menschen
und deren Unterstützung mit Rechnern beschäftigt.

Soft- und Hardware, die zur Kooperationsunterstützung eingesetzt wird, nennt man allgemein
Groupware [Ell91, S. 39 - 58]. Auf Seiten der Software fallen darunter Programme oder Pro-
grammsysteme, die zur Kooperationsunterstützung eingesetzt werden, wie z. B. Dokumentenver-
waltungssysteme und Aufgabenverwaltungssysteme. Groupwaresysteme unterstützen beim Trans-
port der Daten, der Organisation der Arbeitsaufgaben innerhalb einer Gruppe und der eigentlichen
Kooperation der beteiligten Nutzer.

Die Kommunikation zwischen den beteiligten Systemen und deren Nutzern kann über verschiede-
ne Wege erfolgen. Beispiele sind Sockets, Shared Memory, Named Pipes, RPC, DCOM, Webser-
vices u. v. a. Die Tendenz ist jedoch, dass die Kommunikation über das Internet immer bedeutender
wird und hier überwiegend HTTP als Übertragungsprotokoll eingesetzt wird. HTTP ist eine Im-
plementierung des REST-Architekturstils und setzt dessen Paradigmen um.

Die vorliegende Arbeit beschäftigt sich mit Groupware-Szenarien, bei denen ein Dokument inner-
halb einer Gruppe bearbeitet werden soll. Hierbei ist ein Nutzer der Besitzer des Dokuments. Der
Besitzer wählt kollaborierende Nutzer aus seinem Adressbuch aus und weist ihnen Aufgaben und
dazugehörige Zugriffsrechte auf das Dokument zu. Weiterhin kann ein kollaborierender Nutzer die
ihm zugewiesene Aufgabe weiter delegieren. Als Diskussionsgrundlage werden vier repräsentative
Szenarien betrachtet. Szenario 1 behandelt die Erzeugung einer geschützten Ressource und den an-
schließenden autorisierten Zugriff auf die Ressource. In Szenario 2 soll der autorisierte Zugriff auf
eine zuvor angelegte Ressource näher betrachtet werden. Szenario 3 wird sich mit der Delegation
von Zugriffsrechten an einen weiteren Nutzer beschäftigen und Szenario 4 schließlich mit der
Massendelegation.

In der vorliegenden Arbeit werden zunächst Grundlagen beschrieben und Begrifflichkeiten einge-
führt. Die wesentlichen Themen sind hierbei der REST-Architekturstil und das Thema Sicherheit
mit SSL/TLS zur Sicherung des Transportkanals. Dann erfolgt die Diskussion der Szenarien. Da-
bei wird zunächst von der Authentifizierung als querschnittliche Funktionalität abstrahiert. Zur
Delegation der Zugriffsrechte wird ein Algorithmus beschrieben, der die Baumstruktur der Dele-
gation aufgreift.

1

Einleitung

Anschließend werden verschiedene Authentifizierungsmethoden beschrieben und evaluiert. Wei-
terhin werden die besonderen Merkmale und Beschränkungen des OpenID-Protokolls beschrieben
und Erweiterungsmöglichkeiten aufgezeigt.

Schließlich wird noch die Delegation mit dem OAuth-Protokoll beschrieben und ein Ansatz für die
vorliegenden Szenarien skizziert. Dabei soll dargestellt werden, warum die diesem Standard zu-
grundeliegende Problemstellung nicht auf die hier dargestellte Delegationsproblematik übertragbar
ist.

Mit der Schlussbemerkung schließt diese Arbeit.

2

REpresentational State Transfer – REST

2 REpresentational State Transfer – REST
Bei Groupware-Systemen besteht oft die Anforderung an hohe Verteilbarkeit und lose Kopplung,
damit sich das System an sich ändernde Prozesse dynamisch anpassen kann. Weiterhin spielt Ska-
lierbarkeit, Wiederverwendbarkeit und robuste Implementierung von Komponenten eine entschei-
dende Rolle, wie auch die Übertragung über das Internet. In diesem Kapitel soll dargestellt wer-
den, wie der REST Architekturstil diesen Anforderungen Rechnung trägt.

Bei verteilten Anwendungen können Nutzer und genutzte Dienste über die ganze Welt verteilt
sein. Das WWW (World Wide Web) ist eine verteilte Anwendung, die Dokumente auf der ganzen
Welt miteinander verknüpft. Der Zugriff auf Dokumente erfolgt über Links innerhalb anderer Do-
kumente. Dokumente können unterschiedliche Repräsentationsformate haben und zur Übertragung
werden verschiedene Protokolle, die meist auf Standards beruhen, herangezogen. Ziel des WWW
ist, die intuitive Gestaltung der Interaktion zwischen Mensch und Hypertext-Dokumenten
[Bern96].

Das WWW ist weiterhin eine typische Client-Server-Architektur. Der Server stellt Dokumente als
Ressource oder Dienste zur Verfügung, die über einen Universal Resource Identifier (URI) eindeu-
tig adressiert werden. Die Kommunikation erfolgt über Nachrichten (Request-/Response-
Paradigma) mit dem Hypertext Transfer Protokoll (HTTP) als Übertragungsformat.

2.1 Kernprinzipien für RESTful HTTP nach Tilkov

REpresentional State Transfer (REST) ist ein Architekturstil, der von Roy Fielding in seiner Dis-
sertation entscheidend geprägt wurde [Fie00]. REST ist ein Architekturstil für verteilte Hyperme-
dia-Systeme und basiert auf HTTP. REST bietet eine Reihe von architektonischen Prinzipien, die
als Ganzes angewandt die Skalierbarkeit der Komponenten, Allgemeingültigkeit von Schnittstel-
len, unabhängige Verteilbarkeit (Deployment) von Komponenten erzielen. Dadurch werden War-
tezeiten bei Interaktionen verringert, die Sicherheit erhöht und Legacy-Systeme gekapselt [Fie00,
S. 3].

Nach Tilkov [Til11, S. 10] muss genau genommen zwischen dem abstrakten Architekturstil REST,
der konkreten, weitgehend REST-konformen Implementierung HTTP und einzelnen Webanwen-
dungen und Diensten unterschieden werden, die mehr oder weniger konform zu den REST-
Prinzipien umgesetzt sein können. Weiterhin ergeben sich nach Tilkov fünf Kernprinzipien für
REST [Til11, S. 11]:

3


1. Ressourcen mit eindeutiger Identifikation
Das Prinzip der eindeutigen Identifikation fordert, dass jede Ressource ihren eigenen URI
hat, durch den sie anwendungsübergreifend eindeutig identifiziert wird. Die Ressource
kann dabei eine einzelne Entität oder eine Menge von Entitäten repräsentieren. Ein URI
ist eine ID innerhalb eines globalen Namensschemas.
2. Verknüpfungen/Hypermedia
Weiteres Grundprinzip beim Hypermedia-Ansatz ist, dass Verknüpfungen anwendungs-
übergreifend funktionieren. Ressourcen werden mit anderen Ressourcen über Links mit-
einander verknüpft. Da das Namensschema global ist, kann jede Anwendung weltweit mit
einer anderen Anwendung verknüpft werden.
3. Standardmethoden
Damit Clients mit Ressourcen kommunizieren können, sollten alle Ressourcen das
HTTP-Protokoll korrekt implementieren. Daher fordert das dritte Prinzip, dass jede Res-
source einen Satz an Standardmethoden bzw. Verben unterstützt. Hierzu gehören meist
die HTTP-Standardmethoden GET, PUT, POST und DELETE. Oftmals werden noch
HEAD und OPTIONS unterstützt. Dadurch erhält man eine Schnittstelle mit fest definier-
ten Methoden.
4. Unterschiedliche Repräsentationen
Eine Ressource kann mehrere Repräsentationen für unterschiedliche Anwendungen zur
Verfügung stellen. Man sieht nie die Ressource selbst, sondern nur ihre Repräsentation.
Ein Ansatz von HTTP ist die Trennung von Verantwortlichkeiten (Separation of Con-
cerns1) für Daten und Operationen. Operationen in Form der zuvor genannten HTTP-
Standardmethoden sind dabei gleich, aber die Daten können auf unterschiedliche Art und
Weise repräsentiert werden (Content-Negotiation2).
5. Statuslose Kommunikation
REST schreibt vor, dass die Kommunikation grundsätzlich statuslos sein sollte. Ist es un-
bedingt erforderlich einen Zustand zu speichern, sollte dies Client-seitig geschehen oder
vom Server in einen Ressourcenstatus umgewandelt werden. Gründe für Statuslosigkeit
sind Skalierbarkeit und lose Kopplung.

Mit der Umsetzung des skizzierten Groupwareszenarios nach dem REST Architekturstil ergeben
sich viele Vorteile. Da jede Ressource einen weltweit eindeutigen Identifier in Form eines URIs

1
Separation of Concerns http://en.wikipedia.org/wiki/Separation_of_concerns
2
Content negotiation: http://en.wikipedia.org/wiki/Content_negotiation

4


erhält, kann man domänenübergreifend auf sie zugreifen. Daraus resultiert, dass auch Verknüp-
fungen zu abhängigen Ressourcen über Links anwendungs- und domänenübergreifend weltweit
funktionieren. Im Kontext einer Aufgabenverwaltung, bei der ein Dokument in einer zugewiese-
nen Aufgabe verlinkt wird, ist es unerheblich, an welchem Ort der Welt das Dokument und wo die
Aufgabe als Ressource gehosted wird.

Aus der Forderung nach Statuslosigkeit ergibt sich, dass jede Anfrage/Antwort (Requ-
est/Response) völlig autark ist. Manchmal ist es jedoch sinnvoll, einen Zustand zu halten, um be-
stimmte Abläufe nicht unnötig wiederholen zu müssen. Dazu gehört insbesondere die Authentifi-
zierung, die in Kapitel 5 beschrieben wird. Der Authentifizierungsvorgang kann je nach gewähl-
tem Verfahren ein aufwändiger Prozess sein, der bei jeder Anfrage durchlaufen werden muss. Um
dies zu umgehen, kann die einmal festgestellte Identität eines Clients in einem Cookie festgehalten
werden. Ein Cookie ist eine clientseitige Ablage von Sitzungsinformationen in Form von Schlüs-
sel-/Wert-Paaren. Cookies werden i. d. R. von Browsern unterstützt. Cookies verlieren i. d. R. ihre
Gültigkeit, wenn einer der miteinander kommunizierenden Prozesse geschlossen wird.

Die Verwendung von Standardmethoden erleichtert die Schnittstellenbeschreibung und gewähr-
leistet, dass User-Agents3 über Standard-Funktionalitäten auf eine Ressource zugreifen können.
Populärster User-Agent ist der Browser zum Abrufen von Hypermedia-Dokumenten. Bei der Ein-
gabe eines URIs in der Adresszeile, wird eine Anfrage mit der HTTP-Standardmethode GET (z. B.
GET http://www.example.org/tasks HTTP/1.1) ausgeführt. Daneben werden der Anfrage

noch weitere Headerinformationen hinzugefügt, auf die später eingegangen werden soll. Der Ser-
vice, der die Ressource zur Verfügung stellt, versteht die Methode GET und sendet sie im Body
der Antwort die Ressource im bevorzugten Repräsentationsformat. Auf die Einzelheiten soll in
den nächsten Kapiteln eingegangen werden.

2.2 Repräsentationsformate

Eine Ressource ist ein Datenobjekt, welches über einen URI eindeutig identifiziert werden kann.
Eine Ressource kann in verschiedenen Repräsentationsformaten unter demselben URI angeboten
werden. In welchem Repräsentationsformat die Ressource letztendlich übertragen wird, muss zwi-
schen Client und Server „verhandelt“ werden. Dieses Verhalten wird in RFC 2616 als Content
Negotiation beschrieben [Fie99, Kapitel 12].

3
User Agent http://en.wikipedia.org/wiki/User_agent

5


Das HTTP-Protokoll bietet Vorkehrungen für Content Negotiation, d. h. es können mehrere Re-
präsentationen einer Ressource angeboten werden. Es wird zwischen Server-Driven-Negotiation
und Client-Driven-Negotiation unterschieden, d. h. entweder der Server oder der Client entschei-
det über das übermittelte Repräsentationsformat [Fie99, Kapitel 12.1 und 12.2].

Multipurpose Internet Mail Extensions (MIME) ist ein Protokoll, das es erlaubt, verschiedene Do-
kumente unterschiedlicher Formate als eine einzige Nachricht zu verschicken. MIME ist in RFC
2045 [Fre961] und RFC 2046 [Fre962] standardisiert. Bei MIME steht eine Meta-Information, die
die Codierung der Nachricht und ihre hierarchische Struktur beschreibt, als ASCII-Text im Nach-
richten-Header. Die Kopf-(Header-)Information umfasst die MIME-Version, mit der die Nachricht
erstellt wurde, den Typ des Nachrichteninhalts und die Art der Kodierung für den Nachrichten-
transport [Fie99, Kapitel 19.4.1].

REST hat keine architektonischen Beschränkungen bzgl. der physikalischen Repräsentation von
Ressourcen. Im Hinblick auf die unterschiedlichen Nutzerbedürfnisse ist das sinnvoll. Der Typ ei-
ner RESTful-Service-Ressource wird Medientyp genannt. Dieser Medientyp wird immer als
MIME-Type im Content-Type-Header einer HTTP-Response angegeben. Die vier häufigsten Me-
dienformate sind XML, Really Simple Syndication (RSS) / Atom Syndication Format, Extensible
Hypertext Markup Language (XHTML) und Java Script Object Notation (JSON). Die Parameter
des Content-Type-Header-Feldes sind in RFC 2045 spezifiziert [Fre961].

In unserem Beispiel sendet der Browser die von ihm bevorzugten Repräsentationsformate im Ac-
cept-Header der Anfrage: z. B. Accept: text/html, application/xhtml+xml,

application/xml, */*. Das bedeutet, dass das bevorzugte Format text/html ist. Wenn dies

vom Service nicht unterstützt wird, ist die zweite Wahl application/xhtml+xml usw. In letzter
Instanz wird mit */* ausgedrückt, dass jedes Format akzeptiert wird. Formate, die der Browser
nicht darstellen kann, werden von ihm anders behandelt, z. B. zum Download angeboten, um die
Ressource mit einem anderen Programm öffnen zu können.

2.3 Hypertext Transfer Protocol HTTP

Der REST Architekturstil basiert auf dem HTTP-Protokoll, welches in RFC 2616 publiziert ist
[Fie99]. HTTP ist ein offener und interoperabler Webstandard, der einen Standard-Weg für An-

6


wender aufzeigt, miteinander zu interagieren. Diese Interaktionen basieren auf den Anforderungs-
methoden bzw. Verben.

Die Kommunikation über HTTP zwischen Client und Server erfolgt über Nachrichten (Messages)
im Klartextformat (Human-Readable Medium4). Es gibt zwei Arten von Nachrichten: Die Anfrage
(Request) vom Client an den Server und die Antwort (Response) als Reaktion vom Server zum
Client. Eine Nachricht besteht aus zwei Teilen: Dem Nachrichtenkopf (Header) und dem Nach-
richtenkörper (Body). Der Body enthält die Ressourcenrepräsentation, bzw. die Nutzdaten. Der
Header enthält die Metainformationen der Nachricht, bzw. des Bodys, wie etwa verwendete Ko-
dierungen oder den Inhaltstyp, damit dieser vom Client korrekt interpretiert werden kann [Fie99].

Uniform Resource Identifier (URI) sind eine Zeichenfolge, die eine Ressource weltweit eindeutig
identifzieren. Der aktuelle Standard für URIs ist in RFC 3986 publiziert [Ber05]. URIs können ab-
solut oder relativ zu einem Base-URI angegeben werden [Fie99, Kapitel 3.2].

Die generische URI-Syntax besteht insgesamt aus fünf Teilen, für die hier zu bearbeitende Aufga-
be sind jedoch nur drei von Bedeutung: Scheme (Schema), Authority (Anbieter) und Path (Pfad).

Beispiel aus RFC 3986 [Ber05]:

foo://example.com:8042/over/there
_/ ________________/_________/
| | |
scheme authority path
Das Schema gibt den URI-Typ an, z. B. HTTP, HTTPS oder FTP. Die Authority ist ein optionaler
Bestandteil einer URI, der eine Instanz innerhalb eines Domain Name Systems repräsentiert. Auf
die Authority folgt ein weiterer Pflichtbestandteil: Der Path. Der Path enthält meist hierarchisch
organisierte Angaben, die zusammen mit dem Abfrageteil eine Ressource identifizieren. Wenn ei-
ne Authority vorangestellt ist, muss sie mit einem Schrägstrich ("/") beginnen.

2.4 HTTP-Anforderungsmethoden (HTTP-Verben)

Das HTTP-Protokoll beinhaltet eine erweiterbare Menge von Standardverben. Im Folgenden wer-
den die hier relevanten Verben bzw. Methoden, die ein Client im Header des Requests angeben
kann, kurz beschrieben [Fie99, Kapitel 9].

4
Human-Readable Medium http://en.wikipedia.org/wiki/Human-readable_medium

7


Methoden können zum einen sicher sein und/oder idempotent. Von einer sicheren Methode spre-
chen wir, wenn sie keine weiteren Aktionen als das reine Anfordern von Daten hervorruft. Typi-
scherweise erfüllen dieses Kriterium die GET- und HEAD-Methoden. Idempotente Methoden
können zwar Seiteneffekte verursachen, jedoch sind diese bei mehrmaligem Aufruf der Methode
dieselben wie beim einmaligen Aufruf [Fie99, Kapitel 9.1].

 GET
Mit der GET-Methode fordert ein Client eine Ressourcenrepräsentation an, die unter dem
angegebenen URI zu finden ist. Eine der wichtigsten Eigenschaften von GET ist, dass
man das Ergebnis eines GET-Requests cachen kann, wenn bestimmte Voraussetzungen
erfüllt sind. Wenn die im Request angeforderte Ressource im Response-Body enthalten
ist, ist der Response-Code 200 (OK). Die GET-Methode erzeugt keine Seiteneffekte, d. h.
sie verursacht keine Änderungen an anderen Ressourcen. Außerdem ist GET idempotent,
d. h. das mehrmalige Ausführen einer Methode führt zum selben Ergebnis, wie das ein-
malige Ausführen der Methode [Fie99, Kapitel 9.3].
 HEAD
Die HEAD-Methode ist äquivalent zur GET-Methode, wobei aber nicht die Ressourcen-
repräsentation selber, sondern nur ihre Meta-Informationen abgerufen werden. HEAD lie-
fert keinen Message-Body in der Response-Nachricht zurück, wird aber trotzdem mit 200
(OK) quittiert. HEAD ist genau wie GET sicher bzw. erzeugt keine Seiteneffekte [Fie99,
Kapitel 9.4].
 POST
Die POST-Methode wird benutzt, um auf dem Server eine neue Ressource zu erzeugen.
Dabei ist die neue Ressource die untergeordnete Ressource der im Request-URI ange-
sprochenen Ressource. Der Response-Status-Code für eine erfolgreich erzeugte Res-
source sollte 201 (Created) sein. Weiterhin sollte die Response-Message einen Location-
Header mit dem URI der neu erzeugten Ressource enthalten. Wenn die Methode nicht zu
einer adressierbaren Ressource führt, sind die verwendeten Response-Codes 200 (OK)
oder 204 (No Content), je nachdem, ob der Response einen Body mit einem beschreiben-
den Ergebnis liefert. Wenn die Aktion nicht sofort ausgeführt werden kann, liefert der
Server ein 202 (Accepted). POST ist weder idempotent noch sicher [Fie99, Kapitel 9.5].
 PUT
Die PUT-Methode wird benutzt, um eine bestehende Ressource auf dem Server unter
dem angegebenen URI zu speichern oder zu aktualisieren. Der Unterschied zwischen
POST und PUT ist, dass der URI in der Clientanforderung unterschiedlich interpretiert
wird. Der URI in einem PUT gibt die Adresse an, unter der die Ressource, die im Request

8


mitgeschickt wird, ansprechbar sein soll. Der URI in einem POST dagegen spezifiziert
die Ressource, an die die gesendete Ressource angefügt wird, und nicht den URI der ge-
sendeten Ressource. Der Response-Conde für eine modifizierte Ressource sollte 200
(OK) oder 204 (No Content) sein. PUT ist idempotent [Fie99].
 DELETE
Die DELETE-Methode erlaubt es, eine Ressource unter dem angegebenen URI zu lö-
schen. Eine erfolgreiche Response sollte 200 (OK) sein, wenn er eine Entität enthält, wel-
che den Status beschreibt oder 202 (Accepted), wenn die Aktion noch nicht ausgeführt
wurde. Wenn die Aktion ausgeführt wurde, aber keine Entität mitgesendet wird mit 204
(No content) geantwortet. DELETE ist ebenfalls idempotent [Fie99].
 PATCH
Die PUT-Methode ist so definiert, dass sie eine Ressource vollständig überschreibt. Die
PATCH-Methode wird genutzt, um eine Ressource nur partiell zu überschreiben. Der
Satz Änderungen wird in einem Format bereitgestellt, welches man Patch-Dokument
nennt. Die Ressource wird nur modifiziert und nicht überschrieben. PATCH ist weder si-
cher noch idempotent. Der Response-Code ist bei erfolgreicher Modifizierung der Res-
source 204 (No Content), weil der Message Body leer bleibt. Je nach Fehlerfall können
die Response-Codes 404 (Not Found), 409 (Conflict) oder 412 (Precondition Failed) auf-
treten [Dus10].

Header-Fields5 werden im Header einer Nachricht transportiert. Hierbei unterscheidet man zwi-
schen Request- und Response-Header. Im Folgenden sollen die hier wichtigsten Header kurz auf-
geführt werden [Fie99].

 Accept und Content-Type
Der Accept-Header im Request wird genutzt, um Medientypen anzugeben, die der Client
versteht. Es können auch mehrere Medientypen angegeben werden. Der Content-Type-
Header im zugehörigen Response gibt den Medientyp der im Body enthaltenen Ressource
an, bzw. im Falle der HEAD-Methode den Medientyp, der bei der GET-Methode zurück-
geliefert worden wäre [Fie99].
 Authorization und WWW-Authenticate
Im Authorization-Header schickt der Client seine Authentifizierungsinformationen an den
Server. Dies kann initial erfolgen oder infolge eines 401 (Unauthorized) Response. Der

5
List of HTTP Header Fields http://en.wikipedia.org/wiki/List_of_HTTP_header_fields

9


zugehörige WWW-Authenticate-Header des Response muss in einem 401 (Unauthorized)
Response angegeben werden und enthält mindestens eine Challenge, die ein Authentifi-
zierungsschema angibt und weitere Parameter [Fie99].
 Location
Im Location-Response-Header wird der Client zu einem URI umgeleitet, der nicht dem
angefragten URI entspricht. Für 201 (Created) Responses ist der angegebene URI die
URI der neuen Ressource. Der URI der neuen Ressource muss absolut angegeben werden
[Fie99].

Einige wichtige Status Codes6 sind in Anlage A aufgeführt.

6
List of HTTP Status Codes http://en.wikipedia.org/wiki/HTTP_status_code

10

Sicherheit

3 Sicherheit
Verteilte Systeme im Internet nutzen Übertragungswege, die auch von anderen Partnern genutzt
werden. Neben den Nutzern, die diese Wege in friedlicher Absicht mitbenutzen, hat man es auch
mit solchen zu tun, die das Ziel verfolgen, Kommunikationen zu stören oder unrechtmäßig an ver-
trauliche Informationen zu kommen. Ein verteiltes System ist gegen solche Angreifer geeignet zu
schützen. Nach [Web10, S. 285] ergeben sich vier Säulen für sichere Anwendungen:

 Vertraulichkeit
Ist die Fähigkeit, Daten vor dem Zugriff unberechtigter Dritter zu schützen.
 Integrität
Ist die Fähigkeit, Nachrichten während ihrer Übertragung vor Manipulation zu schützen.
 Identität
Ist die Fähigkeit, die Identität der Nutzer nachzuweisen. Die Durchführung eines solchen
Nachweises bezeichnet man als Authentifizierung und wird in Kapitel 5
„Authentifizierungsprotokolle“ beschrieben.
 Vertrauen
Ist die Fähigkeit, beteiligte Parteien für bestimmte Aktionen zu autorisieren. Mit der Au-
torisierung wird sich Kapitel 4 „Szenarien zur Authentifizierung und Autorisierung“ be-
schäftigen.

In diesem Kapitel werden Mechanismen zur Sicherstellung der Vertraulichkeit und der Integrität
beschrieben.

Grundsätzlich unterscheidet man zwischen nachrichtenbasierter und transportbasierter Sicherheit.
Beim nachrichtenorientierten Ansatz wird die Nachricht geeignet geschützt, d. h. verschlüsselt und
signiert und kann dann über einen ungesicherten Transportmechanismus übertragen werden. Bei
der transportbasierten Sicherheit wird der Übertragungskanal gesichert. Die Nachricht kann dann
unverschlüsselt übertragen werden.

Zunächst müssen die Sicherheitsanforderungen definiert werden. Diese Anforderungen nennt man
Security Policy. Eine Security Policy legt genau fest, was in einem System erlaubt ist und was
nicht. Aus der Security Policy werden dann die Maßnahmen festgelegt, die das gewünschte Ver-
halten sicherstellen. Diese Maßnahmen nennt man Security Mechanisms. Hierzu zählen insbeson-
dere die Verschlüsselung, die Authentisierung, die Autorisierung und die Auditierung. Auditierung
wird hier nicht weiter beschrieben.

11

Sicherheit

3.1 Verschlüsselung

Bei der Verschlüsselung handelt es sich um das Umformen der Daten in etwas, was ein Angreifer
nicht versteht. Hierdurch wird Geheimhaltung gewährleistet. Außerdem kann man durch Ver-
schlüsselung erkennen, ob Daten verändert wurden, was den Grundsatz der Integrität unterstützt.
Ver- und Entschlüsselung werden mittels kryptografischer Methoden realisiert, mit Schlüsseln als
Parameter. Grundsätzlich unterscheidet man zwischen symmetrischer und asymmetrischer Ver-
schlüsselung. Bei der symmetrischen Verschlüsselung sind die Schlüssel zum Ver- und Entschlüs-
seln gleich. Bei der asymmetrischen Verschlüsselung sind die Schlüssel ein eindeutiges Paar, je-
doch zum Ver- und Entschlüsseln verschieden. Bei der asymmetrischen Verschlüsselung ist ein
Schlüssel geheim und der andere öffentlich. Daher werden asymmetrische Verschlüsselungssys-
teme auch oft Public-Key Systeme genannt.

Ein schwieriges Thema im Bereich des Schüssel Managements ist die Verteilung von initialen
Schlüsseln. Diese müssen in einem symmetrischen Verschlüsselungssystem über einen sicheren
Übertragungskanal übertragen werden. Bei asymmetrischen Verschlüsselungssystemen muss der
öffentliche Schlüssel in einer Form übertragen werden, die dem Empfänger sicherstellt, dass dieser
Schlüssel tatsächlich zu einem bestimmten privaten Schlüssel gehört [Tan07, S. 430 ff.]. Um die-
ses Verteilungssystem zu lösen, werden Schlüssel über Zertifikate erzeugt. Die Arbeitsweise von
Zertifikaten soll im folgenden Kapitel beschrieben werden.

3.2 Zertifikate

Ein öffentlich verschlüsseltes Zertifikat, üblicherweise nur Zertifikat genannt, ist ein digital sig-
niertes Statement, das den Wert eines öffentlichen Schlüssels an die Identität einer Person oder ei-
nes Services bindet, das den korrespondierenden privaten Key hält. Öffentlich signierte Zertifikate
stammen von einem sogenannten Stammzertifikat ab. Diese Stammzertifikate werden auf Rech-
nersystemen vorinstalliert, so dass der Client die Abstammung verifizieren kann. Einer der Vortei-
le von Zertifikaten ist, dass der Host nicht mehr die Kennwörter der Nutzer und deren individuel-
len Authentifizierungsinformationen pflegen muss, sondern dem Herausgeber des Zertifikates ver-
trauen kann.

Zertifikate spielen in der abgesicherten Kommunikation über das Internet eine wichtige Rolle. Die
Kommunikationspartner können damit ihre Identität beweisen und gleichzeitig einen privaten, ver-
schlüsselten Kanal zueinander aufbauen. Ein Zertifikat ermöglicht diese Verschlüsselung. Die Au-
thentifizierung des Kommunikationspartners ist wichtig für das Vertrauen. Sicherheitsproblem hier

12

Sicherheit

ist, zu verifizieren, ob der Public Key von einer Webseite wirklich zum gewünschten Kommunika-
tionspartner gehört. Die Garantie selber wird Zertifikat genannt [Kri08, S. 90]. Jedes Zertifikat
enthält daher eindeutige authentifizierende Informationen über den Eigentümer des Zertifikats.
Dazu gehört die Identität des Antragstellers, die der zertifizierenden Stelle, Gültigkeitsperiode des
Zertifikats und natürlich der Public Key des Antragstellers nebst Informationen über die eingesetz-
ten Algorithmen [Kri08, S. 91]. Ein Zertifikat ist im Wesentlichen eine von einer vertrauenswürdi-
gen Instanz, der Certification Authority (CA), digital signierte Bestätigung, dass eine bestimmte
Identität und ein bestimmter Public Key zusammen gehören [Kri08, S. 91]. Die CA verifiziert die
Identität des Zertifikateigentümers, bevor das Zertifikat ausgestellt wird. Je nach Einsatzfeld des
ausgestellten Zertifikats kann die CA auch eine innerbetriebliche Instanz sein, sofern die in den
Zertifikaten enthaltenen Public Keys nur innerhalb einer bestimmten Firma bzw. Domäne verwen-
det werden [Kri08, S. 92]. Um eine möglichst weitreichende Kompatibilität auch über System-
und Firmengrenzen hinweg zu gewährleisten, existiert für das Format von Zertifikaten ein Stan-
dard, nämlich das X.509 Format der ITU (International Telecommunications Union) [Kri08, S.
90]. Zertifikate lösen das Verteilungsproblem und können zur Authentifizierung eines Systems
herangezogen werden. Eine Implementierung dieses Verfahrens wird im folgenden Kapitel be-
schrieben.

3.3 Transport Layer Security (TLS) / Secure Sockets
Layer (SSL)

Eine wichtige Implementierung des Public-Key-Verfahrens ist SSL/TLS und ist in RFC 2246
[Die99] spezifiziert. SSL steht für Secure Socet Layer und wurde von der IETF 1999 definiert. Der
Nachfolger von SSL ist TLS (Transport Layer Security), welches auf SSL v3 aufbaut, damit je-
doch nicht kompatibel ist. SSL/TLS sitzt zwischen dem Application Layer und dem Transport
Layer und wird hauptsächlich zusammen mit TCP verwendet. Weiterhin unterstützt SSL/TLS eine
Vielzahl an Verschlüsselungs- und Komprimierungsmethoden und verwendet sowohl symmetri-
sche als auch asymmetrische Verschlüsselung. Das SSL/TLS-Protokoll besteht aus zwei wichtigen
und voneinander unabhängigen Prozessen: Der Authentifizierung und der Datenstromverschlüsse-
lung.

Das SSL/TLS-Protokoll funktioniert folgendermaßen: Ein Client versucht, eine Verbindung zu ei-
nem mit SSL/TLS gesicherten Service herzustellen. Der Client fordert die Identität des Servers an,
der eine Kopie seines SSL/TLS-Zertifikats an den Client sendet. Der Client überprüft, ob das
SSL/TLS-Zertifikat glaubwürdig ist. Bei erfolgreicher Überprüfung sendet er eine Nachricht an
den Server. Der Server sendet anschließend eine digital signierte Bestätigung zurück, um eine

13

Sicherheit

SSL/TLS-verschlüsselte Sitzung einzuleiten. Danach sind Client und Server in der Lage, Daten
über einen verschlüsselten, privaten Kanal über das öffentliche Internet auszutauschen. Dieser Sit-
zungsschlüssel wird auch Session-Key genannt und ist ein gemeinsamer, geheimer Schlüssel, mit
dem Nachrichten verschlüsselt werden. Der Session-Key sorgt sowohl für Geheimhaltung als auch
für Integrität. Ein solcher Schlüssel wird nur so lange genutzt, wie der Übertragungskanal existiert.

3.4 HTTPS

HTTP ist ein Protokoll ohne eigene Sicherheitsmechanismen. Um Verbindungen abzusichern,
wird zusätzlich SSL/TLS eingesetzt. Erkennbar ist eine SSL/TLS geschützte HTTP-Verbindung
durch das angehängte „S“ – HTTPS. In Bezug auf das OSI7-Referenzmodell liegt TLS über
TCP/IP, aber unter dem HTTP-Protokoll. Daher wird SSL/TLS in der Regel der Darstellungs-
schicht zugeordnet. Im TCP/IP-Modell ist TLS oberhalb der Transportschicht und unterhalb der
Anwendungsschicht angesiedelt. Für die Anwendungen arbeitet TLS/SSL transparent. „HTTP o-
ver TLS“ ist in RFC 2818 spezifiziert [Res00].

Der Server muss über ein geeignetes Zertifikat verfügen. Dieses sollte von einer vertrauenswürdi-
gen Zertifizierungsstelle stammen. Reine HTTP-Verbindungen kommunizieren standardmäßig
über Port 80 oder 8080, während HTTPS i. d. R. Port 443 nutzt. Ein HTTP/TLS-Request basiert
auf referenzieren eines URI, wodurch dem Client der Hostname des Servers bekannt ist. Dadurch
ist der Client in der Lage, die Identität des Servers über die erhaltene Server-Zertifikats-Nachricht
zu verifizieren. Zunächst hat der Server bei einer SSL/TLS-Verbindung keine Kenntnis von der
Identität des Clients.

Unter einem Man-In-The-Middle-Angriff versteht man das Abfangen, das Einfügen, das Löschen
und die Modifikation von Nachrichten, sowie das Wiederholen alter Nachrichten und das Umlei-
ten von Nachrichten. Hiervon betroffen sind besonders anonyme Sessions. Beim Abhören von
Nachrichten besteht das Problem in der Übermittlung des gemeinsamen Geheimnisses. Schutz da-
vor kann man nur erreichen, wenn sich mindestens der Server authentifiziert und für die gemein-
same Kommunikation ein Sitzungsschlüssel erzeugt wird. Mit SSL/TLS ist eine sichere Ende-Zu-
Ende-Verschlüsselung und die Authentifizierung mindestens einer Seite möglich. SSL/TLS ist ro-
bust gegen Man-in-the-Middle Angriffe und ein Abhören von Nachrichten ist ebenfalls nicht mög-
lich, da der private Schlüssel nicht mit übertragen wird.

7
OSI model: http://en.wikipedia.org/wiki/OSI_model

14

Sicherheit

3.5 Fazit

Mit der Sicherung des Tranportkanals mit SSL/TLS sind die Anforderungen nach Integrität und
Vertraulichkeit eines verteilten Systems erfüllt. An dieser Stelle kann man bei der Betrachtung der
Problemstellung auf vorhandene Standards zurückgreifen. HTTP ist ein Klartextformat. Dies be-
zieht sich nicht nur auf die Anweisungen im Header, sondern insbesondere auch auf den Content
im Body. Anhand des Content-Types ist ein Mitleser in der Lage die übertragenen Daten abzugrei-
fen. Daher muss in dem hier zu betrachtenden System die Verwendung von SSL/TLS Grundvo-
raussetzung sein, damit zu übertragende Informationen nicht unbemerkt mitgelesen werden kön-
nen. Im REST/HTTP-Umfeld setzt man vorwiegend auf transportbasierte Sicherheit auf Basis von
SSL/TLS [Til11, S. 131].

15

Szenarien zur Authentifizierung und Autorisierung

4 Szenarien zur Authentifizierung und Auto-
risierung
In diesem Kapitel werden vier verschiedene Szenarien zur Authentifizierung und Autorisierung für
Clients beschrieben. Zunächst werden einige Begriffe des Identitätsmanagements eingeführt. An-
schließend erfolgt eine kurze Einführung in grundsätzliche Datenstrukturen, die für die Beschrei-
bung der Szenarien erforderlich sind.

4.1 Identitätsmanagement

Man muss zwischen dem Identitätsbegriff in der Soziologie und der Informatik unterscheiden. Die
Soziologie beschäftigt sich mit dem Wesen von Identitäten, während in der Informatik andere As-
pekte eine Rolle spielen. In der Informatik repräsentiert eine Identität eine bestimmte Kombination
von Rollen und Eigenschaften eines Subjekts (physisch, kontextuell, logisch), das einen eindeuti-
gen Bezeichner hat. Eine Identität umfasst mindestens so viele Merkmale, dass ein Nutzer von an-
deren Nutzern eindeutig unterschieden werden kann [Mez08, S. 9].

Ziel des Identitätsmanagements ist der Schutz von Daten bzw. Ressourcen, d. h. man möchte wis-
sen, wer die Subjekte sind, welche Zugriffsrechte sie haben und was sie mit den Zugriffsrechten
machen. Das Identitätsmanagement umfasst alle notwendigen Maßnahmen, die erforderlich sind,
um Nutzer von IT-Systemen eindeutig zu identifizieren und ihnen die benötigten Zugriffsrechte zu
erteilen. Die Nutzer können natürliche Personen oder IT-Systeme sein. Die zu ergreifenden Maß-
nahmen sollten standardisierte und nachvollziehbare Prozesse sein [Mez08, S. 10].

Zugriffsberechtigungen sind nicht zwingend an natürliche Personen gebunden – ein Identitätsträ-
ger kann auch ein technischer Nutzer sein. Technische Berechtigungen, die keine manuellen Ein-
griffe erfordern, werden hierbei an IT-Systeme vergeben, während Berechtigungen mit manuellen
Vorgängen nur an natürliche Personen vergeben werden [Tso10, S. 25 f].

4.1.1 Authentifizierung und Autorisierung

Als Authentifizierung bezeichnet man die Verifikation einer von einer Entität behaupteten Identi-
tät. Authentifizierung und Integrität der Nachrichten gehören zusammen [Tan07, S. 397]. Authen-
tifizierung ist der Vorgang, bei dem bewiesen wird, dass ein Subjekt tatsächlich das Subjekt ist,
welches es vorgibt zu sein [Til11, S. 128].

16


Formal gesehen gehört das Verifizieren von Zugriffsrechten zur Zugriffskontrolle, während die
Autorisierung das Gewähren dieser Rechte darstellt. Die Authentifizierung geht der Autorisierung
unmittelbar voraus. Subjekte versenden Requests, um auf Objekten bestimmte Operationen auszu-
führen. Zugriffskontrolle bedeutet, alle Objekte gegen den Zugriff von Subjekten zu schützen, die
keine Rechte dazu besitzen. In der Regel wird die Autorisierung von der Entität durchgeführt, die
den Dienst zur Verfügung stellt. Rechte können aber auch von der anfordernden Stelle vergeben
werden. Autorisierung gehört formal zur Software Security.

4.1.2 Zugriffsberechtigung

Eine Zugriffsberechtigung hängt von zwei Faktoren ab: Dem Objekt und der Operation. Das zu
berechtigende Objekt, welches auch als Ressource bezeichnet wird und die zu berechtigende Ope-
ration, welche bei Inhaltsressourcen, die hier ausschließlich betrachtet werden sollen, meist aus ei-
nen einheitlichen Satz von Operationen besteht (z. B. GET, PUT, POST und DELETE) [Tso10,
S167 f].

Eine Möglichkeit, Berechtigungssysteme in Applikationen umzusetzen, sind Zugriffskontrolllisten
(Access Control Lists – ACLs), die z. B. im Microsoft Betriebssystem für den Zugriff auf Dateien
verwendet werden. Eine Zugriffskontrollliste ist an ein Objekt gebunden und beinhaltet eine Liste
von Subjekten und deren Zugriffsrechte. Die Information über die Subjekte und deren Zugriffs-
rechte für eine konkrete Ressource ist jederzeit verfügbar und einfach zu verwalten, was ideal für
eine verteilte Verwaltung von Berechtigungen ist. Aufwändig ist jedoch die Ermittlung der Menge
aller aktuellen Zugriffsrechte eines Subjekts.

4.1.3 Modellierung von Zugriffsrechten mit der Zugriffskontroll-
liste (ACL)

Die Umsetzung mit einer Zugriffskontrollliste erfolgt meist bei der nutzerbestimmten Zugriffskon-
trolle. Dabei erhält jedes Objekt eine eigene Liste von Subjekten mit den zugehörigen erlaubten
Methoden. Im Grunde bedeutet das, dass die Zugriffskontrollmatrix Spaltenweise auf die Objekte
verteilt wird (Abbildung 4-1) [Tan07, S. 415 f].

17


Abbildung 4-1 Beispiele von Zugriffskontrolllisten

Hier ist wieder der Umstand zu berücksichtigen, dass es sich bei dem zu betrachtenden System um
ein verteiltes System handelt und zentrale Berechtigungssysteme vermieden werden sollen. Daher
wird für die Aufgabenressourcen die identitätsbezogene Zugriffskontrolle zusammen mit der Zu-
griffskontrollliste (ACL) zur Modellierung gewählt. Jede Ressource erhält ihre eigene ACL.

4.1.4 Berechtigungsmodelle

Bei den Berechtigungsmodellen wird grundsätzlich zwischen dem zentralen und dem dezentralen
Berechtigungsmodell unterschieden [Tso10, S. 109 ff].

Beim zentralen Berechtigungsmodell werden die Ressourcen und ihre Berechtigungen in einem
zentralen Repository gehalten. Benutzer- und Rechteverwaltung werden z. B. in einem LDAP-
(Lightweight Directory Access Protocol) fähigen Repository/Verzeichnisdienst ausgelagert. Mit
dem zentralen Berechtigungsmodell ergibt sich das Single-Point-Of-Failure8 Problem, welches
entsprechend abzusichern ist. Ein zentrales Modell bietet jedoch auch eine höhere Sicherheit, da
gewährleistet ist, dass nicht autorisierte Personen keine Änderungen vornehmen können [Tso10, S.
109 f].

Beim dezentralen Berechtigungsmodell führt jede Ressource ihren eigenen kleinen Datenspeicher
mit den benötigten Berechtigungsdaten. Der Vorteil ist, dass die Ressource unabhängig von ande-
ren Systemen Zugriffsberechtigungen ermitteln kann. Nachteil ist, dass Identitäten oder Rollen an
jeder Ressource angelegt und bekannt gemacht werden müssen. Die Koordination und Vereinheit-
lichung in der Gesamtarchitektur stellt eine Herausforderung dar [Tso10, S. 111ff].

8
Single Point of Failure http://en.wikipedia.org/wiki/Single_point_of_failure

18


Das hier zu behandelnde System ist ein hochverteiltes System mit der Forderung, von keiner zent-
ralen Instanz abhängig zu sein. Daher wird hier das dezentrale Berechtigungsmodell gewählt.

4.2 Einführung in die Szenarien

Die folgenden Szenarien beziehen sich auf ein offenes System, bei dem neue Ressourcen geschützt
werden sollen. Hierbei ist zu untersuchen, auf welchem Wege sich Clients gegenüber den Servern
authentifizieren und autorisiert werden. Dabei ist der Authentifizierungsvorgang eine querschnitt-
liche Funktionalität. Daher wird bei der Betrachtung der Szenarien von der Authentifizierung abs-
trahiert und zunächst davon ausgegangen, dass die behauptete Identität die tatsächliche Identität
ist. Die eigentliche Authentifizierung wird in Kapitel 5 beschrieben. Alle Lösungsansätze sollten
dem Robustheitprinzips nach Postel folgen: „… be conservative in what you do, be liberal in what
you accept from others.“ [Inf81, Kapitel 2.10].

Die Szenarien werden jeweils in folgende Abschnitte unterteilt:

1. Ausgangssituation
2. Problem
3. Lösung
4. Umsetzung

In dem Beispiel zu den beschreibenden Szenarien werden zwei Ressourcentypen von Bedeutung
sein: Die Aufgabe und das Dokument. Ausgangspunkt ist ein Nutzer, der ein Dokument auf sei-
nem Server anlegt. Weiterhin legt er auf seinem Server eine initiale Aufgabe – die Root-Aufgabe –
an. Innerhalb dieser Aufgabe ist das Dokument verlinkt. Der initiale Nutzer hat natürlich die Be-
rechtigung, alle Methoden auf dem Dokument auszuführen. Nun entschließt er sich, anderen Nut-
zern Aufgaben für die Bearbeitung des Dokuments zuweisen. Hierzu legt er eine Aufgabe auf dem
Aufgabenserver des Mitarbeitenden an und entscheidet, welche Operationen der Mitarbeitende
ausführen darf. Der Mitarbeitende hat wiederum die Möglichkeit, die ihm zugewiesene Aufgabe
zu delegieren und mögliche Operationen an den neuen Mitarbeitenden durchzureichen oder einzu-
schränken. Wenn dann über den Link zum Dokument innerhalb einer beliebig oft delegierten Auf-
gabe auf das Dokument zugegriffen wird, müssen die Zugriffsreche ermittelt werden.

4.2.1 Metadaten der Ressourcen

Zu jeder Ressource werden Metadaten gespeichert, die nicht zu der eigentlichen Repräsentation
gehören. Neben der ACL, die die zugriffsberechtigten Subjekte und deren zugewiesenen Operatio-

19


nen enthält, müssen noch die Informationen zur Delegation gehalten werden. Bei der Delegation
wird in den beschriebenen Szenarien unterschieden, wer Delegierender ist und wer eine delegierte
Aufgabe erhält.

Metadaten:

 Ressource Owner
Der Ressource Owner ist der Besitzer der Ressource und die Identität, welche die Res-
source angelegt hat. Für die beschriebenen Szenarien wird der Ressource Owner in Form
eines OpenID-URIs angegeben.
 Access Control List (ACL)
In der ACL einer Ressource werden für die zugriffsberechtigten Identitäten die Operatio-
nen, welche sie ausführen dürfen, angegeben.
 Parent Ressource
Die Parent Ressource gibt diejenige Ressource an, von der die Delegation ausging, bzw.
die Aufgabe, die delegiert wurde. Ist die Aufgabe direkt dem zu bearbeitenden Dokument
zugeordnet und somit Root-Ressource, ist dieser Eintrag leer. Die Parent-Ressource wird
als URI angegeben.
 Child Ressource
Die Child Ressource ist eine Liste von URIs und gibt an, wohin die aktuelle Aufgabe de-
legiert wurde. Ist die Aufgabe nicht delegiert worden, ist die Liste leer. Weiterhin werden
an jedem Eintrag die zugewiesenen Operationen – ähnlich einer ACL – geschrieben.

Die Metadaten gehören nicht zur Repräsentation der Ressource. Sie werden lediglich als zusätzli-
che Daten an der Ressource persistiert.

4.2.2 Custom Header Fields:

Das HTTP-Protokoll erlaubt die Definition eigener Header-Fields. Diese werden in der Regel mit
einem vorangestellten „X-“9 gekennzeichnet. Da die Metadaten nicht zur Repräsentation einer
Ressource gehören, aber teilweise die Notwendigkeit besteht, Metadaten in den Nachrichten zu
transportieren, werden für die zu beschreibenden Szenarien zusätzliche Header-Fields eingeführt.
Um die, der hier vorliegenden Anwendung zugeordneten, Header-Fields von anderen zusätzlichen

9
HTTP Gallery http://www.httpwatch.com/httpgallery/headers/

20


Header-Fields unterscheiden zu können, wird hier einheitlich „X-CustomHeader“ vorangestellt.
Diese sind wie folgt:

 X-CustomHeader_Client_Identity
Gibt die behauptete Identität des Senders an. Da hier zunächst keine konkreten Authenti-
fizierungsmethoden genutzt werden sollen, wird davon ausgegangen, dass die hier be-
hauptete Identität die tatsächliche ist. Dieser Header wird bei jedem Request mitgesendet.
 X-CustomHeader_Parent_Ressource
Gibt die Ressource an, die delegiert wurde. Dieser Header wird im Request mitgesendet,
wenn über den Link in einer Aufgabe auf ein Dokument zugegriffen wird. Der Dokumen-
tenserver ermittelt über diesen Header die Zugriffsrechte des Nutzers.
 X-CustomHeader_Child_Ressource
Zur Ermittlung der Zugriffsberechtigung, gibt der Dokumentenserver beim Request an
die Parent-Aufgabe in diesem Header die angebliche Child Ressource an. Eine erfolgrei-
che Anfrage quittiert der Aufgabenserver ebenfalls mit diesem Header, zusammen mit
dem folgenden Header.
 X-CustomHeader_Child_Ressource_Operations
Der Aufgabenserver gibt hier im Response an den Dokumentenserver die zugelassenen
Operationen der Child Ressource an.
 X-CustomHeader_Ressource_Name
Gibt die Ressource an, von der die Zielressource aus verlinkt ist, hier die Aufgabe.

Die Anwendung der Parameter soll im Folgenden näher betrachtet werden. Dabei werden einige
Parameter in den Nachrichten zunächst verwendet, ohne direkt erläutert zu werden. Die Erläute-
rung erfolgt in dem darauffolgenden Kontext/Szenario.

4.3 Szenario 1: Anlage und anschließende autorisierte
Anfrage einer geschützten Ressource

4.3.1 Ausgangssituation

Die Komponente A kennt den URI der Listenressource RI einer Komponente B und möchte über
diese Ressource die Anlage einer neuen Ressource RN veranlassen, indem sie eine initiale Reprä-
sentation der neuen Ressource an die Listenressource RI sendet. Komponente A und Komponente
B kennen sich gegenseitig nicht und teilen auch kein Geheimnis. Weiterhin verwenden sie kein
gemeinsames Authentifizierungssystem. Jeder kann auf Komponente B über Listenressource RI

21


eine neue Ressource RN anlegen. Anschließend möchte Komponente A Ressource RN autorisiert
anfragen, d. h. über GET abrufen, mit PUT aktualisieren und eventuell mit DELETE löschen.
Komponente A aktualisiert die Aufgabe mit einem PUT-Request an die Ressource RN (Abbildung
4-2). RN entspricht der zuvor beschriebenen delegierten Aufgabe.

Abbildung 4-2 Anlage und anschließende autorisierte Anfrage einer geschützten Ressource

4.3.2 Problem

Komponente A soll später zur Interaktion mit RN berechtigt sein (PUT, DELETE). Da Komponen-
te B jedoch keine Authentifizierungsinformationen über Komponente A besitzt, muss die initiale
Kommunikation so gestaltet werden, dass Komponente B bei einem späteren Request Komponente
A authentifizieren und autorisieren kann.

4.3.3 Lösung

Um die neue Ressource RN anzulegen, sendet Komponente A die initiale Repräsentation der Res-
source im Body zusammen mit Metadaten im Header der Nachricht mit einem POST an die Lis-
tenressource RI. Die Metadaten müssen für dieses Szenario den Identifier des Clients enthalten.
Für Authentifizierungsinformationen wird bei manchen Authentifizierungsverfahren der Authori-
zation- und der WWW-Authenticate-Header herangezogen. Dies ist jedoch nicht zwingend der
Fall. Um von einem konkreten Authentifizierungsverfahren zu abstrahieren, wird hier der Identifi-
er in einem benutzerdefinierten Header mitgeführt.

Komponente B legt die neue Ressource RN unter einem neuen Identifier an. In den Metadaten der
Ressource RN wird Komponente A als Ressource Owner eingetragen und erhält damit alle Zu-
griffsrechte (GET, PUT, DELETE). Komponente B übermittelt den URI der neuen Ressource RN

22


im Location-Header des Responses an Komponente A. Beim autorisierten Zugriff wird Kompo-
nente A über eine noch zu spezifizierende Authentifizierungsmethode authentifiziert und über die
ACL der Ressource RN autorisiert.

4.3.4 Umsetzung

Zur Umsetzung des Anwendungsfalls wird eine neue Ressource R N angelegt. Dies erfolgt mit der
POST-Methode. Die im Request angesprochene Ressource R I ist die übergeordnete Listenres-
source der neu anzulegenden Ressource RN (Abbildung 4-3).

Komponente A Komponente B

POST

Location...

Abbildung 4-3 Sequenzdiagramm - Anlage einer geschützten Ressource

Der URI www.bob.example/tasks entspricht der Ressource RI der Komponente B. In den Metada-
ten von Listenressource RI auf Komponente B ist eine ACL hinterlegt (Abbildung 4-4). Hier sind
zwei berechtigte Nutzer aufgeführt: <All> und www.bob.example. <All> steht für alle authentifi-
zierten Nutzer. Jeder authentifizierte Nutzer darf ein POST ausführen. Der Nutzer
www.bob.example repräsentiert Komponente B. www.bob.example ist ebenfalls berechtigt ein
POST durchzuführen, kann jedoch auch über GET die Listenressource R I abrufen.

Abbildung 4-4 ACL der Ressource www.bob.example/tasks/

Diese Form der Autorisierung ist eine identitätsbezogene Zugriffskontrolle, bei der jedes Objekt
nach dem Eigentümerprinzip einen Besitzer (Resource Owner) erhält. In der Regel ist dies der Er-
steller des Objekts. Der Ersteller oder Besitzer eines Objekts vergibt die initialen Zugriffsrechte.

23


Bei jedem Zugriff eines Subjekts auf ein Objekt werden die zugeordneten Zugriffsrechte ermittelt.
Die Entscheidung, ob und mit welchen Zugriffsrechten auf ein Objekt zugegriffen werden darf,
wird allein auf der Basis der Identität des Subjekts getroffen. Ein Subjekt, das Zugriffsrechte auf
ein Objekt besitzt, kann diese an ein anderes Subjekt weiterreichen. Dadurch kann ein anderes
Subjekt Zugriffsrechte auf ein Objekt erhalten, ohne dass der Ersteller oder Besitzer hier zustim-
men muss. Die identitätsbezogene Zugriffskontrolle wird üblicherweise mit Zugriffskontrolllisten
(ACLs) implementiert, die an jedem Objekt separat gespeichert werden [Tso10, S. 162].

Der erste Request von Komponente A an Ressource RI auf Komponente B zur Anlage einer neuen
Ressource sieht wie folgt aus:

POST /tasks HTTP/1.1
Host: www.bob.example
X-CustomHeader_Client_Identity: arbeitgeber.example/Alice
X-CustomHeader_Parent_Ressource:
http://arbeitgeber.example/Alice/tasks/task_root

«Repräsentation der Ressource RN»

Optional könnte hier – wie bereits angesprochen – ein Authentifizierungprozess erfolgen. Wichtig
ist es, die Identität des Clients festzustellen, um den Ressource Owner für Ressource RN bestim-
men zu können. Wir gehen davon aus, dass Komponente B die neue Ressource RN erfolgreich an-
legen kann und folgenden Response schickt:

HTTP/1.1 201 Created
Location: http://www.bob.example/tasks/task_0716

Der URI der neuen Ressource RN entspricht dann dem URI der Listenressource plus einem ange-
hängten Identifier für die neue Aufgabe „task_0716“. Ist die Authentifizierung, Autorisierung und
Anlage der Ressource RN nicht erfolgreich, sind mögliche Response-Codes 200 (OK) oder 204
(No Content), in Abhängigkeit davon, ob im Body beschreibender Kontent mitgeliefert wird oder
nicht. Nach der Anlage der Ressource RI hat die in Abbildung 4-5 dargestellte ACL.

24


Abbildung 4-5 Metadaten der Ressource www.bob.example/tasks/task_0716

Arbeitgeber.example/Alice ist der Ressource Owner und hat daher alle Berechtigungen, d. h. ar-
beitgeber.example/Alice kann die Ressource anfordern, verändern und löschen. www.bob.example
kann die Ressource anfordern und verändern, jedoch nicht löschen. Jeder authentifizierte Nutzer
darf Metadaten über die Operation HEAD abrufen, was noch von Bedeutung sein wird.

Wenn arbeitgeber.example/Alice auf die Ressource RN zugreifen möchte, muss er sich authentifi-
zieren. Nach erfolgreicher Authentifizierung muss Komponente B noch autorisieren, indem sie in
der ACL, die in den Metadaten der Ressource RN hinterlegt ist, nachsieht, welche Methoden ar-
beitgeber.example/Alice ausführen darf. Ist die Prüfung erfolgreich, wird der Zugriff auf die Res-
source RN gewährt (Abbildung 4-6).

Komponente A Komponente B

GET

Abbildung 4-6 Sequenzdiagramm - Autorisierte Anfrage einer geschützten Ressource

GET-Request von Komponente A an Ressource RN auf Komponente B:

GET /tasks/task_0716 HTTP/1.1
X-CustomHeader_Ressource_Name:

25


Komponente B führt die Authentifizierung und Autorisierung durch. Lt. Abbildung 4-4 ist arbeit-
geber.example/Alice berechtigt ein GET auszuführen. Daher antwortet Komponente B wie folgt:

Response:

HTTP/1.1 200 Ok
Content-Type: application/xhtml+xml


Äquivalenter PUT-Request von Komponente A an Ressource RN auf Komponente B:

PUT /tasks/task_0716 HTTP/1.1


Response:

HTTP/1.1 204 No Content

Äquivalenter DELETE-Request von Komponente A an Ressource RN auf Komponente B:

DELETE /tasks/task_0716 HTTP/1.1

Response:

HTTP/1.1 204 No Content

Nach erfolgreicher Anlage der Ressource RN kann Komponente A autorisierte Anfragen durchfüh-
ren, indem sie zunächst authentifiziert wird (hier nicht dargestellt) und dann über die ACL ermit-
telt wird, dass sie als Ressource Owner zur Ausführung der Methoden GET, PUT und DELETE
berechtigt ist.

26


4.4 Szenario 2: Aufbau weiterer Verbindungen zu ge-
schützten Ressourcen


Dieses Szenario ähnelt dem Szenario 1, jedoch bietet Komponente A eine weitere Ressource R P
an, das in der Aufgabe, bzw. hier in Ressource RN verlinkte Dokument. Nach dem Erstellen der
Ressource RN, soll die Komponente B in der Lage sein, nach erfolgreicher Authentifizierung die
Berechtigung zu erhalten, auf Ressource RP auf Komponente A zuzugreifen. Die von Komponente
A angelegte Ressource RN beinhaltet einen Link auf Ressource RP auf Komponente A. Komponen-
te B möchte diesem Link folgen und autorisierte Anfragen auf R P durchführen.

4.4.2 Problem

Da die Komponente B zunächst nur den URI der Ressource RP der Komponente A kennt, muss die
Kommunikation so erweitert werden, dass die Komponente A Komponente B authentifiziert und
autorisiert. RP ist ebenfalls eine geschützte Ressource, deren Methoden eine Authentifizierung und
Autorisierung erfordern.

4.4.3 Lösung

Komponente A hat vor der Anlage der Ressource RN eine Root-Ressource auf sich selber angelegt,
deren Metadaten in Abbildung 4-7 angegeben sind.

Abbildung 4-7 Metadaten der Ressource arbeitgeber.example/Alice/tasks/task_root

Ressource Owner ist arbeitgeber.example/Alice selber und arbeitgeber.example/Alice ist auch der
einzige Zugriffsberechtigte auf diese Ressource. Als Child Ressource ist
www.bob.example/tasks/task_ 0716 eingetragen, Ressource RN aus Szenario 1. Die beiden Res-
sourcen stehen also in einer hierarchischen Beziehung zueinander. Weiterhin ist angegeben, dass

27


die Berechtigungen für die Methoden GET und PUT an die Ressource
www.bob.example/tasks/task_ 0716 delegiert wurden.

4.4.4 Umsetzung

Die Ressource RP entspricht dem URI http://arbeitgeber.example/Alice/docs/How_to_get_Tasks.
Komponente A folgt dem in Ressource RI angegebenen Link zur Ressource RP unter dem URI
http://arbeitgeber.example/Alice/docs/How_to_get_Tasks (Abbildung 4-8).

Abbildung 4-8 Zugriff auf die geschützte Ressource RP

Request von Komponente B an Ressource RP:

GET /Alice/docs/How_to_get_Tasks HTTP/1.1
Host: arbeitgeber.example
X-CustomHeader_Client_Identity: www.bob.example
http://www.bob.example/tasks/task_0716
X-CustomHeader_Parent_Ressource: arbeit-
geber.example/Alice/task_root

Komponente A führt zunächst den Authentifizierungsvorgang durch. Da Komponente A nicht er-
kennen kann, aus welcher Aufgabe der Link gefolgt wurde, muss diese Information über den Hea-
der X-CustomHeader_Ressource_Name mitgegeben werden. Weiterhin wird im Header X-
CustomHeader_Parent_Ressource die Parent Ressource arbeitgeber.example/Alice/task_root an-
gegeben. Damit behauptet Komponente B gegenüber Komponente A, dass die ursprüngliche Auf-
gabe mit der Root-Ressource in Beziehung steht und von dieser delegiert wurde. Da die Parent-
Ressource ebenfalls auf Komponente A liegt, kann Komponente A über serverinterne Methoden-
aufrufe ermitteln, dass die Aufgabe www.bob.example/tasks/task_ 0716 tatsächlich von ihr dele-
giert wurde und die Berechtigungen für GET und PUT erteilt wurden (Abbildung 4-7). Kompo-
nente A autorisiert Komponente B die Methode GET auszuführen.

Es erfolgt der Response von Komponente A:

28


HTTP/1.1 200 Ok

«Repräsentation der Ressource RP»

Während die Autorisierung in Szenario 1 aufgrund der Identität erfolgte, haben wir es hier mit ei-
ner Zugriffskontrolle zu tun, die vom System aufgrund der gelieferten Daten ermittelt wird. Die
Autorisierungsinformationen werden nicht am Objekt gespeichert. Dieses Verfahren erlaubt eine
beliebig verzweigte Delegation der Aufgaben, wie wir in Szenario 3 sehen werden.

4.5 Szenario 3: Delegation


Dieses Szenario erweitert Szenario 2 durch Delegation. Komponente B, soll den Zugriff auf Res-
source RP auf Komponente A an eine dritte Komponente C delegieren (Abbildung 4-9).

4.5.2 Problem

Komponente B muss in der Lage sein, der Komponente C alle Rechte einzuräumen, die erforder-
lich, um Zugriffe auf Ressource RP auf Komponente A zu ermöglichen. Eine Delegation des Zu-
griffsrechts auf Ressource RN von Komponente C an eine Komponente D sollte analog möglich
sein.

29


Abbildung 4-9 Delegation

Updates für Ressource RN auf Komponente B sollen automatisch an die Ressource RD auf Kom-
ponente C weitergeleitet werden. Außerdem muss es Bob möglich sein, die Delegation zurück zu
nehmen, bzw. wenn RN auf Komponente C gelöscht wird, müssen die Rechte ebenfalls entzogen
werden.

4.5.3 Lösung

Im Folgenden soll eine Lösungsmöglichkeit mit einer Baum-Berechtigungsstruktur beschrieben
werden. In Kapitel 4.2.1 wurden die Metadaten Parent Ressource und Child Ressource vorgestellt.
Die Parent Ressource gibt an, von welcher Ressource aus delegiert wurde. Child Ressource ist eine
Listenressource und gibt an, an welche Ressourcen delegiert wurde. An der Child Ressource steht
weiterhin, welche Rechte delegiert wurden, d. h. die erlaubten HTTP-Verben. Die Baum-Struktur
ist in Abbildung 4-10 dargestellt.

30


Abbildung 4-10 Berechtigungsbaum

Ressource RR ist die Root-Ressource und befindet sich in den hier beschriebenen Szenarien auf
Komponente A. Ressource RR hat keine Parent Ressource und ist Ressource Owner der Ressource
RP. In Szenario 1 wurde Ressource RR an Komponente B delegiert, indem Ressource RN erzeugt
wurde. Dabei wurde RN als Child Ressource in den Metadaten von Ressource RR und in den Meta-
daten von Ressource RN auf Komponente B wurde RR als Parent Ressource eingetragen. In dem
hier beschriebenen Szenario erfolgt nun eine Delegation von Ressource RN auf Komponente B an
Komponente C. Die neue Ressource auf Komponente C ist dann RD. Dabei wird an Ressource RN
Ressource RD als Child Ressource geschrieben und an Ressource RD Ressource RN als Parent
Ressource.

An den Child Ressource Parameter werden weiterhin die erlaubten Operationen, bzw. HTTP-
Verben geschrieben. Welche Berechtigungen an Ressource RP delegiert werden, entscheidet der
Nutzer der Komponente B. Die Information, welche Rechte Komponente B selber besitzt, ist an
Ressource RN nicht verzeichnet. Man könnte sich vorstellen, einen zusätzlichen Parameter für die
erlaubten Operationen auf Ressource RP einzuführen, dieser hätte dann aber nur informativen Cha-
rakter, da die an der Parent-Ressource eingetragenen erlaubten Operationen für die Berechtigungs-
erteilung maßgeblich sind.

31


Ressource RD auf Komponente C möchte auf Ressource RP auf Komponente A zugreifen. Dabei
sendet sie den Wert des Parent Ressource Parameters aus ihren Metadaten mit. Komponente A
fragt nun unter dem URI aus dem Parameter Parent Ressource an, ob eine noch gültige Delegation
besteht und welche Operationen delegiert wurden. In dem in Abbildung 4-11 skizzierten Fall, er-
hält Komponente A von Komponente B die Antwort, dass die Delegation gültig ist und die HTTP-
Verben GET, PUT und DELETE an Ressource RD auf Komponente C delegiert wurden. An dieser
Stelle kann die Komponente A aber noch nicht auf die ermittelten Informationen vertrauen, weil ja
im Grunde jeder behaupten kann, dass er Delegator der Ressource ist und beliebige Rechte verge-
ben. Wäre das Protokoll hier beendet, wäre vielfältiger Missbrauch denkbar. Daher übermittelt
Ressource RN auf Komponente B weiterhin den URI zur eigenen Parent Ressource.

Komponente A fragt also wiederum bei der Parent Ressource von Ressource RN an, ob eine gülti-
ge Delegation besteht und mit welchen Operationen. Parent Ressource von RN ist RR auf Kompo-
nente A. Ressource RR auf Komponente A gibt an, dass eine gültige Delegation besteht (weil RN
als Child Ressource eingetragen ist) und dass die Operationen GET und PUT delegiert wurden.
Ressource RP auf Komponente A erkennt weiterhin, dass es sich um die Root-Ressource handelt,
da der Ressource Owner der Ressource RR auch Ressource Owner der Ressource RP ist und auf
derselben Komponente liegt.

Nun hat Komponente A jedoch einmal die erlaubten Operationen GET und PUT erhalten und ein
anderes Mal die Operationen GET, PUT und DELETE. Grundsätzlich können nur solche Rechte
delegiert werden, die man auch selber besitzt. Daher wird hier die kleinste Schnittmenge gebildet
und Komponente A stellt fest, dass Komponente C mit Operationen GET und PUT auf Ressource
RP ausführen darf.

32


Abbildung 4-11 Berechtigungsbaum mit Operationen

Eine Delegation kann zurückgenommen werden, indem die Parent Ressource die Child Ressource
selber löscht. Bezogen auf Abbildung 4-11würde also z. B. die Ressource RR die Ressource RN lö-
schen. Damit wäre die Delegation aufgehoben. Ressource RN hatte aber ebenfalls die Rechte an
Ressource RD delegiert. Ressource RR hat keine Zugriffsrechte auf Ressource RD, daher muss Res-
source RN ihrerseits Ressource RD löschen. Da es sich bei den Komponenten um Server handelt, ist
dieses Vorgehen denkbar, wird hier jedoch nicht weiter beschrieben. Ein weiterer Vorteil dieses
Ansatzes ist, dass wenn an einer beliebigen Stelle im Pfad eine Ressource ausfällt, alle Delegatio-
nen ebenfalls nicht mehr gültig sind, da die Kette unterbrochen wird. Es ist keine zentrale Kontrol-
linstanz erforderlich, die Rechte verwaltet.

4.5.4 Umsetzung

Im ersten Schritt delegiert Ressource RN auf Komponente B den Zugriff auf Ressource RP auf
Komponente A, indem sie eine neue Ressource RD auf Komponente C anlegt. Dies erfolgt durch
einen POST an die Listenressource RK auf Komponente C, wobei eine initiale Repräsentation von
RD im Body übermittelt wird (Abbildung 4-12).

33


Komponente B Komponente C

POST

Location...

Abbildung 4-12 Sequenzdiagramm - Anlage einer geschützten Ressource

Der erste Request von Komponente B an Komponente C sieht wie folgt aus:

Host: arbeitgeber.example/Carol
«Repräsentation der Ressource RD»

Optional könnte hier – wie bereits angesprochen – ein Authentifizierungsprozess erfolgen. Wichtig
ist die Identität des Clients im X-CustomHeader_Client_Identity, um den Ressource Owner für
Ressource RN zu bestimmen. Wir gehen davon aus, dass Komponente B die neue Ressource R N er-
folgreich anlegen kann und folgenden Response schickt:

Location: http://arbeitgeber.example/carol/tasks/task_0720

Der beschriebene Ablauf unterscheidet sich nicht wesentlich vom Ablauf aus Szenario 1. Nach
Anlage der neuen Ressource RD müssen an der Parent-Ressource RN die Child-Ressource RD und
die erlaubten Methoden eingetragen werden. Dies erfolgt seitens Komponente B programmatisch
ohne Nachrichtenaustausch (Abbildung 4-13). Die Metadaten für die neu angelegte Ressource er-
geben sich aus Abbildung 4-14.

34


Abbildung 4-13 Metadaten der Ressource www.bob.example/tasks/task_0716

Abbildung 4-14 Metadaten für die Ressource arbeitgeber.example/Carol/tasks/task_0720

Weiterhin soll Komponente B autorisierte Anfragen auf die delegierte Aufgabe RD auf Komponen-
te C ausführen können. Der Lösungsansatz entspricht ebenfalls dem aus Szenario 1 und soll hier
nur für GET dargestellt werden.

Erster Request von Komponente B an Ressource RD auf Komponente C:

GET /carol/task_0720 HTTP/1.1

Response:

HTTP/1.1 200 Ok

«Repräsentation der Ressource RD»

Im nächsten Schritt soll der Zugriff auf eine geschützte Ressource über Dritte erfolgen. Request
von Komponente C an Ressource RP auf Komponente A:

35


GET /Alice/docs/How_to_get_Tasks HTTP/1.1
X-CustomHeader_Client_Identity: arbeitgeber.example/carol
http://arbeitgeber.example/carol/tasks/task_0720

Komponente A fragt nun bei der Ressource www.bob.example/tasks/task_0716 auf Komponente
B an, ob die Rechte wirklich delegiert wurden. Der Request von Komponente A an Ressource R N
sieht wie folgt aus:

HEAD /tasks/task_0716 HTTP/1.1
X-CustomHeader_Child_Ressource:

Hier wird erstmalig zum Abrufen der Metadaten die HEAD-Methode genutzt, die bereits in Abbil-
dung 4-5 Metadaten der Ressource www.bob.example/tasks/task_0716, Abbildung 4-13 Metada-
ten der Ressource www.bob.example/tasks/task_0716 und Abbildung 4-14 Metadaten für die Res-
source arbeitgeber.example/Carol/tasks/task_0720 angegeben wurde. Die Autorisierung erfolgt bei
den Aufgaben-Ressourcen identitätsbezogen. Da jedoch die Aufgabe die Identität der Komponente
A nicht kennt, kann sie auch nicht aufgrund dieser eine Berechtigung erteilen. Daher ist das Abru-
fen der Header-Informationen über die HEAD-Methode allen Nutzern erlaubt. Komponente B er-
mittelt nun, ob und welche Rechte an Komponente C delegiert wurden. Es erfolgt folgender
Response:

HTTP/1.1 200 Ok
http://arbeitgeber.example/Alice/tasks/task_0712
X-CustomHeader_Child_Ressource_Operations: GET,PUT,DELETE

Komponente A stellt fest, dass RN keine Root-Ressource ist und fragt als nächstes unter dem URI
aus dem Parameter Parent Ressource erneut an. Komponente A erkennt, dass es sich bei der ange-
fragten Ressource um die Root-Ressource handelt, z. B. anhand der Tatsache, dass sie auf demsel-
ben Host liegt, wie das Dokument oder weil am Dokument die Root-Ressource eingetragen ist. Es
erfolgt folgender Request:

36


HEAD /tasks/task_0712 HTTP/1.1
Host: arbeitgeber.example/Alice

Der Response erfolgt wie folgt:

HTTP/1.1 200 Ok
X-CustomHeader_Child_Ressource_Operations: GET,PUT

Nun hat Komponente A einmal die erlaubten Operationen GET, PUT und DELETE im Response
erhalten und dann nur GET und PUT. Bei der Weitergabe von Rechten sollte der Grundsatz ver-
folgt werden, dass nur die Rechte weitergegeben werden können, die man auch selber besitzt.
Komponente A muss also die kleinste Schnittmenge bilden und autorisiert Komponente C nun für
die Operationen GET und PUT. Der ursprüngliche Request von Komponente C an Komponente A
war ein GET. Daher antwortet Komponente A wie folgt:

HTTP/1.1 200 Ok
«Repräsentation der Ressource RP»

An dieser Stelle wäre denkbar, dass ein Sitzungsstatus gehalten wird, in dem die ermittelten Rech-
te für folgende Requests persistiert werden. Dies kann in Form eines Cookie geschehen.

4.6 Szenario 4 - Massendelegation


Komponente B veranlasst, dass die Ressource RN von Komponente B an mehrere Instanzen der
Komponente C gepostet wird. Updates, die Komponente B dann über RN bekommt, werden an alle
Instanzen der Komponente C weitergegeben. Dies wurde in Abbildung 4-10 Berechtigungsbaum
bereits kurz skizziert.

37


4.6.2 Problem

Authentifizierung, Umsetzung und Nachrichtenfluss erfolgen analog zu Szenario 3. Beim Zugriff
auf die Ressource RP auf Komponente A müssen Schutzmechanismen zur Nebenläufigkeitskon-
trolle implementiert werden, da die Wahrscheinlichkeit, dass mehrere Personen gleichzeitig ein
Dokument bearbeiten, sehr wahrscheinlich wird.

4.6.3 Lösung

Nebenläufigkeitskontrolle kann dadurch realisiert werden, dass ein Lock gesetzt wird, wenn ein
Nutzer das Dokument zum Bearbeiten abruft. Durch die lose Kopplung der Systeme bekommt die
Ressource RP nicht mit, wenn der Nutzer die Bearbeitung abbricht. Das Dokument bleibt für alle
anderen gesperrt.

Eine weitere Möglichkeit ist die einfache optimistische Nebenläufigkeitskontrolle. Dabei wird
beim Update, bzw. bei der PUT-Message zunächst geprüft, ob das Dokument zwischen dem Abru-
fen und dem PUT von einem anderen Bearbeiter gespeichert wurde. Dabei muss das Dokument
eine Version mitführen. Wurde das Dokument zwischenzeitlich von einem anderen Bearbeiter ge-
speichert, wird die Aktion abgebrochen. Ansonsten wird das Dokument gespeichert.

Es gibt Mechanismen, die das Zusammenführen von verschiedenen Änderungen unterstützen. Ein
Beispiel dafür ist CVS10. Hierauf wird nicht näher eingegangen.

4.7 Fazit

In den Lösungsansätzen der beschriebenen Szenarien wurden repräsentative Problemstellungen
behandelt, die in einer kooperativen Aufgabenverwaltung zur Bearbeitung von gemeinsam genutz-
ten Ressourcen auftreten können. Die zentrale Forderung, von keiner zentralen Instanz abhängig
zu sein, konnte erfüllt werden. Zur Delegation von Berechtigungen wurde eine Baumstruktur ge-
wählt. Ein standardisiertes Delegationsprotokoll ist OAuth, welches in Kapitel 6 näher untersucht
werden soll. Weiterhin wurde in den beschriebenen Szenarien die Authentifizierung nicht näher
betrachtet. Hierzu soll Kapitel 5 die wichtigsten Authentifizierungsmethoden beschreiben und ge-
geneinander abwägen und schließlich das OpenID-Protokoll näher behandeln.

10
Concurrent Versions System http://en.wikipedia.org/wiki/Concurrent_Versions_System

38

Authentifizierungsprotokolle

5 Authentifizierungsprotokolle
Bisher wurde die Authentifizierung für die dargestellten Szenarien in Kapitel 4 nicht näher be-
trachtet. In diesem Kapitel sollen mögliche Techniken zur Authentifizierung beschrieben und we-
sentliche Eigenschaften verglichen werden. Anschließend soll ein Authentifizierungsverfahren für
die in Kapitel 4 beschriebenen Szenarien gewählt und bewertet werden. Bewertungskriterien sind
hierbei, wie weit Protokolle von einer dritten Instanz abhängig sind und ob ein Kennwort weiter-
gegeben werden muss.

Im Wesentlichen wird bei den Authentifizierungsprotokollen zwischen den Challenge-Response-
Verfahren und der Authentifizierung über vertrauenswürdige Dritte unterschieden. Der Unter-
schied besteht darin, dass beim einfachen Challenge-Response-Verfahren nur Client und Server
beteiligt sind, während bei der Authentifizierung über vertrauenswürdige Dritte eine weitere In-
stanz, die Authentifizierungs-Autorität, beteiligt ist [Tso10, S. 127 ff].

Challenge-Response-Verfahren beschreiben einen Ansatz, wobei eine Partei bei der anderen eine
Antwort anfordert, die nur richtig sein kann, wenn die andere Partei den zugehörigen, geheimen
Schlüssel kennt. Bei den Challenge-Response-Verfahren wird zwischen symmetrischen und
asymmetrischen unterschieden. Beim symmetrischen Challenge-Response-Verfahren besitzen bei-
de Kommunikationspartner einen gemeinsamen geheimen Schlüssel, während bei dem asymmetri-
schen Challenge-Response-Verfahren die Kommunikationspartner jeweils ein eigenes Schlüssel-
paar besitzen. Bei diesem Schlüsselpaar wird der eine Schlüssel zum Verschlüsseln und der andere
zum Entschlüsseln genutzt.

5.1 Zertifikate

Zertifikate wurden bereits in Kapitel 3.2 zur Verschlüsselung des Transportkanals mit SSL/TLS
beschrieben. Die Authentifizierung per Zertifikat ist ein alternativer Authentifizierungsmechanis-
mus. Grundsätzlich wird hier zwischen Client- und Serverzertifikat unterschieden. In Kapitel 5.2
wird der Benutzername/Kennwort-Mechanismus beschrieben. Die Verwendung von Zertifikaten
ist wesentlich sicherer als die Verwendung von Benutzername/Kennwort-Kombinationen, da ein
Zertifikat einen eindeutigen Benutzernamen mit einer für diesen Benutzer spezifischen asymmetri-
schen Verschlüsselung verbindet. Ein entscheidender Unterschied besteht darin, dass der Benutzer
die verwendeten Schlüssel nicht auswendig kennen und selbst manuell angeben muss. Stattdessen
übernimmt dies der Web-Browser, welcher Zertifikate importieren und automatisch verwenden

39


kann. Daher sind Zertifikatsschlüssel in der Regel sehr viel länger als es Kennwörter aus prakti-
schen Gründen sein könnten.

Ein weiterer großer Vorteil ist, dass der private Schlüssel bei der Authentifizierung niemals selbst
übertragen wird, sondern lediglich Daten, die mit ihm verschlüsselt wurden. Selbst das Abfangen
von Abfragedaten würde einem Angreifer das Kennwort nicht offenbaren.

Ein digitales Zertifikat dient seinem Inhaber als Identitätsnachweis und wird von einer Zertifizie-
rungsstelle ausgestellt. Diese prüft die Identität des Antragstellers z. B. anhand von Ausweispapie-
ren. Um die Echtheit von digitalen Zertifikaten nachweisen zu können, werden diese von den Zer-
tifizierungsstellen digital signiert, so dass zur Durchführung der Überprüfung der öffentliche
Schlüssel und somit das Zertifikat der Zertifizierungsstelle benötigt wird.

Die Authentifizierung eines Servers gegenüber einem Client mittels Zertifikaten ist eine Vorstufe
der SSL/TLS-Verschlüsselung. Daher findet man die sogenannten Server-Zertifikate sehr häufig
vor. Anders herum kann sich aber auch ein Client gegenüber einem Server mit einen Client-
Zertifikat authentifizieren. Diese Form der Authentifizierung ist eher selten. Ein öffentlich ver-
wendetes Zertifikat muss ebenfalls von einer Zertifizierungsstelle signiert sein, was mit Kosten
verbunden ist. Wenn ein solches Zertifikat von einem Client verwendet wird, muss er es auf sei-
nem Rechner installieren. Dadurch ist der Missbrauch durch einen Mitbenutzer dieses Rechners
möglich. Wenn der Zertifikatsinhaber sein System wechselt, muss er das Zertifikat transportieren.
Dies sollte nicht über ein Netzwerk erfolgen, da sich ansonsten Dritte Besitz verschaffen könnten.
Installation und Weitergabe von Client-Zertifikaten ist somit aufwändig.

5.2 Basic- und Digest-Authentifizierung

Die einfachste Art der Authentifizierung ist die Basic- und Digest-Authentifizierung nach RFC
2617 [Fra99] über den Benutzernamen und ein Kennwort. Diese Methode basiert auf einer öffent-
lichen Information, dem Benutzernamen, und einer privaten Information, dem Kennwort, dem
gemeinsamen Geheimnis. Basic Authentifizierung sollte nur in Kombination mit einer SSL/TLS-
Verbindung zum Einsatz kommen, um Man-In-The-Middle-Attacken zu verhindern. Diese Kom-
bination ist eine beliebte Variante im E-Commerce [Til11, S. 131].

HTTP(S) bietet mit der Basic- und Digest-Authentifizierung einen einfachen Challenge-Response-
Authentifizierungsmechanismus an, der es dem Server erlaubt, beim Client Authentifizierungsin-
formationen abzufragen und dem Client erlaubt, die Authentifizierungsinformationen bereitzustel-
len. Basic- und Digest-Authentifizierung ist in RFC 2617 [Fra99] standardisiert.

40


Sowohl bei Basic- als auch bei Digest-Authentifizierung teilen Client und Server ein Geheimnis –
ein Kennwort. Die Basic-Authentifizierung bietet einen grundlegenden Zugriffsschutz, jedoch
wird das Kennwort im Klartext in der Nachricht mitversendet. Eine Alternative ist die Digest-
Authentifizierung. Bei der Digest-Authentifizierung wird im Gegensatz zur Basic-
Authentifizierung das Kennwort nicht im Klartext übermittelt, sondern als Hashcode – in der Re-
gel MD511.

Bei der Basic- und Digest-Authentifizierung wird ein Token genutzt, der das Authentifizierungs-
schema angibt, gefolgt von Komma-getrennten Schlüssel-Werte-Paaren, die die notwendigen Pa-
rameter transportieren. Die 401 (Unauthorized) Response-Nachricht wird vom Server genutzt, um
über den WWW-Authenticate-Header die Authentifizierungsinformationen beim Client abzufra-
gen [Fie99, Kapitel 10.4.2].

Das Basic-Authentifizierungs-Schema basiert auf dem Model, dass der Client sich gegen jede Re-
alm mit einem Benutzernamen und einem Kennwort authentifizieren muss [Fie99, Kapitel 11]. Die
Realm-Directive wird für alle Authentifizierungsschemas benötigt, die auf einem Request beruhen.
Der Realm-Wert in Verbindung mit der Root-URL definiert den Sicherheitsbereich. Geschützte
Ressourcen können in Sicherheitsbereiche eingeteilt werden. Ein Client kann sich beim Server au-
thentifizieren, indem er einen Authorization-Header im Request mitschickt. Dies muss nicht zwin-
gend auf ein 401 (Unauthorized) erfolgen, sondern er kann bei bekanntem Authentifizierungsver-
fahren auch beim initialen Request den richtigen Authorize-Header mitschicken [Fie99, Kapitel
14.8].

Der Nachrichtenfluss für Basic-Authentifizierung soll hier anhand von Szenario 1 beispielhaft
dargestellt werden. Der erste Request von Komponente A an Ressource R I auf Komponente B
sieht wie folgt aus:


11
Message-Digest Algorithm 5 http://de.wikipedia.org/wiki/Md5

41


Im Request ist kein Authentication-Header mit zusätzlichen Authentifizierungsinformationen an-
gegeben. Da es sich bei Ressource RI um eine geschützte Ressource handelt, erfolgt folgende
Challenge von Komponente B:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=”tasks@www.bob.example”

Daraufhin wiederholt Komponente A den Request mit den erforderlichen Authentifizierungsin-
formationen, die im Authentication-Header angegeben werden. Wenn dem Client im Vorfeld das
Authentifizierungsschema und der zugehörige Realm bekannt sind, kann er auch schon im initia-
len Request die Authentifizierungsinformationen senden. Der Realm repräsentiert den Gültigkeits-
bereich der konkreten Authentifizierungsinformationen. Da in den beschriebenen Szenarien für je-
de Ressource separat authentifiziert wird, gibt es für jede Ressource einen eigenen Realm. Realm
ist kein optionaler Parameter.

Zweiter Request von Komponente A an Ressource RI auf Komponente B mit Authentifizierung:

Authorization: Basic YWxpY2U6c2VjcmV0

Im Falle einer erfolgreichen Authentifizierung, Autorisierung und Anlage der Ressource RN ant-
wortet Komponente B wie folgt:

Location: http://www.bob.example/tasks/task_0716

Das HTTP-Protokoll macht keine Einschränkungen auf den Challenge-Response-Mechanismus.
Vielmehr können zahlreiche andere Mechanismen zusätzlich angewandt werden. Das kann z. B.
Verschlüsselung auf der Transportebene mit SSL/TLS sein, Message Encapsulation oder zusätzli-
che Header-Felder.

Der größte Nachteil bei der Basic-Authentifizierung ist, dass das Kennwort im Klartext übertragen
wird. Andererseits wird weder bei Basic- noch bei Digest-Authentifizierung der Message-Body
verschlüsselt. Digest ist ausschließlich zum Ersetzen der Basic-Authentifizierung gedacht, damit
das Kennwort nicht mehr lesbar übertragen wird. Ansonsten gelten für Digest dieselben Probleme

42


wie bei allen anderen kennwortbasierten Systemen [Fra99]. Eine mögliche Angriffsform ist der
Wörterbuchangriff (Dictionary Attack12).

Der Wörterbuchangriff ist als Angriffsmöglichkeit auf Rechner bereits seit langem bekannt. Hier-
bei verwendet man Wörterbücher und testet mittels eines Skripts Kennwort für Kennwort aus, bis
man das passende gefunden hat. Der Angreifer kann aber auch mittels einer Brute-Force Attacke
alle möglichen Zeichenkombinationen von einem Rechner automatisch ausprobieren lassen. Diese
Angriffsformen gefährden besonders Systeme, die den Benutzer nicht nach einer bestimmten An-
zahl von Fehlversuchen der Passworteingabe aussperren. Wenn diese Funktionalität realisiert ist,
kann ein Angreifer durch vielfache Fehleingabe eines Kennwortes bewusst alle Benutzer aus dem
System aussperren.

Da bei Basic-/Digest-Authentifizierung sind zwei zusammenhängende Informationen in einer Da-
tenbasis auf beiden Seiten des Kommunikationskanals gespeichert werden müssen, muss diese
Speicherung in einer besonders geschützten Form erfolgen, da ansonsten die Gefahr eines Wörter-
buchangriffs besteht.

5.3 Single-Sign-On

Ein Problem bei der Authentifizierung über ein Kennwort in einem Netzwerk ist, dass jeder mit
jedem seine Kennwörter austauschen muss. Um dem entgegenzuwirken, wird eine zentrale Instanz
eingeführt, die mit jedem Host ein Geheimnis teilt. Diese Instanz wird auch vertrauenswürdiger
Dritter (Trusted Third Parties; Secutity Token Issuer) genannt. Sie fungiert als zentrale Authentifi-
zierungsautorität für mehrere Services gleichzeitig. Hierbei wird vermieden, dass sich ein Client
selbst beim Zielservice authentifizieren muss.

Ein mögliches Modell ist das Schlüsselverteilungszentrum, mit dem jeder einzelne Client einen
gemeinsamen Schlüssel teilt. Möchte ein Client mit einem Service kommunizieren, teilt er dem
Schlüsselverteilungszentrum seinen geheimen Schlüssel und den Namen des Services mit. Das
Schlüsselverteilungszentrum authentifiziert den Client und leitet dessen Identität und den Sit-
zungsschlüssel an den Service weiter. Dieses Verfahren ist gegen Replay-Attacken gefährdet. Da-
bei initiiert ein Angreifer einen Service-Aufruf und lauscht auf die Nachricht, die das Schlüssel-
verteilungszentrum dem Service sendet und extrahiert den Sitzungsschlüssel, um ihn dann für ei-
gene Anfragen zu nutzen [Tan03, S. 854 ff].

12
Dictionary Attack: http://en.wikipedia.org/wiki/Dictionary_attack

43

Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen

Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen

Similar a Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen (20)

Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen