BumpyJohnson

Hey,

ja hab ich mir angeschaut und es geht in meine Richtung. Aber ich habe zwei Klassen komplett weggelassen. Hier ist eine UML, leider nicht so ausführlich aber zur Veranschaulichung reicht es hoffentlich.

UML

Wofür brauchst du noch eine Permissions-Set? Ich geb der Rolle einfach unendlich viele Permissions ohne ein Set.

Wenn ich das richtig verstanden hab kannst du deiner Gruppen auch eine Permission oder ein PSet zuweisen. Aber im Endeffekt ist eine Gruppe dann doch sehr ähnlich einer Rolle, oder? Ich denke, dass ich die Idee hinter einer Gruppe noch nicht verstanden hab. Für mich vergibt sich dadurch irgendwie keine Erleichterung bzw. Verbesserung des Access Controlling.

Mister Ad

dr.e.

Hallo Bumpy,

ich bin mir bei der Bedeutung der Beziehungen in deinem Diagramm noch nicht ganz schlüssig. Was bedeutet die gestrichelte Linie zwischen Applikation und Benutzer? Ist das eine Assoziation? Falls ja, ist das problematisch, denn wenn der Benutzer seine Applikationen kennen muss, ist dieser Design-technisch nicht unabhängig genug. Weiterhin fehlen mir Gruppen und weitere Ordnungscontainer, die eine Zugehörigkeit der Strukturelemente zeigen. Ein Benutzer sollte immer unter einer Organisationseinheit hängen - wie im richtigen Leben eben.

Wie ist die Beziehung zwischen dem Controller und der Rolle/dem Benutzer ausgeprägt? Sollte ein (MVC)-Controller nicht eine Business-Schicht konsumieren um die relevanten Tasks der Präsentationsschicht zu erledigen? Mir vermischt das Diagramm ein wenig das reine Domänen-Modell mit dem Klassendiagramm einer Anwendung.

Es geht dabei einerseits um Klassifizierung von Permissions (z.B. Funktionsberechtigungen auf ein Modul "Gästebuch") und um die Wiederverwendbarkeit. Würde eine Rolle - wie vermutlich in deinem Fall - direkt einer Rolle zugewiesen dein (Komposition), kann die Funktionsberechtigung keiner anderen Rolle mehr zugewiesen werden. Im realen Anwendungsfall wirst du jedoch immer mit dem Problem zu kämpfen haben, dass eine Admin-Rolle eines Moduls auch Lesefunktionsrechte hat, bzw. Eigenschaften eines Objekts einsehen darf (ro).

Eben nicht. Gruppen sind Strukturelemente die zur Zugriffsberechtigung auf Objekte einer Anwendung eingesetzt werden und Rollen regeln den Zugriff auf Funktionen. In einfachen Anwendungen mag das sicher so reichen, nur die konsequente Trennung der beiden Bereiche ermöglicht es, z.B. einem Benutzer in einem CMS Rechte auf einen Inhalt zu geben, den er auch bearbeiten kann, nur online stellen ist ihm untersagt.
Nur so kannst du echte Rollen (=~ Sichten auf eine Anwendung) bereitstellen.

Wie bereits angesprochen muss du hier zwischen den Bedeutungen unterscheiden. Beide "Gebiete" verfolgen eine andere Zielsetzung in einer Anwendung / in einem Modul.

Ich hoffe, ich konnte soweit zum Verständnis des Konzeptes beitragen. Wichtig ist hier vor allem, dass du das Objekt- bzw. Domänen-Modell unabhängig der Anwendung skizzierst. So bist du von Beginn an gezwungen über ein allgemeingültiges Szenario nachzudenken.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BumpyJohnson

Hey,

danke für deine ausführliche Antwort. Mein Uml, also das Klassendiagram war ein bisschen stürmisch heute nacht gemacht. Ich hab heute nochmal ein paar Klassendiagramm, UseCases und Systemklassenmodell entworfen (Da ich UML gerade sowieso lernen (vertiefen) muss, dachte ich mir dass ich noch ein bisschen weiter entwerfen kann). Ich setze das Systemklassenmodell ans Ende des Beitrags, erstmal wollte ich auf ein paar deiner Antworten eingehen.

Den markierten Teil kann ich nicht ganz verstehen, aber ich glaube du meinst, wenn ich einer Rolle direkt eine Permission zuweise. Nur ist mir nicht kann klar warum ich verschiedenen Rollen nicht die gleichen Permissions geben kann. Ich mach es so, dass manche Rollen nur Zugriffsrechte haben und andere wiederum auch Bearbeitungs- wie Hinzufügrechte besitzen. Ist da bei mir irgendein Denkfehler drin??


