ENTWURF: Rechte-/Rollen-Konzept (BC v2.0)

Gesperrt
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

ENTWURF: Rechte-/Rollen-Konzept (BC v2.0)

Beitrag von shadowcat »

Das vorhandene - von WebsiteBaker geerbte - Rechtekonzept hat eine Reihe von Einschränkungen; unter anderem kann es nicht durch Module um weitere Berechtigungen erweitert werden. Rechte werden ausschließlich über Gruppen vergeben. Schlimmstenfalls muss für jeden Benutzer auch eine eigene Gruppe eingerichtet werden.

Die erste - und in v1.0 bereits teilweise integrierte - Überlegung war, ein bitbasiertes Rechtesystem zu implementieren. Doch auch hier ergeben sich sehr schnell ungewollte Einschränkungen. So ist ein bitbasiertes System zwar grundsätzlich erweiterbar, ein Modul kann aber nie 'wissen', welches Bit oder welche Bits noch frei sind. Zudem wird ein bitbasiertes System schnell unübersichtlich und damit nicht mehr wartbar.

Rollenbasierte Rechte (role based access control (RBAC))

Einführung: https://de.wikipedia.org/wiki/RBAC

Bei einem rollenbasierten Rechtesystem werden Rollen definiert, die sich an die jeweiligen Aufgaben eines Benutzers orientieren. Eine Rolle könnte z.B. "Redakteur" heißen und Rechte zum Anlegen von Seiten und Ändern von Inhalten beinhalten. Einem Benutzer können nun beliebig viele Rollen zugewiesen werden, aus denen sich die effektiven Rechte ergeben.

Nachteil eines solchen Systems ist, dass es sehr komplex werden kann und der Administrator genau überlegen muss, welche Rollen er definieren möchte und welche Rechte damit verbunden sind. Auf der anderen Seite hat er aber alle Freiheiten, beliebige Rollen zu definieren.

Datenbankschema

Für die Umsetzung eines rollenbasierten Rechtesystems sind vier Tabellen notwendig:
  • Definition der verfügbaren Berechtigungen (permissions) mit ID und Beschreibung
  • Definition der verfügbaren Rollen (roles) mit ID und Rollenname
  • Zuordnung der Berechtigungen zu den Rollen
  • Zuordnung der Rollen zu den einzelnen Benutzern
Auf Basis dieses Schemas können beliebig viele Rollen und Berechtigungen definiert und Benutzern zugeordnet werden.

Beispielhaftes Schema:

Code: Alles auswählen

CREATE TABLE roles (
  role_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  role_name VARCHAR(50) NOT NULL,

  PRIMARY KEY (role_id)
);

CREATE TABLE permissions (
  perm_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  perm_desc VARCHAR(50) NOT NULL,

  PRIMARY KEY (perm_id)
);

CREATE TABLE role_perm (
  role_id INTEGER UNSIGNED NOT NULL,
  perm_id INTEGER UNSIGNED NOT NULL,

  FOREIGN KEY (role_id) REFERENCES roles(role_id),
  FOREIGN KEY (perm_id) REFERENCES permissions(perm_id)
);

CREATE TABLE user_role (
  user_id INTEGER UNSIGNED NOT NULL,
  role_id INTEGER UNSIGNED NOT NULL,

  FOREIGN KEY (user_id) REFERENCES users(user_id),
  FOREIGN KEY (role_id) REFERENCES roles(role_id)
);
Berechtigungen in BlackCat CMS (v1.0)

Basierend auf den Vorläufern WebsiteBaker und LEPTON ergeben sich eine Reihe möglicher Berechtigungen. Hier eine unvollständige Liste (Ausarbeitung später):

Frontend

Bestimmte Seiten sehen (Sichtbarkeit "privat")

Backend

Betreten (Dashboard sehen)

Medien
Sehen (auflisten), Verwenden (z.B. in WYSIWYG-Editor), Hochladen, Löschen; Verzeichnisse anlegen, Verzeichnisse löschen

Seiten
Sehen, Neu anlegen, Ändern, Löschen

Einstellungen
Sehen, Ändern

Addons
Sehen (auflisten), Verwenden (zu Seite hinzufügen), Installieren, Deinstallieren

Admin-Tools
Sehen (auflisten), Verwenden

Benutzer
Sehen (auflisten), Neu anlegen, Ändern, Löschen

Gruppen
entfällt

