Controle de acesso baseado em função versus permissão

38

Estou tentando entender a desvantagem inerente entre funções e permissões quando se trata de controle de acesso (autorização).

Vamos começar com um dado: em nosso sistema, uma Permissão será uma unidade refinada de acesso (" Editar recurso X ", " Acesso a página do painel ", etc.). Uma Função será uma coleção de 1 ou mais permissões. Um Utilizador pode ter 1+ Funções. Todas essas relações (Usuários, Funções, Permissões) são armazenadas em um banco de dados e podem ser alteradas na hora e conforme necessário.

Minhas preocupações:

(1) What is so "bad" about checking Roles for access control? What benefits are gained by checking for permissions instead? In other words, what's the difference between these two snippets below:

if(SecurityUtils.hasRole(user)) {
    // Grant them access to a feature
}

// vs.
if(SecurityUtils.hasPermission(user)) {
    // Grant them access to a feature
}

E:

(2) In this scenario what useful value do Roles even provide? Couldn't we just assign 1+ Permissions to Users directly? What concrete value of abstraction do Roles offer (can someone give specific examples)?

    
por smeeb 13.10.2015 / 10:28
fonte

2 respostas

56

(1) What is so "bad" about checking Roles for access control? What benefits are gained by checking for permissions instead?

No momento da verificação, o código de chamada só precisa saber "o usuário X tem permissão para executar a ação Y?" .
O código de chamada não se importa e não deve estar ciente dos relacionamentos entre funções e permissões.

A camada de autorização verificará se o usuário tem essa permissão, geralmente verificando se a função do usuário tem essa permissão. Isso permite que você altere a lógica de autorização sem atualizar o código de chamada.

Se você verificar diretamente a função no site de chamadas, estará implicitamente formando relações de permissão de função e injetando a lógica de autorização no código de chamada, violando a separação de interesses.

Se mais tarde você decidir que a função foo não deveria ter permissão baz , você teria que alterar cada código que verifica se o usuário é um foo .

(2) In this scenario what useful value do Roles even provide? Couldn't we just assign 1+ Permissions to Users directly? What concrete value of abstraction do Roles offer (can someone give specific examples)?

Os papéis representam conceitualmente uma coleção nomeada de permissões.

Digamos que você esteja adicionando um novo recurso que permite ao usuário editar determinadas configurações. Este recurso deve estar disponível apenas para administradores.

Se você está armazenando permissões por usuário, você teria que encontrar todos os usuários em seu banco de dados que você de alguma forma conhece são administradores (se você não está armazenando informações de função para usuários, como você saberia quais usuários são administradores?) , e acrescente esta permissão à sua lista de permissões.

Se você usa funções, só precisa anexar a permissão à função Administrator , que é mais fácil de executar, mais eficiente em termos de espaço e menos propensa a erros.

    
por 13.10.2015 / 11:07
fonte
16

Em resposta à sua primeira pergunta, o maior problema em verificar se um usuário tem uma função do que uma permissão específica é que as permissões podem ser mantidas por várias funções. Como um exemplo disso, um desenvolvedor pode ter acesso para ver o portal do desenvolvedor na intranet da empresa, que provavelmente também é uma permissão de seu gerente. Se um usuário tentar acessar o portal do desenvolvedor, você terá um cheque semelhante a:

if(SecurityUtils.hasRole(developer)) {
    // Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
    // Grant them access to a feature
} else if...

(Uma declaração switch na sua língua de escolha seria melhor, mas ainda não é particularmente arrumada)

Quanto mais comum ou amplamente usada for uma permissão, mais funções de usuário você precisará verificar para garantir que alguém possa acessar um determinado sistema. Isso também levaria ao problema de que toda vez que você modificasse as permissões para uma função, seria necessário modificar a verificação para refletir isso. Em um sistema grande, isso se tornaria muito difícil de lidar muito rapidamente.

Se você simplesmente verificar que o usuário tem a permissão que permite acesso ao portal do desenvolvedor, por exemplo, não importa qual função ele tenha, ele terá acesso.

Para responder à sua segunda pergunta, o motivo pelo qual você tem papéis é porque eles agem como se fosse fácil modificar e distribuir "pacotes" de permissões. Se você tem um sistema com centenas de funções e milhares de permissões, adicionar um novo usuário (por exemplo, um novo gerente de RH) exigiria que você passasse e desse a cada permissão que outros gerentes de RH reservam. Não só isso seria entediante, mas é propenso a erros se feito manualmente. Compare isso com simplesmente adicionar a função "Gerente de RH" ao perfil de um usuário, que concederá a eles o mesmo acesso que qualquer outro usuário com essa função.

Você poderia argumentar que poderia simplesmente clonar um usuário existente (se o sistema oferecesse suporte para isso), mas ao mesmo tempo concedesse ao usuário as permissões corretas para aquele momento, tentando adicionar ou remover uma permissão para todos os usuários no o futuro pode ser difícil. Um cenário de exemplo para isso é se talvez no passado a equipe de RH também estivesse encarregada da folha de pagamento, mas mais tarde a empresa se tornasse grande o suficiente para contratar pessoal especificamente para lidar com a folha de pagamento. Isso significa que o RH não precisa mais acessar o sistema de folha de pagamento, de modo que a permissão pode ser removida. Se você tiver 10 membros diferentes de RH, precisará passar manualmente e remover a permissão correta, que introduz a possibilidade de erro do usuário. A outra questão com isto é que simplesmente não escala; À medida que você ganha mais e mais usuários em uma determinada função, torna a modificação de um papel muito mais difícil. Compare isso com o uso de funções, em que você só precisaria modificar a função abrangente em questão para remover a permissão, o que seria refletido por todos os usuários que detêm essa função.

    
por 13.10.2015 / 11:14
fonte