Модель базы данных с пользователями, ролями и правами

У меня есть модель базы данных с таблицей пользователей и таблицей ролей. Я хочу контролировать доступ (права) до 10 различных элементов. Доступ может быть предоставлен либо роли, либо одному пользователю. Ниже приведена таблица определений пользователей, ролей и элементов:

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

...

Теперь у меня есть два разных способа оформления прав. Одна таблица со столбцом типа прав или 10 таблиц прав - по одной для каждого элемента, доступ к которому я хочу контролировать.

Каковы плюсы и минусы одной таблицы прав против одной таблицы прав на элемент? - или это более подходящий способ сделать это?

Прежде всего, какую модель безопасности вы планируете внедрить? Управление доступом на основе ролей (RBAC) или Дискреционное управление доступом (DAC)?

RBAC в модели управления доступом на основе ролей (RBAC), доступ к ресурсам основан на роли, назначенной пользователю. В этой модели администратор назначает пользователю роль, которая имеет определенные предопределенные права и привилегии. Из-за ассоциации пользователя с ролью пользователь может получить доступ к определенным ресурсам и выполнять определенные задачи. RBAC также известен как недискреционный контроль доступа. Роли, назначенные пользователям, администрируются централизованно.

DAC В модели Discretionary Access Control (DAC) доступ к ресурсам основан на идентичности пользователя. Пользователь получает разрешения для ресурса, будучи помещенным в список управления доступом (ACL), связанный с ресурсом. Запись в ACL ресурса известна как запись контроля доступа (ACE). Когда пользователь (или группа) является владельцем объекта в модели DAC, пользователь может предоставить разрешение другим пользователям и группам. Модель DAC основана на владении ресурсами.

увидеть источник

1) В RBAC: вам нужна таблица ElementType для назначения прав на роль (пользователям назначаются роли (и)). RBAC определяет: «Что может сделать эта роль / пользователь». Администратор назначает права ролям и разрешения ролям, назначает пользователей ролям для доступа к ресурсам. 2) В ЦАП: пользователи и роли имеют права на элементы через список контроля доступа (владение). ЦАП определяет: «у кого есть доступ к моим данным». Пользователь (владелец) предоставляет разрешения на принадлежащий ему ресурс.

В любом случае я предлагаю эту модель данных:

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

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

(отношения один на один)

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

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

1) RBAC (отношения многие ко многим)

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

2) ЦАП (отношения многие ко многим)

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

С таблицей прав для каждого элемента, как только вы добавите элемент, вам нужно будет добавить таблицу. Это добавит к обслуживанию приложений.

Недостатком размещения всего в одной таблице является то, что вы можете столкнуться с проблемами масштабирования, но их можно устранить с помощью секционирования, материализованных представлений и / или виртуальных столбцов. Вероятно, такие меры не будут необходимы.

Что касается дизайна таблицы, если бы это было в Oracle, я мог бы предложить что-то вроде этого:

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;

Код пакета может использовать последовательность UserRoleID для заполнения идентификатора в таблице «Пользователи» и идентификатора в таблице «Роли» по мере необходимости. В таблице разрешений могут быть элементы, назначенные ролям, которые, в свою очередь, назначаются пользователям и / или элементы которых назначаются непосредственно пользователям.