Rechtemanagement in eigener Anwendung - Was ist sinnvoller?

[s.h.a.r.k]

Hallo,

der Titel meines Threads soll schon andeuten, dass es um das Rechtemanagement in einem selbst geschriebenen Programm geht. Hierbei ist eigentlich egal um welches Thema es sich bei der Applikation dreht, es geht nur darum, dass diverse User bestimmte Funktionen ausführen dürfen und andere, aufgrund deren Rechte, eben nicht.

Ich habe bisher vier Ansätze gefunden, wie ich so etwas implementieren könnte. Hierbei stelle ich nun zunächste die simplen Methoden vor, d.h. man kann Rechte eines Benutzer, der gerade mit einer Anwendung arbeitet, nicht ändern. Die zweite eher komplexerer Möglichkeit umfasst dann auch die Änderungen der Rechte während der der Nutzer am Programm arbeitet. Ich hoffe, dass es aus meiner folgenden Erläuterung klar wird, warum ich einmal eine Betrachtung ohne die Änderung und einmal mit der Änderungsmöglichkeit mache.

Ohne Änderung:

• Zum einen könnte man die Rechte fest im Programm definieren. Die Rechte müssen eh zuvor schon feststehen, da man schon eine Menge an Funktionen hat und diese dann entsprechend mit Rechten versieht. Ein Benutzer wird hierbei einer Gruppe zugewiesen und diese hat wiederrum die Rechte eine Funktion auszuführen oder nicht. Ein Benutzerprofil muss sich somit nur merken, in welcher Gruppe "es liegt" und nicht seine einzelnen Rechte.
  Die Abfrage, ob eine Methode ausgeführt werden darf oder nicht, würde ich über eine globale Methode checkRight() laufen lassen, welcher ich den Namen der Methode (oder ähnliches, bsp. eine ID) und die Gruppe übergebe. Diese liefert mir anschließen TRUE oder FALSE (evtl. auch eine größere Menge an Rückgabewerten), welche aussagen, ob die Applikation die Methode ausführen darf oder nicht.
  
  [Start] -> [Aufruf Methode] -> [checkRight()] -> [ausführen, verweigern]
  
• Zum Anderen könnte ich, beispielsweise in einer Datenbank, Benutzerprofil erstellen, in der auch die einzelnen Rechte des Benutzers abgelegt sind (*). Wenn ich die Applikation starte, dann werden die Daten inkl. den Rechten geladen. Will der User z.B. Drucken, dann soll das Programm prüfen, ob er dies, aufgrund der Rechte, die er hat, überhaupt darf und die Ausführung zulassen oder eben auch nicht. Hierbei ist eben zu beachten, dass die Rechte schon im Programm, innerhalb einer Klasse, vorliegen und nicht geladen werden.
  
  [Programmstart] -> [Rechte laden] -> [Aufruf Methode] -> [Recht prüfen] -> [ausführen/verweigern]
  
  * Von mir aus stehen die Rechte auch in einer anderen Tabelle, wobei dann nur eine 1:1-Beziehung entstehen würde, was eine Auslagerung nicht sinnvoll machen würde, da ich dann immer zwei Tabellen anfassen müsste.

Mit Änderungen der Rechte:

• Die Rechte werden hierbei nicht im Programm selbst definiert, sondern jedes Mal, wenn der Benutzer eine Methode ausführen will, lädt die Methode checkRight() das passende Recht nach (z.B. aus einer DB) und prüft dann anhand der Gruppenzugehörigkeit, ob die Methode ausgeführt werden darf oder nicht.
  Das Diagramm dazu sieht dann wie folgt aus:
  
  [Start] -> [Aufruf Methode] -> [loadRight() + checkRight()] -> [ausführen, verweigern]
  
• Will ein Benutzer eine Methode aufrufen und sind die Rechte in einem Benutzerprofil gespeichert, so wird jedes Mal das Recht in seinem, im Programm gehalteten Benutzerprofil aktualisiert und entsprechend wie oben dann die Abfrage gemacht. An dieser Stelle können die Rechte als Eigenschaften in seinem Profil wegfallen und durch get-Methoden ersetzt werden, d.h. ich frage jedes Mal live seine Recht ab.
  Das zugehörige Diagramm ist nun das folgende
  [Programmstart] -> [Aufruf Methode] -> [loadRight() + Recht prüfen] -> [ausführen/verweigern]

