Controle de access baseado em function (RBAC) versus controle de access baseado em declarações (CBAC) no asp.net MVC

Quais são os principais benefícios do uso do CBAC vs. RBAC ? Quando é melhor usar o CBAC e quando é melhor usar o RBAC?

Estou tentando entender os conceitos gerais do modelo CBAC, mas a ideia geral ainda não está clara para mim.

Vou tentar mostrar como você pode se beneficiar do controle de access baseado em declarações em um contexto ASP.NET MVC.

Quando você está usando a autenticação baseada em function, se você tem uma ação para criar o cliente e deseja que as pessoas que estão na function ‘Venda’ possam fazer isso, então você escreve um código como este:

[Authorize(Roles="Sale")] public ActionResult CreateCustomer() { return View(); } 

Mais tarde, você percebeu que, às vezes, pessoas da function “Marketing” deveriam ser capazes de criar o Customer. Então, você atualiza seu método de ação assim

 [Authorize(Roles = "Sale", "Marketing")] public ActionResult CreateCustomer() { return View(); } 

Agora, você percebeu que algumas pessoas do marketing não podem criar o Cliente, mas não é possível atribuir uma function diferente para as pessoas que estão no Marketing. Assim, você é forçado a permitir que todos os profissionais de marketing criem clientes.

você identificou outro problema, sempre que você decide que as pessoas do Marketing devem ter permissão para criar clientes, é necessário atualizar todo o atributo Autorizar dos methods de Ação do MVC, compilar seu aplicativo, testar e implantar. Alguns dias depois, você decidiu não fazer marketing, mas alguma outra function deveria ter permissão para executar a tarefa, portanto, pesquise em sua base de código e exclua todo o atributo ‘Marketing’ do Authorize e adicione seu novo nome de function no atributo Authorize … Não é um solução saudável. Nesse ponto, você perceberia a necessidade do Controle de Acesso Baseado em Permissão.

O controle de access baseado em permissão é uma maneira de atribuir várias permissions a vários usuários e verificar se um usuário tem permissão para executar uma ação a partir do código em tempo de execução. Depois de atribuir várias permissions a vários usuários, você percebe que precisa permitir que alguns usuários executem algum código se o usuário tiver alguma propriedade como “Usuário do Facebook”, “Usuário de longa data”, etc. Deixe-me dar um exemplo. Digamos que você queira permitir o access a uma página específica se o usuário estiver logado usando o Facebook. Agora, você criaria uma permissão ‘Facebook’ para esse usuário? Não, o ‘Facebook’ não parece uma permissão. Faz isso? Pelo contrário, parece uma afirmação. Ao mesmo tempo, as permissions podem soar como Reivindicação também !! Portanto, é melhor verificar as reivindicações e permitir o access.

Agora, vamos voltar ao exemplo concreto do controle de access baseado em declarações.

Você pode definir algum conjunto de declarações como este:

“CanCreateCustomer”, “CanDeleteCustomer”, “CanEditCustomer” .. etc.

Agora, você pode decorar o seu método de ação assim:

  [ClaimAuthorize(Permission="CanCreateCustomer")] public ActionResult CreateCustomer() { return View(); } 

(por favor note, [ClaimAuthorize (Permission = “CanCreateCustomer”)] pode não ser construído na biblioteca de classs MVC, estou mostrando apenas como um exemplo, você pode usar alguma biblioteca de classs que tenha essa definição de class Attribute)

Agora, você pode ver que o método de ação CreateCustomer sempre precisará da permissão ‘CanCreateCustomer’ e nunca será alterado ou dificilmente será alterado. Assim, no seu database, você cria uma tabela de permissions (declarações) e relação de permissão do usuário. Do seu painel de administração, você pode definir permissão (reivindicação) para cada usuário que pode fazer o que. Você pode atribuir a permissão ‘CanCreateCustomer’ (reivindicação) a quem quiser e somente o usuário permitido poderá criar um cliente e o usuário permitido poderá criar apenas cliente e nada mais (a menos que você atribua outras permissions ao mesmo usuário).

