User- und Gruppenbehandlung

[xsign.dll]

Mir ist ein wenig langweilig und deshalb will ich mir mal in dem Thread den Kopf über User/Gruppen Management machen.

Ich gehe davon aus, dass wir PEAR::Liveuser aussortiert haben. Ich habe es mir gerade noch einmal angeschaut und muss sagen, dass es zu hochgestochen ist für unsere Verhältnisse. Außerdem wäre es nicht wirklich kompatibel mit unserem Source und hajo hat in Sachen PEAR sowieso eine kleine Phobie - ähnlich wie ich bei $_REQUEST.

Das führt dazu, dass wir alles selber programmieren müssen. Somit stellen sich für mich ein paar Fragen, die ich in den folgenden Zeilen erörtern möchte.

Was für Anforderungen werden an jene user.class.php gestellt?
- Authentifizierung ( security.class.php => SALT,MD5,SHA1 und co. )
- Cookieverwaltung
- Sessionverwaltung ( index.php?s=45254325gsdfgsdfg )
- Rechteverwaltung ( Spezialrechte, die Gruppenrechte überschreiben, ergänzen oder entziehen )
- Status ( online/offline, inactive/active )
- Suchmaschinen Robots Behandlung
- allg. Userverwaltung ( add, delete, edit )
- Bereitstellung eines globalen Arrays z.B. $user->current['name'] --> Derzeitiger User
- Verschiedene Funktionen wie z.b. $user->get( $_REQUEST['id'] ); --> gibt ein Array mit Informationen über den angeforderten User
- Import/Export
- ?

Was für Anforderung werden an eine groups.class.php gestellt?
- Rechteverwaltung ( Gruppen: Admins, Clanleader, Squadleader, Benutzer, Gäste, Gebannt )
- allg. Gruppenverwaltung ( add, delete, edit )
- Bereitstellung eines globaen Arrays z.b. $group->current['name'] --> Benutzergruppe des derzeitigen Users
- Verschiedene Funktionen wie z.b. $group->get( $_REQUEST['id'] ); --> gibt ein Array mit Informationen über die angeforderte Gruppe
- Import/Export
- ?

Welche Datenbankstruktur kommt dabei zum Einsatz?
Klar ist denke ich mal:

- prefix_users
- prefix_groups
- prefix_sessions

Die einzelnen Datenfelder ergeben sich dann aus der Notwendigkeit beim programmieren selbst.


Das ist defintiv ein Kraftakt. Ich hoffe daher inständig, dass relativ bald der DB Layer fertig ist, auch wenn hajp nur beschränkt Zeit hat. Denn ohne DB keine User-/Gruppenverwaltung.

[hajo]

hab ab 12.06. urlaub, kann davor nur kleinere arbeiten daran anfangen leider ..

[Jens-A. Koch]

Wenn PEAR rausfliegt, dann fliegen PHPUnit2, PHPOpentracker leider auch.
Schade auch das Liveuser nicht zum Einsatz kommt.
Das System wäre skalierbar in seiner Anwendung. Also hochgestochen finde ich es nicht: wenn wir uns auf das angesprochene Verfahren von User->Gruppe->Rechte einigen können, dann wäre das auch bei Liveuser die letzte Ebene. Die zugrundliegene Db-Struktur zur Abbildung dieser Einteilung ist immer gleich.

Anfangs wurde auch noch phpgacl angesprochen, wie siehts damit aus?

Eigentlich können wir auch ohne Db-Schnittstelle arbeiten und sämtliche Queries in Normalform aufschreiben. Was die Umsetzung anbelangt, sollten Classes erstellt werden, die erstmal nur die Funktionen beschreiben und Input + Output festlegen.

Thema: Rechteverwaltung
Voraussetzung für die Rechteverwaltung ist die Identifizierung des Benutzers.

Wenn Spezialrechte angesprochen werden, die Gruppenrechte überschreiben, ergänzen oder entziehen dann ist also gemeint: Userrechte gehen Gruppenrechten immer vor!

Gehen wir mal ein wenig ins Detail der möglichen Rechteverwaltung:
Ich gehe grundsätzlich vom Verbot aus und vergebe die Erlaubnis.
Anknüpfungsgrundlage sind Subjekt->Handlung->Ressource.

Beispiel:
Gäste: Wer die öffentlichen Bereiche sehen will, braucht die Berechtigung für die Handlung "view".

Ein Recht ergibt sich dabei immer aus der Rechtetabelle.
Die Gruppentabelle erfasst Gruppierungen von Berechtigte.
Durch Gruppenbildung vermindert man die Granularität im Bereich Berechtigte.
Berechtigte können also einzelne Benutzer (individuelle Berechtigung) bzw. bestimmte Benutzergruppen sein (Gruppenberechtigung).
Beispiel: Der Gastnutzer könnte also einerseits direkt aus der Rechtetabelle das "view"-Recht erlangt haben. Andererseits über die beiden Zuordnung des Users zur Gruppe "Gäste" und des Rechts "view" zu dieser Gruppe.

