RBAC ze statusami w JMatrixPlatform

RBAC z powiązaniem do statusów obiektów w JMatrixPlatform

JMatrixPlatform implementuje model RBAC poprzez przypisywanie uprawnień dostępu do konkretnych statusów obiektów. Każdy obiekt ma typ oraz cykl życia — sekwencję statusów określającą jego aktualny stan. Przy tworzeniu obiektu określa się jego typ i cykl życia; początkowy status jest automatycznie ustawiany na pierwszy z listy lub nadpisany w metodzie createAction.

Jeden typ może obsługiwać wiele różnych cykli życia. Przykład:

| Obiekt | Typ | Cykl | Status | Dostępne stany |

|--------|------|------|------------|--------------------------|

| Obj1 | Typ1 | CL1 | Stan.1 | Stan.1*, Stan.2 |

| Obj2 | Typ1 | CL2 | Stan.4 | Stan.1–4* |

| Obj3 | Typ1 | CL3 | Stan.2 | Stan.1–3* |

Typowy cykl dla dokumentów: Szkic → Opublikowany → Zatwierdzanie → Archiwum → Wydany. Dla słowników: Nowy → Aktywny → Przestarzały.

Zmiana statusu odbywa się przez operacje promote (przejście do kolejnego etapu) lub demote (powrót do wcześniejszego etapu), z pełnym audytem w tabeli object_states:

create table object_states (
    object_id uuid not null,
    policy_state varchar(100) not null,
    user_id uuid not null,
    state_start timestamp not null,
    state_end timestamp
);

Audyt pozwala analizować opóźnienia procesowe: SELECT user_id FROM object_states WHERE policy_state = ? AND (state_end - state_start) >= ?.

Konfiguracja ról i polityk

Role dziedziczą po klasie JRole:

@JModelPart
public final class ARLReferenceAdmin extends JRole {
  public final static ARLReferenceAdmin ROLE = new ARLReferenceAdmin();

  @Override
  public Set<JRole> getParents() {
    return Set.of(ARLRefDesigner.ROLE, ARLRefChangeManagementAdmin.ROLE, ARLRefApprover.ROLE);
  }

  @Override
  public String getDescription() {
    return "Administrator słowników";
  }
}

Cykle życia definiowane są jako polityki dziedziczące po JPolicy:

@JModelPart
public final class ALCReference extends JPolicy {
  public final static ALCReference POLICY = new ALCReference();

  @Override
  public Set<JType> getTypes() {
    return Set.of(ATPReference.TYPE);
  }
  
  @Override
  public List<JState> getStates() {
    return List.of(New.STATE, Active.STATE, Inactive.STATE);
  }

  public static final class New extends JPolicy.JState {
    public static final New STATE = new New();
    @Override
    public Set<RoleAccess> getAccess() {
      return Set.of(new RoleAccess(ARLReferenceAdmin.ROLE, AccessType.ALL));
    }
  }

  public static final class Active extends JPolicy.JState {
    public static final Active STATE = new Active();
    @Override
    public Set<RoleAccess> getAccess() {
      return Set.of(
        new RoleAccess(JPublic.ROLE, AccessType.READ),
        new RoleAccess(ARLReferenceAdmin.ROLE, AccessType.PROMOTE, AccessType.DEMOTE));
    }
  }

  public static final class Inactive extends JPolicy.JState {
    public static final Inactive STATE = new Inactive();
    @Override
    public Set<RoleAccess> getAccess() {
      return Set.of(
        new RoleAccess(JPublic.ROLE, AccessType.READ),
        new RoleAccess(ARLReferenceAdmin.ROLE, AccessType.DEMOTE));
    }
  }
}

Dostępne typy uprawnień (AccessType):

• ALL: pełna kontrola
• READ: odczyt
• CREATE: tworzenie
• MODIFY: modyfikacja
• DELETE: usuwanie
• RELEASE: wersjonowanie
• PROMOTE: przejście do następnego statusu
• DEMOTE: powrót do poprzedniego statusu
• CHECKIN: przesyłanie plików
• CHECKOUT: pobieranie plików

Tworzenie obiektu:

JDomainObject obj = new JDomainObject();
obj.create(ctx, ATPDocuments.TYPE, ALCDocument.POLICY);

Platforma sprawdza uprawnienia do działania CREATE w początkowym statusie. Metody zmiany statusu:

obj.promote(ctx); // przejście do kolejnego etapu
obj.demote(ctx);  // powrót do poprzedniego etapu

Mechanizmy autoryzacji na poziomie bazy danych

Role z tokenów JWT są synchronizowane z Keycloakiem; filtrowanie danych odbywa się bezpośrednio w zapytaniach SQL — dane nie opuszczają bazy bez odpowiednich uprawnień.

Maksymalny dostęp

JSystemAdmin — brak kontroli dostępu, maksymalna wydajność.

Dostęp zależny od statusu

Przykładowa macierz uprawnień:

| Rola | Nowy | Aktywny | Przestarzały |

|---------------------|-------------|-----------------------------|--------------|

| ARLReferenceAdmin | ALL | READ, PROMOTE, DEMOTE | READ, DEMOTE |

| JPublic | #NOACCESS | READ | READ |

Dla użytkownika JPublic: WHERE policy_state IN ('ALCReference.Active', 'ALCReference.Inactive').

Dla administratora — dostęp do wszystkich statusów. Optymalizacja: ograniczenie liczby obsługiwanych statusów do ok. 100; planowane wprowadzenie tymczasowych tabel.

Filtrowanie po atrybutach

W fazie rozwoju. Rekurencyjne sprawdzanie relacji między obiektami jest nieefektywne.

Kluczowe zalety rozwiązania

• Statusy są integralną częścią modelu RBAC, umożliwiając szczegółową kontrolę dostępu bez usuwania danych.
• Pełny audyt zmian statusów w tabeli object_states wspiera analizę procesów biznesowych.
• Filtrowanie na poziomie SQL zapewnia, że dane pozostają w bazie, dopóki użytkownik nie uzyska odpowiednich uprawnień.
• Operacje promote/demote rejestrują identyfikator użytkownika i dokładny czas wykonania.
• Automatyczna synchronizacja ról z Keycloakiem poprzez tokeny JWT.

— Editorial Team