Rest und Sicherheit

G

grinser

Gast
Hallo,

und zwar möchte ich einen RESTful Service um Sicherheit erweitern. Man findet ja viel rund um dieses Thema, aber so richtige Implementierungen oder Patterns kamen mir noch nicht unter. Deswegen dachte ich mir, erstelle ich diesen Thread um etwas darüber zu diskutieren und mir vielleicht mehr darüber im Klaren zu werden. Korrigiert mich bitte sollte ich bei meinen Aussagen falsch liegen. Auch spreche ich verschiedene Aspekte an, deswegen muss demnach nicht auf alles geantwortet werden. Hoffe jedoch ein paar Antworten die zur Diskussion beitragen zu erhalten :)

Session

Da der Server ja stateless sein soll kommt das halten einer Session nicht in Frage. Gilt das auch für folgendes Vorgehen: Mit dem ersten erfolgreichen authentifizieren erstelle ich auf Serverseite einen Token, welcher zurück zum Client gesendet wird. Damit will ich umgehen, dass bei jedem Aufruf ein Nutzername/Passwort mitgesendet werden muss. Bei jeder weiteren Anfrage wird der Token mitgesendet und in einer Hash Tabelle auf dem Server abgeglichen. Wird der Server dadurch schon stateful oder kann man so vorgehen? Im Buch "Rest und HTTP" von Stefan Tilkov meine ich gelesen zu haben, dass man das stateful in diesem Fall umgehen kann, indem man die Tokens auch als Ressource anlegt. (Oder reicht auch eine einfache Hash Tabelle?)
Ansonsten sollte es doch auch herkömmlich gehen, indem man bei jedem Request die Authentifizierungsdaten mitsendet. Dann sollte doch aber beachtet werden das diese mittels SSL/TLS verschlüsselt werden richtig?
Sollte nun erstere Variante mit dem Token auch funktionieren, gibt es da Konventionen was man bei einem Rest Service vorziehen sollte? Gibt es Vor- oder Nachteile?

SSL/TLS

Um die Daten zu verschlüsseln möchte ich einen Apache meinem Tomcat vorschalten. Die Theorie habe ich verstanden, aber wie wird sowas im Endeffekt realisiert? Auch bei der Google Suche fehlt es an Tutorials und Implementierungen. Vielleicht kennt wer von euch ein nützliches Buch/Tutorial, wie man einen Apache Server aufsetzt und wie das dann mit den Zertifikaten geregelt wird.

Rest Service Sichern

Habe in diesem Fall viel über HTTP Basic und Digest gelesen. Auch waren viele der Meinung man sollte seinen Service mit HTTP Basic zuzüglich SSL absichern. Soweit ich HTTP Basic verstanden habe werden auf Serverseite Nutzername und Passwort abgeglichen. Auch eine Rollenfestlegung gibt es. Diese ist jedoch statischer Natur oder? Wenn ich also Ressourcen habe, wo sich die Zugriffsrechte dynamisch ändern, löse ich das am besten indem ich in der Ressource speicher, wer Zugriff auf diese hat oder?

JAX-RS Frameworks

Gibt es in den vorgesehenen Frameworks wie Restlet, RestEasy, Jersey Sicherheitsuntersützungen oder wird das mit einer Standard HTTP Bibliothek realisiert? Kann dazu wer ein Statement abgeben, falls wer Erfahrungen mit eines der Frameworks hat.

Soweit erst einmal. Ich hoffe natürlich das sich wer an der Diskussion beteiligt :)

Grüße


So, das war es erstmal. Hoffe es finden sich ein paar Antworten auf das Durcheinander.
 

DerFeivel

Bekanntes Mitglied
Ich wage mal nen ersten Ansatz:


@Frage 1:

Irgendwie habe ich gerade den Eindruck, dass du über deine Token-Implementierung einfach nur ne Session nachgebaut hast.
Im Endeffekt ist dann eine Antwort auf Anfrage x auch nur von Token y abhängig. (wenn dieser vorhanden ist, liefert der Dienst bei gleicher Anfrage eine andere Antwort als wenn er nicht vorhanden wäre)
Somit also dann auch zustansbehaftet.

Persönlich würde ich eine saubere Variante, bei der ich die Authentifizierungsdaten -verschlüsselt - mitschicke, weitesgehend immer bevorzugen.


@Rest Service Sichern

Ich kann jetzt leider gerade nur für JBoss und Glassfish aus Erfahrung sprechen. Prinzipiell solltest du aber über JAAS eine SecurityRealm konfigurieren können. (Stichwort: deklarative Sicherheit, siehe auch: Tomcat 6 - Security).

Wenn sich Rollen/Benutzer dynamisch während der Laufzeit ändern sollen, solltest du dir mal eine JDBCRealm antun ;)

@JAX-RS Frameworks

Ich glaube mal gelesen zu haben, dass Resteasy mit diversen Annotationen wie @RolesAllowed o.ä. aufwarten kann. Da ich allerdings meist eine Framework-unabhängige Implementierung anstrebe, (und meistens eh nur die App und nicht einzelne Methoden spezifisch absichere) ....keine Ahnung :D
 

rholzmueller

Mitglied
Ich beschäftige mich auch gerade mit dem Thema und möchte mich an der Diskussion mit beteiligen.

@Session @Frage 1
Hier hat sich mir auch die Frage gestellt, ob jedesmal Login/Passwort (natürlich verschlüsselt) mitgeschickt werden soll, oder ob ein Art Token/Session-Id verwendet werden soll. Ob man eine eigen Token-Implementierung verwendet oder die Cookies (Session-ID) verwendet ist dabei egal. Das Vorgehen ist im Prinzip gleich (Zustand identifizieren anhand einer eindeutigen Id), wobei Cookies sicherheitstechnisch manchmal problematisch sind. Über einen Token/Session-ID kann der zustandlose RestFul Service auf dem Server zu einem zustandsbehafteten Service werden

Vorteil Login/Passwort

  • Authentifizierung wird jedesmal durchgeführt
Nachteil Login/Passwort

  • Authentifizierung ist eine teure Operation (z.B. LDAP-Anfrage)

Vorteile Token/Session-ID

  • nach erstmaliger Authentifizierung durch Login/Passwort ist die Authentifizierung gegen ein Token sehr schnell (nur im Speicher, kein Zugriff auf Fremdsystem)
Nachteile Token/Session-ID
  • zusätzlich Sicherheitsimplementierung gegen Session Hijacking notwendig (Prüfung zusätzlicher Parameter z.B. IP-Adresse, nur POST Parameter, ???)

@SSL/TLS
Natürlich ist die Kommunikation mit SSL abzusichern, kann dir aber leider keine Tutorials empfehlen.

@Autorisierung (wer darf was)
Bei dem Thema bin ich nicht. Falls ich soweit bin und wissenswerte zu berichten habe, ...
 

Ähnliche Java Themen

Neue Themen


Oben