Rollen und Berechtigungsumfang

OpenFactory speichert unabhängige Rollen auf Organisations-, Unit- und Team-Ebene. Ein Rollenname beschreibt einen Scope; er ist keine universelle Berechtigung, die automatisch für jede API oder jedes Produktfeature gilt.

Scope-Modell


organization membership: owner | admin | member
└── unit membership: unit_admin | base_creator | base_approver | member
    └── team membership: team_lead | variant_creator | variant_deployer | variant_user

Organisationsmitgliedschaft ist die äußere Grenze. Ein User muss Organisationsmitglied sein, bevor ein Administrator ihn zu Units oder Teams hinzufügt. Mitgliedschaft wird auf jeder Ebene unabhängig geprüft; leiten Sie keine Unit- oder Team-Rolle aus einer Organisationsrolle in anderem Kontext ab.

Organisationsrollen

Die aktuelle Organization-Management-API erzwingt diese Berechtigungen:

Operation	Owner	Admin	Member
Organisation, Mitglieder, Groups, Units und Teams anzeigen	Ja	Ja	Ja
Organisationsname oder -beschreibung bearbeiten	Ja	Ja	Nein
Groups anlegen, bearbeiten oder löschen und Group-Mitglieder verwalten	Ja	Ja	Nein
Ordentliche Mitglieder einladen oder entfernen	Ja	Ja	Nein
Rollen ordentlicher Member/Admin ändern	Ja	Ja	Nein
Owner einladen oder befördern	Ja	Nein	Nein
Bestehenden Owner ändern oder entfernen	Ja	Nein	Nein
Units anlegen oder löschen	Ja	Ja	Nein
Organisation löschen	Ja	Nein	Nein
Organisation verlassen	Ja, außer alleiniger Owner	Ja	Ja

Eine Organisation kann mehr als einen Owner haben. Die API verhindert, dass der alleinige Owner geht, bis ein weiterer Owner existiert oder die Organisation gelöscht wird. Es gibt keine separate „transfer ownership“-Aktion in dieser API; ein Owner setzt die Rolle eines anderen Members auf owner, dann kann er den vorherigen Owner wie beabsichtigt ändern oder entfernen.

Unit-Rollen

Organisations-Owner und -Admins können jede Unit verwalten. Innerhalb einer Unit gewährt die aktuelle Organization-Management-API unit_admin diese Admin-Operationen:

Unit bearbeiten;
Unit-Member-Rollen hinzufügen, entfernen und ändern;
Teams in dieser Unit anlegen, bearbeiten und löschen;
Team-Mitglieder in dieser Unit hinzufügen und verwalten.

Nur Organisations-Owner oder -Admin kann die Unit selbst löschen.

base_creator, base_approver und Unit-member sind gespeicherte Rollenlabels für Base-Image-Workflow-Policy. Die Organization-CRUD-Routes beweisen nicht selbst, dass jede Create-, Approve- oder Deployment-Aktion anderswo diese Labels durchsetzt. Prüfen Sie Authorization-Verhalten des konkreten Build- oder Approval-Workflows, bevor Sie es als Control vertrauen.

Team-Rollen

Organisations-Owner/Admins und unit_admin der Parent-Unit können Team-Mitgliedschaft verwalten. Ein team_lead kann:

Teamname oder -beschreibung bearbeiten;
Team-Mitglieder hinzufügen und entfernen;
Team-Member-Rollen ändern.

Ein team_lead kann das Team über die aktuelle Organisations-API nicht löschen; diese Operation ist Organisations-Owner/Admin oder Parent-unit_admin vorbehalten.

variant_creator, variant_deployer und variant_user drücken beabsichtigte Variant-Workflow-Verantwortlichkeiten aus. Lesen Sie sie nicht als Nachweis, dass jeder Variant-Endpoint eine vollständige Create/Edit/Deploy-Matrix durchsetzt. Testen Sie exakten Workflow und Denied Paths in der ausgerollten Version.

Groups sind anders

Groups sind Organisations-Level-Sharing-Sammlungen, keine weitere Rollenhierarchie. Owner und Admins legen Groups an und verwalten Group-Mitgliedschaft; alle Organisationsmitglieder können Groups und deren Mitglieder listen. Group-Mitgliedschaft macht einen User nicht zum Organisations-Admin, Unit-Admin oder Team-Lead.

Rolle sicher ändern

Ziel-Organisation, Unit oder Team bestätigen.
Aktuelle effektive Mitgliedschaften des Users auf allen drei Scopes dokumentieren.
Eine Rollenänderung anwenden.
Erlaubte und verweigerte Operation mit der eigenen Session des Users testen.
Prüfen, dass gecachter UI-Zustand und bestehende Sessions die Änderung widerspiegeln.
Audit-Record außerhalb des Rollenlabels aufbewahren, falls Ihre Policy es verlangt.

Eine Label-Änderung ohne Denied-Path-Test ist kein ausreichender Nachweis für Least-Privilege-Durchsetzung.

Häufige Edge Cases

Ein Admin kann niemanden zum Owner befördern oder die Rolle eines bestehenden Owners ändern.
Ein User kann nicht zu Unit oder Team hinzugefügt werden, bis er zur Organisation gehört.
Unit- und Team-Mitglieder können sich selbst entfernen; Organisationsmitgliedschaft bleibt, sofern nicht separat entfernt.
Organisationsmitgliedschaft-Entfernung sollte auf stale Unit-, Team-, Group-, Share- und Session-Effekte in Ihrer Version geprüft werden.
UI-Badge-Farben sind Präsentation, kein Security-Control. Verlassen Sie sich auf serverseitige Authorization und Denied-Path-Tests.