best practice

fsicher

Bekanntes Mitglied
Hallo allerseits

Da ich mit meiner Anfrage

http://www.java-forum.org/mobile-geraete/123059-session-id-verwalten.html

bis heute nicht weiter gekommen bin, versuche ich hier die Frage etwas allgemeiner zu stellen. Hoffentliche, erfahre ich mehr.

In einer Anwendung, die mehrere Schnittstellen zur Verfügung stellen muss (WebAnwendung mit JSF, Android App, SOAP-WebServices (JAX-WS) und RESTfull-WebServices (JAX-RS)), muss sichergestellt werden, dass diese nur von angemeldeten Benutzer verwendet werden darf. Die Frage ist: Wo prüfe ich, ob der Benutzer angemeldet ist, bevor ich ihm den Zugriff auf die Funktionalitäten der Anwendung gewähre oder ihn mit einer passenden Meldung zum Anmeldungsformular weiterleite?

Ich habe folgende Situation:

Code:
---------------      ---------------     ---------------
-     JSF     -      -    JAX-RS   -     -   JAX-WS    -
---------------      ---------------     ---------------

--------------------------------------------------------
-                     Business Logic Layer             -
--------------------------------------------------------

--------------------------------------------------------
-              DAO Layer  (mit Hibernate)              -
--------------------------------------------------------

Die untersten zwei Layer sind schon implementiert, und in der obersten Etage ist JSF-Layer schon implementiert.

Ich war der Meinung, dass die Kontrolle, ob ein Benutzer angemeldet ist oder nicht und falls ja, was für eine Rolle er hat (Administartor, Superuser, Standarduser ...), oberhalb des Business Logic Layers stattfinden muss. Ein wichtiger Grund dafür ist die Navigation:

  • Wenn ein Administrator angemeldet ist, bekommt er alles zu sehen und kann auch alles machen.
  • Ist ein Standard-Benutzer angemeldet, bekommt er weniger zu sehen und kann dementsprechend auch weniger machen.

Diese Prüfung gehört aus meiner Sicht nicht in Business Logic Layer.

Bei der JSF-Schnittstelle habe ich dies mit Hife des Session-Objekts realisiert. Wenn sich ein Benutzer anmeldet, lege ich seine Rolle in die Sitzung ab. Bevor auf eine Anfrage reagiert wird, wird zuerst geprüft, ob der Benutzer angemeldet ist und falls ja, welche Rolle er hat. Erst dann wird entschieden, wie es weiter geht bzw. wass der Benutzer zu sehen bekommt.

Bei der Reslisierung der App (für Android) sind bei mir diverse Fragen aufgetaucht.
  • Wenn sich ein Benutzer korrekt anmeldet, bekommt er erst dann die Activity zu sehen, die er sehen darf. So übernehme die App die Kontrolle darüber, wer was sehen und machen darf. Die Folge wäre, dass ich im JAX-RS Layer auf dei Überprüfung der Anmeldung und der Rolle verzichten könnte.
  • Ich versuche, ähnlich wie bei der JSF-Lösung, die Rolle in der Sitzung zu verwalten.

Das Problem im ersten Fall ist, dass man auf die Funktionalitäten der Anwendung aus einem Browser durch das einfache Eingeben der URL zugreifen könnte, ohne sich angemeldet zu haben. Denn, das JAX-RS Layer übernimmt keine Überprüfung, ob der Benutzer korrekt angemeldet ist oder nicht. Aus meiner sicht: unbrauchbar

Im zweiten Fall muss ich irgendwie das Sitzungsobjekt noch verwalten (als HttpClient wird Apache HttpClient verwendet). Wie macht man dies?

  • Die Lösung mit Cookies wäre eine Alternative, aber meines Wissens gibt es kein Standard für Cookies und je nach eingesetztem Server könnte es Probleme geben.
  • Müsste ich die ganze zeit mit einer HttpClient-Instanz arbeiten? Oder, könnte ich in jeder Methode eine neue HttpClient-Instanz erstellen (pro Client-System und Server gebe es ein Cookie)?

Wie geht man in einem solchen Fall vor? Sind meine Überlegungen bezüglich Login-Prüfung "im grünen Bereich", ober voll daneben? Und, wie macht man das im Falle einer App?

Vielen Dank.
 

mvitz

Top Contributor
Ich denke es hilft für das Verständnis, wenn man das ganze nochmal in zwei Bereiche aufteilt:
1. Das Recht eine Aktion auszuführen.
2. Das Anzeigen/Ausblenden von Links/Masken die der Nutzer nicht sehen darf.

Aus diesem Grunde, bin ich der Meinung, dass du hier auf jeden Fall die Security "2mal" implementieren muss. Einmal zwischen GUI und Business und eben einmal sozusagen in der GUI (zumidnest für JSF und Android musst du dort ja auch unterscheiden).
 

freez

Top Contributor
Aus diesem Grunde, bin ich der Meinung, dass du hier auf jeden Fall die Security "2mal" implementieren muss. Einmal zwischen GUI und Business und eben einmal sozusagen in der GUI (zumidnest für JSF und Android musst du dort ja auch unterscheiden).

Das klingt etwas merkwürdig. Natürlich muss er in der GUI, egal welche GUI es ist, auf Zugriffbeschränkungen reagieren, aber diese werden zentraler geregelt.
 

fsicher

Bekanntes Mitglied
... , aber diese werden zentraler geregelt.

