Dynamische Anlage geschützter Ressourcen                   Masterarbeit           Eingereicht von Melanie Eibl            ...
Versicherung der eigenständigen ArbeitHiermit erkläre ich, dass ich die vorliegende Abschlussarbeit selbständig verfasst u...
ZusammenfassungDie vorliegende Arbeit beschäftigt sich mit Authentifizierung und Autorisierung in einem verteil-ten System...
INHALTSVERZEICHNIS1     EINLEITUNG ..........................................................................................
4.4.3         Lösung ........................................................................................................
Einleitung1 EinleitungImmer mehr Rechnernetze werden zur Unterstützung von Gruppen- und Teamarbeit eingesetzt.Die rechnerg...
EinleitungAnschließend werden verschiedene Authentifizierungsmethoden beschrieben und evaluiert. Wei-terhin werden die bes...
REpresentational State Transfer – REST2 REpresentational State Transfer – RESTBei Groupware-Systemen besteht oft die Anfor...
REpresentational State Transfer – REST      1.   Ressourcen mit eindeutiger Identifikation           Das Prinzip der einde...
REpresentational State Transfer – RESTerhält, kann man domänenübergreifend auf sie zugreifen. Daraus resultiert, dass auch...
REpresentational State Transfer – RESTDas HTTP-Protokoll bietet Vorkehrungen für Content Negotiation, d. h. es können mehr...
REpresentational State Transfer – RESTwender aufzeigt, miteinander zu interagieren. Diese Interaktionen basieren auf den A...
REpresentational State Transfer – RESTMethoden können zum einen sicher sein und/oder idempotent. Von einer sicheren Method...
REpresentational State Transfer – REST           mitgeschickt wird, ansprechbar sein soll. Der URI in einem POST dagegen s...
REpresentational State Transfer – REST           zugehörige WWW-Authenticate-Header des Response muss in einem 401 (Unauth...
Sicherheit3 SicherheitVerteilte Systeme im Internet nutzen Übertragungswege, die auch von anderen Partnern genutztwerden. ...
Sicherheit3.1 VerschlüsselungBei der Verschlüsselung handelt es sich um das Umformen der Daten in etwas, was ein Angreifer...
Sicherheitist, zu verifizieren, ob der Public Key von einer Webseite wirklich zum gewünschten Kommunika-tionspartner gehör...
SicherheitSSL/TLS-verschlüsselte Sitzung einzuleiten. Danach sind Client und Server in der Lage, Datenüber einen verschlüs...
Sicherheit3.5 FazitMit der Sicherung des Tranportkanals mit SSL/TLS sind die Anforderungen nach Integrität undVertraulichk...
Szenarien zur Authentifizierung und Autorisierung4 Szenarien zur Authentifizierung und Auto-  risierungIn diesem Kapitel w...
Szenarien zur Authentifizierung und AutorisierungFormal gesehen gehört das Verifizieren von Zugriffsrechten zur Zugriffsko...
Szenarien zur Authentifizierung und AutorisierungAbbildung 4-1 Beispiele von ZugriffskontrolllistenHier ist wieder der Ums...
Szenarien zur Authentifizierung und AutorisierungDas hier zu behandelnde System ist ein hochverteiltes System mit der Ford...
Szenarien zur Authentifizierung und Autorisierungnen enthält, müssen noch die Informationen zur Delegation gehalten werden...
Szenarien zur Authentifizierung und AutorisierungHeader-Fields unterscheiden zu können, wird hier einheitlich „X-CustomHea...
Szenarien zur Authentifizierung und Autorisierungeine neue Ressource RN anlegen. Anschließend möchte Komponente A Ressourc...
Szenarien zur Authentifizierung und Autorisierungim Location-Header des Responses an Komponente A. Beim autorisierten Zugr...
Szenarien zur Authentifizierung und AutorisierungBei jedem Zugriff eines Subjekts auf ein Objekt werden die zugeordneten Z...
Szenarien zur Authentifizierung und AutorisierungAbbildung 4-5 Metadaten der Ressource www.bob.example/tasks/task_0716Arbe...
Szenarien zur Authentifizierung und AutorisierungKomponente B führt die Authentifizierung und Autorisierung durch. Lt. Abb...
Szenarien zur Authentifizierung und Autorisierung4.4 Szenario 2: Aufbau weiterer Verbindungen zu ge-    schützten Ressourc...
Szenarien zur Authentifizierung und Autorisierungdie    Berechtigungen         für     die     Methoden       GET   und   ...
Szenarien zur Authentifizierung und Autorisierung           HTTP/1.1 200 Ok           Content-Type: application/xhtml+xml ...
Szenarien zur Authentifizierung und AutorisierungAbbildung 4-9 DelegationUpdates für Ressource RN auf Komponente B sollen ...
Szenarien zur Authentifizierung und AutorisierungAbbildung 4-10 BerechtigungsbaumRessource RR ist die Root-Ressource und b...
Szenarien zur Authentifizierung und AutorisierungRessource RD auf Komponente C möchte auf Ressource RP auf Komponente A zu...
Szenarien zur Authentifizierung und AutorisierungAbbildung 4-11 Berechtigungsbaum mit OperationenEine Delegation kann zurü...
Szenarien zur Authentifizierung und Autorisierung   Komponente B                 Komponente C                    POST     ...
Szenarien zur Authentifizierung und AutorisierungAbbildung 4-13 Metadaten der Ressource www.bob.example/tasks/task_0716Abb...
Szenarien zur Authentifizierung und Autorisierung            GET /Alice/docs/How_to_get_Tasks HTTP/1.1            Host: ar...
Szenarien zur Authentifizierung und Autorisierung            HEAD /tasks/task_0712 HTTP/1.1            Host: arbeitgeber.e...
Szenarien zur Authentifizierung und Autorisierung4.6.2 ProblemAuthentifizierung, Umsetzung und Nachrichtenfluss erfolgen a...
Authentifizierungsprotokolle5 AuthentifizierungsprotokolleBisher wurde die Authentifizierung für die dargestellten Szenari...
Authentifizierungsprotokollekann. Daher sind Zertifikatsschlüssel in der Regel sehr viel länger als es Kennwörter aus prak...
AuthentifizierungsprotokolleSowohl bei Basic- als auch bei Digest-Authentifizierung teilen Client und Server ein Geheimnis...
AuthentifizierungsprotokolleIm Request ist kein Authentication-Header mit zusätzlichen Authentifizierungsinformationen an-...
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
Masterarbeit / Fakultät für Mathematik und Informatik / Lehrgebiet Datenverarbeitungstechnik / Fernuniversität in Hagen
Nächste SlideShare
Wird geladen in …5
×

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

4.016 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
4.016
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

  1. 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. 2. Versicherung der eigenständigen ArbeitHiermit 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 entnommenwurden, 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. 3. ZusammenfassungDie 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. Dabeiwerden Beschränkungen des OpenID-Protokolls untersucht. Weiterhin soll der Einsatz von OAuthals Protokoll zur Delegation von Zugriffsrechten evaluiert werden.
  4. 4. INHALTSVERZEICHNIS1 EINLEITUNG ........................................................................................................................ 12 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) ................................................................... 73 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 ................................................................................................................................. 154 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. 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 ................................................................................................................................. 385 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 ................................................................................................................................. 566 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 ................................................................................................................................. 677 PROTOTYPISCHE IMPLEMENTIERUNG ............................................................................... 688 SCHLUSSBEMERKUNG ....................................................................................................... 699 LITERATURVERZEICHNIS.................................................................................................... 7010 ABBILDUNGSVERZEICHNIS ............................................................................................ 73 II
  6. 6. Einleitung1 EinleitungImmer 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 Menschenund deren Unterstützung mit Rechnern beschäftigt.Soft- und Hardware, die zur Kooperationsunterstützung eingesetzt wird, nennt man allgemeinGroupware [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 eigentlichenKooperation 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 bedeutenderwird 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. DerBesitzer wählt kollaborierende Nutzer aus seinem Adressbuch aus und weist ihnen Aufgaben unddazugehörige Zugriffsrechte auf das Dokument zu. Weiterhin kann ein kollaborierender Nutzer dieihm zugewiesene Aufgabe weiter delegieren. Als Diskussionsgrundlage werden vier repräsentativeSzenarien 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 aufeine zuvor angelegte Ressource näher betrachtet werden. Szenario 3 wird sich mit der Delegationvon Zugriffsrechten an einen weiteren Nutzer beschäftigen und Szenario 4 schließlich mit derMassendelegation.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 Sicherheitmit 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. ZurDelegation der Zugriffsrechte wird ein Algorithmus beschrieben, der die Baumstruktur der Dele-gation aufgreift. 1
  7. 7. EinleitungAnschließend werden verschiedene Authentifizierungsmethoden beschrieben und evaluiert. Wei-terhin werden die besonderen Merkmale und Beschränkungen des OpenID-Protokolls beschriebenund Erweiterungsmöglichkeiten aufgezeigt.Schließlich wird noch die Delegation mit dem OAuth-Protokoll beschrieben und ein Ansatz für dievorliegenden Szenarien skizziert. Dabei soll dargestellt werden, warum die diesem Standard zu-grundeliegende Problemstellung nicht auf die hier dargestellte Delegationsproblematik übertragbarist.Mit der Schlussbemerkung schließt diese Arbeit. 2
  8. 8. REpresentational State Transfer – REST2 REpresentational State Transfer – RESTBei 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 verteiltsein. Das WWW (World Wide Web) ist eine verteilte Anwendung, die Dokumente auf der ganzenWelt miteinander verknüpft. Der Zugriff auf Dokumente erfolgt über Links innerhalb anderer Do-kumente. Dokumente können unterschiedliche Repräsentationsformate haben und zur Übertragungwerden verschiedene Protokolle, die meist auf Standards beruhen, herangezogen. Ziel des WWWist, die intuitive Gestaltung der Interaktion zwischen Mensch und Hypertext-Dokumenten[Bern96].Das WWW ist weiterhin eine typische Client-Server-Architektur. Der Server stellt Dokumente alsRessource 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 TilkovREpresentional 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, dieals 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ürREST [Til11, S. 11]: 3
  9. 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 ergebensich viele Vorteile. Da jede Ressource einen weltweit eindeutigen Identifier in Form eines URIs1 Separation of Concerns http://en.wikipedia.org/wiki/Separation_of_concerns2 Content negotiation: http://en.wikipedia.org/wiki/Content_negotiation 4
  10. 10. REpresentational State Transfer – RESTerhä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 weltweitfunktionieren. 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 dieAufgabe 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. Umdies zu umgehen, kann die einmal festgestellte Identität eines Clients in einem Cookie festgehaltenwerden. 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. ihreGü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 Anfragenoch 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 Bodyder Antwort die Ressource im bevorzugten Repräsentationsformat. Auf die Einzelheiten soll inden nächsten Kapiteln eingegangen werden.2.2 RepräsentationsformateEine Ressource ist ein Datenobjekt, welches über einen URI eindeutig identifiziert werden kann.Eine Ressource kann in verschiedenen Repräsentationsformaten unter demselben URI angebotenwerden. In welchem Repräsentationsformat die Ressource letztendlich übertragen wird, muss zwi-schen Client und Server „verhandelt“ werden. Dieses Verhalten wird in RFC 2616 als ContentNegotiation beschrieben [Fie99, Kapitel 12].3 User Agent http://en.wikipedia.org/wiki/User_agent 5
  11. 11. REpresentational State Transfer – RESTDas 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-Negotiationund 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 RFC2045 [Fre961] und RFC 2046 [Fre962] standardisiert. Bei MIME steht eine Meta-Information, diedie 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 Nachrichterstellt 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 vonRessourcen. Im Hinblick auf die unterschiedlichen Nutzerbedürfnisse ist das sinnvoll. Der Typ ei-ner RESTful-Service-Ressource wird Medientyp genannt. Dieser Medientyp wird immer alsMIME-Type im Content-Type-Header einer HTTP-Response angegeben. Die vier häufigsten Me-dienformate sind XML, Really Simple Syndication (RSS) / Atom Syndication Format, ExtensibleHypertext Markup Language (XHTML) und Java Script Object Notation (JSON). Die Parameterdes 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 diesvom Service nicht unterstützt wird, ist die zweite Wahl application/xhtml+xml usw. In letzterInstanz wird mit */* ausgedrückt, dass jedes Format akzeptiert wird. Formate, die der Browsernicht darstellen kann, werden von ihm anders behandelt, z. B. zum Download angeboten, um dieRessource mit einem anderen Programm öffnen zu können.2.3 Hypertext Transfer Protocol HTTPDer 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. 12. REpresentational State Transfer – RESTwender 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 zumClient. 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. DerHeader 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 eindeutigidentifzieren. 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 pathDas Schema gibt den URI-Typ an, z. B. HTTP, HTTPS oder FTP. Die Authority ist ein optionalerBestandteil einer URI, der eine Instanz innerhalb eines Domain Name Systems repräsentiert. Aufdie Authority folgt ein weiterer Pflichtbestandteil: Der Path. Der Path enthält meist hierarchischorganisierte 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 angebenkann, kurz beschrieben [Fie99, Kapitel 9].4 Human-Readable Medium http://en.wikipedia.org/wiki/Human-readable_medium 7
  13. 13. REpresentational State Transfer – RESTMethoden 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 Methodenkönnen zwar Seiteneffekte verursachen, jedoch sind diese bei mehrmaligem Aufruf der Methodedieselben 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. 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. Der5 List of HTTP Header Fields http://en.wikipedia.org/wiki/List_of_HTTP_header_fields 9
  15. 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. 16. Sicherheit3 SicherheitVerteilte Systeme im Internet nutzen Übertragungswege, die auch von anderen Partnern genutztwerden. Neben den Nutzern, die diese Wege in friedlicher Absicht mitbenutzen, hat man es auchmit 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 zuschü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ätbeschrieben.Grundsätzlich unterscheidet man zwischen nachrichtenbasierter und transportbasierter Sicherheit.Beim nachrichtenorientierten Ansatz wird die Nachricht geeignet geschützt, d. h. verschlüsselt undsigniert und kann dann über einen ungesicherten Transportmechanismus übertragen werden. Beider transportbasierten Sicherheit wird der Übertragungskanal gesichert. Die Nachricht kann dannunverschlüsselt übertragen werden.Zunächst müssen die Sicherheitsanforderungen definiert werden. Diese Anforderungen nennt manSecurity Policy. Eine Security Policy legt genau fest, was in einem System erlaubt ist und wasnicht. 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. Auditierungwird hier nicht weiter beschrieben. 11
  17. 17. Sicherheit3.1 VerschlüsselungBei der Verschlüsselung handelt es sich um das Umformen der Daten in etwas, was ein Angreifernicht 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 alsParameter. 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 einSchlü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 initialenSchlü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 dieserSchlü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 vonZertifikaten soll im folgenden Kapitel beschrieben werden.3.2 ZertifikateEin ö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 Zertifikatestammen 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. DieKommunikationspartner 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. 18. Sicherheitist, 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 Zertifikatenthä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 desZertifikats 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 bestimmteIdentität und ein bestimmter Public Key zusammen gehören [Kri08, S. 91]. Die CA verifiziert dieIdentität des Zertifikateigentümers, bevor das Zertifikat ausgestellt wird. Je nach Einsatzfeld desausgestellten Zertifikats kann die CA auch eine innerbetriebliche Instanz sein, sofern die in denZertifikaten 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 Systemsherangezogen 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. DerNachfolger 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 TransportLayer und wird hauptsächlich zusammen mit TCP verwendet. Weiterhin unterstützt SSL/TLS eineVielzahl an Verschlüsselungs- und Komprimierungsmethoden und verwendet sowohl symmetri-sche als auch asymmetrische Verschlüsselung. Das SSL/TLS-Protokoll besteht aus zwei wichtigenund 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 dasSSL/TLS-Zertifikat glaubwürdig ist. Bei erfolgreicher Überprüfung sendet er eine Nachricht anden Server. Der Server sendet anschließend eine digital signierte Bestätigung zurück, um eine 13
  19. 19. SicherheitSSL/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, mitdem Nachrichten verschlüsselt werden. Der Session-Key sorgt sowohl für Geheimhaltung als auchfür Integrität. Ein solcher Schlüssel wird nur so lange genutzt, wie der Übertragungskanal existiert.3.4 HTTPSHTTP ist ein Protokoll ohne eigene Sicherheitsmechanismen. Um Verbindungen abzusichern,wird zusätzlich SSL/TLS eingesetzt. Erkennbar ist eine SSL/TLS geschützte HTTP-Verbindungdurch das angehängte „S“ – HTTPS. In Bezug auf das OSI7-Referenzmodell liegt TLS überTCP/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 derAnwendungsschicht 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 basiertauf referenzieren eines URI, wodurch dem Client der Hostname des Servers bekannt ist. Dadurchist der Client in der Lage, die Identität des Servers über die erhaltene Server-Zertifikats-Nachrichtzu verifizieren. Zunächst hat der Server bei einer SSL/TLS-Verbindung keine Kenntnis von derIdentität des Clients.Unter einem Man-In-The-Middle-Angriff versteht man das Abfangen, das Einfügen, das Löschenund die Modifikation von Nachrichten, sowie das Wiederholen alter Nachrichten und das Umlei-ten von Nachrichten. Hiervon betroffen sind besonders anonyme Sessions. Beim Abhören vonNachrichten 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. 20. Sicherheit3.5 FazitMit der Sicherung des Tranportkanals mit SSL/TLS sind die Anforderungen nach Integrität undVertraulichkeit eines verteilten Systems erfüllt. An dieser Stelle kann man bei der Betrachtung derProblemstellung 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 Contentim 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 vonSSL/TLS [Til11, S. 131]. 15
  21. 21. Szenarien zur Authentifizierung und Autorisierung4 Szenarien zur Authentifizierung und Auto- risierungIn diesem Kapitel werden vier verschiedene Szenarien zur Authentifizierung und Autorisierung fürClients 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ätsmanagementMan muss zwischen dem Identitätsbegriff in der Soziologie und der Informatik unterscheiden. DieSoziologie 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 Kombinationvon 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 Zugriffsrechtenmachen. 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 zuerteilen. 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 manuellenVorgängen nur an natürliche Personen vergeben werden [Tso10, S. 25 f].4.1.1 Authentifizierung und AutorisierungAls 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. 22. Szenarien zur Authentifizierung und AutorisierungFormal gesehen gehört das Verifizieren von Zugriffsrechten zur Zugriffskontrolle, während dieAutorisierung das Gewähren dieser Rechte darstellt. Die Authentifizierung geht der Autorisierungunmittelbar voraus. Subjekte versenden Requests, um auf Objekten bestimmte Operationen auszu-führen. Zugriffskontrolle bedeutet, alle Objekte gegen den Zugriff von Subjekten zu schützen, diekeine Rechte dazu besitzen. In der Regel wird die Autorisierung von der Entität durchgeführt, dieden Dienst zur Verfügung stellt. Rechte können aber auch von der anfordernden Stelle vergebenwerden. Autorisierung gehört formal zur Software Security.4.1.2 ZugriffsberechtigungEine Zugriffsberechtigung hängt von zwei Faktoren ab: Dem Objekt und der Operation. Das zuberechtigende 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 Dateienverwendet werden. Eine Zugriffskontrollliste ist an ein Objekt gebunden und beinhaltet eine Listevon 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üreine verteilte Verwaltung von Berechtigungen ist. Aufwändig ist jedoch die Ermittlung der Mengealler 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 erlaubtenMethoden. Im Grunde bedeutet das, dass die Zugriffskontrollmatrix Spaltenweise auf die Objekteverteilt wird (Abbildung 4-1) [Tan07, S. 415 f]. 17
  23. 23. Szenarien zur Authentifizierung und AutorisierungAbbildung 4-1 Beispiele von ZugriffskontrolllistenHier ist wieder der Umstand zu berücksichtigen, dass es sich bei dem zu betrachtenden System umein verteiltes System handelt und zentrale Berechtigungssysteme vermieden werden sollen. Daherwird 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 BerechtigungsmodelleBei den Berechtigungsmodellen wird grundsätzlich zwischen dem zentralen und dem dezentralenBerechtigungsmodell unterschieden [Tso10, S. 109 ff].Beim zentralen Berechtigungsmodell werden die Ressourcen und ihre Berechtigungen in einemzentralen Repository gehalten. Benutzer- und Rechteverwaltung werden z. B. in einem LDAP-(Lightweight Directory Access Protocol) fähigen Repository/Verzeichnisdienst ausgelagert. Mitdem zentralen Berechtigungsmodell ergibt sich das Single-Point-Of-Failure8 Problem, welchesentsprechend abzusichern ist. Ein zentrales Modell bietet jedoch auch eine höhere Sicherheit, dagewä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 Datenspeichermit 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 anjeder 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. 24. Szenarien zur Authentifizierung und AutorisierungDas 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 SzenarienDie folgenden Szenarien beziehen sich auf ein offenes System, bei dem neue Ressourcen geschütztwerden sollen. Hierbei ist zu untersuchen, auf welchem Wege sich Clients gegenüber den Servernauthentifizieren 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ätist. Die eigentliche Authentifizierung wird in Kapitel 5 beschrieben. Alle Lösungsansätze solltendem Robustheitprinzips nach Postel folgen: „… be conservative in what you do, be liberal in whatyou accept from others.“ [Inf81, Kapitel 2.10].Die Szenarien werden jeweils in folgende Abschnitte unterteilt: 1. Ausgangssituation 2. Problem 3. Lösung 4. UmsetzungIn dem Beispiel zu den beschreibenden Szenarien werden zwei Ressourcentypen von Bedeutungsein: 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 demAufgabenserver des Mitarbeitenden an und entscheidet, welche Operationen der Mitarbeitendeausführen darf. Der Mitarbeitende hat wiederum die Möglichkeit, die ihm zugewiesene Aufgabezu 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 RessourcenZu jeder Ressource werden Metadaten gespeichert, die nicht zu der eigentlichen Repräsentationgehören. Neben der ACL, die die zugriffsberechtigten Subjekte und deren zugewiesenen Operatio- 19
  25. 25. Szenarien zur Authentifizierung und Autorisierungnen enthält, müssen noch die Informationen zur Delegation gehalten werden. Bei der Delegationwird in den beschriebenen Szenarien unterschieden, wer Delegierender ist und wer eine delegierteAufgabe 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 miteinem vorangestellten „X-“9 gekennzeichnet. Da die Metadaten nicht zur Repräsentation einerRessource gehören, aber teilweise die Notwendigkeit besteht, Metadaten in den Nachrichten zutransportieren, 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ätzlichen9 HTTP Gallery http://www.httpwatch.com/httpgallery/headers/ 20
  26. 26. Szenarien zur Authentifizierung und AutorisierungHeader-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 einigeParameter 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 Ressource4.3.1 AusgangssituationDie Komponente A kennt den URI der Listenressource RI einer Komponente B und möchte überdiese 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 KomponenteB kennen sich gegenseitig nicht und teilen auch kein Geheimnis. Weiterhin verwenden sie keingemeinsames Authentifizierungssystem. Jeder kann auf Komponente B über Listenressource RI 21
  27. 27. Szenarien zur Authentifizierung und Autorisierungeine neue Ressource RN anlegen. Anschließend möchte Komponente A Ressource RN autorisiertanfragen, 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 (Abbildung4-2). RN entspricht der zuvor beschriebenen delegierten Aufgabe.Abbildung 4-2 Anlage und anschließende autorisierte Anfrage einer geschützten Ressource4.3.2 ProblemKomponente 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 initialeKommunikation so gestaltet werden, dass Komponente B bei einem späteren Request KomponenteA authentifizieren und autorisieren kann.4.3.3 LösungUm 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 derFall. 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 derRessource 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. 28. Szenarien zur Authentifizierung und Autorisierungim Location-Header des Responses an Komponente A. Beim autorisierten Zugriff wird Kompo-nente A über eine noch zu spezifizierende Authentifizierungsmethode authentifiziert und über dieACL der Ressource RN autorisiert.4.3.4 UmsetzungZur Umsetzung des Anwendungsfalls wird eine neue Ressource R N angelegt. Dies erfolgt mit derPOST-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 RessourceDer 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 sindzwei 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 Nutzerwww.bob.example repräsentiert Komponente B. www.bob.example ist ebenfalls berechtigt einPOST 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 Objektnach 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. 29. Szenarien zur Authentifizierung und AutorisierungBei 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 aufein Objekt besitzt, kann diese an ein anderes Subjekt weiterreichen. Dadurch kann ein anderesSubjekt 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 neuenRessource 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. Wichtigist 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_0716Der 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 undAnlage 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 odernicht. Nach der Anlage der Ressource RI hat die in Abbildung 4-5 dargestellte ACL. 24
  30. 30. Szenarien zur Authentifizierung und AutorisierungAbbildung 4-5 Metadaten der Ressource www.bob.example/tasks/task_0716Arbeitgeber.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.examplekann die Ressource anfordern und verändern, jedoch nicht löschen. Jeder authentifizierte Nutzerdarf 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 inder 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 GETAbbildung 4-6 Sequenzdiagramm - Autorisierte Anfrage einer geschützten RessourceGET-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. 31. Szenarien zur Authentifizierung und AutorisierungKomponente 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_rootResponse: HTTP/1.1 204 No ContentNach 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 DELETEberechtigt ist. 26
  32. 32. Szenarien zur Authentifizierung und Autorisierung4.4 Szenario 2: Aufbau weiterer Verbindungen zu ge- schützten Ressourcen4.4.1 AusgangssituationDieses Szenario ähnelt dem Szenario 1, jedoch bietet Komponente A eine weitere Ressource R Pan, das in der Aufgabe, bzw. hier in Ressource RN verlinkte Dokument. Nach dem Erstellen derRessource RN, soll die Komponente B in der Lage sein, nach erfolgreicher Authentifizierung dieBerechtigung zu erhalten, auf Ressource RP auf Komponente A zuzugreifen. Die von KomponenteA 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 ProblemDa die Komponente B zunächst nur den URI der Ressource RP der Komponente A kennt, muss dieKommunikation so erweitert werden, dass die Komponente A Komponente B authentifiziert undautorisiert. RP ist ebenfalls eine geschützte Ressource, deren Methoden eine Authentifizierung undAutorisierung erfordern.4.4.3 LösungKomponente 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_rootRessource Owner ist arbeitgeber.example/Alice selber und arbeitgeber.example/Alice ist auch dereinzige Zugriffsberechtigte auf diese Ressource. Als Child Ressource istwww.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. 33. Szenarien zur Authentifizierung und Autorisierungdie Berechtigungen für die Methoden GET und PUT an die Ressourcewww.bob.example/tasks/task_ 0716 delegiert wurden.4.4.4 UmsetzungDie 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 URIhttp://arbeitgeber.example/Alice/docs/How_to_get_Tasks (Abbildung 4-8).Abbildung 4-8 Zugriff auf die geschützte Ressource RPRequest 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_rootKomponente 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. 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. DieAutorisierungsinformationen werden nicht am Objekt gespeichert. Dieses Verfahren erlaubt einebeliebig verzweigte Delegation der Aufgaben, wie wir in Szenario 3 sehen werden.4.5 Szenario 3: Delegation4.5.1 AusgangssituationDieses 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 ProblemKomponente 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öglichsein. 29
  35. 35. Szenarien zur Authentifizierung und AutorisierungAbbildung 4-9 DelegationUpdates 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 zunehmen, bzw. wenn RN auf Komponente C gelöscht wird, müssen die Rechte ebenfalls entzogenwerden.4.5.3 LösungIm Folgenden soll eine Lösungsmöglichkeit mit einer Baum-Berechtigungsstruktur beschriebenwerden. 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 eineListenressource und gibt an, an welche Ressourcen delegiert wurde. An der Child Ressource stehtweiterhin, welche Rechte delegiert wurden, d. h. die erlaubten HTTP-Verben. Die Baum-Strukturist in Abbildung 4-10 dargestellt. 30
  36. 36. Szenarien zur Authentifizierung und AutorisierungAbbildung 4-10 BerechtigungsbaumRessource RR ist die Root-Ressource und befindet sich in den hier beschriebenen Szenarien aufKomponente A. Ressource RR hat keine Parent Ressource und ist Ressource Owner der RessourceRP. In Szenario 1 wurde Ressource RR an Komponente B delegiert, indem Ressource RN erzeugtwurde. 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 demhier beschriebenen Szenario erfolgt nun eine Delegation von Ressource RN auf Komponente B anKomponente C. Die neue Ressource auf Komponente C ist dann RD. Dabei wird an Ressource RNRessource RD als Child Ressource geschrieben und an Ressource RD Ressource RN als ParentRessource.An den Child Ressource Parameter werden weiterhin die erlaubten Operationen, bzw. HTTP-Verben geschrieben. Welche Berechtigungen an Ressource RP delegiert werden, entscheidet derNutzer der Komponente B. Die Information, welche Rechte Komponente B selber besitzt, ist anRessource RN nicht verzeichnet. Man könnte sich vorstellen, einen zusätzlichen Parameter für dieerlaubten 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. 37. Szenarien zur Authentifizierung und AutorisierungRessource RD auf Komponente C möchte auf Ressource RP auf Komponente A zugreifen. Dabeisendet sie den Wert des Parent Ressource Parameters aus ihren Metadaten mit. Komponente Afragt nun unter dem URI aus dem Parameter Parent Ressource an, ob eine noch gültige Delegationbesteht 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 dieserStelle kann die Komponente A aber noch nicht auf die ermittelten Informationen vertrauen, weil jaim 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 übermitteltRessource 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 RNals 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 aufderselben Komponente liegt.Nun hat Komponente A jedoch einmal die erlaubten Operationen GET und PUT erhalten und einanderes Mal die Operationen GET, PUT und DELETE. Grundsätzlich können nur solche Rechtedelegiert werden, die man auch selber besitzt. Daher wird hier die kleinste Schnittmenge gebildetund Komponente A stellt fest, dass Komponente C mit Operationen GET und PUT auf RessourceRP ausführen darf. 32
  38. 38. Szenarien zur Authentifizierung und AutorisierungAbbildung 4-11 Berechtigungsbaum mit OperationenEine Delegation kann zurückgenommen werden, indem die Parent Ressource die Child Ressourceselber 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 anRessource 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, istdieses Vorgehen denkbar, wird hier jedoch nicht weiter beschrieben. Ein weiterer Vorteil diesesAnsatzes 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 UmsetzungIm ersten Schritt delegiert Ressource RN auf Komponente B den Zugriff auf Ressource RP aufKomponente A, indem sie eine neue Ressource RD auf Komponente C anlegt. Dies erfolgt durcheinen POST an die Listenressource RK auf Komponente C, wobei eine initiale Repräsentation vonRD im Body übermittelt wird (Abbildung 4-12). 33
  39. 39. Szenarien zur Authentifizierung und Autorisierung Komponente B Komponente C POST Location...Abbildung 4-12 Sequenzdiagramm - Anlage einer geschützten RessourceDer 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. Wichtigist die Identität des Clients im X-CustomHeader_Client_Identity, um den Ressource Owner fürRessource 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_0720Der beschriebene Ablauf unterscheidet sich nicht wesentlich vom Ablauf aus Szenario 1. NachAnlage der neuen Ressource RD müssen an der Parent-Ressource RN die Child-Ressource RD unddie erlaubten Methoden eingetragen werden. Dies erfolgt seitens Komponente B programmatischohne Nachrichtenaustausch (Abbildung 4-13). Die Metadaten für die neu angelegte Ressource er-geben sich aus Abbildung 4-14. 34
  40. 40. Szenarien zur Authentifizierung und AutorisierungAbbildung 4-13 Metadaten der Ressource www.bob.example/tasks/task_0716Abbildung 4-14 Metadaten für die Ressource arbeitgeber.example/Carol/tasks/task_0720Weiterhin 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 hiernur 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_0716Response: 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. Requestvon Komponente C an Ressource RP auf Komponente A: 35
  41. 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_0716Komponente A fragt nun bei der Ressource www.bob.example/tasks/task_0716 auf KomponenteB an, ob die Rechte wirklich delegiert wurden. Der Request von Komponente A an Ressource R Nsieht 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_0720Hier 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 beiden Aufgaben-Ressourcen identitätsbezogen. Da jedoch die Aufgabe die Identität der KomponenteA 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 folgenderResponse: 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,DELETEKomponente A stellt fest, dass RN keine Root-Ressource ist und fragt als nächstes unter dem URIaus 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. Eserfolgt folgender Request: 36
  42. 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_0716Der 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,PUTNun hat Komponente A einmal die erlaubten Operationen GET, PUT und DELETE im Responseerhalten 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ürdie Operationen GET und PUT. Der ursprüngliche Request von Komponente C an Komponente Awar 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 - Massendelegation4.6.1 AusgangssituationKomponente B veranlasst, dass die Ressource RN von Komponente B an mehrere Instanzen derKomponente C gepostet wird. Updates, die Komponente B dann über RN bekommt, werden an alleInstanzen der Komponente C weitergegeben. Dies wurde in Abbildung 4-10 Berechtigungsbaumbereits kurz skizziert. 37
  43. 43. Szenarien zur Authentifizierung und Autorisierung4.6.2 ProblemAuthentifizierung, Umsetzung und Nachrichtenfluss erfolgen analog zu Szenario 3. Beim Zugriffauf die Ressource RP auf Komponente A müssen Schutzmechanismen zur Nebenläufigkeitskon-trolle implementiert werden, da die Wahrscheinlichkeit, dass mehrere Personen gleichzeitig einDokument bearbeiten, sehr wahrscheinlich wird.4.6.3 LösungNebenläufigkeitskontrolle kann dadurch realisiert werden, dass ein Lock gesetzt wird, wenn einNutzer das Dokument zum Bearbeiten abruft. Durch die lose Kopplung der Systeme bekommt dieRessource RP nicht mit, wenn der Nutzer die Bearbeitung abbricht. Das Dokument bleibt für alleanderen gesperrt.Eine weitere Möglichkeit ist die einfache optimistische Nebenläufigkeitskontrolle. Dabei wirdbeim 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 Dokumenteine 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. EinBeispiel dafür ist CVS10. Hierauf wird nicht näher eingegangen.4.7 FazitIn den Lösungsansätzen der beschriebenen Szenarien wurden repräsentative Problemstellungenbehandelt, die in einer kooperativen Aufgabenverwaltung zur Bearbeitung von gemeinsam genutz-ten Ressourcen auftreten können. Die zentrale Forderung, von keiner zentralen Instanz abhängigzu 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 untersuchtwerden soll. Weiterhin wurde in den beschriebenen Szenarien die Authentifizierung nicht näherbetrachtet. 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. 44. Authentifizierungsprotokolle5 AuthentifizierungsprotokolleBisher 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ürdie in Kapitel 4 beschriebenen Szenarien gewählt und bewertet werden. Bewertungskriterien sindhierbei, 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 Serverbeteiligt 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 eineAntwort anfordert, die nur richtig sein kann, wenn die andere Partei den zugehörigen, geheimenSchlüssel kennt. Bei den Challenge-Response-Verfahren wird zwischen symmetrischen undasymmetrischen 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 anderezum Entschlüsseln genutzt.5.1 ZertifikateZertifikate wurden bereits in Kapitel 3.2 zur Verschlüsselung des Transportkanals mit SSL/TLSbeschrieben. Die Authentifizierung per Zertifikat ist ein alternativer Authentifizierungsmechanis-mus. Grundsätzlich wird hier zwischen Client- und Serverzertifikat unterschieden. In Kapitel 5.2wird der Benutzername/Kennwort-Mechanismus beschrieben. Die Verwendung von Zertifikatenist wesentlich sicherer als die Verwendung von Benutzername/Kennwort-Kombinationen, da einZertifikat einen eindeutigen Benutzernamen mit einer für diesen Benutzer spezifischen asymmetri-schen Verschlüsselung verbindet. Ein entscheidender Unterschied besteht darin, dass der Benutzerdie 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. 45. Authentifizierungsprotokollekann. 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 Abfangenvon 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 öffentlicheSchlüssel und somit das Zertifikat der Zertifizierungsstelle benötigt wird.Die Authentifizierung eines Servers gegenüber einem Client mittels Zertifikaten ist eine Vorstufeder SSL/TLS-Verschlüsselung. Daher findet man die sogenannten Server-Zertifikate sehr häufigvor. 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 Kostenverbunden 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 Rechnersmö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-AuthentifizierungDie einfachste Art der Authentifizierung ist die Basic- und Digest-Authentifizierung nach RFC2617 [Fra99] über den Benutzernamen und ein Kennwort. Diese Methode basiert auf einer öffent-lichen Information, dem Benutzernamen, und einer privaten Information, dem Kennwort, demgemeinsamen 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. 46. AuthentifizierungsprotokolleSowohl bei Basic- als auch bei Digest-Authentifizierung teilen Client und Server ein Geheimnis –ein Kennwort. Die Basic-Authentifizierung bietet einen grundlegenden Zugriffsschutz, jedochwird 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]. DieRealm-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ützteRessourcen 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, Kapitel14.8].Der Nachrichtenfluss für Basic-Authentifizierung soll hier anhand von Szenario 1 beispielhaftdargestellt werden. Der erste Request von Komponente A an Ressource R I auf Komponente Bsieht 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. 47. AuthentifizierungsprotokolleIm Request ist kein Authentication-Header mit zusätzlichen Authentifizierungsinformationen an-gegeben. Da es sich bei Ressource RI um eine geschützte Ressource handelt, erfolgt folgendeChallenge 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 dasAuthentifizierungsschema 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. Realmist 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_0716Das 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 übertragenwird. Andererseits wird weder bei Basic- noch bei Digest-Authentifizierung der Message-Bodyverschlüsselt. Digest ist ausschließlich zum Ersetzen der Basic-Authentifizierung gedacht, damitdas Kennwort nicht mehr lesbar übertragen wird. Ansonsten gelten für Digest dieselben Probleme 42

×