Skip to content
May 10 15

dotnet Cologne 2015

by Melanie Eibl

Dieses Mal haben wir wieder einen neuen Rekord bei den Ticket-Verkäufen hingelegt: 232 Sekunden hat es von der ersten Anmeldung bis zum ersten Teilnehmer auf der Warteliste gedauert. Die Konferenz hat wie immer sehr viel Spaß gemacht. – Wir sehen uns nächstes Jahr wieder ;-)

080515RP

080515RP

080515RP

http://dotnet-cologne.de/2015.MainPage.ashx

Feb 23 15

OAuth 2.0

by Melanie Eibl

Im Vergleich zu OAuth 1.0 ist OAuth 2.0 komplett überarbeitet und eigenständig. Es ist in RFC 6749 beschrieben: https://tools.ietf.org/html/rfc6749

May 15 14

Die dotnet Cologne 2014

by Melanie Eibl

Die dotnet Cologne war dieses Jahr innerhalb einer halben Stunde aufverkauft. Das war eine große Überraschung für uns. Mittlerweile freuen wir uns jedes Jahr auf viele bekannte Gesichter und auch auf solche Teilnehmer, Sprecher und Sponsoren, die neu hinzu kommen.

http://dotnet-cologne.de/2014.MainPage.ashx

Jun 28 13

//build/ 2013

by Melanie Eibl

IMG_1638

IMG_1648

IMG_1718

https://channel9.msdn.com/events/build/2013

May 7 13

Die dotnet Cologne 2013

by Melanie Eibl

Am 03.05.2013 fand die insgesamt fünfte dotnet Cologne statt. Es war meine vierte Veranstaltung, bei der ich mitgewirkt habe und wieder einmal war das Feedback der Teilnehmer, Sprechern und Sponsoren sehr gut, was für mich eine wunderbare Entlohnung für die Arbeit im Vorfeld ist. Ich möchte mich an dieser Stelle ganz besonders bei Stefan Lange, Roland Weigelt und Albert Weinert für die gute Zusammenarbeit bei der Organisations im Vorfeld bedanken, sowie Herrn Hartmut Weinert, der als Event-Manager an seinem Geburtstag (!!!) mal wieder alles im Griff hatte.

GH6C4941

Nun heißt es “Nach der dotnet Cologne ist vor der dotnet Cologne” und wir werden kurzfristig ein Review ansetzten, Danksagungen schreiben, Rechnungen bezahlen und die Vorplanung für nächstes Jahr auf den Weg bringen. Ich freue mich schon!

Jun 1 12

Delegation mit OAuth 1.0

by Melanie Eibl

In lokalen Systemen gibt es meist eine zentrale Instanz zur Authentifizierung und Autorisierung von Nutzern. Im Internet möchte man solche zentralen Instanzen möglichst vermeiden und setzt auf andere Mechanismen zur Authentifizierung und Autorisierung. In verteilten Systemen stehen Autorisierungsinformationen oft in Form von Metadaten an der geschützten Ressource. Grundsätzlich wird zwischen Impersonation und Delegation unterschieden. Bei der Impersonation gibt der Besitzer der Ressource seine persönlichen Authentifizierungsinformationen an den Client weiter, der sich dann gegen den Server mit diesen Authentifizierungsinformationen authentifiziert. Der Client nimmt die Identität des Besitzers der Ressource an und der Server erhält keine Kenntnis davon, wer sich tatsächlich authentifiziert. Bei der Delegation handelt der Client im Auftrag des Besitzers der Ressource, d. h. der Besitzer der Ressource authentifiziert sich beim Server und gibt das Ergebnis an den Client weiter, der daraufhin Zugriff auf die geschützte Ressource des Servers erhält [Kri08, S. 69 f].

OAuth-Rollen und -Begriffe nach RFC5849 [Ham10]

Das OAuth 1.0 Protokoll ist ein offener Standard und spezifiziert in RFC 5849 [Ham10] delegierten Zugriff auf geschützte Ressourcen. Es dient dazu, Dritten den Zugriff auf geschützte Ressourcen zu erlauben. Das OAuth-Protokoll führt für das traditionelle Client-Server-Modell eine dritte Rolle ein, die des Ressource Owners. Nun ist also nicht mehr der Client der Eigentümer der Ressource, sondern er handelt lediglich noch in dessen Auftrag [Ham10, Kapitel 1]. In dem hier folgenden Szenario sind folgende OAuth-Rollen von Bedeutung [Ham10, Kapitel 1.1]:

  • Client

    Der Client ist ein HTTP-Client, der in der Lage ist, OAuth-authentifizierte Requests abzusetzen. Er ist also die Entität, welche auf eine Ressource zugreifen möchte, die ihm nicht gehört, handelt aber im Auftrag des Besitzers der Ressource.

  • Server

    Der Server ist ein HTTP-Server, der in der Lage ist, OAuth-authentifizierte Requests anzunehmen. Der Server ist die Entität, welche geschützte Ressourcen bereitstellt.

  • Resource Owner (Besitzer der Ressource)

    Der Resource Owner ist die Entität, die in der Lage ist, auf eine geschützte Ressource zuzugreifen und zu kontrollieren, indem sie sich mit ihren Credentials (Zugansdaten) beim Server authentifiziert. Dem Resource Owner gehört die Ressource. Dabei ist eine geschützte Ressource eine zugriffsbeschränkte Ressource, die vom Server bereitgestellt wird und über einen OAuth-authentifizierten Request abgerufen werden kann.

