Autorização em Aplicações e Serviços Web conscientes de sinistros
Atualizado: 19 de junho de 2015
Aplica-se a: Azure
Aplica-se A
Microsoft Azure Ative Directory Controlo de Acesso (também conhecido como serviço de Controlo de Acesso ou ACS)
® Fundação Windows identidade (WIF)
ASP.NET
Windows Communication Foundation (WCF)
Resumo
Num requerimento de parte adutor, a autorização determina quais os recursos a que uma identidade autenticada é permitida a aceder e quais as operações que é autorizada a realizar nesses recursos. Uma autorização imprópria ou fraca leva à divulgação de informações e à adulteração de dados. Este tópico descreve as abordagens disponíveis para implementar a autorização para aplicações e serviços ASP.NET web conscientes de sinistros utilizando ACS e WIF.
Objetivos
Enumerar as abordagens de autorização que utilizam reclamações.
Delineie o design de alto nível para cada abordagem.
Chame a atenção para as vantagens e desvantagens de cada abordagem.
Descrição Geral
Desde a sua primeira versão, o .NET Framework ofereceu um mecanismo flexível para implementar a autorização. Este mecanismo baseia-se em duas interfaces simples - IPrincipal e IIentity. Implementações concretas da IIentity representam um utilizador autenticado. Por exemplo, a implementação da WindowsIdentity representa um utilizador que é autenticado pelo Ative Directory, e a GenericIdentity representa um utilizador que é autenticado por uma autenticação personalizada. Implementações concretas do IPrincipal ajudam a verificar permissões usando funções dependendo da loja de funções. Por exemplo, o WindowsPrincipal verifica a WindowsIdentity para a adesão em grupos de Diretório Ativo. Esta verificação é realizada através da chamada do método IsInRole na interface IPrincipal . Verificar o acesso com base em funções chama-se Role-Based Controlo de Acesso (RBAC). O RBAC é explicado na secção "Controlo de Acesso baseada em papéis" deste tópico. As reclamações podem ser usadas para transportar informações sobre funções para apoiar mecanismos de autorização familiares e baseados em funções.
As reclamações também podem ser usadas para permitir decisões de autorização muito mais ricas para além das funções. As reclamações podem ser baseadas em praticamente qualquer coisa - idade, código postal, tamanho do sapato, e assim por diante. Verificar o acesso com base em reclamações arbitrárias chama-se Controlo de Acesso (CBAC) ou autorização baseada em sinistros. A autorização baseada em sinistros é explicada na secção "Controlo de Acesso baseado em sinistros" deste tópico.
As verificações de autorização são efetuadas no lado do pedido, não no lado acs. A ACS serve como um serviço de símbolo de segurança (STS) que emite fichas que transportam as reclamações para a aplicação. Os tokens são enriquecidos com reclamações por fornecedores de identidade e opcionalmente pela própria ACS, utilizando o seu motor de regras. Quando o pedido recebe o token com reclamações, pode analisar o token, extrair as reclamações relevantes e tomar decisões de autorização usando o RBAC ou uma abordagem baseada em sinistros. O WIF é utilizado para analisar o token e torná-lo utilizável para decisões de autorização através de uma interface de programação de aplicações fáceis de usar (API). Para obter mais informações sobre a WIF, consulte o WIF SDK (https://go.microsoft.com/fwlink/?LinkID=187481). Considere o seguinte diagrama ao pensar na autorização em aplicações e serviços conscientes de sinistros. Note que após a autenticação bem sucedida o fornecedor de identidade gera um símbolo (o token IdP no diagrama). O token IdP pode ser transformado pelo motor de regras ACS. A ACS pode adicionar, remover ou alterar as alegações que vêm no sinal que o fornecedor de identidade emite. Finalmente, o token emitido pela ACS é enviado para o pedido e processado pela WIF. O controlo de acesso é realizado na WIF, utilizando a abordagem RBAC ou CBAC.
.gif "ACS v2 WIF Authorization")
Controlo de Acesso Baseado em Funções
O RBAC é uma abordagem de autorização na qual as permissões dos utilizadores são geridas e aplicadas por uma aplicação baseada nas funções dos utilizadores. Se um utilizador tiver uma função necessária para realizar uma ação, o acesso é concedido; caso contrário, o acesso é negado.
Método iPrincipal.IsInrole
Para implementar a abordagem RBAC em aplicações conscientes de sinistros, utilize o método IPrinicpal interface IsInRole(), tal como faria em aplicações não conscientes das reclamações. Existem várias formas de utilizar o método IsInRole :
Chamando explicitamente iPrincipal.IsInRole ("Administrador"). Nesta abordagem, o resultado é um Boolean. Use-o nas suas declarações condicionais. Pode ser usado arbitrariamente em qualquer lugar do seu código.
Utilizando o pedido de segurança PrincipalPermission.Demand(). Nesta abordagem, o resultado é uma exceção no caso de a procura não ser satisfeita. Isto deve encaixar na sua estratégia de tratamento de exceções. Lançar exceções é muito mais caro do ponto de vista do desempenho em comparação com a reforma de Boolean. Isto pode ser usado em qualquer lugar do seu código.
Utilizando os atributos declarativos [PrincipalPermission (SecurityAction.Demand, Role = "Administrator")]. Esta abordagem chama-se declarativa, porque é usada para decorar métodos. Não pode ser utilizado em blocos de código dentro das implementações do método. O resultado é uma exceção no caso de a procura não ser satisfeita. Deve certificar-se de que se encaixa na sua estratégia de tratamento de exceções.
Utilizando a autorização de URL, utilizando a <secção de autorização> em web.config. Esta abordagem é adequada quando está a gerir a autorização a nível de URL. Este é o nível mais grosseiro entre os mencionados anteriormente. A vantagem desta abordagem é que as alterações são feitas no ficheiro de configuração, o que significa que o código não deve ser compilado para tirar partido da mudança.
Expressando papéis como reivindicações
Quando o método IsInRole é chamado, há uma verificação feita para ver se o utilizador atual tem essa função. Em aplicações conscientes das reclamações, o papel é expresso por um tipo de reivindicação de papel que deve estar disponível no token. O tipo de reivindicação de funções é expresso utilizando o seguinte URI:
https://schemas.microsoft.com/ws/2008/06/identity/claims/role
Existem várias formas de enriquecer um símbolo com um tipo de reivindicação de papel:
Utilização do motor de regras ACS — Neste caso, cria uma regra utilizando o AcS Management Portal ou o ACS Management Service para criar regras de transformação de sinistros que gerem reclamações de um determinado tipo de função. Para obter mais informações sobre regras e transformação simbólica, consulte Grupos de Regras e Regras e Como: Implementar a Lógica de Transformação simbólica Usando regras.
Transformar reivindicações arbitrárias em tipo de papel de sinistro usando ClaimsAuthenticationManager — The ClaimsAuthenticationManager é um componente que envia como parte da WIF. Permite que os pedidos sejam intercetados quando lançam uma aplicação, inspecionando tokens e transformando-os adicionando, alterando ou removendo reclamações. Para obter mais informações sobre como utilizar o ClaimsAuthenticationManager para a transformação de sinistros, consulte Como implementar Controlo de Acesso baseado em funções (RBAC) numa aplicação de ASP.NET de sinistros utilizando WIF e ACS
Mapeamento de reivindicações arbitrárias para um tipo de papel usando a secção de configuração samlSecurityTokenRequirement - Uma abordagem declarativa onde a transformação de alegações é feita usando apenas a configuração e não é necessária codificação.
Controlo de Acesso baseado em sinistros
A CBAC é uma abordagem de autorização em que a decisão de autorização de concessão ou negação de acesso se baseia numa lógica arbitrária que utiliza dados disponíveis em sinistros para tomar a decisão. Recorde-se que, no caso do RBAC, a única alegação utilizada foi a alegação do tipo de papel. Foi utilizada uma alegação do tipo de papel para verificar se o utilizador pertence ou não a uma função específica. Para ilustrar o processo de tomada das decisões de autorização utilizando a abordagem de autorização baseada em sinistros, considere as seguintes etapas:
O pedido recebe um pedido.
O pedido extrai as reclamações recebidas.
O pedido transmite as reivindicações para o mecanismo de lógica de decisão. Pode ser código de memória ou uma chamada para um serviço web, uma consulta a uma base de dados, ou pode invocar um motor de regras sofisticado.
O mecanismo de decisão calcula o resultado com base nas alegações.
O acesso é concedido se o resultado for verdadeiro e negado se for falso. Por exemplo, a regra pode ser que o utilizador tenha 21 anos ou mais, vive em Washington State, e foi autenticado por Windows Live ID (conta Microsoft).
A ACS serve como uma STS que emite fichas que carregam as reclamações. Pode controlar quais as alegações que estão a ser emitidas - tanto os tipos de reclamações como os valores - utilizando o motor de regras ACS. Para saber mais sobre o motor das regras da ACS, consulte Grupos de Regras e Regras e Como: Implementar a Lógica de Transformação token usando regras. ClaimsAuthorizationManager é fundamental para implementar o CBAC em aplicações de sinistros. ClaimsAuthorizationManager é um componente que envia como parte da WIF. Sinistros A Autoridade de Autorização permite-lhe intercetar pedidos de entrada e implementar qualquer lógica da sua escolha para tomar decisões de autorização com base nas reclamações recebidas. Este é também um ponto de extensibilidade onde as decisões de autorização podem ser externalizadas e dissociadas do código de aplicação. Isto torna-se importante quando a lógica de autorização precisa de ser alterada. Nesse caso, a utilização da ClaimsAuthorizationManager não afetará a integridade da aplicação, reduzindo assim a probabilidade de um erro de aplicação como resultado da alteração. Para saber mais sobre como usar o ClaimsAuthorizationManager para implementar o controlo de acesso baseado em sinistros, consulte Como Implementar a Autorização de Sinistros numa Aplicação de ASP.NET Consciente de Sinistros utilizando WIF e ACS.