Das heißt du legst mit deinen Gruppen die "Sichtbarkeit" einer Seite/Objekt fest. Alles weiteres machen dann die Rollen. z.B.

Ein User ist in Gruppe "User" hat aber als Rolle "Moderator" und darf nicht nur Artikel anschauen sondern auch verändern bzw. neue hinzufügen. Richtig?

Ich regele das direkt über die Permissions. Entweder man hat die Permissions zum Bearbeiten oder nicht und so weiter.

Hier ist jetzt mein Systemklassenmodell:
Systemklassenmodell

Bitte nicht so viel Beachtung auf die Assoziationen, die Name sind teils nicht so optimal gewählt.

gruß b.j.

dr.e.

Hallo,

Es geht um die Korrektheit des Datenmodells. Wenn du darin den Anspruch erhebst, dass eine Permission unterhalb einer Rolle komponiert ist, macht es keinen Sinn diese zu einer weiteren Rolle zu assoziieren. Das sprengt den Wirkungsbereich des Objekts. Das bedeutet im Umkehrschluss, dass eine Permission - sofern du diese in mehreren Rollen verwenden möchtest - nur zu dieser assoziiert sein darf. Sonst ist eine Permission zu abhängig von einer Rolle!

Die Trennung ist: Rechtezuweisung auf Objekte passiert über Gruppen (und natürlich direkt über eine Assoziation zu einem Benutzer direkt), Rechtezuweisung auf Funktionen einer Applikation steuern Rollen. In deinem Beispiel bedeutet das, dass ein Benutzer A Sichtbarkeitsrechte (über eine Gruppe oder eine direkte Beziehung zu den relevanten Objekten) auf bestimmte Objekte hat, mit diesen jedoch nur diejenigen Aktionen ausführen darf die auch in seiner Rolle definiert sind.

Dann sind deine Aussagen und dein UML falsch. Dort steht, dass Permissions dem Benutzer über eine Rolle zuweist. Das ist auch gut so, sonst müsstest du jedem Benutzer erneut alle relevanten Permissions zuweisen. Das ist unbenutzbar.
Weiterhin solltest du das Domänen-Modell vom Klassenmodell der Anwendung trennen. Das System-Diagramm ist IHMO immernoch verwirrend.

Ich will nicht pedantisch wirken, aber ein UML muss korrekt sein! Andernfalls bietet es Platz für zu viel Interpretationsspielraum und wird von unterschiedlichen Entwicklern unterschiedlich verstanden.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BumpyJohnson

So,

hab jetzt noch mal ein UML-Diagram überarbeitet. Hab jetzt noch ein zusätlichen Controller eingesetzt, der als WebController fungiert um halt anfragen eines Users abzuarbeiten. Ich glaube den Punkt hatteich noch nicht bedacht. Dazu hab ich jetzt Aggregation, Komposition und Multiplizitäten hinzugefügt. Desweiteren hab ich mir erlaubt die Benennung der Assoziation nach deiner Konfektion umzuändern, so ist das Diagram wohl leichter zu verstehen. Wäre aber immernoch super wenn du mich auf Fehler aufmerksam machst.

Nochmal zum Thema Gruppen. In meinem System sind kein Gruppen vorgesehen, da ich glaube, dass ich sie nicht brauche. Ich arbeite einfach nur mit Rollen. Wie du hoffentlich jetzt sehen kannst bekommt jeder Benutzer n Rollen zugewiesen und nur allein an den entscheide ich ob er genug Rechte hat um das Objekt zuberachten bzw. die Objektoperationen auszuführen.
Nichtsdestotrotz werde ich mir den (dein) Ansatz nochmal genau durch den Kopfgehen lassen und schauen ob es nicht vielleicht doch sinnvoll ist diese Methode zu verwenden.

UML

dr.e.

Hallo Bumpy,

das Diagramm sieht nun "freundlicher" aus. Was du mir nur erklären musst, ist die Komposition des Permission- und Role-Handlers zum RBAC-Controller? Möchtest du eine direkte Abhängigkeit der Komponenten darstellen oder soll das eine Komposition im Sinne von Domänen-Objekten sein? Letzteres IMHO wahrscheinlich nicht.

An sich macht es natürlich Sinn, eigene Business-Komponenten für das Handling von Permissions und Rollen zu definieren, nur sind das für meine Begriffe so elementare Funktionen eines Benutzer-Managements, dass man diese zusammenfassen sollte. Dieser Meinung bin ich deshalb, da die beiden von den Komponenten verwalteten Domänen-Objekte duch Ihre Beziehung zusammengehören. Grundsätzlich spricht aber auch nichts gegen eine Trennung, sofern die beiden Komponenten so zusammen spielen, dass diese als "gemeinsame" API von einer Applikation genutzt werden können.