Bei OAuth kann der Besitzer einer Ressource (Ressource Owner) einem Dritten (Client) die Erlaubnis erteilen, auf seine privaten Ressourcen zuzugreifen, die von einer anderen Anwendung (Server) verwaltet werden, ohne alle Details seiner Zugangsberechtigung zur anderen Anwendung preiszugeben. Diese Erlaubnis wird in Form eines Tokens und einem passenden Shared-Key ausgedrückt. Damit ist es nicht mehr erforderlich, dass der Ressource Owner dem Client sein Geheimnis preisgibt. Durch die Nutzung eines Tokens ist es möglich, den Zugriff beliebig einzuschränken, d. h. im Umfang der gewährten Rechte und im Hinblick auf die Gültigkeitsdauer. Anwendungsfälle für OAuth findet man z. B. bei Twitter, Yahoo, AOL, Google, Flickr und Amazon.

072513_1140_delegationm1

Abbildung 1: Kommunikationsparter beim OAuth-Protokoll

Der OAuth-Prozess ist vergleichbar mit dem OpenID-Prozess. Die beiden Protokolle haben jedoch unterschiedliche Einsatzbereiche. Die OpenID-Spezifikation beschäftigt sich mit Authentifizierung und Identitätsmanagement, während sich OAuth mit dem delegierten Aufruf von Webservices und dem zentralisierten Autorisierungs- und Datenaustauschprozess beschäftigt. Der Authentifizierungsprozess spielt bei OAuth eine untergeordnete Rolle.

OAuth Nachrichtenfluss

072513_1140_delegationm2

Abbildung 2: Sequenzdiagramm – OAuth Protokollfluss

Der OAuth-Protokollfluss ist in Abbildung 2 in einem Sequenzdiagramm abgebildet. Hierbei sind die Nachrichten neben den in RFC 5849 [Ham10] spezifizierten um solche ergänzt, die in den hier dargestellten Szenarien ebenfalls von Bedeutung sind:

  1. Der Ressource Owner übermittelt dem Client einen Request, eine Aufgabe auszuführen.
  2. Der Client fragt die Ressource an.
  3. Der Server antwortet mit einer Challenge.
  4. Der Client fordert vom Server ein Set temporäre Credentials in Form eines Identifiers und einem gemeinsamen Geheimnis an. Der Server sendet die temporären Credentials im Response.
  5. Der Client sendet zusammen mit den temporären Credentials einen Redirect zum Server an den Ressource Owner.
  6. Der Redirect führt zum Authentication-Reqest des Ressource Owners an den Server.
  7. Der Server sendet dem Ressource Owner eine HTML-Seite zur Eingabe der Login-Informationen und der zu delegierenden Rechte im Response.
  8. Der Ressource Owner sendet in einem erneuten Request die angeforderten Informationen an den Server und bestätigt ihm damit, dass er den Zugriff auf die geschützte Ressource durch den Client erlauben möchte. Der Ressource Owner autorisiert somit den Server, dem Client den Zugriff auf die geschützte Ressource zu gewähren.
  9. Der Server validiert den Request und initiiert einen erneuten Redirect vom Server über den Ressource Owner auf den Client.
  10. Der Redirect führt zum Request vom Ressource Owner an den Client.
  11. Der Client nutzt die temporären Credentials, um einen Satz Token-Credentials beim Server zu erhalten, welcher den Zugriff auf die geschützte Ressource ermöglicht.
  12. Der Server antwortet mit den Token-Credentials.
  13. Der Client quittiert die Erledigung der Aufgabe an den Ressource Owner.

Der vereinbarte Schlüssel wird während der gesamten Kommunikation zwischen Konsumenten und Providern innerhalb eines Requests mit angegeben.

 

 

[Ham10] E. Hammer-Lahav. (2010, Apr.) RFC 5849 – The OAuth 1.0 Protocol. [Online]. http://tools.ietf.org/html/rfc5849

[Kri08] Walter Kriha and Roland Schmitz, Internet-Security aus Software-Sicht. Berlin Heidelberg: Springer-Verlag, 2008.

Jun 1 12

Authentifizierungsprotokolle

by Melanie Eibl

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

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

Zertifikate

