Organisationen

OpenFactorys Organisations-API speichert Organisationsmitgliedschaften plus optionale Groups, Units und Teams. Sie liefert auch Ziele zum Teilen von Conversations/Variants.


organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
    ├── unit members
    └── teams
        └── team members

Diese Hierarchie ist Authorization-Input. Ein Rollenlabel beweist nicht, dass jeder Build-, VM-, Download- oder Deployment-Endpoint die beabsichtigte Policy durchsetzt. Siehe Rollen und Berechtigungsumfang für die derzeit pro Rolle governed Routes.

Kernobjekte

Organization: oberste Mitgliedschafts- und Administrationsgrenze. Ein User kann mehreren Organisationen angehören.
Group: benannte Sammlung von Organisationsmitgliedern als Share-Target; keine administrative Hierarchie.
Unit: abteilungsähnlicher Container mit eigener Mitgliedschaft und gespeicherten Workflow-Rollen.
Team: Kind einer Unit mit eigener Mitgliedschaft und gespeicherten Workflow-Rollen.

User müssen Organisationsmitglieder sein, bevor sie darunter hinzugefügt werden.

Sichere Setup-Reihenfolge

Organisation anlegen; der Ersteller wird Owner.
Zweiten verantwortlichen Owner hinzufügen, bevor Sie die Organisation für dauerhafte Operationen nutzen.
User zu exakten E-Mail-Adressen einladen und die niedrigste nötige Organisationsrolle zuweisen.
Units oder Teams nur anlegen, wenn der Scope einen echten Workflow ändert.
Eine erlaubte und eine verweigerte Aktion pro repräsentativer Rolle testen.
Share- und Mitgliedschaftsverhalten nach Rollenentzug und Session-Refresh prüfen.

Einladungen laufen ab und müssen von einem Konto mit passender E-Mail angenommen werden. Übermitteln Sie Invite-Tokens nicht in Tickets oder öffentlichen Logs.

Kontext und Ownership

Organisationsauswahl kann sichtbare Kollaborationsdaten beeinflussen, aber einzelne Ressourcen tragen weiter Owner- und Share-Regeln. Leiten Sie keinen Zugriff auf privaten Build oder Artefakt allein daraus ab, dass zwei User derselben Organisation angehören. Nutzen Sie explizites Teilen, wo unterstützt, und testen Sie Download/VM-Aktion getrennt.

Isolations-Nachweis

Organisations- und Sharing-Routes führen Membership-Checks und Same-Organization-Validation für ihre scoped Operations aus. „Tenant isolation“ ist eine breitere Systemeigenschaft und braucht Cross-Tenant-Denied-Path-Tests über Conversations, Builds, Artefakte, VMs, APIs, Caches, Exports und Logs. Nutzen Sie die Organisationshierarchie allein nicht als diesen Nachweis.

Administrations-Safeguards

Mehrere Owner sind unterstützt; der alleinige Owner kann nicht gehen.
Nur ein Owner kann einen weiteren Owner befördern oder die Organisation löschen.
Löschung und Membership-Entfernung können abhängigen Zugriff beeinflussen. Inventarisieren Sie Shares, Units, Teams, aktive Sessions und owned Resources zuerst.
Bewahren Sie externen Audit-Record, falls Ihre Policy es verlangt; eine aktuelle Rollenliste ist kein historischer Audit-Trail.

Weiter mit Sharing und Units and Teams.