Modelo de banco de dados com usuários, funções e direitos

Eu tenho um modelo de banco de dados com uma tabela de usuário e tabela de funções. Quero controlar o acesso (direitos) a até 10 elementos diferentes. O acesso pode ser concedido a uma função ou a um único usuário. Abaixo está a definição de tabela de usuários, funções e itens:

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

...

Agora, tenho duas maneiras diferentes de projetar os direitos. Uma tabela com uma coluna do tipo de direitos ou 10 tabelas de direitos - uma para cada elemento ao qual desejo controlar o acesso.

Quais são os prós e os contras de uma tabela de direitos versus uma tabela de direitos por elemento? - ou é a maneira mais adequada de fazer isso?

Primeiro de tudo, que tipo de modelo de segurança você planeja implementar? Controle de Acesso Baseado em Função (RBAC) ou Controle de Acesso Discricionário (DAC)?

RBAC no modelo RBAC (Controle de Acesso Baseado em Função), o acesso aos recursos é baseado na função atribuída a um usuário. Nesse modelo, um administrador atribui um usuário a uma função que possui certos direitos e privilégios predeterminados. Devido à associação do usuário com a função, o usuário pode acessar determinados recursos e executar tarefas específicas. O RBAC também é conhecido como Controle de Acesso Não Discricionário. As funções atribuídas aos usuários são administradas centralmente.

DAC No modelo Controle de Acesso Discricionário (DAC), o acesso aos recursos é baseado na identidade do usuário. Um usuário recebe permissões para um recurso ao ser colocado em uma lista de controle de acesso (ACL) associada ao recurso. Uma entrada na ACL de um recurso é conhecida como Entrada de Controle de Acesso (ACE). Quando um usuário (ou grupo) é o proprietário de um objeto no modelo DAC, o usuário pode conceder permissão para outros usuários e grupos. O modelo DAC é baseado na propriedade dos recursos.

ver fonte

1) No RBAC: você precisa da tabela ElementType para atribuir direitos à função (os usuários são atribuídos às funções). O RBAC define: "O que essa função / usuário pode fazer". O administrador atribui direitos a funções e permissões a funções, atribui usuários a funções para acessar recursos. 2) No DAC: usuários e funções têm direito a elementos via lista de controle de acesso (propriedade). O DAC define: "quem tem acesso aos meus dados". Usuário (proprietário) concede permissões ao recurso de propriedade.

De qualquer forma, sugiro este modelo de dados:

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

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

(relacionamento um a um)

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

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

1) RBAC (relacionamento muitos-para-muitos)

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

2) DAC (relacionamento muitos-para-muitos)

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

Com uma tabela de direitos para cada elemento, assim que você adicionar um elemento, será necessário adicionar uma tabela. Isso adicionaria à manutenção do aplicativo.

A desvantagem de colocar tudo em uma tabela é que você pode ter problemas de dimensionamento, mas esses podem ser mitigados usando particionamento, visualizações materializadas e / ou colunas virtuais. Provavelmente, essas medidas não seriam necessárias.

Quanto ao design da tabela, se isso estivesse no Oracle, eu poderia sugerir algo assim:

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;

O código do pacote pode usar a sequência UserRoleID para preencher o ID na tabela Usuários e o ID na tabela Funções, conforme necessário. A tabela Permissões pode ter elementos atribuídos a funções que, por sua vez, são atribuídas a usuários e / ou elementos atribuídos diretamente a usuários.