Die Authentifizierung per Zertifikat ist ein alternativer Authentifizierungsmechanismus. Grundsätzlich wird hier zwischen Client- und Serverzertifikat unterschieden. Die Verwendung von Zertifikaten ist wesentlich sicherer als die Verwendung von Benutzername/Kennwort-Kombinationen, da ein Zertifikat einen eindeutigen Benutzernamen mit einer für diesen Benutzer spezifischen asymmetrischen Verschlüsselung verbindet. Ein entscheidender Unterschied besteht darin, dass der Benutzer die verwendeten Schlüssel nicht auswendig kennen und selbst manuell angeben muss. Stattdessen übernimmt dies der Web-Browser, welcher Zertifikate importieren und automatisch verwenden kann. Daher sind Zertifikatsschlüssel in der Regel sehr viel länger als es Kennwörter aus praktischen Gründen sein könnten.

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

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

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

Basic- und Digest-Authentifizierung

Die einfachste Art der Authentifizierung ist die Basic- und Digest-Authentifizierung nach RFC 2617 [Fra99] über den Benutzernamen und ein Kennwort. Diese Methode basiert auf einer öffentlichen Information, dem Benutzernamen, und einer privaten Information, dem Kennwort, dem gemeinsamen Geheimnis. Basic Authentifizierung sollte nur in Kombination mit einer SSL/TLS-Verbindung zum Einsatz kommen, um Man-In-The-Middle-Attacken zu verhindern. Diese Kombination 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 Authentifizierungsinformationen abzufragen und dem Client erlaubt, die Authentifizierungsinformationen bereitzustellen. Basic- und Digest-Authentifizierung ist in RFC 2617 [Fra99] standardisiert.

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

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

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

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

072513_1137_authentifiz1

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

072513_1137_authentifiz2

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

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

072513_1137_authentifiz3

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

072513_1137_authentifiz4

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

Der größte Nachteil bei der Basic-Authentifizierung ist, dass das Kennwort im Klartext übertragen wird. Andererseits wird weder bei Basic- noch bei Digest-Authentifizierung der Message-Body verschlüsselt. Digest ist ausschließlich zum Ersetzen der Basic-Authentifizierung gedacht, damit das Kennwort nicht mehr lesbar übertragen wird. Ansonsten gelten für Digest dieselben Probleme wie bei allen anderen kennwortbasierten Systemen [Fra99]. Eine mögliche Angriffsform ist der Wörterbuchangriff (Dictionary Attack).

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

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

Single-Sign-On

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

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

Verbessert wird der beschriebene Mechanismus durch ein Mehrwege-Challenge-Response-Verfahren. Ein bekanntes Beispiel ist das Needham-Schroeder-Authentifizierungsprotokoll, wobei Zufallszahlen mit ausgetauscht werden, um Replay-Attacken zu vermeiden. Das Needham-Schroeder-Protokoll vereint Schlüsselaustausch und Authentifizierung und ermöglicht einen sicheren Datenaustausch in einem dezentralen Netzwerk.

Kerberos ist ein offener Standard, der in RFC 4120 [Neu05] definiert ist und basiert auf dem Needham-Schroeder Protokoll. Kerberos kann als System gesehen werden, welches Nutzer dabei unterstützt, einen sicheren Kanal mit jedem Server innerhalb eines verteilten Systems aufzubauen. Kerberos arbeitet mit verschlüsselten “Tickets”: Nach der Authentifizierung bei einem Kerberos-Server erhält der Client einen “Fahrschein”, der als eine Art Ausweis gegenüber den Diensten im Netzwerk fungiert, die der Client benutzen darf [Neu05].

Ein Single-Sign-On- (SSO-) Mechanismus erlaubt es einem Benutzer, sich mit einer einzigen Authentifizierung an einem gesamten Anwendungsverbund anzumelden. Der Nutzer wird nur einmal – in der Regel bei der Anmeldung – zur Eingabe eines Kennwortes aufgefordert. Solange der Nutzer das System nicht wechselt, ist es nicht notwendig, sich bei einem anderen Server selber zu authentifizieren. Der Nutzer hat nur noch ein Kennwort für verschiedene Dienste und wird auch nur einmal zur Eingabe aufgefordert. Verzeichnisse werden abgeglichen. Dieser Mechanismus birgt jedoch auch ein Sicherheitsrisiko, da ein Angreifer das Ausspähen einer einzigen Benutzeridentität ausreicht, um Zugriff auf den gesamten Verbund zu bekommen. Dies wird aber in den meisten Fällen in Kauf genommen, denn der Vorteil von SSO überwiegt. Nach einer einzigen Anmeldung werden alle Systeme im Anwendungsverbund automatisch und zeitsparend mit den notwendigen Authentifizierungsparametern – den Credentials – versorgt.

