Zum Hauptinhalt springen

Berechtigungen & Rollen

Canopy verwendet ein dreischichtiges Berechtigungsmodell, das plattformweite rollenbasierte Zugriffskontrolle mit kartenspezifischen Stakeholder-Rollen kombiniert. Diese Seite erläutert das Design, wann welche Schicht zu verwenden ist und wie die Schichten zu effektiven Berechtigungen kombiniert werden.

Warum drei Schichten?​

Enterprise Architecture ist von Natur aus funktionsübergreifend. Eine bestimmte Karte – beispielsweise eine Application – kann sein:

  • Nur lesbar für die meisten Benutzer (Viewer sehen das Inventar, können es aber nicht bearbeiten)
  • Bearbeitbar durch das allgemeine EA-Team (Member können jede Karte aktualisieren)
  • Verwaltbar durch eine bestimmte Person, die für diese Anwendung verantwortlich ist (der Technical Application Owner kann die Karte bearbeiten und den Status genehmigen, auch wenn er keine organisationsweiten Bearbeitungsrechte hat)
  • Vollständig kontrollierbar durch Admins (die alles tun können)

Ein flaches Rollensystem deckt die ersten drei Fälle ab, scheitert aber beim vierten: Sie müssen entweder jemandem organisationsweite Bearbeitungsrechte geben (zu weitreichend) oder gar keine (zu restriktiv). Die Stakeholder-Schicht löst dieses Problem, indem sie bestimmten Personen Berechtigungen pro Karte erteilt.

Schicht 1 — Anwendungsrollen​

Anwendungsrollen werden Benutzern zugewiesen und gelten plattformweit. Sie werden in Admin → Benutzer & Rollen definiert und verwaltet.

Jede Rolle trägt einen JSON-Berechtigungssatz. Die integrierten Rollen sind:

RolleSchlüsselGeltungsbereich
AdminadminPlatzhalter {"*": true} – uneingeschränkt
BPM Adminbpm_adminVollständiges BPM + volles Inventar, kein admin.*
MembermemberVolles Inventar + BPM-Bearbeitung, kein admin.*
ViewerviewerNur Lesezugriff in allen Bereichen

Benutzerdefinierte Rollen können mit jeder Kombination der verfügbaren Berechtigungsschlüssel erstellt werden, gruppiert in Domänen wie inventory.*, reports.*, bpm.*, ppm.*, grc.*, todos.*, admin.*.

Verwenden Sie Anwendungsrollen, wenn Sie steuern möchten, was eine Klasse von Benutzern auf der gesamten Plattform tun kann.

Schicht 2 — Stakeholder-Rollen​