Bei der Beziehung Benutzer <-> Rolle bin ich jedoch nicht so ganz deiner Meinung. Die Quelle der Beziehung sollte IMHO von der Rolle und nicht vom Benutzer ausgehen. Grund ist, dass eine Rolle soetwas wie eine "Kategorisierung" ist. Beispiel aus dem richtigen Leben: ein Junge wird in eine Fußballmannschaft aufgenommen und nicht der Junge nimmt die Fußballmanschaft zu sich auf.

Weitere Fragen, die sich mir stellen:
* Was stellt die Klasse WebControl für dich da? Ist das ein Objekt einer Webseite, gar eine TagLib?
* Wird der RBAC_Controller als Business-Komponente eingesetzt und dient einer Webapplikation bzw. einem WebControl als Service?

Ja, ich kann erkennen, dass ein Benutzer verschiedene Rollen assoziieren kann. Wie bereits eingangs erwähnt, sollte man nicht den Fehler machen "Rechte" auf Funktionen und "Rechte" auf Domänen-Objekte einer Anwendung gleich zu setzen. Das mag in einfachen Applikationen sicher funktionieren, nur bei einem CMS wird das problematisch. Würdest du das Konzept su umsetzen, würde schlimmstenfalls jeder Benutzer einer Rolle alle Funktionen auf Objekte, die mit dieser assoziiert sind, ausführen können. Das ist sicher nicht im Sinne des Erfinders. Aus diesem Grund braucht es zwei Unterscheidungsmerkmale:
1. Darf ich dieses Objekt sehen/nicht sehen (Sichtbarkeitsrechte)
2. Was darf ich mit diesem Objekt anstellen (Funktionsrechte)

Wenn du möchtest, zeige ich dir auch nochmal einen Anwendungsfall auf, in dem dieses Konzept von essentieller Bedeutung ist.

Danke für die spannende Diskussion!

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BumpyJohnson

Das soll ne direkte Abhänigkeit sein. Also wenn es kein RBAC-Controller gibt, gibt es auch kein Role- wie PermissionHandler.

Als ich das Diagram hochgeladen hatte, hab ich auch genau das gedacht. Brauch ich eigentlich noch diese Controller? Da die bei mir direkt abhänig von RBAC-Controller sind, sind diese eigentlich komplett unnötig.

Jetzt wirds ein bisschen haarig. Meine Rollen sind "eigentlich" deine Gruppen. Im Endeffekt basiert das RBAC - Konzept in den Grundzügen auf einem group-based access-control Konzept. Nur ein wichtiger Punkt beim RBACKonzept ist, dass User unmengen an Rollen haben können. Es gibt kein gesetztes Limit. Es wird nur später in der Praxis bzw. genaueren Planung ersichtlich, ob ein solches Limit sinn macht.

Hier dem Punkt muss ich mich leider entschuldigen. Mein RBAC ist grundlegend schon auf dem RBAC - Konzept aufgebaut doch war ich bei der Planung und im Design sehr ungenau. Ich wollte zu schnell fertig werden. Im Moment bin ich mit meiner Implementierung gar nicht mehr zu frieden und auch ein bisschen naja "sauer" auf mich, dass ich so schlampig recherchiert habe.

Ich hab mir jetzt nochmal ein paar Dokumente zum RBAC angeschaut und konnte halt so viele Fehler und Missverständnisse entdecken bzw. aufklären.

Ein wichtiger Punkt ist auch die hierarchisch Rollenzuordnung. Im Klartext heißt, dass es halt "höhere" Rollen gibt die von "niedrigern" Rollen die Permissions übernehmen.

Für weitere Informationen hab ich mal zwei PDF hochgeladen. In den selbst sollten noch weiterführende Links enthalten sein. Sind aber auf englisch.

RBAC-PDFs

Der WebController ist der Frontcontroller meiner Seite. Ich wollte hier einfach nur ein Controller reinbringen, der zwischen der Boundary und dem RBAC-Controller sitzt. Irgendwie dachte ich, dass diese Verbindung falsch verstanden werden könnte. Nun bin ich mir auch nicht mehr sicher ob dass nicht zu noch mehr Verwirrung geführt.
Jetzt müsste ich eigentlich alle meine anderen Klassen einbauen, so ist das ganze System natürlich noch nicht vollständig.

Der RBAC-Controller ist eigentlich die Control-Klasse, die halt den Akteur(durch die Boundary) die Funktion stellt um die Rollen bzw. Permissions zuverwalten.
Leider kann ich mit der Vokabel "Business-Komponente" nix anfange auch paar Google- und Wikipediasuchen haben das Geheimnis nicht lüften können. Also, was meinst du mit Business-Komponente?