Das heisst, man soll es nicht zweimal (redundant) implementierten: O.K.

Ich hatte zuerst vor, einen AccessRightsManger zu implementieren. Da hätte ich alles zentral, jedoch stellt sich die Frage, wo dieser Manger untergebracht werden soll:

  1. In GUI Layer (z. B. JSF-Layer)?
  2. Im BusinessLogik Layer? Denn, er muss etwas vom Business verstehen, um zu entscheiden, ob die Zugriffsrechte gewährt werden oder nicht? Ausserdem kann die BusinessLogic, vor dem Gewähren eines Zugriffs direkt prüfen, ob die gewünschte Aktion erlaubt ist oder nicht.
  3. In einem separaten Layer?

Zum Punkt 1:
Wenn ich es im GUI-Layer habe, kann ich die Navigation (Anzeige von Formularen / Masken) gut regeln. Dab Problem ist aber, dass das BusinessLayer von unten nach oben Anfragen bezüglich Zugriffsrechte senden müsste! Und, dass ein darunterliegende Layer etwas von einem höher liegenden Layer verlangen soll, scheint mir nicht korrekt zu sein. Also, GUI-Layer fällt weg.

Zum Punkt 2:
Die oberen Layers müssten auf das darunterliegende Layer zugreifen, um die Authorisierungsinfos zu erhalten und die Navigation korrekt abzuwickeln, was zu einer stärkeren Kopplung führt. Des Weiteren könnten sich die "festen Vorgaben" aus BusinessLogic-Layer auf den Spielraum bei der GUI-Implementierung evtl. negativ auswirken.

Wenn der AccessRightsManager in einem separaten Layer realisiert wird, habe ich ein ähnliches Problem: wo kommt deieses Layer hin? Möglicherweise so:

Code:
---------------      ---------------     ---------------     -------
-     JSF     -      -    JAX-RS   -     -   JAX-WS    -     ¦     ¦
---------------      ---------------     ---------------     ¦  A  ¦
                                                             ¦  R  ¦
--------------------------------------------------------     ¦  M  ¦
-                     Business Logic Layer             -     ¦     ¦
--------------------------------------------------------     -------

--------------------------------------------------------
-              DAO Layer  (mit Hibernate)              -
--------------------------------------------------------

ARM --> AccessRightManager

Dieser Ansatz bietet den Vorteil, dass die Implementierung zentral wäre. Jedoch bleibt ein Problem ungelöst: die "fixen Vorgaben" könnten weiterhin den Spielraum bei der GUI-Implementierung evtl. stark einschränken. Und, da komme ich irgendwie nicht weiter ...

Es läuft doch auf das hinaus, was mviz geschrieben hat: vermutlich muss man es irgenwie logisch trennen. Dann hätte ich in meinem ARM-Layer zwei Teile: BusinessLogic- und GUI-Teil. Während der BusinessLogic-Teil immer fix bleiben würde, könnte man den GUI-Teil, je nach eingesetzte GUI-Framework, anpassen.

Oder, hat jemand eine bessere Idee? War jemand mit solchen Problemen schon konfrontiert, und falls ja, wie hat man es gelöst?

Danke.
 

TheDarkRose

Gesperrter Benutzer
Schau dir doch mal JAAS an. Ist defacto Java EE Standard. Vorallem wird da viel mit Annotationen gearbeitet, was vieles erleichtert. Einfach deine EJB mit den Rollen deklarieren, im Application Server wird dann JAAS konfiguriert. Die Einbindung von JAAS in JSF ist auch relativ einfach.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
T Best Practice überprüfen von Übergabeparametern Allgemeine Java-Themen 17
S best practice: Einordnung Enitity und Datenklasse Allgemeine Java-Themen 11
temi best practice: Parameter überprüfen, wo? Allgemeine Java-Themen 9
Airwolf89 JUnit: Vorschläge/ Best Practice Allgemeine Java-Themen 7
M Best Practice: Daten aufnehmen-speichern-bereitstellen Allgemeine Java-Themen 8
H Best Practice zu vielen konstanten Objekten? Allgemeine Java-Themen 10
J Input/Output Dateien bearbeiten - "Best Practice" Allgemeine Java-Themen 3
R Statische Klasse: Best practice mit flags (2) Allgemeine Java-Themen 3
musiKk Best Practice für kleine Variationen in gegebenen Modellklassen Allgemeine Java-Themen 11
J Best Practice für implementierung von equals(...) Allgemeine Java-Themen 7
Daniel_L Best Practice zum Löschen von Log-Files? Allgemeine Java-Themen 8
Ameise03 Best&Worst Case bei Insertionsort Allgemeine Java-Themen 10
S Best Practices CopyConstrutor mit ArrayList Allgemeine Java-Themen 1
F Error Logging - best practices? Allgemeine Java-Themen 3
M Best Practices für Undo/Redo Allgemeine Java-Themen 16
G Best Practices Software-Engineering‏ Allgemeine Java-Themen 3
G Best Practices Allgemeine Java-Themen 10
M Best Practices Exception Handling für eigene library Allgemeine Java-Themen 8
S best practise Allgemeine Java-Themen 6
S Array: Anzahl Elemente mit best. Wert zählen Allgemeine Java-Themen 4
M Best Match / Best Fit auf Strings Allgemeine Java-Themen 9

Ähnliche Java Themen

Neue Themen


Oben