Rechtemanagement (in diesem Fall PHP, aber sicher auch universell)

[ToM80]

Hallo zusammen,

ich sitze wiedermal über einem Puntk über den ich schon so oft gegrübelt habe.
Es geht darum eine Rechtemanagement für einen Loginbereich zu erzeugen. Ich weiß dass es hierfür ein Haufen PHP Frameworks gibt auf die ich zurückgreifen könnte. Aber ich habe die Struktur soweit schon fertig und würde deshalb gern ohne Framework auskommen.

Nun wie wohl in jedem Loginbereich wird es verschiedene Arten von Nutzergruppen geben, denen verschiedene Rechte zugeteilt werden sollen.
Ich könnte jetzt eine ewiglange DB mit J/N oder True/False verfasse, jedoch ist das denke ich nicht zielführend.
Am Ende komme ich immer wieder auf die BIT Vergabe, jedoch erreicht man hier sehr schnell sehr große Zahlen und ich bin mir nicht sicher, ob aus Preformancesicht dies sinnvoll ist.

Hier ein Beispiel für die Bitvergabe:
0 | darf alles | Nur Superadminstrator
1 | darf nichts | Nur Gast
2 | einloggen, Profil ändern
4 | Nachricht schreiben
8 | Bild upload
16 | Dateiupload
32 | Suche speichern
....

Hat ein Nutzer also ein Rechteindex von 26 darf er sich einloggen sowie Bilder und Dateien hochladen.
Somit sind die Rechte mittels Auflösung sehr schnell und einfach ermittelt.
Würdet ihr die auch so vergeben oder habt ihr andere vorschläge?

Grüße

ToM80

 

[kkapsner]

Ich würde ja kein extra Flag für Gast machen: also 0 ist ein Gast und darf nichts. Wenn alle Flags gesetzt sind, ist es ein Supermoderator und darf alles.

 

[jspit]

Die Bitbelegung sehe ich nur als Beispiel. Solange man im 32-Bit-Bereich bleibt, sehe ich da keinerlei Probleme. Mit den BIT-Operatoren kann man bequem filtern. Probleme mit der Performance bei großen Zahen ? PHP ist egal, ob es mit 1 oder 4096 arbeitet.

 

[ToM80]

Guten Morgen,

danke für die Antworten. Die Liste war tatsächlich nur ein Beispiel.
Würde 32-Bit nicht heißen, dass es nicht mehr als 32 verschiedene Rechte geben darf? Das wäre ja schnell erreicht.

Grüße

ToM80

 

[mikdoe]

Bei mir bekommt jedes Recht eine fortlaufende Nummer. Diese Nummern können Profilen zugeordnet werden und die Profile wiederum den Benutzern. Und beim Login werden die Einzelrechte über die Profile gezogen und in der Sitzung zwischengespeichert. Einfach nummerisch durch Komma getrennt. Und bei jedem Scriptaufruf werden diese Rechte gelesen und in ein internes Hash geschrieben. Somit kann ich bei jeder Funktion die Existenz des zugehörigen Hash-Eintrags prüfen und weiß somit, ob für die Funktion Berechtigung besteht.

 

[jspit]

Würde 32-Bit nicht heißen, dass es nicht mehr als 32 verschiedene Rechte geben darf? Das wäre ja schnell erreicht.

Ja, um ganz sicher zu gehen würde ich sogar nicht mehr als 30 nehmen. Für meine Fälle war dies immer ausreichend.
Wenn man mehr braucht und es einfach halten möchte , kann alternativ ein String der Form '00101..' benutzt werden.
Das Filtern erfolgt dann über entsprechende String-Funktionen. Nicht zuletzt lohnt es sich über die Variante von mikdoe nachzudenken.

 

[ToM80]

