SlideShare ist ein Scribd-Unternehmen logo
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.1         Ausgangssituation................................................................................................... 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.1         Ausgangssituation................................................................................................... 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.1         Ausgangssituation................................................................................................... 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
REpresentational State Transfer – REST



      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
REpresentational State Transfer – REST



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
REpresentational State Transfer – REST



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
REpresentational State Transfer – REST



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
REpresentational State Transfer – REST



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
REpresentational State Transfer – REST



           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
REpresentational State Transfer – REST



           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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung




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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung




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
             Host: www.bob.example
             X-CustomHeader_Client_Identity: arbeitgeber.example/Alice
             X-CustomHeader_Ressource_Name:
                 http://arbeitgeber.example/Alice/tasks/task_root




                                                        25
Szenarien zur Authentifizierung und Autorisierung



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

             «Repräsentation der Ressource RN»


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


             PUT /tasks/task_0716 HTTP/1.1
             Host: www.bob.example
             Content-Type: application/xhtml+xml
             X-CustomHeader_Client_Identity: arbeitgeber.example/Alice
             X-CustomHeader_Ressource_Name:
                 http://arbeitgeber.example/Alice/tasks/task_root

             «Repräsentation der Ressource RN»



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
             Host: www.bob.example
             X-CustomHeader_Client_Identity: arbeitgeber.example/Alice
             X-CustomHeader_Ressource_Name:
                 http://arbeitgeber.example/Alice/tasks/task_root



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
Szenarien zur Authentifizierung und Autorisierung



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

4.4.1 Ausgangssituation

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
Szenarien zur Authentifizierung und Autorisierung



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
              X-CustomHeader_Ressource_Name:
                  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
Szenarien zur Authentifizierung und Autorisierung




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

           «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

4.5.1 Ausgangssituation

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
Szenarien zur Authentifizierung und Autorisierung




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
Szenarien zur Authentifizierung und Autorisierung




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
Szenarien zur Authentifizierung und Autorisierung



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
Szenarien zur Authentifizierung und Autorisierung




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
Szenarien zur Authentifizierung und Autorisierung




   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:


             POST /tasks HTTP/1.1
             Host: arbeitgeber.example/Carol
             X-CustomHeader_Client_Identity: www.bob.example
             X-CustomHeader_Parent_Ressource:
                 http://www.bob.example/tasks/task_0716
             «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:


             HTTP/1.1 202 Created
             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
Szenarien zur Authentifizierung und Autorisierung




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
             Host: arbeitgeber.example
             X-CustomHeader_Client_Identity: www.bob.example
             X-CustomHeader_Ressource_Name:
                 http://www.bob.example/tasks/task_0716


Response:


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

             «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
Szenarien zur Authentifizierung und Autorisierung




            GET /Alice/docs/How_to_get_Tasks HTTP/1.1
            Host: arbeitgeber.example
            X-CustomHeader_Client_Identity: arbeitgeber.example/carol
            X-CustomHeader_Ressource_Name:
                http://arbeitgeber.example/carol/tasks/task_0720
            X-CustomHeader_Parent_Ressource:
                http://www.bob.example/tasks/task_0716



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
            Host: www.bob.example
            X-CustomHeader_Client_Identity: arbeitgeber.example/Alice
            X-CustomHeader_Child_Ressource:
                http://arbeitgeber.example/carol/tasks/task_0720



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
            X-CustomHeader_Parent_Ressource:
                http://arbeitgeber.example/Alice/tasks/task_0712
            X-CustomHeader_Child_Ressource:
                http://arbeitgeber.example/carol/tasks/task_0720
            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
Szenarien zur Authentifizierung und Autorisierung




            HEAD /tasks/task_0712 HTTP/1.1
            Host: arbeitgeber.example/Alice
            X-CustomHeader_Client_Identity: arbeitgeber.example/Alice
            X-CustomHeader_Child_Ressource:
                http://www.bob.example/tasks/task_0716



Der Response erfolgt wie folgt:


            HTTP/1.1 200 Ok
            X-CustomHeader_Child_Ressource:
                http://www.bob.example/tasks/task_0716
            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
            Content-Type: application/xhtml+xml
            «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

4.6.1 Ausgangssituation

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
Szenarien zur Authentifizierung und Autorisierung



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
Authentifizierungsprotokolle



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
Authentifizierungsprotokolle



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:


             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»




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


                                                 41
Authentifizierungsprotokolle



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:


            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
            Authorization: Basic YWxpY2U6c2VjcmV0
            «Repräsentation der Ressource RN»



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


            HTTP/1.1 201 Created
            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
Authentifizierungsprotokolle



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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen

Weitere ähnliche Inhalte

Was ist angesagt?

Homematic
HomematicHomematic
Homematic
guest3f30e4
 
