Role i zakres uprawnień

OpenFactory przechowuje niezależne role na poziomie organizacji, unitu i zespołu. Nazwa roli opisuje zakres; to nie uniwersalne uprawnienie, które automatycznie dotyczy każdego API ani każdej funkcji produktu.

Model zakresu

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

Członkostwo w organizacji to zewnętrzna granica. Użytkownik musi należeć do organizacji, zanim administrator doda go do unitu lub zespołu. Członkostwo sprawdza się osobno na każdym poziomie; nie wnioskuj roli unitu ani zespołu z roli organizacji pokazanej w innym kontekście.

Role organizacji

Obecne API zarządzania organizacją wymusza te uprawnienia:

Organizacja może mieć więcej niż jednego owner. API blokuje wyjście jedynego owner, dopóki nie ma innego owner albo organizacja nie zostanie usunięta. W tym API nie ma osobnej akcji « transfer ownership »; owner zmienia rolę innego członka na owner, a potem może zmienić lub usunąć poprzedniego owner zgodnie z planem.

Role unitu

Ownerzy i admini organizacji mogą zarządzać każdym unit. W unit obecne API zarządzania organizacją przyznaje unit_admin te operacje administracyjne:

• edycja unitu;
• dodawanie, usuwanie i zmiana ról członków unitu;
• tworzenie, edycja i usuwanie zespołów w tym unit;
• dodawanie członków zespołu w tym unit i zarządzanie nimi.

Tylko owner lub admin organizacji może usunąć sam unit.

base_creator, base_approver i unit member to zapisane etykiety ról dla polityki workflow obrazów bazowych. Trasy CRUD organizacji same w sobie nie dowodzą, że każda akcja create, approve lub deploy gdzie indziej egzekwuje te etykiety. Sprawdź zachowanie autoryzacji konkretnego workflow build lub approval, zanim potraktujesz je jako kontrolę.

Role zespołu

Ownerzy/admini organizacji oraz unit_admin nadrzędnego unitu mogą zarządzać członkostwem w zespole. team_lead może:

• edytować nazwę lub opis zespołu;
• dodawać i usuwać członków zespołu;
• zmieniać role członków zespołu.

team_lead nie może usunąć zespołu przez obecne organization API; ta operacja jest zarezerwowana dla owner/admin organizacji lub nadrzędnego unit_admin.

variant_creator, variant_deployer i variant_user opisują zamierzone obowiązki w workflow wariantów. Nie traktuj ich jako dowodu, że każdy endpoint wariantu egzekwuje pełną macierz create/edit/deploy. Przetestuj dokładny workflow i denied paths w wdrożonej wersji.

Groups to coś innego

Groups to kolekcje udostępniania na poziomie organizacji, a nie kolejna hierarchia ról. Ownerzy i admini tworzą groups i zarządzają członkostwem w group; wszyscy członkowie organizacji mogą wyświetlać groups i ich członków. Członkostwo w group nie czyni użytkownika adminem organizacji, adminem unitu ani team lead.

Bezpieczna zmiana roli

1. Potwierdź docelową organizację, unit lub zespół.
2. Zapisz bieżące skuteczne członkostwa użytkownika na wszystkich trzech poziomach.
3. Wprowadź jedną zmianę roli.
4. Przetestuj dozwoloną i odrzuconą operację w sesji tego użytkownika.
5. Sprawdź, czy zbuforowany stan UI i istniejące sesje odzwierciedlają zmianę.
6. Zachowaj rekord audytu poza etykietą roli, jeśli wymaga tego polityka.

Zmiana etykiety bez testu denied path nie wystarczy jako dowód egzekwowania least privilege.

Typowe przypadki brzegowe

• Admin nie może awansować nikogo na owner ani zmienić roli istniejącego owner.
• Użytkownika nie dodasz do unitu ani zespołu, dopóki nie należy do organizacji.
• Członkowie unitu i zespołu mogą usunąć siebie; członkostwo w organizacji zostaje, chyba że usuniesz je osobno.
• Po usunięciu członkostwa w organizacji sprawdź w swojej wersji efekty dla przestarzałych unitów, zespołów, groups, share i sesji.
• Kolory odznak w UI to prezentacja, nie kontrola bezpieczeństwa. Opieraj się na autoryzacji po stronie serwera i testach denied path.