Como projetar o controle de acesso baseado em função?

Estou tentando seguir o modelo de controle de acesso às bases de função para restringir o que os usuários podem ou não fazer no meu sistema.

Até o momento, tenho as seguintes entidades:

usuários - Pessoas que usarão o sistema. Aqui eu tenho nomes de usuário e senhas. Papéis - conjunto de papéis que os usuários podem ter. Recursos como gerente, administrador, etc. recursos - coisas que os usuários podem manipular. Como contratos, usuários, rascunhos de contrato, etc. operações - coisas que os usuários podem fazer com os recursos. Como criar, ler, atualizar ou excluir.

Agora, minha dúvida surge aqui no diagrama em que tenho uma relação como esta:

As operações (0 .. *) são executadas nos recursos (0 .. *) que geram uma tabela que chamei de permissões e que armazenará a operação e o recurso .

A tabela de permissões terá esta aparência (uma linha): ID: 1, operação: create, recurso: contrato.

O que significa uma permissão para criar um contrato .

Fiz dessa maneira porque sinto que alguns recursos podem não ter todos os tipos de operações. Por exemplo, para registrar contratos , os usuários podem fazer upload de arquivos , mas esta operação não está disponível para registrar um provedor .

Portanto, agora, quando o administrador conceder permissões para uma função , ele não terá uma lista de recursos com todas as operações registradas no sistema.

Eu acho que cada recurso tem sua própria coleção de operações que podem ser executadas nele.

Posso esclarecer se algo não é compreensível.

Essa é a maneira correta de implementar o rbac?

EDITAR

O que quero dizer é que, por ter uma tabela de permissões que possui operação e recurso , tenho DUAS tabelas extras porque quero associar recursos a operações . Eu também poderia ter acabado de fazer os recursos terem permissões onde a tabela de permissões armazenaria as permissões.

Mas o que teria acontecido é que algumas permissões que nem sequer existem para alguns recursos apareceriam quando o administrador as atribuiria.

Então, eu quero saber do ponto de vista do design do banco de dados se esta permissão de tabela que possui uma operação de coluna e outro recurso está correta? Terei problemas se continuar assim?

Seu design parece bem próximo de mim. Apenas algumas sugestões.

usuários - Pessoas que usarão o sistema. Aqui eu tenho nomes de usuário e senhas.

Bem

Papéis - conjunto de papéis que os usuários podem ter. Coisas como gerente, administrador etc.

Bem também. Mas você também precisará de uma entidade / tabela "UserRoles" que indique quais usuários têm quais funções. É provável que um determinado usuário possa ter duas ou mais funções.

recursos - Coisas que os usuários podem manipular. Como contratos, usuários, rascunhos de contrato, etc.

Pode ser apenas uma questão de semântica. Não acho que os usuários manipulem recursos diretamente; papéis fazem. Assim vai o usuário -> função do usuário -> função -> operação -> recurso

operações - coisas que os usuários podem fazer com os recursos. Como criar, ler, atualizar ou excluir.

sim, exceto "papéis" em vez de "usuários"

A tabela de permissões terá esta aparência (uma linha): ID: 1, operação: create, recurso: contrato. O que significa uma permissão para criar um contrato.

Hummm. Existem duas maneiras de fazer isso. Você pode ter a tabela de permissões que descreve, mas também precisa de uma RolePermissionstabela / entidade adicional que informe qual função tem qual permissão. Mas não tenho certeza se isso é necessário.

Uma maneira mais simples de fazer isso é uma tabela / entidade de permissões com estas colunas / atributos: ID da função, ID da operação, ID do recurso. Dessa forma, as operações x combinações de recursos são atribuídas diretamente a uma função, em vez de carregadas em uma permissão atribuída a uma função. Elimina uma entidade. Realmente não há necessidade de uma tabela de permissões independente de função, a menos que você queira predefinir quais combinações de permissões são permitidas e quais não são.

Eu não usaria ou implementaria o RBAC. Em vez disso, eu usaria o ABAC. Deixe-me explicar...

• O RBAC ou controle de acesso baseado em função é sobre gerenciamento de usuário e atribuição de função. No RBAC, você pode dizer que Alice é gerente. Você pode definir permissões estáticas junto com isso. Por exemplo, um gerente pode aprovar empréstimos. Portanto, há um link de Alice para o gerente para aprovar o empréstimo como uma permissão. Existem muitos sistemas que permitem fazer isso, assim você não precisa implementar suas próprias tabelas. Até o LDAP tem suporte para conjuntos limitados de RBAC. Tudo bem, desde que você tenha um conjunto relativamente pequeno de funções e permissões. Mas e se você quiser levar em conta permissões específicas, como é o seu caso? Ver, excluir, inserir? E se você quiser levar em consideração os relacionamentos?
• O ABAC ou controle de acesso baseado em atributos é sobre autorização refinada e orientada por políticas. Com o ABAC, você pode usar as funções definidas no RBAC e escrever políticas, por exemplo
  • Os gerentes podem visualizar documentos em seu departamento
  • Os funcionários podem editar documentos que possuem

Na sua pergunta, você definiu essencialmente o modelo de informação. Seus objetos e seus atributos, por exemplo, um usuário (nome, senha, departamento ...); um objeto (por exemplo, um contrato) e assim por diante.

Portanto, no ABAC, você desacopla completamente o código / lógica do aplicativo da lógica de autorização, que é então armazenada como políticas usando atributos. As permissões em si são armazenadas diretamente na política (veja o exemplo acima). A arquitetura de implantação ABAC se parece com a seguinte

O ponto é que, se você adotar uma abordagem ABAC, escreve políticas para o ABAC (em XACML ou ALFA - existem muitas ferramentas para isso) e nunca precisa codificar ou implementar RBAC ou implementar o RBAC ou o controle de acesso novamente.