Ich denke 30 reichen bei mir nicht aus.
Ok, MikeDoes Variante ist natürlich auch machbar aber auch wirklich Sinnvoll bei, sagen wir mal 100 Einzelrechten?
Wie würdet Ihr die Möglichkeit von Hexcodes einschätzen. Also quasi die Farbcodes missbrauchen für die einzelnen Rechte? Mit dem Standardfarbcode wären ja quasi 16 Mio Rechte verfügbar, was natürlich viel zu viel ist.
Aber diese Vergabe müsste sich doch sehr einfach auslesen lassen. Ich frage mich gerade nur ob ich dann beim Kummulieren von verschiedenen Rechten auf das gleiche Ergebnis kommen kann. Bislang bin ich der Meinung das geht nicht. Aber vllt. habe ich was übersehen?

 

[ToM80]

Mir ist gerade was anderes eingefallen.
Ich denke ich bleibe bei den Bits, jedoch werde ich für jeden Bereich einen extra Block hernehmen. Somit sollte och mit den zur Verfügung stehenden Bits auskommen und zeitgleich wird die Rechteverwaltung übersichtlich bleiben.

Im Prinzip wird es dann also so aussehen:

A8
B0
C136
...

 

[Albu]

Wie würdet Ihr die Möglichkeit von Hexcodes einschätzen. Also quasi die Farbcodes missbrauchen für die einzelnen Rechte? Mit dem Standardfarbcode wären ja quasi 16 Mio Rechte verfügbar, was natürlich viel zu viel ist.

Ein Farbcode ist doch auch nur ein 32bit Integer, wie Du da 100te von Rechten mit abbilden willst, die sich beliebig kombinieren lassen, weiß ich nicht.

Ansonsten ist 100 schon eine ziemlich hohe Anzahl, das kann man nicht mehr wirklich überblicken oder administrieren. Zumal es sicherlich auch bestimmte Abhängigkeiten gibt, die man im Admintool aufwändig abbilden müsste.

Wenn eine reine rollenbasierte Zugriffssteuerung nicht in Frage kommt, weil die hardkodierten Rechte und die gewünschten Einstellmöglichkeiten zu einer zu großen Zahl Rollen führen würde oder man sich eine feinere Einstellmöglichkeit wünscht, so kann man eventuell auf Access Control Listen (ACL) zurückgreifen.
Jeder Resource ist dabei eine Liste mit Berechtigungen zugeordnet, die den Zugriff regeln. Dabei ist die Anzahl der individuellen Rechte und der damit benötigten Bits pro ACL-Eintrag relativ gering z.B.: Beiträge lesen, eigene Beiträge ändern, fremde Beiträge ändern, eigene Beiträge löschen, fremde Beiträge löschen, neu, Beiträge freigeben, Berechtigungen ändern, usw.
Das ganze kann man dann noch weiter aufpeppen mit Rollen oder Gruppen, die eine Grobeinstellung von ACL-Rechten für eine größere Benutzergruppe erlauben, mit der Möglichkeit zur Feinjustierung individueller Nutzer. Beim Auswerten der Rechte, werden alle Gruppen- und Individualbits des Benutzers gelesen und verodert, so erhält man die tatsächlichen Rechte des Nutzers und kann entscheiden, ob dieser die gewählte Aktion ausführen darf.

 

[mikdoe]

Ok, MikeDoes Variante ist natürlich auch machbar aber auch wirklich Sinnvoll bei, sagen wir mal 100 Einzelrechten?

Bei mir sind es derzeit 97 Einzelrechte. Und das klappt wunderbar.
Die Einzelrechte sind in einer Tabelle fest verankert. Der jeweilige Admin kann die Profile definieren und somit die Rechte zuordnen.
Bei mir kommt noch hinzu, dass es Rechte gibt, die systemübergreifend sind und welche die bereichsabhängig sind, je nach dem, was funktionell freigeschaltet ist. Das heißt, ich kann auch über die Freischaltung der Funktionsbereiche schon von vornherein für bestimmte Benutzergruppen bestimmte Einzelrechte ausschließen. Die stehen der Benutzergruppe dann garnicht zur Verfügung.