Este modelo de segurança oferece uma prática de código limpa. Além disso, quando você escreve o seu método de ação, você não precisa pensar em quem pode usar esse método, em vez disso, pode sempre ter certeza de que quem estiver usando esse método terá a devida permissão (reivindicação) dada pelo administrador. Em seguida, o administrador pode decidir quem poderá fazer o quê. Não você como desenvolvedor. É assim que sua lógica de negócios é separada da lógica de segurança.

Sempre que alguém fizer login, seu aplicativo verificará quais permissions estão disponíveis para esse usuário e que a permissão (reivindicação) definida estará disponível como propriedades adicionais do usuário atualmente conectado (geralmente o conjunto de declarações é armazenado como cookie para o usuário conectado) assim você não precisa verificar a permissão definida todo o tempo do database. Em resumo, você obtém mais controle de sua lógica de segurança em seu aplicativo se aplicar o access com base em declarações em vez de acessar com base em funções. Na verdade, um Papel também pode ser considerado uma Reivindicação.

Se o seu aplicativo for um aplicativo muito pequeno em que haveria apenas duas funções: Cliente e Administrador e não há chance de que o Cliente possa fazer qualquer outra coisa além daquilo que ele deve fazer em seu aplicativo, então, talvez o controle de access servirá para o propósito, mas à medida que seu aplicativo crescer, você começará a sentir a necessidade de controle de access baseado em declarações em algum momento.

Eu não concordo plenamente com a resposta de Emran

 [Authorize(Roles="Sale")] 

É ingênuo

A questão é como

  [Authorize(Roles="CustomerCreator")] 

é diferente de

  [ClaimAuthorize(Permission="CanCreateCustomer")] 

Se ambos são igualmente bons, por que precisamos reivindicar?

Eu acho que porque

Conceito de reclamações é mais genérico comparado ao papel

No contexto do exemplo acima, podemos dizer que “CustomerCreator” é uma reivindicação do tipo “role” fornecida por “Asp.NETroleProvider”

Exemplos adicionais de reivindicações.

  1. “AAA” é uma reivindicação do tipo “MYExamSite.Score” fornecida por “MYExamSite.com”

  2. “Gold” é a reivindicação do tipo “MYGYM.Membershiptype” fornecido por “MYGYMApp”

A resposta aceita parece posicionar os papéis como um object contundente e afirma como uma ferramenta flexível, mas de outra forma os faz parecer quase idênticos. Infelizmente, esse posicionamento é um desserviço ao conceito de reclamações e pode refletir fundamentalmente um leve equívoco de seu propósito.

Os papéis existem e só fazem sentido dentro de um escopo implícito. Geralmente isso é uma aplicação ou escopo organizacional (ou seja, Role = Administrador). Reivindicações, por outro lado, podem ser “feitas” por qualquer pessoa. Por exemplo, a autenticação do Google pode gerar declarações que incluem o “email” de um usuário, anexando, assim, esse email a uma identidade. O Google faz a reivindicação, o aplicativo escolhe se deve entender e aceitar essa reivindicação. O aplicativo em si pode append posteriormente uma declaração chamada “authenticationmethod” (como faz a ASP.NET MVC Core Identity) com um valor “Google”. Cada reivindicação inclui um escopo para que seja possível identificar se uma reivindicação tem significado externamente, localmente ou ambos (ou mais refinado conforme necessário).

Os pontos-chave são que todas as declarações são explicitamente anexadas a uma identidade e incluem um escopo explícito. Essas afirmações podem, é claro, ser usadas para autorização – e a ASP.NET MVC fornece suporte para isso através do atributo Authorize, mas essa não é a única ou necessariamente a finalidade principal das Reivindicações. Certamente não o distingue dos Papéis, que podem ser usados ​​exatamente da mesma maneira para autorização com escopo local.

