Warum dieses Modell existiert
Payroll-Zusammenarbeit hat echte Sicherheitsauswirkungen. Ein Rollenmodell, das leicht zu lesen, zu testen und zu prüfen ist, ist sicherer als verstreute Einzelprüfungen.
Die Organization <-> Member-Struktur gibt jedem Akteur eine explizite Beziehung zu einer Organisation mit richtlinienbewusstem Status, Rolle und Scope.
Änderungen an der Organization <-> Member-Beziehung
- Mitgliedschaft wird als explizite Beziehung statt als impliziter UI-Zustand dargestellt.
- Lebenszykluszustände für Zugriffsanfrage, Einladung, Genehmigung, Aktivierung und Widerruf werden durch Backend-Policy erzwungen.
- Organisationsbereiche und Benachrichtigungen spiegeln Übergänge und Rollenergebnisse konsistenter wider.
- Geteiltes Organisationsverhalten wird vor privilegierten Aktionen durch den Mitgliedschaftszustand gesteuert.
Rollenänderungen und aktuelle Rollenphilosophie
Rollen sind capability-gesteuert, mit Scope-Beschränkungen pro Operation. Die aktuelle Basis:
- owner: sovereign control including ownership transfer and high-trust governance actions.
- manager: day-to-day operational control without ownership transfer authority.
- contributor: trusted operator with write authority constrained by assigned scope.
- member: limited self-service participation with restricted mutation rights.
- viewer: read-only visibility without write permissions.
Wir bevorzugen explizite Capability- und Scope-Komposition gegenüber überladenen Rollenflags. So bleiben Rollenergebnisse leichter testbar und nachvollziehbar.
Sicherheits- und Verschlüsselungsphilosophie
Organisationszusammenarbeit überschneidet sich mit Verschlüsselung und Consent-Kontrollen. Mitgliedschafts- und Rollenprüfungen steuern geteiltes Envelope-Verhalten, damit sensible Operationen an Richtlinien gebunden bleiben.
- Mitgliedschafts- und Consent-Zustand werden validiert, bevor geteilte sichere Operationen fortfahren.
- Rollenänderungen und Mitgliedschaftsübergänge gelten als sicherheitsrelevante Ereignisse, nicht nur als UX-Ereignisse.
- Zugriffsverweigerungen sind erwartetes Verhalten bei Policy-Abweichungen und werden für Auditierbarkeit sichtbar gemacht.
Operative Philosophie nach vorn
- Single policy source: role and scope decisions should originate from shared backend policy maps.
- UI as projection: interfaces should display policy outcomes rather than duplicate authorization logic.
- Traceable transitions: approvals, role changes, and revocations should remain observable and reviewable.
- Release transparency: behavior changes in membership and roles are documented in changelogs and transparency pages.