Modello di database con utenti, ruoli e diritti

Ho un modello di database con una tabella utente e una tabella dei ruoli. Voglio controllare l'accesso (diritti) a un massimo di 10 elementi diversi. L'accesso può essere concesso a un ruolo oa un singolo utente. Di seguito è riportata la definizione della tabella di utenti, ruoli ed elementi:

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,
  ...
);

...

Ora ho due modi diversi di progettare i diritti. Una tabella con una colonna del tipo di diritti o 10 tabelle dei diritti, una per ogni elemento a cui voglio controllare l'accesso.

Quali sono i pro e i contro di una tabella dei diritti rispetto a una tabella dei diritti per elemento? - o è il modo più adatto per farlo?

Innanzitutto, che tipo di modello di sicurezza prevedi di implementare? Controllo degli accessi in base al ruolo (RBAC) o Controllo dell'accesso discrezionale (DAC)?

RBAC nel modello RBAC (Role-Based Access Control), l'accesso alle risorse si basa sul ruolo assegnato a un utente. In questo modello, un amministratore assegna un utente a un ruolo che ha determinati diritti e privilegi predeterminati. A causa dell'associazione dell'utente al ruolo, l'utente può accedere a determinate risorse ed eseguire attività specifiche. RBAC è anche noto come controllo di accesso non discrezionale. I ruoli assegnati agli utenti sono amministrati centralmente.

DAC Nel modello Discretionary Access Control (DAC), l'accesso alle risorse si basa sull'identità dell'utente. A un utente vengono concesse le autorizzazioni per una risorsa essendo collocato in un elenco di controllo di accesso (ACL) associato alla risorsa. Una voce nell'ACL di una risorsa è nota come voce di controllo di accesso (ACE). Quando un utente (o gruppo) è il proprietario di un oggetto nel modello DAC, l'utente può concedere l'autorizzazione ad altri utenti e gruppi. Il modello DAC si basa sulla proprietà delle risorse.

vedi fonte

1) In RBAC: è necessario disporre della tabella ElementType per assegnare i diritti al ruolo (gli utenti sono assegnati ai ruoli). RBAC definisce: "Cosa può fare questo ruolo / utente". L'amministratore assegna i diritti per i ruoli e le autorizzazioni ai ruoli, assegna gli utenti ai ruoli per accedere alle risorse. 2) Nel DAC: utenti e ruoli hanno diritti sugli elementi tramite l'elenco di controllo degli accessi (proprietà). Il DAC definisce: "chi ha accesso ai miei dati". L'utente (proprietario) concede le autorizzazioni alla risorsa posseduta.

Ad ogni modo suggerisco questo modello di dati:

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

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

(relazione uno a uno)

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

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

1) RBAC (relazione molti-a molti)

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

2) DAC (rapporto molti-a-molti)

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 tabella dei diritti per ogni elemento, non appena aggiungi un elemento dovrai aggiungere una tabella. Ciò aggiungerebbe alla manutenzione dell'applicazione.

L'aspetto negativo di mettere tutto in una tabella è che potresti incorrere in problemi di ridimensionamento, ma questi potrebbero essere mitigati usando il partizionamento, le viste materializzate e / o le colonne virtuali. Probabilmente tali misure non sarebbero necessarie.

Per quanto riguarda il design del tavolo, se questo fosse su Oracle potrei suggerire qualcosa del genere:

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;

Il codice del pacchetto potrebbe utilizzare la sequenza UserRoleID per popolare l'id nella tabella Users e l'id nella tabella Ruoli, se necessario. La tabella Autorizzazioni può quindi avere elementi assegnati a ruoli a loro volta assegnati agli utenti e / o elementi assegnati direttamente agli utenti.