Single-Sign-On-Systeme unterscheiden sich in der Art, wie dieses Vertrauensverhältnis aufgebaut wird und wie Authentifizierungsinformationen formatiert und übermittelt werden. Das Ergebnis ist aber immer, dass der Benutzer Anwendungen und Dienste aus anderen Domänen aufrufen kann. Solange das Vertrauensverhältnis besteht, wird der Benutzer als bereits authentifiziert erkannt.

Single-Sign-On in einer Web-Umgebung funktioniert im Grunde ähnlich. Eine zentrale Instanz, der Identity-Provider, fügt nach erfolgreicher Authentifizierung einen Token in den HTTP-Header des Browsers ein. Der Browser sendet diesen Token bei jedem Request mit. Wenn eine Anwendung einen solchen Request erhält, muss eine Komponente den Request zuerst abfangen und die Gültigkeit beziehungsweise Existenz des Tokens überprüfen. Ist der Token gültig, wird der Request zugelassen. Ist der Token hingegen ungültig, wird der Aufrufer zur zentralen Anmeldeinstanz weitergeleitet. Oftmals wird diese abfangende Komponente “Policy Enforcement Point” oder kurz PEP genannt. Für die erstmalige Authentifizierung am Sign-On-, bzw. Ticket-Server sollte der Übertragungskanal mit SSL/TLS gesichert sein. Die Anmeldeinformationen werden damit nicht mehr unverschlüsselt über das Netzwerk übertragen, was das Risiko potenzieller Angriffe drastisch reduziert.

Die Implementierung eines Single-Sign-On- (SSO-) Systems ist relativ aufwändig. Am Markt sind jedoch einige existierende Implementierungen – zum Teil proprietär, zum Teil frei verfügbar – erhältlich. Gebräuchliche Implementierungen für Single-Sign-On- (SSO-) Systeme sind OpenID, Kerberos, OpenAM, Microsoft Passport, Central Authentication Service (CAS) und Shibboleth.

Die Security Assertion Markup Language (SAML) ist ein XML-Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten. Es handelt sich in erster Linie um ein Übertragungsformat. Der Austausch kann auch Domänenübergreifend erfolgen. Der typische Anwendungsfall ist, dass sich ein Nutzer bei einem Single-Sign-On System authentifiziert und anschließend zur Nutzung bestimmter Dienste berechtigt ist. Konkrete Implementierungen, die SAML als Übertragungsformat nutzen, basieren auf einer Vertrauensstellung zwischen Identity Provider und Server, die i. d. R. über den Austausch von Zertifikaten hergestellt wird. Dabei handelt es sich um eine Abhängigkeit, die für das hier zu betrachtende System nicht geeignet ist. Diese Abhängigkeit besteht bei der Nutzung von OpenID nicht.

OpenID

OpenID ist ein Web-Single-Sign-On System, welches aus einem Open-Source-Projekt entstanden und mittlerweile als offener Standard auf der OpenID-Foundation Webseite spezifiziert ist [Ope07]. OpenID ist ein auf öffentlich zugängliche Webseiten zugeschnittener Dienst [Küb11, S. 78]. Über OpenID kann man sich mit einer Identität online über verschiedene Webanwendungen authentifizieren. Es ist also nicht mehr erforderlich, für jede Webanwendung ein eigenes Benutzerkonto zu pflegen, sondern man authentifiziert sich mit einem OpenID Benutzerkonto gegen eine Vielzahl von Anwendungen.

Wie bereits in Kapitel 2.3 für die Ressourcen beschrieben, gilt auch bei der Verwendung eines URI als Benutzerkennung, dass diese weltweit eindeutig ist. Dadurch entfällt die Abhängigkeit von einer zentralen Instanz. Nachteil von OpenID ist, dass ein Angreifer Zugang zu allen verbundenen Anwendungen erhält, wenn er den Dienst selbst erfolgreich angreifen kann [Küb11, S. 78]. Der Nachrichtenaustausch erfolgt zwischen Endpunkten. Diese Endpunkte repräsentieren die Relying Party (RP) und den Identity Provider (IP). Zum Nachrichtenaustausch benutzt OpenID HTTP.

Arbeitsweise des OpenID-Protokolls

072513_1137_authentifiz5

Abbildung 1: Kommunikationspartner im OpenID-Protokoll

In Abbildung 1 werden die Beteiligten Parteien einer OpenID-Authentifizierung dargestellt. Dies sind der Browser des Nutzers (Client), der OpenID-Provider (IP) und die Relying-Party (RP). Die RP ist ein Service Provider, der eine beliebige Ressource zur Verfügung stellt. Im eigentlichen OpenID-Protokoll ist die Ressource nicht auf eine REST-konforme Ressource beschränkt, sondern kann auch ein Service o. Ä. sein. In Abbildung 52 ist der Nachrichtenfluss in einem Sequenzdiagramm dargestellt.

