Skip to Content
OrganizationsOrganisaties

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 members

Deze 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

  1. Maak de organization aan; de maker wordt owner.
  2. Voeg een tweede verantwoordelijke owner toe voordat u op de organization vertrouwt voor blijvende operaties.
  3. Nodig gebruikers uit op hun exacte e-mailadressen en wijs de laagste vereiste organization-rol toe.
  4. Voeg units of teams alleen toe wanneer hun scope een echte workflow wijzigt.
  5. Test één toegestane en één geweigerde actie met elke representatieve rol.
  6. 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.