Modèle de base de données avec utilisateurs, rôles et droits

J'ai un modèle de base de données avec une table d'utilisateurs et une table de rôles. Je souhaite contrôler l'accès (droits) à 10 éléments différents au maximum. L'accès peut être accordé à un rôle ou à un seul utilisateur. Vous trouverez ci-dessous la définition du tableau des utilisateurs, rôles et éléments:

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

...

J'ai maintenant deux manières différentes de concevoir les droits. Une table avec une colonne de type de droits ou 10 tables de droits, une pour chaque élément pour lequel je souhaite contrôler l'accès.

Quels sont les avantages et les inconvénients d'une table de droits par rapport à une table de droits par élément? - ou est-ce un moyen plus approprié de le faire?

Tout d’abord, quel type de modèle de sécurité envisagez-vous de mettre en œuvre? Contrôle d'accès basé sur les rôles (RBAC) ou contrôle d'accès discrétionnaire (DAC)?

RBAC dans le modèle de contrôle d'accès basé sur le rôle (RBAC), l'accès aux ressources est basé sur le rôle attribué à un utilisateur. Dans ce modèle, un administrateur attribue à un utilisateur un rôle doté de certains droits et privilèges prédéterminés. En raison de l'association de l'utilisateur avec le rôle, l'utilisateur peut accéder à certaines ressources et effectuer des tâches spécifiques. Le RBAC est également connu sous le nom de contrôle d'accès non discrétionnaire. Les rôles attribués aux utilisateurs sont administrés de manière centralisée.

DAC Dans le modèle DAC (Discretionary Access Control), l'accès aux ressources est basé sur l'identité de l'utilisateur. Un utilisateur se voit accorder des autorisations sur une ressource en étant placé sur une liste de contrôle d'accès (ACL) associée à une ressource. Une entrée de la liste de contrôle d'accès d'une ressource est appelée entrée de contrôle d'accès (ACE). Lorsqu'un utilisateur (ou un groupe) est le propriétaire d'un objet dans le modèle DAC, l'utilisateur peut accorder des autorisations à d'autres utilisateurs et groupes. Le modèle DAC est basé sur la propriété des ressources.

voir la source

1) Dans RBAC: vous avez besoin de la table ElementType pour attribuer des droits au rôle (les utilisateurs sont affectés à un ou plusieurs rôles). RBAC définit: "Que peut faire ce rôle / utilisateur". L'administrateur attribue des droits pour les rôles et des autorisations pour les rôles, attribue aux utilisateurs des rôles pour accéder aux ressources. 2) Sous DAC: les utilisateurs et les rôles ont des droits sur les éléments via la liste de contrôle d'accès (propriété). DAC définit: "qui a accès à mes données". Utilisateur (propriétaire) accorde des autorisations à la ressource possédée.

De toute façon, je suggère ce modèle de données:

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

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

(une à une relation)

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

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

1) RBAC (relation plusieurs à plusieurs)

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

2) DAC (relation plusieurs à plusieurs)

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

Avec une table de droits pour chaque élément, dès que vous ajoutez un élément, vous devez ajouter une table. Cela ajouterait à la maintenance de l'application.

L'inconvénient de tout mettre dans une seule table est que vous pouvez rencontrer des problèmes de dimensionnement, mais que ceux-ci pourraient être atténués à l'aide du partitionnement, des vues matérialisées et / ou des colonnes virtuelles. De telles mesures ne seraient probablement pas nécessaires.

En ce qui concerne la conception de la table, si cela était sur Oracle, je pourrais suggérer quelque chose comme ceci:

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;

Le code de package peut utiliser la séquence UserRoleID pour renseigner l'ID dans la table Users et l'ID dans la table Roles, si nécessaire. La table des autorisations peut alors avoir des éléments attribués à des rôles qui sont à leur tour attribués à des utilisateurs et / ou des éléments attribués directement à des utilisateurs.