Den Abschnitt muss ich mir morgen nochmal anschauen. Bin zuuu müde

Immer gern und selber danke

gute nacht, b.j.

dr.e.

Hallo Bumpy,

Das bedeutet im Umkehrschluss jedoch, dass die Implementierung des Konzeptes nicht wiederverwendbar ist...

Verstehe ich nicht. Rollen und Gruppen sind weder identisch noch so ähnlich, dass man das synonym verwenden könnte. Wenn du Berechtigungen auf Objekte (z.B. News-Einträge, Termine, CMS-Artikel) definieren möchtest, sind Rechte über Beziehungen zu diesen Objekten abzubilden (direkt oder indirekt über eine Gruppe), wenn es um Berechtigungen zu Funktionen einer Software geht, sprechen wir von Rollen. Ich wiederhole mich - ich weiß das - nur exakt diese Vermischung zu vollziehen ist aus meiner Erfahrung heraus fatal.

Keine Limits - ok. Es ist nur wichtig, dass hinter den Rollen auch ein klares Konzept hinsichtlich der Funktionen einer Anwendung stecken. Weder zu generisch noch zu strikt ist hier hilfreich für die Administratoren und den Betrieb der Software nach dem Livegang.

Braucht es wirklich hirarchische Rollen? IMHO sollte man nur eine Rangordnung bei den Permissions definieren. Als praktikabel hat sich hier erwiesen, dass ein Verbot höher gewertet wird als ein Gebot. In der Implementierung kann das in der Form gelöst werden, dass die Werte für Permissions nur true und false sind, bei gleichen Keys sticht false.

Hmm, da kann ich leider nicht drauf zugreifen, bekomme einen 404er.

Ich denke wir sprechen von ähnlichen Konstrukten. "Business" ist dabei ein Begriff aus dem 3-Schicht-Architektur-Pattern, das besagt, dass eine gute Strukturierung einer Applikation durch Trennung in 3 Schichten erreicht wird. Diese sind Präsentationslogik (Pres; alle Funktionen zur Darstelung), Geschäftslogik (Business-Logik; Biz; alle zentralen Funktionen einer Applikation; so auch das Theme Rollen/Rechte/Benutzerverwaltung) und Datenschicht (Data; Beschaffung und Speicherung von Daten; OR-Mapping; Abbildung des Domänen-Models auf eine Datenhaltung).
Im Sinne dieses Pattern kapsele ich gerne gemeinsame und global verwendbare Funktionen in einer Business-Komponente, die zumeist das Wort "Manager" im Namen trägt. In diesem Fall wäre das der UsermanagementManager, der allen Teilen der Applikation ein Interface zur Benutzerverwaltung zur Verfügung stellt. Das stellt nicht nur sicher, dass innerhalb einer Applikation Funktionen zentral zur Verfügung stehen, sondern ich kann diese auch in anderen Applikationen wiederverwenden und muss nicht jedes mal neu implementieren/kopieren.

Viele Grüße,
Christian

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#Avedo

Hallo!
Ich krame diesen Thread mal wieder aus, da das Thema nun auch bei mir wieder etwas aktueller wird.

Ich habe leider noch nicht ganz verstanden, wo der Unterschied zwischen Rollen und Gruppen liegt. Könnte mir jemand das etwas näher erklären?

Zudem würde mich interessieren, ob im APF die Rechte nur einer Gruppe und die Gruppe dann den einzelnen Nutzern zugeordnet werden kann oder ob es auch möglich ist neben den Rechten, die einem durch seine Gruppenzugehörigkeit verliehen werden, auch noch einzelne Rechte zu vergeben.
MfG, Andy

__________________
I'm so tired of slitting the throats of people calling me a violent psychopath.

Manko10

Der Unterschied liegt darin, dass beim Gruppensystem eine Vererbung stattfindet. Es können der Gruppe Rechte zugewiesen, die auf den Benutzer übergehen. Der Benutzer kann aber ebenso spezielle Rechte erhalten, die die Rechte der Gruppe überschreiben.
Bei einer rollenbasierten Rechteverwaltung wird hingegen von einer realen Rolle ausgegangen, die ein Benutzer im Leben haben könnte und es werden somit nur noch der Rolle Rechte zugewiesen (also Redakteure dürfen dies, Akquisiteure jenes, Zeitungsträger noch wieder etwas anderes).
Eine gute Beschreibung findest du auch hier: Rollen sind keine Gruppen | Mike Wiesner - IT-Security, Spring, Acegi

Wie das APF aufgebaut ist, weiß ich nicht, aber sofern es rollenbasiert arbeitet, dürfte es nicht möglich sein, einzelnen Benutzern Rechte zuzuweisen.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”