Organisaties
De organization API van OpenFactory slaat organisatie-lidmaatschappen op, plus optionele groups, units en teams. Ze levert ook doelen voor het delen van conversations/variants.
organization
├── members: owner | admin | member
├── groups: organization-level sharing collections
└── units
├── unit members
└── teams
└── team membersDeze hiërarchie is input voor autorisatie. Een rollabel bewijst niet dat elk build-, VM-, download- of deployment-endpoint het beoogde beleid afdwingt. Zie Rollen en machtigingsbereik voor de routes die momenteel per rol worden afgedekt.
Kernobjecten
- Organization: grens voor lidmaatschap en beheer op het hoogste niveau. Een gebruiker kan bij meerdere organizations horen.
- Group: benoemde verzameling organization-leden die als share-doel dient; geen administratieve hiërarchie.
- Unit: container vergelijkbaar met een afdeling, met eigen lidmaatschap en opgeslagen workflow-rollen.
- Team: onderdeel van een unit met eigen lidmaatschap en opgeslagen workflow-rollen.
Gebruikers moeten organization-leden zijn voordat ze lager in de structuur worden toegevoegd.
Veilige opvolging bij setup
- Maak de organization aan; de maker wordt owner.
- Voeg een tweede verantwoordelijke owner toe voordat u op de organization vertrouwt voor blijvende operaties.
- Nodig gebruikers uit op hun exacte e-mailadressen en wijs de laagste vereiste organization-rol toe.
- Voeg units of teams alleen toe wanneer hun scope een echte workflow wijzigt.
- Test één toegestane en één geweigerde actie met elke representatieve rol.
- Controleer share- en lidmaatschapsgedrag na rolverwijdering en sessie-vernieuwing.
Uitnodigingen verlopen en moeten worden geaccepteerd door een account waarvan het e-mailadres overeenkomt met de uitnodiging. Stuur invite-tokens niet mee in tickets of openbare logs.
Context en eigendom
De gekozen organization kan zichtbare samenwerkingsgegevens beïnvloeden, maar individuele resources hebben nog steeds eigen owner- en share-regels. Leid geen toegang tot een private build of artifact af alleen omdat twee gebruikers tot dezelfde organization behoren. Gebruik expliciet delen waar dat wordt ondersteund en test de download-/VM-actie apart.
Isolatiebewijs
De organization- en sharing-routes voeren membership-checks en same-organization-validatie uit voor hun afgebakende operaties. “Tenant isolation” is een bredere systeemeigenschap en vereist cross-tenant denied-path-tests over conversations, builds, artifacts, VMs, API’s, caches, exports en logs. Gebruik de organization-hiërarchie alleen niet als dat bewijs.
Beveiliging bij beheer
- Meerdere owners worden ondersteund; de enige owner kan niet vertrekken.
- Alleen een owner kan een andere owner promoveren of de organization verwijderen.
- Verwijdering en het schrappen van lidmaatschap kunnen afhankelijke toegang raken. Inventariseer eerst shares, units, teams, actieve sessies en owned resources.
- Bewaar een extern auditrecord als uw beleid dat vereist; een actuele rollenlijst is geen historisch auditspoor.
Ga verder met Sharing en Units and Teams.