072513_1137_authentifiz6

Abbildung 2: Sequenzdiagramm OpenID-Protokoll

Im Folgenden werden die Nachrichten angelehnt an [Ope07, Kapitel 3] beschrieben:

  1. Der Client möchte auf eine geschützte Ressource der RP zugreifen (Im Protokoll nicht spezifiziert).
  2. Initiation: Die RP leitet auf eine Login-Seite um und fordert den Client auf, seinen OpenID-URI einzutragen. Diese OpenID ist der sog. User-Supplied Identifier.
  3. Der Client übermittelt der RP seinen OpenID-URI bzw. User-Supplied Identifier.
  4. Discovery: Der User-Supplied Identifier muss nicht dem Claimed Identifier entsprechen. Die RP ermittelt mittels Discovery den Claimed Identifier und den OpenID-Endpunkt des IP. Der Discovery-Prozess nutzt hierzu das Yadis-Protokoll oder HTML-Dokumente.
  5. Response der Discovery-Seite mit dem Claimed Identifier.
  6. Key Exchange (optional): RP und IP tauschen ein Geheimnis mittels Diffie-Hellman Key Exchange aus [Res99].
  7. Response aus Key Exchange
  8. Redirect: Als Response auf die Initiation (3) sendet die RP eine OpenID-Authentifizierungs-Request in Form einer HTML-Seite mit einer Redirect-Anweisung zum IP an den Client.
  9. Authentication: Der Redirect auf den IP erfolgt für den Nutzer transparent. Der Browser erzeugt aus Nachricht (8) eine Authentication-Request an den IP.
  10. Der IP empfängt die Authentication-Request des Clients und antwortet mit einer HTML-Seite zur Eingabe den Kennwortes. (Im Protokoll nicht spezifiziert)
  11. Der Client gibt sein Kennwort ein und übermittelt es dem IP. (Im Protokoll nicht spezifiziert)
  12. Redirect: Der IP verifiziert die Identität und erzeugt einen Response in Form einer HTML-Seite mit einer Redirect-Anweisung zur RP an den Client. Die HTML-Seite enthält die Information, ob die Authentifizierung erfolgreich war oder nicht.
  13. Credentials: Der Client übermittelt – für den Nutzer transparent – der RP die Authentifizierungs-Request.
  14. Bei erfolgreicher Authentifizierung und Autorisierung antwortet die RP mit der ursprünglich angeforderten Ressource [Til11, 137 f].

RP und IP kommunizieren indirekt miteinander, d. h. Nachrichten werden über den Client geleitet.

 

[Fie99] R. Fielding et al. (1999, June) RFC 2616 – Hypertext Transfer Protocol — HTTP/1.1. [Online]. http://tools.ietf.org/html/rfc2616

[Fra99] J. Franks et al. (1999, June) RFC 2617 – HTTP Authentication: Basic and Digest Access Authentication. [Online]. http://www.ietf.org/rfc/rfc2617.txt

[Küb11] Sebastian Kübeck, Web-Sicherheit – Wie Sie Ihre Webanwendungen sicher vor Angreifern schützen. Heidelberg, München, Landsberg, Frechen, Hamburg: mitp, 2011.

[Neu05] C. Neuman, T. Yu, S. Hartman, and K. Raeburn. (2005, July) RFC 4120 – The Kerberos Network Authentication Service (V5). [Online]. http://www.rfc-editor.org/rfc/rfc4120.txt

[Ope07] (2007, Dec.) OpenID Authentication 2.0 – Final. [Online]. http://openid.net/specs/openid-authentication-2_0.html

[Res99] E. Rescorla. (1999, June) RFC 2631 – Diffie-Hellman Key Agreement Method. [Online]. http://www.ietf.org/rfc/rfc2631.txt

[Tan03] Andrew S. Tanenbaum, Computernetzwerke. München: Pearson Studium, 2003.

[Til11] Stefan Tilkov, REST und HTTP – Einsatz der Architektur des Web für Integrationsszenarien. Heidelberg: dpunkt.verlag, 2011.

[Tso10] Alexander Tsolkas and Klaus Schmidt, Rollen und Berechtigungskonzepte. Wiesbaden: Vieweg+Teubner Verlag, 2010, TWZ 4536.

Jun 1 12

Identitätsmanagement

by Melanie Eibl

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

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

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

Authentifizierung und Autorisierung

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

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

Zugriffsberechtigung

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

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

Modellierung von Zugriffsrechten mit der Zugriffskontrollliste (ACL)

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

072513_1134_identittsma1

072513_1134_identittsma2

072513_1134_identittsma3

Abbildung 1: Beispiele von Zugriffskontrolllisten

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

Berechtigungsmodelle

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

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

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

 

[Mez08] Christian Mezler-Andelberg, Identity Management – Eine Einführung. Heidelberg: dpunkt.verlag, 2008.