Portanto, pode-se optar por usar Funções, ou Reivindicações, ou ambos, para fins de autorização e, provavelmente, não encontrar vantagem ou desvantagem inerente a nenhum deles, desde que essas Funções e Reivindicações tenham escopo local. Mas se, por exemplo, a autorização depende de declarações externas de identidade, então os Papéis serão inadequados. Você teria que aceitar a declaração externa e traduzi-la em uma function com escopo local. Não há necessariamente nada de errado com isso, mas introduz uma camada de indireção e descarta o contexto.

Mais amplamente, você deve considerar o controle de access baseado em atributos (ABAC). RBAC e ABAC são ambos conceitos definidos pelo NIST, o Instituto Nacional de Padrões e Tecnologia. O CBAC, por outro lado, é um modelo impulsionado pela Microsoft que é muito semelhante ao ABAC.

Leia mais aqui:

  • Página NIST de controle de access baseada em function
  • Página NIST de controle de access baseada em atributos

A fundamental entre o RBAC e o CBAC é que:

RBAC : um usuário deve ser atribuído a uma function para ser autorizado a executar uma ação.

CBAC : o usuário deve ter uma reclamação com o valor correto, como esperado pelo aplicativo, para ser autorizado. Controle de access baseado em declarações é elegante para escrever e mais fácil de manter.

Além disso, as reclamações são emitidas para o aplicativo por um serviço de autorização de emissão (Security Service Token STS) de confiança do seu aplicativo (Parte Confiante)

O papel é apenas um tipo de reivindicação. Assim, pode haver muitos outros tipos de declaração, por exemplo, o nome do usuário é um dos tipos de declaração

É importante analisar primeiro o que é necessário para a autenticação antes de decidir qual método é o melhor. Da documentação da Microsoft abaixo, ele diz “Uma reivindicação não é o que o sujeito pode fazer. Por exemplo, você pode ter uma carteira de motorista, emitida por uma autoridade de licença de condução local. Sua carteira de motorista tem sua data de nascimento. Neste caso o nome da reivindicação seria DateOfBirth, o valor da reivindicação seria sua data de nascimento, por exemplo, 8 de junho de 1970 e o emissor seria a autoridade da licença de condução.A autorização baseada em reivindicações, em sua forma mais simples, verifica o valor de uma reivindicação e permite access a Por exemplo, se você quiser ter access a um clube noturno, o processo de autorização pode ser: 6 “O encarregado de segurança da porta avaliaria o valor da sua data de nascimento e se eles confiam no emissor (a autoridade da carteira de motorista ) antes de lhe conceder access.

A partir desse exemplo, podemos ver que o access a um clube noturno com uma Autorização Baseada em Reivindicações é diferente do tipo de Autorização que será exigido pela equipe que trabalha na boate, neste caso o pessoal da boate exigirá Autorização baseada em papéis que não é exigida para os visitantes do clube noturno, já que os visitantes do clube noturno têm um objective comum no clube noturno, portanto, nesta situação, uma Autorização Baseada em Reivindicações é adequada para os visitantes do clube noturno.

Autorização baseada em function https://docs.microsoft.com/pt-br/aspnet/core/security/authorization/roles 14/10/2016 Quando uma identidade é criada, ela pode pertencer a uma ou mais funções. Por exemplo, Tracy pode pertencer às funções de Administrador e Usuário, enquanto Scott pode pertencer apenas à function Usuário. Como essas funções são criadas e gerenciadas depende do armazenamento de suporte do processo de autorização. As funções são expostas ao desenvolvedor por meio do método IsInRole na class ClaimsPrincipal.

Autorização Baseada em Declarações https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 14/10/2016 Quando uma identidade é criada, ela pode receber uma ou mais declarações emitidas por uma parte confiável . Uma reivindicação é um par de valores de nome que representa o que é o sujeito, não o que o sujeito pode fazer. Por exemplo, você pode ter uma carteira de motorista, emitida por uma autoridade de licença de condução local. Sua carteira de motorista tem sua data de nascimento. Nesse caso, o nome da reivindicação seria DateOfBirth, o valor da reivindicação seria sua data de nascimento, por exemplo, 8 de junho de 1970, e o emissor seria a autoridade da carteira de habilitação. A autorização baseada em declarações, em sua forma mais simples, verifica o valor de uma reivindicação e permite o access a um recurso com base nesse valor. Por exemplo, se você quiser ter access a uma boate, o processo de autorização pode ser:

