Modelo de base de datos con usuarios, roles y derechos.

Tengo un modelo de base de datos con una tabla de usuario y una tabla de roles. Quiero controlar el acceso (derechos) a hasta 10 elementos diferentes. El acceso se puede otorgar a un rol o a un solo usuario. A continuación se muestra la definición de la tabla de usuarios, roles y elementos:

CREATE TABLE users
(
  id serial NOT NULL PRIMARY KEY,
  username character varying UNIQUE,
  password character varying,
  first_name character varying,
  last_name character varying,
  ...
);

CREATE TABLE roles
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

CREATE TABLE element_1
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

...

Ahora tengo dos formas diferentes de diseñar los derechos. Una tabla con una columna de tipo de derechos o 10 tablas de derechos, una para cada elemento al que quiero controlar el acceso.

¿Cuáles son los pros y los contras de una tabla de derechos frente a una tabla de derechos por elemento? ¿O es la forma más adecuada de hacer esto?

En primer lugar, ¿qué tipo de modelo de seguridad planea implementar? ¿Control de acceso basado en roles (RBAC) o control de acceso discrecional (DAC)?

RBAC en el modelo de Control de acceso basado en roles (RBAC), el acceso a los recursos se basa en el rol asignado a un usuario. En este modelo, un administrador asigna un usuario a un rol que tiene ciertos derechos y privilegios predeterminados. Debido a la asociación del usuario con el rol, el usuario puede acceder a ciertos recursos y realizar tareas específicas. RBAC también se conoce como control de acceso no discrecional. Los roles asignados a los usuarios se administran centralmente.

DAC En el modelo de control de acceso discrecional (DAC), el acceso a los recursos se basa en la identidad del usuario. Un usuario recibe permisos sobre un recurso al ser colocado en una lista de control de acceso (ACL) asociada con el recurso. Una entrada en la ACL de un recurso se conoce como Entrada de control de acceso (ACE). Cuando un usuario (o grupo) es el propietario de un objeto en el modelo DAC, el usuario puede otorgar permiso a otros usuarios y grupos. El modelo DAC se basa en la propiedad de los recursos.

ver fuente

1) En RBAC: necesita la tabla ElementType para asignar derechos a roles (los usuarios se asignan a roles). RBAC define: "¿Qué puede hacer este rol / usuario"? El administrador asigna derechos para roles y permisos a roles, asigna usuarios a roles para acceder a los recursos. 2) En DAC: los usuarios y los roles tienen derechos sobre los elementos a través de la lista de control de acceso (propiedad). DAC define: "quién tiene acceso a mis datos". El usuario (propietario) otorga permisos al recurso propio.

De cualquier manera sugiero este modelo de datos:

CREATE TABLE ElementType
(
    Id (PK)
    Name
    ...
)

CREATE TABLE ElementBase
(
    Id (PK)
    Type (FK to ElementType)
    ...
)

(relación uno a uno)

CREATE TABLE Element_A
(
    Id (PK, FK to ElementBase)
    ...
)

CREATE TABLE Element_B
(
    Id (PK, FK to ElementBase)
    ...
)

1) RBAC (relación de muchos a muchos)

CREATE TABLE ElementType_To_Role_Rights
(
    RightId (PK)
    RoleId  (FK to Role)
    ElementTypeId (FK to ElementType)
    ...
)

2) DAC (relación de muchos a muchos)

CREATE TABLE ElementBase_To_Actor_Rights
(
    RightId (PK)
    ElementBaseId (FK to ElementBase)
    ActorId (FK to Actor)
    ...
)

CREATE TABLE Actor
(
    Id (PK)
    Name
)

CREATE TABLE User
(
    Id (PK, FK to Actor)
    Password
    ...
)

CREATE TABLE Role
(
    Id (PK, FK to Actor)
    ...
)

Con una tabla de derechos para cada elemento, tan pronto como agregue un elemento, deberá agregar una tabla. Esto agregaría al mantenimiento de la aplicación.

La desventaja de poner todo en una tabla es que podría tener problemas de escala, pero estos podrían mitigarse mediante particiones, vistas materializadas y / o columnas virtuales. Probablemente tales medidas no serían necesarias.

En cuanto al diseño de la tabla, si esto estuviera en Oracle, podría sugerir algo como esto:

CREATE SEQUENCE UserRoleID;

CREATE TABLE USERROLE 
(
  USERID NUMBER(7) NOT NULL 
, ROLEID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    USERID 
  , ROLEID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

CREATE TABLE PERMISSIONS 
(
  ID NUMBER(7) NOT NULL 
, ELEMENTID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    ID 
  , ELEMENTID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

El código del paquete podría usar la secuencia UserRoleID para completar el Id. En la tabla Usuarios y el Id. En la tabla Roles según sea necesario. La tabla Permisos podría tener elementos asignados a roles que a su vez se asignan a usuarios y / o elementos asignados directamente a los usuarios.