[Tan07] Andrew S. Tanenbaum and Maarten Van Steen, Distributed Systems.: Pearson Education, 2007.

[Til11] Stefan Tilkov, REST und HTTP – Einsatz der Architektur des Web für Integrationsszenarien. Heidelberg: dpunkt.verlag, 2011.

[Tso10] Alexander Tsolkas and Klaus Schmidt, Rollen und Berechtigungskonzepte. Wiesbaden: Vieweg+Teubner Verlag, 2010, TWZ 4536.

 

Jun 1 12

Sicherheit

by Melanie Eibl

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

  • Vertraulichkeit

    Ist die Fähigkeit, Daten vor dem Zugriff unberechtigter Dritter zu schützen.

  • Integrität

    Ist die Fähigkeit, Nachrichten während ihrer Übertragung vor Manipulation zu schützen.

  • Identität

    Ist die Fähigkeit, die Identität der Nutzer nachzuweisen. Die Durchführung eines solchen Nachweises bezeichnet man als Authentifizierung.

  • Vertrauen

    Ist die Fähigkeit, beteiligte Parteien für bestimmte Aktionen zu autorisieren.

Hier werden Mechanismen zur Sicherstellung der Vertraulichkeit und der Integrität beschrieben.

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

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

Verschlüsselung

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

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

Zertifikate

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

Zertifikate spielen in der abgesicherten Kommunikation über das Internet eine wichtige Rolle. Die Kommunikationspartner können damit ihre Identität beweisen und gleichzeitig einen privaten, verschlüsselten Kanal zueinander aufbauen. Ein Zertifikat ermöglicht diese Verschlüsselung. Die Authentifizierung des Kommunikationspartners ist wichtig für das Vertrauen. Sicherheitsproblem hier ist, zu verifizieren, ob der Public Key von einer Webseite wirklich zum gewünschten Kommunikationspartner gehört. Die Garantie selber wird Zertifikat genannt [Kri08, S. 90]. Jedes Zertifikat enthält daher eindeutige authentifizierende Informationen über den Eigentümer des Zertifikats. Dazu gehört die Identität des Antragstellers, die der zertifizierenden Stelle, Gültigkeitsperiode des Zertifikats und natürlich der Public Key des Antragstellers nebst Informationen über die eingesetzten Algorithmen [Kri08, S. 91]. Ein Zertifikat ist im Wesentlichen eine von einer vertrauenswürdigen Instanz, der Certification Authority (CA), digital signierte Bestätigung, dass eine bestimmte Identität und ein bestimmter Public Key zusammen gehören [Kri08, S. 91]. Die CA verifiziert die Identität des Zertifikateigentümers, bevor das Zertifikat ausgestellt wird. Je nach Einsatzfeld des ausgestellten Zertifikats kann die CA auch eine innerbetriebliche Instanz sein, sofern die in den Zertifikaten enthaltenen Public Keys nur innerhalb einer bestimmten Firma bzw. Domäne verwendet 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 Standard, nämlich das X.509 Format der ITU (International Telecommunications Union) [Kri08, S. 90]. Zertifikate lösen das Verteilungsproblem und können zur Authentifizierung eines Systems herangezogen werden.

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

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

Das SSL/TLS-Protokoll funktioniert folgendermaßen: Ein Client versucht, eine Verbindung zu einem mit SSL/TLS gesicherten Service herzustellen. Der Client fordert die Identität des Servers an, der eine Kopie seines SSL/TLS-Zertifikats an den Client sendet. Der Client überprüft, ob das SSL/TLS-Zertifikat glaubwürdig ist. Bei erfolgreicher Überprüfung sendet er eine Nachricht an den Server. Der Server sendet anschließend eine digital signierte Bestätigung zurück, um eine SSL/TLS-verschlüsselte Sitzung einzuleiten. Danach sind Client und Server in der Lage, Daten über einen verschlüsselten, privaten Kanal über das öffentliche Internet auszutauschen. Dieser Sitzungsschlüssel wird auch Session-Key genannt und ist ein gemeinsamer, geheimer Schlüssel, mit dem Nachrichten verschlüsselt werden. Der Session-Key sorgt sowohl für Geheimhaltung als auch für Integrität. Ein solcher Schlüssel wird nur so lange genutzt, wie der Übertragungskanal existiert.

HTTPS

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

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

Unter einem Man-In-The-Middle-Angriff versteht man das Abfangen, das Einfügen, das Löschen und die Modifikation von Nachrichten, sowie das Wiederholen alter Nachrichten und das Umleiten von Nachrichten. Hiervon betroffen sind besonders anonyme Sessions. Beim Abhören von Nachrichten besteht das Problem in der Übermittlung des gemeinsamen Geheimnisses. Schutz davor kann man nur erreichen, wenn sich mindestens der Server authentifiziert und für die gemeinsame 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 robust gegen Man-in-the-Middle Angriffe und ein Abhören von Nachrichten ist ebenfalls nicht möglich, da der private Schlüssel nicht mit übertragen wird.

 