Entwurf: Rechte auf Seiten

Derzeit ist es möglich, Benutzern Rechte auf Seiten zu geben, mit denen sie nichts anfangen können - etwa indem ein Benutzer (über die Gruppe) das Rechte erhält, eine Seite anzulegen, aber nicht, sie dann auch zu bearbeiten. Das mag im Einzelfall so gewollt sein, in der Regel jedoch eher nicht.

Ansatz:
  • Wer eine Seite anlegt (=das Recht dazu hat), wird Eigentümer der Seite.
  • Der Eigentümer einer Seite hat IMMER folgende Rechte: Inhalte bearbeiten, Seite löschen, Eigentümer ändern
  • Diese Rechte besitzt er auch dann, wenn er über keine seine Rollen entsprechende Berechtigungen erhält
Einschränkungen:
  • Es ist nicht möglich, einem Eigentümer das Recht zu entziehen, seine eigenen Seiten zu bearbeiten und zu löschen (ein "Superadmin" könnte aber das Recht besitzen, den Eigentümer zu ändern)
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: ENTWURF: Rechte-/Rollen-Konzept

Beitrag von shadowcat »

Benutzerspezifische Einstellungen

Das betrifft das Rechte-/Rollenkonzept nur indirekt, hängt aber thematisch damit zusammen. Ich will hier sammeln, was benutzerspezifisch einstellbar sein soll. Hierarchie: Benutzer -> Gruppe -> Global
  • Default-Seite beim Login (bereits in v1.0 erledigt, globale Einstellung ist 'Dashboard', Gruppeneinstellung nicht existent)
  • WYSIWYG-Editor und -Konfiguration
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Datenbankschema (Entwurf)

Beitrag von shadowcat »

Vorläufiges Modell siehe Bild.

Spalte "perm_source" beinhaltet die Quelle eines Rechts. Das kann entweder der Core sein, oder ein Modul.
Dateianhänge
bcroles.png
bcroles.png (25.15 KiB) 6051 mal betrachtet
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Privilege escalation

Beitrag von shadowcat »

Unter Privilegien-Eskalation versteht man die ungewollte Rechteausweitung, d.h. ein Benutzer kann einen Designfehler oder Bug ausnutzen, um sich höhere Rechte zu verschaffen, als er eigentlich besitzt.

Beispiel: Ein Benutzer hat das Recht, Benutzerkennworte zurückzusetzen (z.B. ein Helpdesk-Mitarbeiter). Sofern dies nicht für höherberechtigte Benutzerkonten unterbunden wird, kann er das Kennwort eines höherberechtigten Benutzers ändern und sich anschließend mit dessen Kennung anmelden, um dessen Rechte zu erhalten.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
creativecat
Beiträge: 1430
Registriert: Mi 6. Feb 2013, 12:41
Kontaktdaten:

Re: ENTWURF: Rechte-/Rollen-Konzept

Beitrag von creativecat »

Sehe ich das richtig, dass ich mit diesem System auch eine Rolle definieren kann, die beispielsweise ein einziges Admin-Tool verwalten kann, sonst aber gar nichts?
Also ich habe beispielsweise ein Admin-Tool, mit welchem ich bestimmte Inhalte in einer DB pflegen lasse, die Person, die diese Inhalte pflegt, soll aber nur darauf zugreifen dürfen. Alles andere (Seiten, Medien, alle anderen Tools, Add-Ons etc.) soll dann ausgeblendet werden....
100%ig habe ich die Datenbank noch nicht verstanden ;-)
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: ENTWURF: Rechte-/Rollen-Konzept

Beitrag von shadowcat »

Das ist das Ziel, ja. Grundsätzlich läßt sich das mit der DB-Struktur erreichen, es ist halt eine Frage, wie man die Rechte definiert. Also wie weit man da ins Detail geht. Wenn wir erst mal 1:1 übernehmen, was WB kann, kann man es nicht bis auf Modulebene runterbrechen. Aber da die Rechte im Gegensatz zu WB nicht "hartverdrahtet" sind, ist eine Erweiterung in jede Richtung denkbar.
My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Benutzeravatar
shadowcat
Administrator
Beiträge: 5283
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Re: ENTWURF: Rechte-/Rollen-Konzept

Beitrag von shadowcat »

My software never has bugs, it just develops random features.
If it’s not broken, keep fixing it until it is
Gesperrt