Creation ii v0.93 vorläufig
Creation ii v0.93 vorläufigCreation ii v0.93 vorläufig
Creation ii v0.93 vorläufig
markktoo
 
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der ErsatzteillogistikTechnikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
TheRealWolf
 
SPSS: Praxis-Leitfaden
SPSS: Praxis-LeitfadenSPSS: Praxis-Leitfaden
SPSS: Praxis-Leitfaden
René Reineke
 
PHSt Wording
PHSt WordingPHSt Wording
PHSt Wording
heiko.vogl
 
Laz Infos Svn0082
Laz Infos Svn0082Laz Infos Svn0082
Laz Infos Svn0082
guestd7366e5
 
Test Management Software Benutzerhandbuch
Test Management Software BenutzerhandbuchTest Management Software Benutzerhandbuch
Test Management Software Benutzerhandbuch
Test Management
 
Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0
agorum Software GmbH
 
agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0
agorum Software GmbH
 
Maven Definitive Guide De
Maven Definitive Guide DeMaven Definitive Guide De
Maven Definitive Guide De
bouchri
 
Game Design Document - Pogomania
Game Design Document - PogomaniaGame Design Document - Pogomania
Game Design Document - Pogomania
Philipp Strecker
 
Herzklappenprothese
HerzklappenprotheseHerzklappenprothese
Herzklappenprothese
medentic
 
Praxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
Praxisworkshop GIMP 2 - Die wichtigsten WerkzeugePraxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
Praxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
guestadcc8ae
 
Best Practice Guide
Best Practice GuideBest Practice Guide
Best Practice Guide
guestc141a6
 

Was ist angesagt? (20)

Homematic
HomematicHomematic
Homematic
 
Creation ii v0.93 vorläufig
Creation ii v0.93 vorläufigCreation ii v0.93 vorläufig
Creation ii v0.93 vorläufig
 
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der ErsatzteillogistikTechnikerarbeit: Technische Dokumentation in der Ersatzteillogistik
Technikerarbeit: Technische Dokumentation in der Ersatzteillogistik
 
Handbuch
HandbuchHandbuch
Handbuch
 
SPSS: Praxis-Leitfaden
SPSS: Praxis-LeitfadenSPSS: Praxis-Leitfaden
SPSS: Praxis-Leitfaden
 
07168030 05
07168030 0507168030 05
07168030 05
 
B8 Handbuch
B8 HandbuchB8 Handbuch
B8 Handbuch
 
PHSt Wording
PHSt WordingPHSt Wording
PHSt Wording
 
Hb Autopilot
Hb AutopilotHb Autopilot
Hb Autopilot
 
Mocek Thesis
Mocek ThesisMocek Thesis
Mocek Thesis
 
Handbuch
HandbuchHandbuch
Handbuch
 
Laz Infos Svn0082
Laz Infos Svn0082Laz Infos Svn0082
Laz Infos Svn0082
 
Test Management Software Benutzerhandbuch
Test Management Software BenutzerhandbuchTest Management Software Benutzerhandbuch
Test Management Software Benutzerhandbuch
 
Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0Agorum core-entwickler-dokumentation-6 4-0
Agorum core-entwickler-dokumentation-6 4-0
 
agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0agorum core-benutzer-handbuch-6 4-0
agorum core-benutzer-handbuch-6 4-0
 
Maven Definitive Guide De
Maven Definitive Guide DeMaven Definitive Guide De
Maven Definitive Guide De
 
Game Design Document - Pogomania
Game Design Document - PogomaniaGame Design Document - Pogomania
Game Design Document - Pogomania
 
Herzklappenprothese
HerzklappenprotheseHerzklappenprothese
Herzklappenprothese
 
Praxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
Praxisworkshop GIMP 2 - Die wichtigsten WerkzeugePraxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
Praxisworkshop GIMP 2 - Die wichtigsten Werkzeuge
 
Best Practice Guide
Best Practice GuideBest Practice Guide
Best Practice Guide
 

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

Final Opentrans 2.0 Rfq
Final Opentrans 2.0   RfqFinal Opentrans 2.0   Rfq
Final Opentrans 2.0 Rfq
guest6f1fb4
 
Diplomarbeit
DiplomarbeitDiplomarbeit
Diplomarbeit
Thorsten Grün
 
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
Frank Oellien
 
lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)
Cogneon Akademie
 
2011 sondergutachten 100_prozent_erneuerbare
2011 sondergutachten 100_prozent_erneuerbare2011 sondergutachten 100_prozent_erneuerbare
2011 sondergutachten 100_prozent_erneuerbare
metropolsolar
 
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz LeuendorfWissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Andreas Genth
 
Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0
Detlef Kahrs
 
Sappres Netweaver Identity Management
Sappres Netweaver Identity ManagementSappres Netweaver Identity Management
Sappres Netweaver Identity Management
gueste2a899
 
