RBAC avec statuts dans JMatrixPlatform

RBAC basé sur les statuts dans JMatrixPlatform : contrôle d'accès adapté au cycle de vie

JMatrixPlatform implémente un contrôle d’accès basé sur les rôles (RBAC) en liant les autorisations aux statuts des objets. Chaque objet possède un type et un cycle de vie — une séquence prédéfinie de statuts reflétant son état actuel. Lors de la création d’un objet, son type et le cycle de vie associé sont spécifiés ; le statut initial correspond par défaut au premier statut de ce cycle, ou est explicitement remplacé dans l’action createAction.

Un même type d’objet peut supporter plusieurs cycles de vie. Par exemple :

| Objet | Type | Cycle de vie | Statut | Statuts suivants disponibles |

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

| Obj1 | Type1 | LC1 | Stat1 | Stat1*, Stat2 |

| Obj2 | Type1 | LC2 | Stat4 | Stat1–4* |

| Obj3 | Type1 | LC3 | Stat2 | Stat1–3* |

Des cycles de vie courants incluent :

• Documentation : Brouillon → Publié → En relecture → Archivé → Diffusé
• Données de référence : Nouveau → Actif → Obsolète

Les transitions de statut s’effectuent via promote (avancement) ou demote (recul), avec une traçabilité complète dans la table 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
);

Les journaux d’audit permettent d’analyser les retards de processus : SELECT user_id FROM object_states WHERE policy_state = ? AND (state_end - state_start) >= ?.

Configuration des rôles et des politiques

Les rôles étendent la classe 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 "Administrateur des données de référence";
  }
}

Les cycles de vie étendent 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));
    }
  }
}

Valeurs de AccessType :

• ALL : Contrôle total
• READ : Lecture seule
• CREATE : Création de nouvelles instances
• MODIFY : Modification des données existantes
• DELETE : Suppression des objets
• RELEASE : Gestion des versions
• PROMOTE : Passage au statut suivant
• DEMOTE : Retour au statut précédent
• CHECKIN : Téléversement de fichiers
• CHECKOUT : Téléchargement de fichiers

Création d’un objet :

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

La plateforme valide l’autorisation CREATE par rapport au statut initial. Les transitions de statut utilisent :

obj.promote(ctx); // avancement
obj.demote(ctx);  // recul

Mécanismes d’autorisation au niveau base de données

Les rôles JWT s’intègrent nativement à Keycloak, et le filtrage au niveau ligne est appliqué directement dans les requêtes SQL — aucune donnée ne quitte la base sans autorisation explicite.

Accès maximal

Le rôle JSystemAdmin contourne tous les contrôles pour garantir des performances optimales.

Accès basé sur les statuts

Exemple de matrice d’accès :

| Rôle | Nouveau | Actif | Obsolète |

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

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

| JPublic | #NOACCESS | READ | READ |

Pour JPublic : WHERE policy_state IN ('ALCReference.Active', 'ALCReference.Inactive').

Pour les administrateurs : aucune restriction liée au statut. Note d’optimisation : environ 100 statuts maximum par politique ; un filtrage basé sur des tables temporaires est à l’étude.

Filtrage basé sur les propriétés

En cours de développement. La traversée récursive des relations pour les vérifications d’accès reste actuellement peu efficace.

Points clés à retenir

• Les statuts sont intégrés nativement au RBAC — ce qui permet un contrôle d’accès fin, précis et non destructif.
• La traçabilité complète des statuts dans object_states soutient l’analyse des processus et les rapports de conformité.
• Le filtrage au niveau SQL garantit qu’aucune donnée sensible ne quitte la base sans autorisation explicite.
• Chaque action promote/demote est journalisée avec l’identifiant utilisateur et l’horodatage.
• Synchronisation transparente des rôles Keycloak vers les jetons JWT.

— Editorial Team