Meine Frage ist hierbei nun, welche Methode der Implementierung ist sinnvoller und flexibler?! Welche Methode wirft eurer Meinung nach mehr Probleme auf? Welche hat mehr Vorteile? Hierzu sollten aber die beiden Modelle im Bezug auf die Änderung der Rechte während der Laufzeit unterschieden werden!

Mit freundlichen Grüßen
der Hai

[generic]

Windows erzeugt das Token auch nur bei der Anmeldung neu, deshalb kannst du es auch bei Programmstart laden.
Nachteil:
Ändern sich Rechte, werden diese nicht sofort übernommen.

In meinen Anwendungen nutze ich die Rechteverwaltung von Windows.
Ich schaue ob ein User in bestimmten Sicherheitsgruppen ist.
Diesen Sicherheitsgruppen, lassen sich in meiner Datenbank dann Rechte zuordnen.

Vorteil: Die Admins brauchen nur zu wissen, welche Windowssicherheitsgruppe was erlaubt. Internen Aufbau oder Pflege in der Fachanwendung sind nicht erforderlich.

Diese Modelle setzen vorraus, das der User Zugriff auf die Datenbank hat.
Nachteil: mit einen Sniffer könnte der User die Datenbank (inkl. user/pass) rausfinden und mit Tools sich die Daten anschauen.

2 Möglichkeiten
1)
- die Datenbank prüft alle Rechte über Storedproceduren.
- auf Tabellen wird kein Zugriff gewährt

2)
- du baust einen Dienst/Webservice dazwischen, welcher die Daten filtert und liefert.
- ggf. mit Kerberosauthentifizierung um an das Token des Users zu kommen.

[Union]

Ich halte es für besser, wenn die Änderungen "Online" erfolgen können. Es gibt dabei aber auch Nachteile:

• Die Abfragen können die Performance stark beinträchtigen, besonders bei Verknüpfung mit TAction, da diese permanent während des Idling abgefragt werden. Dies kann man aber durch nur einmaliges Einlesen verhindern (dann ist es aber nicht mehr wirklich "Online") oder durch eine entsprechende Zeitabfrage, damit die Rechte nur alle x Sekunden ereneut abgefragt werden.
• Wird dem Benutzer ein Recht entzogen, während er sich in einer Bearbeitung befindet, kann dies dazu führen, dass er Vorgänge nicht vollständig abschliessen kann.

Bei der Rechteverwaltung halte ich eine Kombination von Benutzer- und Gruppenrechten für sinnvoll. Dies vereinfacht die Verwaltung. So kann man z.B. einen bestimmten Benutzer der Gruppe "Buchhaltung" zuordnen, ihmn aber nur das Recht "Jahresabschluß" entziehen. Bei einer Verwaltung nur mit Benutzerrechten müsste man dem Benutzer alle Rechte der Buchhaltung erteilen bis auf den Jahresabschluß. Auch vereinfacht dies die schnelle Erweiterung der Rechte ganzer Benutzerguppen.

Wenn Du die Benutzerverwaltung in einem existierenden System einführen willst, musst Du auch entsprechende Prüfroutinen einbauen, die allen Benutzern beim ersten Mal sinnvolle Rechte erteilen oder einen Admin festlegen, der dann diese Arbeit machen kann. Auch beim Hinzufügen von neuen Funktionalitäten ist daran zu denken, dass diese beim Update sich automatisch in die Rechtetabelle eintragen.

Zur Speicherung würde ich folgendes Schema vorsehen:

• Benutzer [BenutzerID]
• Gruppen [GruppenId]
• Rechte [RechtId]
• Benutzergruppen [GruppenId * BenutzerId]
• Benutzerrechte [BenutzerId * RechtId]
• Gruppenrechte [GruppenId * RechtId]

Nicht zu unterschätzen ist auch eine stabile und gut bedienbare Benutzer- und Rechte verwaltung, sonst legen die Benutzer das System innerhalb kürzester Zeit komplett lahm.