[Die99] T. Dierks and C. Allen. (1999, Jan.) RFC 2246 – The TLS Protocol Version 1.0. [Online]. http://tools.ietf.org/html/rfc2246

[Kri08] Walter Kriha and Roland Schmitz, Internet-Security aus Software-Sicht. Berlin Heidelberg: Springer-Verlag, 2008.

[Res00] E. Rescorla. (2000, May) RFC 2818 – HTTP Over TLS. [Online]. http://tools.ietf.org/html/rfc2818

[Tan07] Andrew S. Tanenbaum and Maarten Van Steen, Distributed Systems.: Pearson Education, 2007.

[Web10] Jim Webber, REST in practice – Hypermedia and Systems Architecture, O’REILLY, Ed. Beijing, Cambridge, Farnham, Köln, Sebastopol, Tokyo, 2010, TWP 9502.

Jun 1 12

REpresentational State Transfer – REST

by Melanie Eibl

Bei Groupware-Systemen besteht oft die Anforderung an hohe Verteilbarkeit und lose Kopplung, damit sich das System an sich ändernde Prozesse dynamisch anpassen kann. Weiterhin spielt Skalierbarkeit, Wiederverwendbarkeit und robuste Implementierung von Komponenten eine entscheidende Rolle, wie auch die Übertragung über das Internet. Hier soll dargestellt werden, wie der REST Architekturstil diesen Anforderungen Rechnung trägt.

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

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

Kernprinzipien für RESTful HTTP nach Tilkov

REpresentional State Transfer (REST) ist ein Architekturstil, der von Roy Fielding in seiner Dissertation entscheidend geprägt wurde [Fie00]. REST ist ein Architekturstil für verteilte Hypermedia-Systeme und basiert auf HTTP. REST bietet eine Reihe von architektonischen Prinzipien, die als Ganzes angewandt die Skalierbarkeit der Komponenten, Allgemeingültigkeit von Schnittstellen, unabhängige Verteilbarkeit (Deployment) von Komponenten erzielen. Dadurch werden Wartezeiten 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 Webanwendungen und Diensten unterschieden werden, die mehr oder weniger konform zu den REST-Prinzipien umgesetzt sein können. Weiterhin ergeben sich nach Tilkov fünf Kernprinzipien für REST [Til11, S. 11]:

  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 miteinander 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 Ressource 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 definierten 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 Concerns) 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-Negotiation).
  5. Statuslose Kommunikation: REST schreibt vor, dass die Kommunikation grundsätzlich statuslos sein sollte. Ist es unbedingt 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.

Da jede Ressource einen weltweit eindeutigen Identifier in Form eines URIs erhält, kann man domänenübergreifend auf sie zugreifen. Daraus resultiert, dass auch Verknüpfungen zu abhängigen Ressourcen über Links anwendungs- und domänenübergreifend weltweit funktionieren. Aus der Forderung nach Statuslosigkeit ergibt sich, dass jede Anfrage/Antwort (Request/Response) völlig autark ist. Manchmal ist es jedoch sinnvoll, einen Zustand zu halten, um bestimmte Abläufe nicht unnötig wiederholen zu müssen. Dazu gehört insbesondere die Authentifizierung. Der Authentifizierungsvorgang kann je nach gewähltem Verfahren ein aufwändiger Prozess sein, der bei jeder Anfrage durchlaufen werden muss. Um dies zu umgehen, kann die einmal festgestellte Identität eines Clients in einem Cookie festgehalten werden. Ein Cookie ist eine clientseitige Ablage von Sitzungsinformationen in Form von Schlüssel-/Wert-Paaren. Cookies werden i. d. R. von Browsern unterstützt. Cookies verlieren i. d. R. ihre Gültigkeit, wenn einer der miteinander kommunizierenden Prozesse geschlossen wird.