Linux advanced
Linux advancedLinux advanced
Linux advanced
heiko.vogl
 
Projektkommunikation: Leseprobe
Projektkommunikation: LeseprobeProjektkommunikation: Leseprobe
Projektkommunikation: Leseprobe
vdf Hochschulverlag AG
 
Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
Johannes Hohenbichler
 
Bachelorarbeit paul gerber.pdf
Bachelorarbeit paul gerber.pdfBachelorarbeit paul gerber.pdf
Bachelorarbeit paul gerber.pdf
wissem hammouda
 
German Original
German OriginalGerman Original
German Original
guestbf6d98
 
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
 
Erfolsfaktor Musikmarketing im Social Web
Erfolsfaktor Musikmarketing im Social WebErfolsfaktor Musikmarketing im Social Web
Erfolsfaktor Musikmarketing im Social Web
DigiMediaL_musik
 
Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...
ArtemEger
 
Large Scale Multilayer Perceptron
Large Scale Multilayer PerceptronLarge Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
Sascha Jonas
 
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
eBusinessLotse-Suedwestfalen-Hagen
 
Das projekt-gaia-x
Das projekt-gaia-xDas projekt-gaia-x
Das projekt-gaia-x
Paperjam_redaction
 

Ähnlich wie Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen (20)

Final Opentrans 2.0 Rfq
Final Opentrans 2.0   RfqFinal Opentrans 2.0   Rfq
Final Opentrans 2.0 Rfq
 
Diplomarbeit
DiplomarbeitDiplomarbeit
Diplomarbeit
 
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
 
lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)lernOS Prozessmodellierung Guide (Version 1.0)
lernOS Prozessmodellierung Guide (Version 1.0)
 
2011 sondergutachten 100_prozent_erneuerbare
2011 sondergutachten 100_prozent_erneuerbare2011 sondergutachten 100_prozent_erneuerbare
2011 sondergutachten 100_prozent_erneuerbare
 
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz LeuendorfWissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
 
Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0
 
Sappres Netweaver Identity Management
Sappres Netweaver Identity ManagementSappres Netweaver Identity Management
Sappres Netweaver Identity Management
 
Linux advanced
Linux advancedLinux advanced
Linux advanced
 
Projektkommunikation: Leseprobe
Projektkommunikation: LeseprobeProjektkommunikation: Leseprobe
Projektkommunikation: Leseprobe
 
Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
Stack- und Heap-Overflow-Schutz bei Windows XP und Windows Vista
 
BSI Audit
BSI AuditBSI Audit
BSI Audit
 
Bachelorarbeit paul gerber.pdf
Bachelorarbeit paul gerber.pdfBachelorarbeit paul gerber.pdf
Bachelorarbeit paul gerber.pdf
 
German Original
German OriginalGerman Original
German Original
 
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
 
Erfolsfaktor Musikmarketing im Social Web
Erfolsfaktor Musikmarketing im Social WebErfolsfaktor Musikmarketing im Social Web
Erfolsfaktor Musikmarketing im Social Web
 
Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...Blockchain-based access right management for private data in decentralized cl...
Blockchain-based access right management for private data in decentralized cl...
 
Large Scale Multilayer Perceptron
Large Scale Multilayer PerceptronLarge Scale Multilayer Perceptron
Large Scale Multilayer Perceptron
 
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
 
