Roller og tilladelsesomfang

OpenFactory gemmer uafhængige roller på organisations-, unit- og teamniveau. Et rollenavn beskriver et omfang; det er ikke en universel tilladelse, der automatisk gælder for hvert API eller hver produktfunktion.

Omfangsmodel

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

Organisationsmedlemskab er den ydre grænse. En bruger skal være organisationsmedlem, før en administrator kan tilføje vedkommende til units eller teams. Medlemskab tjekkes separat på hvert niveau; udled ikke en unit- eller teamrolle ud fra en organisationsrolle vist i en anden kontekst.

Organisationsroller

Det nuværende organization-management API håndhæver disse tilladelser:

En organisation kan have mere end én owner. API’et forhindrer den eneste owner i at forlade, indtil der findes en anden owner, eller organisationen slettes. Der findes ingen separat handling « transfer ownership » i dette API; en owner sætter en anden medlems rolle til owner og kan derefter ændre eller fjerne den tidligere owner efter hensigt.

Unitroller

Organisations-owners og -admins kan administrere hver unit. Inden for en unit giver det nuværende organization-management API unit_admin disse administrative handlinger:

• redigere unit;
• tilføje, fjerne og ændre unit-medlemsroller;
• oprette, redigere og slette teams i den unit;
• tilføje og administrere teammedlemmer i den unit.

Kun organisations-owner eller -admin kan slette selve unit.

base_creator, base_approver og unit-member er gemte rolleetiketter til policy for base-image-workflows. Organization CRUD-ruterne beviser ikke i sig selv, at hver create-, approve- eller deployment-handling andre steder håndhæver disse etiketter. Kontrollér autorisationsadfærden i den konkrete build- eller approval-workflow, før I stoler på den som kontrol.

Teamroller

Organisations-owners/admins og unit_admin i den overordnede unit kan administrere teammedlemskab. En team_lead kan:

• redigere teamnavn eller -beskrivelse;
• tilføje og fjerne teammedlemmer;
• ændre teammedlemsroller.

En team_lead kan ikke slette teamet via det nuværende organization API; den handling er forbeholdt organisations-owner/admin eller overordnet unit_admin.

variant_creator, variant_deployer og variant_user udtrykker tilsigtede ansvarsområder i variant-workflows. Læs dem ikke som bevis for, at hvert variant-endpoint håndhæver en fuld create/edit/deploy-matrice. Test den præcise workflow og denied paths i den udrullede version.

Groups er anderledes

Groups er delingskollektioner på organisationsniveau, ikke endnu en rollehierarki. Owners og admins opretter groups og administrerer groupmedlemskab; alle organisationsmedlemmer kan liste groups og deres medlemmer. Groupmedlemskab gør ikke en bruger til organisationsadmin, unit-admin eller team lead.

Skift rolle sikkert

1. Bekræft målorganisation, unit eller team.
2. Notér brugerens nuværende effektive medlemskaber på alle tre niveauer.
3. Gennemfør én rolleændring.
4. Test både en tilladt og en afvist handling med brugerens egen session.
5. Kontrollér, at cachelagret UI-tilstand og eksisterende sessioner afspejler ændringen.
6. Bevar auditpost uden for rolleetiketten, hvis jeres policy kræver det.

At ændre etiket uden denied-path-test er ikke tilstrækkeligt bevis for, at least privilege håndhæves.

Almindelige kanttilfælde

• En admin kan ikke forfremme nogen til owner eller ændre en eksisterende owners rolle.
• En bruger kan ikke tilføjes til unit eller team, før vedkommende hører til organisationen.
• Unit- og teammedlemmer kan fjerne sig selv; organisationsmedlemskab består, medmindre det fjernes separat.
• Ved fjernelse af organisationsmedlemskab bør I i jeres release tjekke for forældede unit-, team-, group-, share- og sessionseffekter.
• Farver på UI-badges er præsentation, ikke sikkerhedskontrol. Stol på server-side autorisation og denied-path-tests.