Wenn ich die Bereiche jetzt auf Bitstränge legen müsse stelle ich mir das sehr starr und unflexibel vor. Denn bei mir bewegen sich die Sachen auch hin und wieder. Und das stelle ich mir nicht ganz einfach vor, wenn die Bereiche geknubbelt sind.

Das zugrundeliegende Konzept sieht quasi die Rolle Hauptadmin vor, der nur Benutzergruppen und deren Funktionsbereiche definiert. Innerhalb der Benutzergruppen gibt es jeweils nochmal beliebig viele Admins, die dann die Profile mit den Einzelrechten und am Ende auch die reellen Benutzer definieren. Somit ist das ganze glasklar und transparent auf zwei Ebenen aufgeteilt und die Administration funktioniert wunderbar.

 

[jspit]

Ich denke 30 reichen bei mir nicht aus.
Ok, MikeDoes Variante ist natürlich auch machbar aber auch wirklich Sinnvoll bei, sagen wir mal 100 Einzelrechten?
Wie würdet Ihr die Möglichkeit von Hexcodes einschätzen. Also quasi die Farbcodes missbrauchen für die einzelnen Rechte? Mit dem Standardfarbcode wären ja quasi 16 Mio Rechte verfügbar, was natürlich viel zu viel ist.
Aber diese Vergabe müsste sich doch sehr einfach auslesen lassen. Ich frage mich gerade nur ob ich dann beim Kummulieren von verschiedenen Rechten auf das gleiche Ergebnis kommen kann. Bislang bin ich der Meinung das geht nicht. Aber vllt. habe ich was übersehen?

Wenn du 100 Rechte als Bits hexadezimal abbilden möchtst, brauchst du einen String von 25 Hexzahlen, genau 4 Bit pro Hexzahl. Der Vorteil wäre daß du diese in einer einfachen Variablen hast, den du aber mit einem höheren Aufwand bei der Codierung/Decodierung erkaufen musst, um gedachte Bits abzufragen bzw. zu setzen.

 

[ToM80]

Hi,

ja ich gebe zu das mit den HexaCodes war nicht durchdacht. Ich hab mich am Anfang davon leiten lassen, dass man halt
000000 Recht 1
00000f Recht 2...
hernimmt. Aber das ist ein völliger Schmarn, weil er riesen Rechenaufwand bedarf.
Die ACL Methode hört sich sehr gut an. Ich wußte erst nicht wie man soetwas realisieren soll, da ich bisher davon ausgegangen bin, auf jeder Seite entsprechende Rechteabfragen zu machen, weshalb sich mir der Vorteil einer solchen Liste nicht erschließen lies. Allerdings bin ich dann auf http://www.net-developers.de/blog/2008/12/23/erste-version-der-acl-access-control-list/ gestoßen. Das sieht in meinen Augen sehr viel versprechend aus.
Nun muss ich allerdings mir immer noch klar werden, wie ich die einzelnen Schreibrechte abbilde. Der Zugriff auf eine Seite lässt sich damit aufjedenfall einfach festlegen. Aber die Aktionen auf der Seite bedarf es wohl weitere Parameter, bzw. abfragen. Hier könnte man ggf. mit gecachten Seiten arbeiten um den Rechenaufwand auf dem Server zu minimieren.
@Mikedoe, ich steige an deinem Vorschlag immer noch nicht so ganz entlang. Könntest du mir mal ein Scriptbeispiel dafür geben?

 

[mikdoe]

@Mikedoe, ich steige an deinem Vorschlag immer noch nicht so ganz entlang. Könntest du mir mal ein Scriptbeispiel dafür geben?

Scriptbeispiel geht nicht, zieht sich ja durch das ganze Projekt.
Nachdem ich die Einzelrechte in der Session serverseitig einmalig beim Login hinterlegt habe wird der Parameter ja bei jedem Request gezogen. Danach entscheided das Script 1. welche Menüpunkte überhaupt angezeigt werden und 2. ob bei Aufruf eines Menüpunkts (Formular kann ja gefaket sein) tatsächlich die Berechtigung besteht.

