Zurück zur Startseite

RBAC mit Status in JMatrixPlatform

JMatrixPlatform kombiniert RBAC mit Objektstatus für granulare Zugriffssteuerung. Filterung wird auf SQL-Ebene angewendet, Status werden auditiert. Beispiele für Rollen-, Richtlinienkonfiguration und promote/demote-Methoden werden bereitgestellt.

Status-Rollen-RBAC in JMatrix: Code und Praxis
Advertisement 728x90

Statusbasiertes RBAC in JMatrixPlatform: Zugriffskontrolle mit Lebenszyklus-Bewusstsein

JMatrixPlatform implementiert rollenbasierte Zugriffskontrolle (RBAC), indem Berechtigungen an die Status von Objekten gebunden werden. Jedes Objekt besitzt einen Typ und einen Lebenszyklus – eine definierte Abfolge von Statuswerten, die seinen aktuellen Zustand widerspiegeln. Bei der Erstellung eines Objekts wird dessen Typ sowie der zugehörige Lebenszyklus festgelegt; der Anfangsstatus ist standardmäßig der erste Status dieses Lebenszyklus oder wird explizit im createAction überschrieben.

Ein einzelner Objekttyp kann mehrere Lebenszyklen unterstützen. Beispiel:

| Objekt | Typ | Lebenszyklus | Status | Mögliche Folgestatus |

Google AdInline article slot

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

| Obj1 | Typ1 | LZ1 | Stat1 | Stat1*, Stat2 |

| Obj2 | Typ1 | LZ2 | Stat4 | Stat1–4* |

Google AdInline article slot

| Obj3 | Typ1 | LZ3 | Stat2 | Stat1–3* |

Typische Lebenszyklen umfassen:

  • Dokumentation: Entwurf → Veröffentlicht → Prüfung → Archiviert → Ausgestellt
  • Referenzdaten: Neu → Aktiv → Veraltet

Statusübergänge erfolgen über promote (vorwärts) oder demote (rückwärts); sämtliche Änderungen werden vollständig protokolliert in der Tabelle object_states:

Google AdInline article slot
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
);

Die Audit-Logs ermöglichen Analysen zu Prozessverzögerungen: SELECT user_id FROM object_states WHERE policy_state = ? AND (state_end - state_start) >= ?.

Rollen- und Richtlinienkonfiguration

Rollen erweitern 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 für Referenzdaten";
  }
}

Lebenszyklen erweitern 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));
    }
  }
}

Werte für AccessType:

  • ALL: Vollzugriff
  • READ: Nur Lesen
  • CREATE: Neue Instanzen erstellen
  • MODIFY: Vorhandene Daten bearbeiten
  • DELETE: Objekte löschen
  • RELEASE: Versionsverwaltung
  • PROMOTE: Zum nächsten Status vorrücken
  • DEMOTE: Auf vorherigen Status zurücksetzen
  • CHECKIN: Dateien hochladen
  • CHECKOUT: Dateien herunterladen

Objekterstellung:

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

Die Plattform prüft die CREATE-Berechtigung am Anfangsstatus. Statusübergänge nutzen:

obj.promote(ctx); // vorwärts
obj.demote(ctx);  // rückwärts

Datenbankebene Autorisierungsmechanismen

JWT-Rollen sind nahtlos mit Keycloak integriert; zeilenbasierte Filterung erfolgt direkt in SQL-Abfragen – sensible Daten verlassen die Datenbank niemals ohne vorherige Autorisierung.

Maximaler Zugriff

JSystemAdmin umgeht alle Prüfungen für maximale Performance.

Statusbasierte Zugriffskontrolle

Beispielhafte Zugriffsmatrix:

| Rolle | Neu | Aktiv | Veraltet |

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

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

| JPublic | #KEINZUGRIFF| READ | READ |

Für JPublic: WHERE policy_state IN ('ALCReference.Active', 'ALCReference.Inactive').

Für Administratoren: Keine Statusbeschränkungen. Optimierungshinweis: Maximal ca. 100 Status pro Richtlinie; Filterung über temporäre Tabellen wird evaluiert.

Eigenschaftsbasierte Filterung

In Entwicklung. Die rekursive Durchquerung von Beziehungen für Zugriffsprüfungen ist aktuell ineffizient.

Wichtigste Erkenntnisse

  • Status sind nativ in das RBAC-Konzept integriert – damit wird feingranulare, nicht-destruktive Zugriffskontrolle möglich.
  • Der vollständige Status-Audit-Verlauf in object_states unterstützt Prozessanalysen und Compliance-Berichterstattung.
  • Filterung auf SQL-Ebene stellt sicher, dass sensible Daten niemals ohne ausdrückliche Autorisierung die Datenbank verlassen.
  • Jede promote-/demote-Aktion wird mit Benutzer-ID und Zeitstempel protokolliert.
  • Nahtlose Synchronisation von Keycloak-Rollen in JWT-Tokens.

— Editorial Team

Advertisement 728x90

Weiterlesen