Das projekt-gaia-x
Das projekt-gaia-xDas projekt-gaia-x
Das projekt-gaia-x
 

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

  • 1. 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
  • 2. 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
  • 3. 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.
  • 4. 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.1 Ausgangssituation................................................................................................... 27 4.4.2 Problem ................................................................................................................... 27 I
  • 5. 4.4.3 Lösung ..................................................................................................................... 27 4.4.4 Umsetzung .............................................................................................................. 28 4.5 SZENARIO 3: DELEGATION ..................................................................................................... 29 4.5.1 Ausgangssituation................................................................................................... 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.1 Ausgangssituation................................................................................................... 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. REpresentational State Transfer – REST 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
  • 10. REpresentational State Transfer – REST 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
  • 11. REpresentational State Transfer – REST 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
  • 12. REpresentational State Transfer – REST 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
  • 13. REpresentational State Transfer – REST 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
  • 14. REpresentational State Transfer – REST 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
  • 15. REpresentational State Transfer – REST 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
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. Szenarien zur Authentifizierung und Autorisierung 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
  • 23. Szenarien zur Authentifizierung und Autorisierung 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
  • 24. Szenarien zur Authentifizierung und Autorisierung 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
  • 25. Szenarien zur Authentifizierung und Autorisierung 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
  • 26. Szenarien zur Authentifizierung und Autorisierung 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
  • 27. Szenarien zur Authentifizierung und Autorisierung 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
  • 28. Szenarien zur Authentifizierung und Autorisierung 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
  • 29. Szenarien zur Authentifizierung und Autorisierung 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
  • 30. Szenarien zur Authentifizierung und Autorisierung 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 Host: www.bob.example X-CustomHeader_Client_Identity: arbeitgeber.example/Alice X-CustomHeader_Ressource_Name: http://arbeitgeber.example/Alice/tasks/task_root 25
  • 31. Szenarien zur Authentifizierung und Autorisierung 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 «Repräsentation der Ressource RN» Äquivalenter PUT-Request von Komponente A an Ressource RN auf Komponente B: PUT /tasks/task_0716 HTTP/1.1 Host: www.bob.example Content-Type: application/xhtml+xml X-CustomHeader_Client_Identity: arbeitgeber.example/Alice X-CustomHeader_Ressource_Name: http://arbeitgeber.example/Alice/tasks/task_root «Repräsentation der Ressource RN» 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 Host: www.bob.example X-CustomHeader_Client_Identity: arbeitgeber.example/Alice X-CustomHeader_Ressource_Name: http://arbeitgeber.example/Alice/tasks/task_root 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
  • 32. Szenarien zur Authentifizierung und Autorisierung 4.4 Szenario 2: Aufbau weiterer Verbindungen zu ge- schützten Ressourcen 4.4.1 Ausgangssituation 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
  • 33. Szenarien zur Authentifizierung und Autorisierung 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 X-CustomHeader_Ressource_Name: 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
  • 34. Szenarien zur Authentifizierung und Autorisierung HTTP/1.1 200 Ok Content-Type: application/xhtml+xml «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 4.5.1 Ausgangssituation 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
  • 35. Szenarien zur Authentifizierung und Autorisierung 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
  • 36. Szenarien zur Authentifizierung und Autorisierung 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
  • 37. Szenarien zur Authentifizierung und Autorisierung 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
  • 38. Szenarien zur Authentifizierung und Autorisierung 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
  • 39. Szenarien zur Authentifizierung und Autorisierung 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: POST /tasks HTTP/1.1 Host: arbeitgeber.example/Carol X-CustomHeader_Client_Identity: www.bob.example X-CustomHeader_Parent_Ressource: http://www.bob.example/tasks/task_0716 «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: HTTP/1.1 202 Created 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
  • 40. Szenarien zur Authentifizierung und Autorisierung 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 Host: arbeitgeber.example X-CustomHeader_Client_Identity: www.bob.example X-CustomHeader_Ressource_Name: http://www.bob.example/tasks/task_0716 Response: HTTP/1.1 200 Ok Content-Type: application/xhtml+xml «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
  • 41. Szenarien zur Authentifizierung und Autorisierung GET /Alice/docs/How_to_get_Tasks HTTP/1.1 Host: arbeitgeber.example X-CustomHeader_Client_Identity: arbeitgeber.example/carol X-CustomHeader_Ressource_Name: http://arbeitgeber.example/carol/tasks/task_0720 X-CustomHeader_Parent_Ressource: http://www.bob.example/tasks/task_0716 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 Host: www.bob.example X-CustomHeader_Client_Identity: arbeitgeber.example/Alice X-CustomHeader_Child_Ressource: http://arbeitgeber.example/carol/tasks/task_0720 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 X-CustomHeader_Parent_Ressource: http://arbeitgeber.example/Alice/tasks/task_0712 X-CustomHeader_Child_Ressource: http://arbeitgeber.example/carol/tasks/task_0720 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
  • 42. Szenarien zur Authentifizierung und Autorisierung HEAD /tasks/task_0712 HTTP/1.1 Host: arbeitgeber.example/Alice X-CustomHeader_Client_Identity: arbeitgeber.example/Alice X-CustomHeader_Child_Ressource: http://www.bob.example/tasks/task_0716 Der Response erfolgt wie folgt: HTTP/1.1 200 Ok X-CustomHeader_Child_Ressource: http://www.bob.example/tasks/task_0716 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 Content-Type: application/xhtml+xml «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 4.6.1 Ausgangssituation 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
  • 43. Szenarien zur Authentifizierung und Autorisierung 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
  • 44. 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
  • 45. Authentifizierungsprotokolle 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
  • 46. Authentifizierungsprotokolle 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: 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» 11 Message-Digest Algorithm 5 http://de.wikipedia.org/wiki/Md5 41
  • 47. Authentifizierungsprotokolle 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: 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 Authorization: Basic YWxpY2U6c2VjcmV0 «Repräsentation der Ressource RN» Im Falle einer erfolgreichen Authentifizierung, Autorisierung und Anlage der Ressource RN ant- wortet Komponente B wie folgt: HTTP/1.1 201 Created 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
  • 48. Authentifizierungsprotokolle 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