Die Verwendung von Standardmethoden erleichtert die Schnittstellenbeschreibung und gewährleistet, dass User-Agents über Standard-Funktionalitäten auf eine Ressource zugreifen können. Populärster User-Agent ist der Browser zum Abrufen von Hypermedia-Dokumenten. Bei der Eingabe eines URIs in der Adresszeile, wird eine Anfrage mit der HTTP-Standardmethode GET (z. B. GET http://www.example.org/tasks HTTP/1.1) ausgeführt. Daneben werden der Anfrage noch weitere Headerinformationen hinzugefügt. Der Service, der die Ressource zur Verfügung stellt, versteht die Methode GET und sendet sie im Body der Antwort die Ressource im bevorzugten Repräsentationsformat.

Repräsentationsformate

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

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

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

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

Hypertext Transfer Protocol HTTP

Der REST Architekturstil basiert auf dem HTTP-Protokoll, welches in RFC 2616 publiziert ist [Fie99]. HTTP ist ein offener und interoperabler Webstandard, der einen Standard-Weg für Anwender aufzeigt, miteinander zu interagieren. Diese Interaktionen basieren auf den Anforderungsmethoden bzw. Verben.

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

Uniform Resource Identifier (URI) sind eine Zeichenfolge, die eine Ressource weltweit eindeutig identifzieren. Der aktuelle Standard für URIs ist in RFC 3986 publiziert [Ber05]. URIs können absolut 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 Aufgabe sind jedoch nur drei von Bedeutung: Scheme (Schema), Authority (Anbieter) und Path (Pfad).

Beispiel aus RFC 3986 [Ber05]:

foo://example.com:8042/over/there

_/ ________________/_________/

| | |

scheme authority path

Das Schema gibt den URI-Typ an, z. B. HTTP, HTTPS oder FTP. Die Authority ist ein optionaler Bestandteil einer URI, der eine Instanz innerhalb eines Domain Name Systems repräsentiert. Auf die Authority folgt ein weiterer Pflichtbestandteil: Der Path. Der Path enthält meist hierarchisch organisierte Angaben, die zusammen mit dem Abfrageteil eine Ressource identifizieren. Wenn eine Authority vorangestellt ist, muss sie mit einem Schrägstrich (“/”) beginnen.

HTTP-Anforderungsmethoden (HTTP-Verben)

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

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

  • GET

    Mit der GET-Methode fordert ein Client eine Ressourcenrepräsentation an, die unter dem angegebenen URI zu finden ist. Eine der wichtigsten Eigenschaften von GET ist, dass man das Ergebnis eines GET-Requests cachen kann, wenn bestimmte Voraussetzungen erfüllt sind. Wenn die im Request angeforderte Ressource im Response-Body enthalten ist, ist der Response-Code 200 (OK). Die GET-Methode erzeugt keine Seiteneffekte, d. h. sie verursacht keine Änderungen an anderen Ressourcen. Außerdem ist GET idempotent, d. h. das mehrmalige Ausführen einer Methode führt zum selben Ergebnis, wie das einmalige Ausführen der Methode [Fie99, Kapitel 9.3].

  • HEAD

    Die HEAD-Methode ist äquivalent zur GET-Methode, wobei aber nicht die Ressourcenrepräsentation selber, sondern nur ihre Meta-Informationen abgerufen werden. HEAD liefert 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 angesprochenen Ressource. Der Response-Status-Code für eine erfolgreich erzeugte Ressource 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 beschreibenden 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 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 gesendeten 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, welche 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 sicher noch idempotent. Der Response-Code ist bei erfolgreicher Modifizierung der Ressource 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) auftreten [Dus10].

Header-Fields werden im Header einer Nachricht transportiert. Hierbei unterscheidet man zwischen Request- und Response-Header. Im Folgenden sollen die hier wichtigsten Header kurz aufgefü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ückgeliefert worden wäre [Fie99].

  • Authorization und WWW-Authenticate

    Im Authorization-Header schickt der Client seine Authentifizierungsinformationen an den Server. Dies kann initial erfolgen oder infolge eines 401 (Unauthorized) Response. Der zugehörige WWW-Authenticate-Header des Response muss in einem 401 (Unauthorized) Response angegeben werden und enthält mindestens eine Challenge, die ein Authentifizierungsschema 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].

 

[Bern96] Tim Berners-Lee, “The World Wide Web: Past, Present and Future,” IEEE Computer, Oct. 1996.

[Fie00] Roy Thomas Fielding. (2000) Architectural Styles and the Design of Network-based Software Architectures. [Online]. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[Til11] Stefan Tilkov, REST und HTTP – Einsatz der Architektur des Web für Integrationsszenarien. Heidelberg: dpunkt.verlag, 2011.

[Fie99] R. Fielding et al. (1999, June) RFC 2616 – Hypertext Transfer Protocol — HTTP/1.1. [Online]. http://tools.ietf.org/html/rfc2616

[Fre961] N. Freed and N. Borenstein. (1996, Nov.) RFC 2045 – Multipurpose Internet Mail Extensions. [Online]. http://www.ietf.org/rfc/rfc2045.txt

[Fre962] N. Freed and N. Borenstein. (1996, Nov.) RFC 2046 – Multipurpose Internet Mail Extensions. [Online]. http://www.ietf.org/rfc/rfc2046.txt

[Ber05] T. Berners-Lee, R. Fielding, and L. Masinter. (2005, Jan.) RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax. [Online]. http://tools.ietf.org/html/rfc3986

[Dus10] L. Dusseault and J. Snell. (2010, Mar.) RFC 5789 – PATCH Method for HTTP. [Online]. http://tools.ietf.org/html/rfc5789