O responsável pela segurança da porta avaliaria o valor da sua data de nascimento e se confia no emissor (a autoridade da carteira de habilitação) antes de lhe conceder access.

Uma identidade pode conter várias declarações com vários valores e pode conter várias reivindicações do mesmo tipo.

Eu acho que esta questão poderia ser respondida a partir do database prospectivo. Se você notou como as tabelas envolvidas nesta implantação você vai encontrar o seguinte

  1. AspNetUsers: cada usuário tem uma linha com todos os atributos exigidos por todos os usuários, como e-mail, telefone de endereço, senha …..
  2. AspNetRoles; define diferentes funções conforme os requisitos da aplicação, como GM, CTO, HRM, ADMIN, EMP. o que cada function define é conforme as necessidades da aplicação.
  3. AspNetUserRoles: cada linha vincula AspNetUsers e AspNetRoles e efetivamente vincula entre um usuário e várias funções.
  4. AspNetUserClaims: cada linha tem chave para AspNetUsers e um tipo e valor. Então, adicione efetivamente um atributo para cada usuário que possa ser adicionado / removido em tempo de execução.

O uso dessas tabelas pode ser ajustado em um momento do tempo de vida do usuário / aplicativo para atender a necessidades específicas.

Considere o estágio inicial do “Purchasing Manager” (PM), poderíamos ter três abordagens

  1. O aplicativo preenche AspNetUserRoles com uma linha para conceder o direito de compra ‘PM’. Para emitir uma ordem de compra com qualquer quantia, o usuário só precisa da function “PM”.

  2. O aplicativo preenche AspNetUserRoles com uma linha para conceder o direito ‘PM’ de comprar e preenche o AspNetUserClaims uma reivindicação do tipo TYPE ‘Purchasing Amount’ e do valor “<1000" para definir o limite de valor. Para emitir uma ordem de compra, o usuário precisa ter "PM" e o valor do pedido deve ser menor que o valor da reivindicação da reivindicação TYPE "Valor da compra".

  3. Aplicação preencher AspNetUserClaims com reivindicação de tipo TYPE ‘Purchasing Amount’ e “<1000". Qualquer usuário pode emitir um pedido de compra, dado que o valor é menor que o valor da reivindicação do TIPO "Valor de compra" para esse usuário.

Como pode ser notado, o papel baseado é uma granulação grosseira de direitos rígidos que simplificam a vida útil do usuário do aplicativo do ponto de vista do gerenciamento do sistema. no entanto, isso limitará as habilidades do usuário do ponto de vista dos requisitos de negócios. Por outro lado, a reivindicação baseada é um direito muito bom que precisa ser atribuído a cada usuário. A alegação baseada irá empurrar o negócio também o limite, no entanto, fará o gerenciamento do sistema muito complexo.

Também é possível gerenciar funções de maneira reivindicativa.

Em vez de criar funções de autorização que refletem uma function de negócios, crie funções que reflitam papéis de ação, por exemplo, CreateCustomer, EditCustomer, DeleteCustomer. Anote os methods conforme necessário.

Não é uma questão simples mapear indivíduos para um conjunto de papéis de ação, especialmente à medida que a lista de funções aumenta. Portanto, você precisará gerenciar as funções de negócios em um nível mais baixo de granularidade (por exemplo, Vendas, Marketing) e mapear a function de negócios para as funções de ação necessárias. Ou seja, adicionar um usuário a uma function de negócios e mapeia-os para as funções necessárias (ação) na tabela de autorização existente.

Você pode até mesmo replace a function de negócios e adicionar uma pessoa diretamente a um papel de ação.

Porque você constrói em cima do que já funciona, você não desfaz o processo de autorização existente. Você precisa apenas de mais algumas tabelas para implementar essa abordagem

Intereting Posts