Benutzerrecht in der Anwendung neu strukturieren

[DaBe1812]

Hi,

ich habe (mal wieder) eine Bremse im Kopf.

Wir müssen bei unserer Anwendung die Rechte umstrukturieren. Zukünftig sollen alle Menüpunkte an einem eigenen Recht hängen:
Der User soll Hardware importieren können --> Der User braucht das HW Import Recht
Der User will IPs ändern können --> Der User braucht das IP-Ändern recht
...

Außerdem soll das ganze zukünftig dynamisch sein und ohne Deployment anpassbar sein.

Was ich bisher habe ist eine Tabelle mit meinen Menüpunkten, in denen das benötigte Recht, allerdings aktuell als ENUM, in einer Spalte gehalten wird.

Das System funktioniert auch aktuell, aber eben nicht dynamisch ohne Deployment.

Was ich machen will ist eine Tabelle, in der ein "Interner Name für ein Recht" in einer Spalte steht und der Name der AD-Gruppe in der zweiten Spalte, so könnte man zum Testen einfach irgendwelche AD-Gruppen hinter ein Recht verpacken, bzw. später könnte man schon das Recht in der Tabelle definieren, hat aber vielleicht noch keine AD-Gruppe dazu.

Allerdings tue ich mich gerade schwer damit das in einer UserBean zu handeln.

Aktuell ist es so, dass ich eine Bean habe, die zum Serverstart die aktuelle Übersetzung lädt (für eine Änderung hier bräuchte ich in der Firma wenigstens einen Change mit einer Vorlaufzeit von 5 Tagen, also nicht dynamisch), dann lade ich mir die AD-Gruppen vom Benutzer und lege in der Benutzerbean eine Liste an mit den ENUMs, die er laut Gruppen besitzt.
Dann kann ich beim Wechsel des Menüpunkts prüfen, ob er das ENUM in seiner Liste hat, welches für den Menüpunkt benötigt wird (also eigentlich zeige ich die Menüpunkte für die man keine Rechte hat schon garnicht an, aber wenn der Benutzer einen Direktlink verwenden möchte, prüfe ich das nochmal).

Jetzt habe ich irgendwie Hemmungen die Übersetzungs Tabelle zu laden und Einträge aus dieser Tabelle in eine Liste in der UserBean zu packen.

Allerdings fällt mir auch keine Dynamische Methode ein, wie es besser gehen soll.

 

[LimDul]

Ich bin mal ganz naiv und frage wo ist das Problem

• Ein User hat Rollen - das sind die Gruppen, die aus dem AD kommen.
• Eine Aktion braucht Berechtigungen - das sind in der Anwendung intern festgelegte Berechtigungen

Dynamisch soll nun die Zuordnung von Rollen zu Berechtigungen sein, richtig? Oder sollen auch Berechtigungen dynamisch ergänzt werden?

Das heißt, aus meiner Sicht müssen die User ihre Berechtigungen gar nicht kennen.
Was man braucht, ist meines Erachtens eine Komponente/Service die man folgendes fragen kann: Hat Benutzer X die Berechtigung Y? Diese Komponente ist die einzige, die diese Zuordnung kennt - und kann dynamisch aus der DB oder woher immer laden.
Will man auch die Zuordnung von Aktionen zu Berechtigungen dynamisch machen, eine weitere Komponente - die kann ich fragen "Welche Berechtigung brauche ich für Aktion Z". Dann ist die Komponente die einzige, diese Zuordnung kennt.

 

[DaBe1812]

Vielleicht mache ich mir es im Kopf auch viel zu kompliziert.

Aber ja, es sollen auch Rollen dynamisch ergänzt werden können.

Also vielleicht haben heute zwei Menüpunkte dieselbe Rolle und morgen will ich dafür zwei verschieden Rollen, weil der Benutzerkreis für eine Sache weiter eingeschränkt werden muss.

Ich glaube mein größtes Problem im Kopf ist die Liste mit Datenbankobjekten, irgendwie fühlt sich das falsch an, aber vielleicht ist das auch der Weg

 

[Oneixee5]

Ich würde mit den gegeben Informationen etwa so rangehen:
1. Es gibt eine Tabelle Module: ID, Name, Sort, ...
2. Es gibt eine Tabelle Rollen: ID, Name, Sort, ...
3. Es gibt eine Tabelle Zuordnungen: ID, Rolle_ID, Module_ID
4. Es gibt eine Tabelle User: ID, Name, ...
5. Es gibt eine Tabelle Berechtigungen: ID, User_ID, Rolle_ID
So kann ich immer herausfinden, welche Rollen ein User hat und auf welche Module der User Zugriff hat. Falls Rollen und Module eine 1:1 Beziehung haben, dann reicht auch eine Tabelle, das ließt sich aber nicht so.

Beim Login wird ein Principal erzeugt, der Principal hat eine Liste von Authorities. Jetzt kann ich schon beim erstellen des Principal die Authorities aus der DB-Abfrage/Bean erzeugen. Der Server hält den normalerweise auch im Speicher, so dass das nicht bei jedem Request passieren muss. Ansonsten kann man auch einen Cache verwenden. In dem jeweiligen Endpunkt ist der Zugriffsschutz dann nur noch eine Annotation: @RolesAllowed("HW-Import-Recht") (Je nach Framework unterschiedlich)

 

[DaBe1812]

Das mit den Annotations muss ich mir anschauen, das klingt spannend.

Aber die UserTable kann ich mir sparen, hier wird alles über AD geregelt.

Erste Tests mit der Tabelle sahen ganz gut aus, jetzt muss ich nur mit den Menüpunkten langsam machen, weil sonst kann jeder außerhalb meines Branch nicht mehr zugreifen.

 

[Oneixee5]

Das mit den Annotations muss ich mir anschauen, das klingt spannend.

Aber die UserTable kann ich mir sparen, hier wird alles über AD geregelt.

Erste Tests mit der Tabelle sahen ganz gut aus, jetzt muss ich nur mit den Menüpunkten langsam machen, weil sonst kann jeder außerhalb meines Branch nicht mehr zugreifen.

Ja 4. und 5. bekommst du wahrscheinlich vom AD. Die Tabelle Module ist auch eher für die Anzeige in der Anwendung, Hilfelinks, etc.