Möglich wäre jetzt auch die Einführung eines Area-Systems, einer Granularitätsminderung im Bereich Rechte bzw. Sicherungsobjekte. Man bildet (ausgehend vom Create, Read, Update, Delete - System ) Zusammenfassungen einzelner Rechte bzw. Bereiche. Beispiel: CRUD-News, Guestbook.

Warum macht man das?
Ausgehend von User und Recht bildet sich eine n*m-Tabelle. Das Auslesen der Rechte aus einer solchen Tabelle wäre ein Performancehammer. Bei vielen Joins kommt man manchmal darauf zurück. Man gruppiert also auf Seiten von n und m und benutzt Relationstabellen.

Ergänzungen kann man ja bei Bedarf hinzufügen: Untergruppen, Rollen, implizite Rechte.

Soweit erstmal. Wie stellt ihr Euch das vor?

[hajo]

phpgacl klingt nice, hab wiegesagt nur ne pear phobie, die müsste mir sonst jemand nehmen

hab heut mein vor ewigkeiten bestelltes neues sql pocket guide bekommen (rev april 2006 von O'Reilly) und werd mich jetzt mal mit den eigenheiten von oracle und db2 grob beschäftigen

was die rechteverwaltung angeht:

dachte auch an ein system "Benutzer/Gast -> Gruppe -> Abgeleitete Rechte" wobei man in mehreren gruppen seien können sollte und jeweils das höchste recht auf module und deren aktionen bekommt bei überschneidungen. davon auszugehen das im grundsatz erstmal alles verboten ist dachte ich mir ebenfalls genauso, prima

[Jens-A. Koch]

PEAR is nich wirklich wild. Entweder man nimmt das als Vorlage für eigene Classen oder man bindet es halt ein. Also ich hab keine Bedenken die Klassen von dort zu verwenden.

Rechtesysteme im Bild:
http://www.gvngroup.be/doc/LiveUser/permission_simple.php
http://www.gvngroup.be/doc/LiveUser/permission_medium.php
http://www.gvngroup.be/doc/LiveUser/permission_complex.php

Link zu GACL Manual:
http://phpgacl.sourceforge.net/demo/phpgacl/docs/manual.html

[xsign.dll]

Nunja eigentlich greift man auf PEAR::Liveuser eben dann zurück, wenn man keine Zeit hat. Und die haben wir. Außerdem find ich es wirklich schöner, wenn ich persönlich weiß, was wir geprogged haben. Das is bei liveuser leider nicht der Fall. vorallem weiß ich nicht, was eine Änderung im PEAR Source für Auswirkungen nach sich zieht. Und das lässt mich in dieser Hinsicht ein wenig zögern.

Klar, das oben genannte is wirklich arbeit - doch ich liebe arbeit - vorallem wenn ich danach weiß: "Das haben wir vollbracht!"
Find den "Nervenkitzel" irgendwie interessanter, als einfach mal ne Klasse zu importieren. Außerdem steigert sich dabei der Skill - und das möchte ich nicht missen. Man kann sich ja durchaus von den PEAR Sourcen etwas abschauen oder eben inspirieren lassen - aber ganz darauf setzen bin ich nich so dafür. Selbiges gilt eben auch für GACL.

Wenn ihr da anderer Meinung seid, dann nehmen wir halt pear oder gacl Aber sowas echtes aus eigener Kraft heraus isses dann eben nichtmehr :/

Möglich wäre jetzt auch die Einführung eines Area-Systems, einer Granularitätsminderung im Bereich Rechte bzw. Sicherungsobjekte. Man bildet (ausgehend vom Create, Read, Update, Delete - System ) Zusammenfassungen einzelner Rechte bzw. Bereiche. Beispiel: CRUD-News, Guestbook.

Warum macht man das?
Ausgehend von User und Recht bildet sich eine n*m-Tabelle. Das Auslesen der Rechte aus einer solchen Tabelle wäre ein Performancehammer. Bei vielen Joins kommt man manchmal darauf zurück. Man gruppiert also auf Seiten von n und m und benutzt Relationstabellen.

Ergänzungen kann man ja bei Bedarf hinzufügen: Untergruppen, Rollen, implizite Rechte.

Das mir jetzt ersma nen Schwung zu hart für mein Schlafentzuggeschädigtes Hirn. Also - ich versuch das mal zu dechiffrieren.
CRUD System: Soll heißen ich bilde z.B. nen CRU für den Bereich News, für die Gruppe Clanleader, CRUD wäre für Admins Only ? Sowas in die Richtung ? Oder versteh ich da grad ein bissl Bahnhof...

Und den Performancehammer kann ich momentan garnicht nachvollziehn, da ich es schlichtweg nicht verstehe gib mal bitte nen bsp.

[Jens-A. Koch]

Nagut dann lass den Skill steigern Erstmal ordentlich planen:

User

user_id	user_nachname
1	Müller
2	Meier
3	Schulze
4	Lampe

User -> Gruppen

user_id	group_id
1 (Müller)	1 (Newsmanager)
2 (Meier)	1 (Newsmanager)
3 (Schulze)	2 (Guestbookmanager)

Gruppen

group_id	group_name
1	Newsmanager
2	Guestbookmanager

Gruppe -> Rechte

group_id	right_id
1 (Newsmgr)	1 (News-View)
1 (Newsmgr)	2 (News-Delete)
2 (GBmgr)	4 (Guestbook-Delete)

Rechte

area_id	right_id	right_name
1	1	News-View
1	2	News-Delete
2	3	Guestbook-View
2	4	Guestbook-Delete

Soweit ein normales Rechtesystem!

Erweiterung um Freaky-Zusätzen:

Implizierte Recht

right_id	impliedright_id
4 (Guestbook-Delete)	3 (Guestbook-View)

Area

area_id	area_name
1	NewsAdminArea
2	GuestbookAdminArea

User to Area

user_id	area_id
4 (Lampe)	1 (NewsAdminArea)

DOH! mann - war das ne fizzel arbeit

jetzt kann man folgendes nachvollziehen:
a. Schulze -> ist Gruppe Guestbookmgr -> bekommt deleterecht -> deleterecht impliziert view
b. Lampe  -> NewsAdmin über Areavergabe


wenn man jetzt zu hochform aufläuft, dann bildet man noch
group_superuser oder area_superuser mit leveln oder prozenten, mit gegenseitigem ausschluß etc. (wenn superuser_news eingeloggt, alle anderen ausgesperrt, etc.)


basierend auf diesem modell kann ich alle beispiele bauen.
bitte anfragen.

[xsign.dll]

Also DAS sieht mal sehr sehr gut aus. Die implizierten Rechte gefallen mir gut - mit dem Area gefällt mir das sogar noch besser. Ich werd später mal antworten - muss erstmal arbeiten...

so...
also kurz mal mit hajo geschwätzt - implizierte rechte stellen eben immer ein risiko dar. und ob man das eingedämmt kriegt ist auch irgendwie fraglich. natürlich find ich sowas geil, weil man dann mehr flexibilität hat. die frage is halt nur, ob das überflüssig ist.

[xsign.dll]

Also dann mal das Statement von Zeus:

Nunja,

ich will es nicht aufbröseln. Aber vom Gedankengang sollte man es verfeinern.

Warum werden die Rechte nach Benutzer/Gruppe getrennt? Dann lieber eine Tabelle erstellen, die alle Rechte beinhaltet. Wenn es notwendig sein sollte, kann man dem Einzelrecht auch noch ein Flag wie etwa "Nur Benutzer" oder "Nur Gruppe" zuweisen.

So könnt ihr dann direkt sehr individuell dem Benutzer und der Gruppe die Rechte vergeben. Genauso lassen sich dann die Bereiche Abbilden.

Damit wir dann auf das Rollensystem kommen, könnte man sehr elegant eine solche über Benutzer, Gruppe, Recht und optional Bereich bilden.

Somit bleiben alle 3 Rechtesysteme unangetastet und werden über die Rolle zusammengefasst.

Z

[Jens-A. Koch]

Die Rechte werden doch gar nicht getrennt:
Es besteht eine Tabelle die alle Rechte in Form von einzelnen Rechten beinhaltet.
Es besteht keine Trennung in Gruppenrechte oder Benutzerrechte.

Es bestehen Zuordnungen von Personen zu Gruppen.
Und Zuordnungen von Rechten zu Gruppen.

Was fehlt ist, die Relation Rechte zu User.
Dann ergänzt man die Tabelle (wie bei clansuite)

user -> right
user_id right_id

Mit anderen Worten und bezogen auf das angehängte Bild:
der User-Gruppe-Rechte Weg ist obenrum, der User-Rechte Weg ist untenrum.
Gimmicks sind nicht im Bild.

[Jens-A. Koch]

Du willst es wissenschaftlich? Hier, bitte - eine kleine Kopfnuss zum Thema:
 
Dissertation:  Gerhard Popp - TU München - Informatik
Thema: Methode zur Integration von Sicherheitsanforderungen in die Entwicklung zugriffssicherer Systeme.


Link

[xsign.dll]

wat? lol... Das werdsch dann bestimmt auch noch irgendwann im Studium anfangen...
Hast da nen Link zu ?