RBAC i uprawnienia

Autoryzacja na platformie DataFlow AI jest regulowana przez hierarchiczny model kontroli dostępu opartej na rolach (RBAC). Haczyk: istnieją trzy różne słowniki ról — role realmu Keycloak, hierarchia backendowa DataFlowRole oraz persony frontendu — które muszą być pogodzone przez zakodowane na sztywno tabele mapowania. Ta strona dokumentuje wszystkie trzy, pełne macierze uprawnień, sposób działania egzekwowania oraz znane luki.

Trzy słowniki ról

Pojedynczy człowiek-użytkownik jest opisywany trzema różnymi nazwami ról w zależności od tego, na którą warstwę patrzysz. Zrozumienie mapowania między nimi jest niezbędne do rozumowania o dostępie.

1. Role realmu Keycloak

Realm dataflow dostarcza sześć ról realmu: org_admin, workspace_admin, developer, analyst, operator oraz viewer. org_admin jest rolą złożoną, która obejmuje pozostałych pięć.

2. Hierarchia backendowa DataFlowRole

RBACService.DataFlowRole definiuje pięć uporządkowanych ról, każdą z numerycznym poziomem:

ADMIN(100) > ENGINEER(75) > ANALYST(50) > STEWARD(40) > VIEWER(25)

Rola przyznaje każde uprawnienie, którego requiredRole.level jest mniejszy lub równy poziomowi roli użytkownika (RBACService.hasPermission).

3. Persony frontendu

SPA modeluje cztery persony (PersonaId): admin, engineer, analyst oraz steward. Każda persona mapuje się na stały zestaw uprawnień oraz listę dozwolonych prefiksów tras.

Tabele mapowania

Grupy Keycloak → role realmu

Eksport realmu mapuje cztery grupy w stylu korporacyjnym na role realmu:

KeycloakJwtConverter oraz RBACService dodatkowo wiedzą o PLK-BI-Stewards i PLK-BI-Viewers, ale te grupy nie występują w dostarczonym eksporcie realmu.

Zaszczepieni użytkownicy

Wszyscy czterej zaszczepieni użytkownicy mają puste credentials oraz requiredActions: [UPDATE_PASSWORD].

Dowolna surowa rola → DataFlowRole

Brama mapuje każdy surowy ciąg roli, który zobaczy — role realmu, role klienta, nazwy grup oraz ścieżki grup — na pojedynczy DataFlowRole (RBACService.mapSingleRole / KeycloakJwtConverter). Wygrywa najwyższa zmapowana rola; wartością domyślną jest VIEWER.

KeycloakJwtConverter.extractAuthorities konwertuje rozwiązaną rolę na uprawnienia Spring ROLE_*. Jeśli JWT nie ma żadnych mapowalnych ról, zestaw uprawnień jest pusty, a żądanie jest odrzucane przez @PreAuthorize — to celowy wybór przeciwdziałający eskalacji uprawnień. Mapowania org_admin / developer / operator zostały dodane późno, aby naprawić sytuację użytkowników, którzy w przeciwnym razie byliby po cichu degradowani do ANALYST lub VIEWER.

Backendowa macierz uprawnień

RBACService definiuje katalog 30 uprawnień, każde oznaczone requiredRole. Ponieważ model jest hierarchiczny, rola otrzymuje uprawnienie, gdy jej poziom jest ≥ poziomu wymaganej roli uprawnienia.

Uprawnienia według domeny

Role × uprawnienia (hierarchicznie)

✔ = przyznane. Poziomy: ADMIN 100, ENGINEER 75, ANALYST 50, STEWARD 40, VIEWER 25.

Kontrole uwzględniające workspace

RBACService udostępnia także kontrole o zakresie workspace nałożone na kontrole uprawnień:

• canAccessWorkspace — ADMIN widzi wszystkie workspace; workspace default jest otwarty dla wszystkich; każdy inny workspace wymaga członkostwa.
• canModifyPipeline, canDeletePipeline, canRunPipeline — każda ocenia odpowiednie uprawnienie oraz kontrolę workspace.

Frontendowa macierz uprawnień