Stakeholder-Rollen werden Benutzern auf bestimmten Karten zugewiesen. Jeder Kartentyp definiert seinen eigenen Satz von Stakeholder-Rollendefinitionen (z. B. haben Application-Karten „Technical Application Owner", „Business Application Owner", „Data Steward"). Diese werden in Admin → Metamodell → [Typ] → Stakeholder-Rollen konfiguriert.

Jede Stakeholder-Rollendefinition trägt einen Satz von Berechtigungen auf Kartenebene – Dinge wie card.edit, card.approve, card.manage_relations. Wenn ein Benutzer als Stakeholder zu einer Karte hinzugefügt wird, erhält er diese Berechtigungen nur für diese Karte.

Verwenden Sie Stakeholder-Rollen, wenn Eigentümerschaft oder Verantwortlichkeit kartenspezifisch ist: Der Eigentümer einer bestimmten Anwendung soll diese verwalten können, ohne Bearbeitungsrechte für alle anderen 500 Anwendungen zu erhalten.

Schicht 3 — Effektive Berechtigungen​

Wenn ein Benutzer eine Aktion auf einer Karte versucht, berechnet das System seine effektiven Berechtigungen durch Kombination von:

  1. Seinen Anwendungsrollen-Berechtigungen (von plattformweiten auf Kartenebenen-Schlüssel abgebildet)
  2. Allen Stakeholder-Rollen-Berechtigungen, die er auf dieser bestimmten Karte hält

Das Ergebnis ist die Vereinigung beider Mengen. Ein Benutzer, der ein Viewer (plattformweit) ist, aber Technical Application Owner auf einer Karte, kann diese Karte bearbeiten, weil die Stakeholder-Rolle card.edit gewährt, obwohl die Viewer-Rolle dies nicht tut.

Die effektiven Berechtigungen des aktuellen Benutzers auf einer bestimmten Karte werden über GET /cards/{id}/effective-permissions bereitgestellt und steuern alle Bearbeitungs-, Genehmigungs- und Löschsteuerungen in der Benutzeroberfläche.

Der Admin-Platzhalter​

Die Admin-Rolle verwendet {"*": true} als Berechtigungssatz. Dies wird als „alles erlauben" ausgewertet – einschließlich Berechtigungen, die zum Zeitpunkt der Rollenerstellung noch nicht existierten. Das bedeutet, dass neue Module und neue Berechtigungsschlüssel automatisch für Admins verfügbar sind, ohne dass die Rolle aktualisiert werden muss.

Keine andere integrierte Rolle verwendet den Platzhalter. Beim Erstellen benutzerdefinierter Rollen sollten Sie explizite Berechtigungsschlüssel statt Platzhalter verwenden – dadurch wird der Geltungsbereich der Rolle prüfbar und eine versehentliche Übervergabe von Berechtigungen verhindert.

Struktur der Berechtigungsschlüssel​

Alle Berechtigungsschlüssel folgen dem Muster domäne.aktion:

  • inventory.view – Karten lesen
  • inventory.edit – Karten aktualisieren
  • inventory.create – Karten erstellen
  • admin.metamodel – Kartentypen und Relationstypen verwalten
  • admin.impersonate – vorübergehend als eine andere Rolle agieren (siehe Rollenübernahme)
  • bpm.approve – BPMN-Prozessfluss-Versionen genehmigen
  • todos.view / todos.create / todos.manage – Aufgaben aufrufen und verwalten
  • risks.manage – Risikoregistereinträge erstellen und aktualisieren

Die vollständige Liste gültiger Schlüssel befindet sich in backend/app/core/permissions.py, das die einzige Quelle der Wahrheit ist. Neue Berechtigungsschlüssel müssen dort hinzugefügt werden, bevor sie einer Rolle gewährt werden können.

Häufige Muster​

Ein Modul auf ein Team beschränken: Erstellen Sie eine benutzerdefinierte Rolle mit nur den Berechtigungen ppm.* und inventory.view. Weisen Sie sie dem Projektportfolioteam zu. Sie können im PPM arbeiten, können aber nicht das Hauptinventar bearbeiten.

Genehmigungsrechte ohne Bearbeitungsrechte vergeben: Geben Sie einem Business-Stakeholder die Stakeholder-Rolle „Business Application Owner" auf bestimmten Application-Karten. Konfigurieren Sie diese Rolle so, dass sie card.approval_status einschließt, aber nicht card.edit. Sie können Karten genehmigen, die das EA-Team befüllt hat, aber die Daten nicht ändern.

Break-Glass für einen Admin: Der Admin-Platzhalter bedeutet, dass jede zukünftige Berechtigung – einschließlich Berechtigungen, die durch Erweiterungen oder zukünftige Versionen hinzugefügt werden – automatisch gewährt wird. Verwenden Sie die Admin-Rolle nur für Benutzer, die wirklich uneingeschränkten Zugriff benötigen.

Als bestimmte Rolle testen: Benutzer mit admin.impersonate können aus dem Benutzermenü in eine beliebige Nicht-Admin-Rolle wechseln (Als Rolle anzeigen…), um genau zu überprüfen, was diese Rolle sehen und tun kann – ohne ein separates Testkonto erstellen zu müssen. Die Übernahme-Sitzung ist nur JWT-basiert und hinterlässt keine Spuren auf dem zugrunde liegenden Konto. Siehe Rollenübernahme für den vollständigen Ablauf.

Siehe auch​