REST nutzt mit Hypermedia eines der grundlegendsten Konzepte des www: die Verknüpfung zwischen Ressourcen und die damit verbundene Steuerung der Applikation. Doch dieses Konzept gilt nicht nur für uns, die wir mit dem Browser interagieren, sondern auch für die Kommunikation von Anwendung-zu-Anwendung.
Doch erfolgt REST immer vom Server bis direkt zum Client? Ab wann ist eine Anwendung vielleicht doch nicht mehr so RESTful, wie sie gegenüber dem Product Owner versprochen wurde? Spätestens mit der Implementierung von Sicherheitskonzepten muss man sich dieser Frage zwingend stellen. Denn wenn man Authentifizierungsinformationen überträgt, kippt ein weiteres Hauptkonzept von REST: die statuslose Kommunikation.
Jens Broos, Developer bei Mayflower, vermittelt Beispiele und Grundgedanken zum Thema Hypermedia und gibt einen Einstieg in die Sicherheitsmechanismen von RESTful WebServices.
Die Präsentation erweitert den Vortrag „RESTful WebServices“ von Paul Seiffert, der am 20.10.2011 gehalten wurde. Den Foliensatz findet man unter:
http://www.slideshare.net/mayflowergmbh/restful-webservices-10103497
2. Rückbesinnung: Grundprinzipien von REST
I Ressourcen mit eindeutiger Identifikation
I Standardmethoden (Verbs)
• GET, HEAD, POST, PUT, DELETE…
I Unterschiedliche Repräsentationen
• XML, JSON, HTML, Image, Video, PDF, uvm.
I Statuslose Kommunikation
I Verknüpfungen / Hypermedia
2
4. HATEOAS - Hypermedia as the engine of application state
I Links bestimmen Möglichkeiten des Clients
I Link wird in Repräsentation eingebettet
I Keine externe Beschreibung notwendig
I Server verwendet Format, das Client versteht
I Anwendungsstatus bestehend aus
• Ressourcenrepräsentation im Client
• serverseitigen Ressourcenstatus
• NICHT aus Sitzungsinformationen
4
5. Hypermedia – Im Browser
I Anchor Elemente
<a href=“http://www.mayflower.de“>Mayflower</a>
I Formulare
<form action=“nextSite.php“ method=“GET/POST“>
5
6. Hypermedia – Anwendung-zu-Anwendung
I Entkoppelung von Client und Server
I Transparenz bei Änderungen an Ressourcen
I Serverseitig steuerbarer Anwendungsfluss
I Reduktion von separaten Metadaten
6
12. REST und Sicherheit
I Warum brauchen wir Sicherheit?
– Geschütze Ressourcen
• Bestellsystem
• Pay Content, z.B. Maxdome
• Nachrichten abrufen
• Kreditkarteninformationen
• Etc.
12
13. Sicherheitsmechanismen unterscheiden
I Nachrichtenorientierte Sicherheit
• Ist Nachricht / Inhalt geeignet geschützt?
• Verschlüsselung, Signatur
• Übertragung über ungesicherten Transportmechanismus
I Transportbasierte Sicherheit
• Ungesicherte Nachricht über gesicherten Kanal
• Vorrangige Nutzung in der Praxis
13
15. SSL und HTTPS
I HTTP über SSL / TSL
I Server beweist Identität gegenüber Client mit Zertifikat
I Zertifikat von vertrauenswürdiger Zertifizierungsstelle
I Clientseitig
• Benutzername / Passwort
• Clientzertifikat
I Keine „Man-in-the-middle Attacken“
I Ignorieren von Proxy-Caches
15
16. Begrifflichkeiten in der Sicherheit
I Der Unterschied liegt im Detail …
• Identifizierung mit einem Benutzernamen
• Authentisierung mit einem Passwort
• Authentifizierung beider Eingaben via Server
• Autorisierung gewährt Recht zum Aufruf einer Ressource
I Im englischen nur: Authentication and Authorization
16
17. HTTP-Authentifizierung
I Ressource für anonymen Zugriff gesperrt
• Rückgabe HTTP Statuscode: 401 Unauthorized
I „Authentication Challenge“
I WWW-Authenticate im Header legt Schema fest
• Basic
• Digest
I Header: „Realm“ - Geltungsbereich der Authentifizierung
I REST Spielregeln: Keine Session aufbauen!
17
18. Beispiel Authentication Challenge
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=“Private Area“
Content-Type: text/html; charset=iso-8859-1
<html>
<head>
<title>Authorization Required</title>
</head>
<body>
You are not allowed to do this.
….
18
19. HTTP Basic Authentication
I base64enc(‘admin‘ + ‘:‘ + ‘secret‘)
• RtaW46c2VjcmV0Cg==
I Im Header
GET / HTTP 1.0
Accept: text/html
Authorization: RtaW46c2VjcmV0Cg==
I Nicht verschlüsselt: Basic ohne weitere Anstrengungen sinnlos
19
20. HTTP Digest Authentication
I Passwort nicht im Klartext übertragen
I Berechnung von Hashwert mit kryptografischer Funktion
• Vorteil: Passwort bleibt geheim
• Ergebnis der Berechnung nennt man „Digest“
I Server informiert Client über Schema, Geltungsbereich und
„nonce“
I Gleicher Berechnungsalgorithmus auf Server und Client
20
23. Die 80% Lösung: HTTPS + Basic Authentication
I Beide Sicherheitsprinzipien ergänzen sich
• SSL tunnelt von Client bis Server
• Authentifizierung durch Basic Authentication
SSL SSL REST
Client WebServer Application
Auth Server
23
24. Cookies – Statefull Poison
I Cookies sind üblicher Weg, Authentifizierungs- bzw.
Benutzerinformationen zu übermitteln
I Umgehen den statuslosen Charakter von HTTP
I Server erstellt Schlüssel/Wert-Paare
I Lieferung des Paare per „Set-cookie“ Header
I Client schickt diese Werte bei jeder Anfrage an gleichen Server
und Pfad in einem Cookie-Header
I Wenn man Cookies nicht verhindern kann, dann zumindest
Auswirkungen begrenzen
24
25. Cookies – Auswirkungen begrenzen
1.) Server berechnet geheimen Wert
2.) Client schickt Logindaten per SSL an Server
3.) Server authentifiziert
4.) Wenn erfolgreich: Server erstellt „Ticket“ oder „Token“
Ticket = hash(Benutzername . “:“ . Secret . “:“ Gültigkeitsdauer)
5.) Server setzt Cookies für Benutzername, Ticket und
Gültigkeitsdauer
6.) Nächster Request: Browser überliefert diese drei Werte
in Form von Cookies als Teil der Anfrage
7.) Browser berechnet Ticket und prüft gegen
25
27. Webserver als „Filter“
I Daten werden je nach Berechtigung im Webserver gefiltert
I Nicht mehr stateless
I Aushebeln von Caching-Mechanismen
SSL REST
Client WebServer Application
Auth Server
27
28. Nur Berechtigungen via SSL verschickt
I Daten für jeden zugänglich
I Daten liegen permanent in verschlüsselter Form vor
I Berechtigungen werden hierarchisch via SSL an den Client
verschickt
unverschlüsselt
Client WebServer Application
SSL
Auth Server
28
30. HMAC Keyed-Hashing for Message Authentication
I Anforderung: Verhinderung von unerlaubter Modifikation
I Nachricht mit Signatur anreichern
I Basis =geheimer Schlüssel, Client und Server bekannt
I Vorteile:
• Stellt sicher, dass Nachricht von vertrauenswürdiger Stelle
stammt
• Ausschluss von Man-in-the-middle-Attacken
I Nachteil:
• Nachricht kann immer mitgelesen werden
30
33. Nachrichtenverschlüsselung und Signatur
I Kein generischer, standardisierter Mechanismus
I Verwendung bestehender Mechanismen auf
Repräsentationsbasis
• Verschlüsseltes PDF
• Generische PGP-Verschlüsselung und –Signatur
• XML Encryption
• XML Digital Signature (XML DSIG)
I Letztendlich bleibt die Frage:
Ist SSL-Übertragung nicht sicher genug?
33
35. OpenID
I Problem: Viele Webseiten, viele Logins
I OpenID: Kooperierende Dienste nutzen einen Authentifizierungsservice
I Zentrale einmalige Registrierung
I Konzept: URL-basierte Identität
I Parteien
• Browser des Endanwenders
• OpenID Provider
• Webanwendung
35
36. OpenID
OpenID
Provider
User WebService
http://idprovi.der/ids/1848
36
37. OAuth
I Anforderung: „Übertragung“ der Rechte an andere Anwendung
I Notwendig: Spezifische, eingeschränkte Autorisierung
I Parteien
• Service prodiver
• Consumer
• User
37
41. Hypermedia – Checkliste
I Keine Abhängigkeiten von spezifischen Kommunikationsprotokollen
I Bestehende Methoden dürfen durch API nicht geändert werden
(PUT bleibt PUT, etc.)
I Keine fixen Ressourcennamen oder Hierarchien
I Ressourcen sind nicht getypt, nur deren Repräsentation
I Kein Wissen über spezifische URIs
• Ausnahme: Einstiegspunkt
• Alle anderen Links werden „entdeckt“
41