Frontendowy katalog uprawnień (frontend/src/types/permissions.ts) definiuje 28 uprawnień jako ciągi domain:action obejmujące domeny pipeline, quality, governance, lineage, code, admin, system oraz catalog. (Komentarz nagłówkowy pliku mówi „26"; rzeczywista lista to 28.) Uprawnienia są przypisywane per persona poprzez personaPermissions, a model jest opisany jako wspierany po stronie serwera przez PolicyEngine.kt w metadata-service.

Persona × uprawnienia

✔ = przyznane. Persona admin posiada wszystkie 28 uprawnień.

Zwróć uwagę, jak frontendowa persona steward posiada bogate uprawnienia governance:*, quality:*, lineage:edit oraz catalog:* — dokładnie te uprawnienia, których backendowa hierarchia odmawia STEWARD (poziom 40). Ta rozbieżność jest jedną ze znanych luk.

Jak działa egzekwowanie

Autoryzacja jest egzekwowana w dwóch warstwach: brama sprawdza ważność tokenu i obecność roli; każda usługa stosuje drobnoziarniste kontrole na poziomie metody oraz workspace/własności.

 Request ──▶ API Gateway ──▶ Downstream service ──▶ @PreAuthorize ──▶ workspace check
              │                  │                       │
              │ token valid?     │ JWT re-validated      │ method-level
              │ role present?    │ X-User-* → context    │ role/permission
              ▼                  ▼                       ▼
        coarse HTTP rule    SecurityContext        fine-grained grant

Reguły na poziomie bramy

Gdy dev-permit-reads=false, reaktywny SecurityConfig bramy stosuje gruboziarniste reguły oparte na metodzie do /api/v1/**:

Gdy dev-permit-reads=true, wszystkie żądania GET plus POST-y copilot / ai / catalog-ask / search stają się permitAll.

Adnotacja @PreAuthorize na poziomie usługi

Usługi niższego poziomu uruchamiają @EnableMethodSecurity(prePostEnabled = true), więc kontrolery noszą adnotacje @PreAuthorize. Ponieważ KeycloakJwtConverter produkuje rzeczywiste uprawnienia ROLE_*, hasRole / hasAnyRole oceniają autentyczne role Keycloak. Reprezentatywna próbka zaobserwowanych zabezpieczeń:

Zabezpieczenia tras frontendu

RBAC frontendu jest tylko UX — SPA jest klientem publicznym, a rzeczywiste egzekwowanie zawsze odbywa się po stronie serwera. Mimo to frontend uniemożliwia użytkownikom nawigację do stron, których nie mogą używać:

• ProtectedRoute pokazuje spinner podczas isLoading, przekierowuje do /login jeśli !isAuthenticated, następnie wywołuje canAccess(effectivePersona, pathname) i renderuje AccessDenied w przypadku niepowodzenia. effectivePersona to magazyn person w trybie deweloperskim, w przeciwnym razie user.persona.

• RBAC oparty na prefiksie trasy — data/permissions.ts definiuje personaRoutes; canAccess dopasowuje dozwolony prefiks dokładnie lub jako prefix + '/'. Ta mapa jest zablokowana przez permissions-rbac.test.ts (65 asercji).
• PermissionGate to zabezpieczenie na poziomie komponentu zbudowane na hookach usePermission / usePermissions / useAnyPermission, obsługujące pojedyncze lub wiele uprawnień z requireAll oraz opcjonalnym fallback.
• useAuth().hasRole(role) sprawdza realmRoles; useAuth().hasPermission(perm) sprawdza pochodzącą z persony tablicę permissions.

Dozwolone prefiksy tras per persona

Znane ryzyka i luki

Badanie ujawniło kilka problemów z poprawnością autoryzacji wartych śledzenia.

Niedopasowane role @PreAuthorize

Kilka kontrolerów zabezpiecza punkty końcowe nazwami ról, których rzeczywisty token Keycloak nigdy nie może nosić. KeycloakJwtConverter emituje wyłącznie pięć kanonicznych uprawnień ROLE_ADMIN, ROLE_ENGINEER, ROLE_ANALYST, ROLE_STEWARD oraz ROLE_VIEWER. Zabezpieczenia takie jak:

• hasRole('DATA_STEWARD') oraz hasRole('DATA_ENGINEER') — QuarantineController
• hasRole('PLATFORM_OPS') — reindeksacja SearchController
• hasAnyRole('governance-admin','data-steward') — TagController

...nigdy nie dopasują się do autentycznego użytkownika. Te punkty końcowe są faktycznie niedostępne dla rzeczywistych użytkowników — stają się osiągalne tylko w trybie dev-permit-reads, gdzie anonimowemu użytkownikowi przyznawany jest szeroki zestaw ról, który akurat obejmuje ROLE_DATA_STEWARD / ROLE_DATA_ENGINEER. To rzeczywista wada poprawności autoryzacji.

Inwersja hierarchii STEWARD

Jak zauważono powyżej, STEWARD (poziom 40) plasuje się poniżej ANALYST (poziom 50) w hierarchii backendu, więc STEWARD dziedziczy tylko uprawnienia poziomu VIEWER z RBACService — podczas gdy model person frontendu nadaje stewardowi szerokie prawa zarządzania, jakości, lineage oraz katalogu. Oba modele nie zgadzają się co do tego, jak potężny jest steward, a uprawnienia STEWARD w backendzie zależą całkowicie od jawnych list @PreAuthorize, a nie od hierarchii.

Furtka dev-permit-reads

dataflow.gateway.dev-permit-reads (domyślnie false) to potężny przełącznik. Gdy true, dopuszcza wszystkie żądania GET bez uwierzytelnienia i przyznaje anonimowemu użytkownikowi niższego poziomu szeroki zestaw ról (ROLE_ADMIN, ROLE_DPO, ROLE_COMPLIANCE_OFFICER, ROLE_AUDITOR, ROLE_STEWARD, ROLE_OPS, ROLE_ENGINEER, ROLE_USER, ROLE_DATA_ENGINEER, ROLE_DATA_STEWARD). W produkcji musi być false, a nie znaleziono żadnego zabezpieczenia środowiskowego, które by to egzekwowało.

Inne obserwacje

• Fragmentacja słownika ról — trzy systemy ról godzone wyłącznie przez zakodowane na sztywno tabele mapowania w RBACService, KeycloakJwtConverter oraz keycloak.ts. Mapowania org_admin / developer były późną poprawką błędu.
• Rozbieżność dokumentacji — przewodnik administratora opisuje rolę MANAGER oraz klienta dataflow-ui, które nie istnieją ani w kodzie, ani w eksporcie realmu.

Podsumowanie

Aby poznać stronę uwierzytelniania — jak tożsamość jest ustanawiana, zanim uruchomi się którakolwiek z tych kontroli — zobacz Uwierzytelnianie i SSO.