Beispiel: User hat die Rechte 2,6,12,20 usw.
Es kommt der Request "Hauptmenü". Nun rödelt das Script durch alle Menüpunkte und schaut nach. Z.B. Menüpunkt "Passwortänderung", Berechtigung 6 vorhanden oder nicht vorhanden? Wenn vorhanden, Menüpunkt anzeigen usw.
Und bei Aufruf der Funktion selbst wird ebenfalls nochmal geschaut, ob im Berechtigungsstring ",6," enthalten ist, dann ausführen sonst Fehlermeldung wg. fehlender Berechtigung anzeigen.

 

[ToM80]

Hi danke. Genau so. Hatte ich es in älteren Projekten gehandhabt. Das sieht mir aber halt nicht elegant genug aus. Ich denke ich werde mein Glück mit den ACLs veruchen.

 

[mikdoe]

Das sieht mir aber halt nicht elegant genug aus.

Nicht elegant genug? Was heißt das? Nicht einfach genug? Zu schnell? Benötigt zu wenig Rechenkapazität? Man muss sich das Hirn zu wenig verknoten?
Komisch. Ich finde die einfachen und schnellen Lösungen immer die besten.

Gibt es auch sachliche Gründe gegen diese Lösung? Ich lerne ja auch gern dazu.

 

[ToM80]

Hi,
sorry dass ich erst jetzt antworte, aber ich stecke im Umzugsrummel und gleichzeitig hatte ich gestern noch ein Außerhaustermin.
Mit nicht elegant genug meine ich folgendes.
Ich muss auf jeder Seite oder sogar in jedem Modul vor der Ausgabe abfragen ob der User das recht hat das Modul/die Seite zu sehen und wenn ja was er damit machen darf.
Das kann ich z. B. über ein in_array machen, wenn meine Rechte in einem Array liegen oder über If Abfragen oder wie auch immer. Aber ich muss es gezielt in jede Seite einbauen.

Die ACL scheint mir zur Zeit genau die elegante Lösung zu sein die ich mir wünsche.
Ich habe eine Klasse und die das Rechtemanagement übernimmt. Die einzelnen Abfragen auf den Seiten kann ich mir sparen.

Es wird min meiner Liste halt Seiten und Modul zugriffe geben und zusätzlich folgende Rechte:
lesen, schreiben, editieren, hinzufügen, löschen
Ich denke damit dürfte ich alles erschlagen was es geben kann.
Die Seite ansich wird dann nach den Rechten mittels der Klasse modular aufgebaut und gecacht.
Soweit zumindest meine Theorie. Die Praxisumsetzung werde ich demnächst beginnen. Mal schauen wo ich das zw. den Kistenpacken noch einbauen kann ;-)

 

[mikdoe]

OK verstehe. Solange es bei diesen fünf Berechtigungen bleibt. Bei mir ist es allerdings so, dass die meisten Berechtigungen inhaltlicher und nicht formeller Natur sind.
Am Beispiel einer Belegverarbeitung: Einer darf einscannen, ein anderer darf indizieren (aber nicht das Betragsfeld), der nächste darf nur Betragsfelder korrigieren und der übernächste darf kontrollieren usw.
Hinzu kommen Berechtigungen im Vieraugenprinzip. Das heißt, wer das Recht indizieren + kontrollieren hat darf dennoch nicht die selbst indizierten Belege kontrollieren sondern nur fremde.
Und da ist es mit lesen, schreiben usw. halt nicht getan, weil sich die Berechtigungen nicht sinnvoll in diese 5 Stufen clustern lassen. Denn in diesem Zusammenhang würde es keinen Sinn machen, nur Leserecht zu geben. Wenn einer etwas bearbeiten darf, sind immer alle fünf Rechte eingeschlossen. Sie sind halt anderweitig begrenzt und definiert.

Und dafür finde ich mein Prinzip wunderbar flexibel.
Dies ist für dich vielleicht mal eine andere interessante Sichtweise, wie man Berechtigungen vergeben könnte.