RBAC con estados en JMatrixPlatform

RBAC basado en estados en JMatrixPlatform: control de acceso consciente del ciclo de vida

JMatrixPlatform implementa el Control de Acceso Basado en Roles (RBAC) vinculando los permisos a los estados de los objetos. Cada objeto tiene un tipo y un ciclo de vida: una secuencia definida de estados que refleja su estado actual. Al crear un objeto, se especifica su tipo y el ciclo de vida asociado; el estado inicial es, por defecto, el primero de ese ciclo o se sobrescribe explícitamente en la acción createAction.

Un solo tipo de objeto puede soportar múltiples ciclos de vida. Por ejemplo:

| Objeto | Tipo | Ciclo de vida | Estado | Estados siguientes disponibles |

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

| Obj1 | Tipo1 | CL1 | Est1 | Est1*, Est2 |

| Obj2 | Tipo1 | CL2 | Est4 | Est1–4* |

| Obj3 | Tipo1 | CL3 | Est2 | Est1–3* |

Ciclos de vida típicos incluyen:

• Documentación: Borrador → Publicado → Revisión → Archivado → Emitido
• Datos de referencia: Nuevo → Activo → Obsoleto

Las transiciones de estado se realizan mediante promote (hacia adelante) o demote (hacia atrás), con registro completo de auditoría en la tabla 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
);

Los registros de auditoría permiten analizar retrasos en los procesos: SELECT user_id FROM object_states WHERE policy_state = ? AND (state_end - state_start) >= ?.

Configuración de roles y políticas

Los roles extienden 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 "Administrador de datos de referencia";
  }
}

Los ciclos de vida extienden 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));
    }
  }
}

Valores de AccessType:

• ALL: Control total
• READ: Solo lectura
• CREATE: Crear nuevas instancias
• MODIFY: Editar datos existentes
• DELETE: Eliminar objetos
• RELEASE: Gestión de versiones
• PROMOTE: Avanzar al siguiente estado
• DEMOTE: Retroceder al estado anterior
• CHECKIN: Subir archivos
• CHECKOUT: Descargar archivos

Creación de objetos:

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

La plataforma valida el permiso CREATE contra el estado inicial. Las transiciones de estado usan:

obj.promote(ctx); // hacia adelante
obj.demote(ctx);  // hacia atrás

Mecanismos de autorización a nivel de base de datos

Los roles JWT se integran con Keycloak, y el filtrado a nivel de fila se aplica directamente en las consultas SQL: los datos nunca salen de la base de datos sin autorización previa.

Acceso máximo

JSystemAdmin omite todas las comprobaciones para lograr el máximo rendimiento.

Acceso basado en estados

Ejemplo de matriz de acceso:

| Rol | Nuevo | Activo | Obsoleto |

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

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

| JPublic | #NOACCESS | READ | READ |

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

Para administradores: sin restricciones por estado. Nota de optimización: máximo ~100 estados por política; se está evaluando el filtrado basado en tablas temporales.

Filtrado basado en propiedades

En desarrollo. Actualmente, el recorrido recursivo de relaciones para las comprobaciones de acceso es ineficiente.

Conclusiones clave

• Los estados están integrados de forma nativa en el RBAC, lo que permite un control de acceso granular y no destructivo.
• El historial completo de estados en object_states respalda el análisis de procesos y los informes de cumplimiento normativo.
• El filtrado a nivel de SQL garantiza que los datos sensibles nunca abandonen la base de datos sin autorización explícita.
• Cada acción promote/demote se registra con el ID de usuario y la marca de tiempo.
• Sincronización fluida de roles de Keycloak en tokens JWT.

— Editorial Team