Alguém pode explicar o que o mecanismo de reivindicação significa no novo ASP.NET Identity Core?
Como eu posso ver, há uma AspNetUserLoginstabela, que contém UserId, LoginProvidere ProviderKey.
Mas ainda não consigo entender ou encontrar informações sobre quando os dados são adicionados à AspNetUserClaimstabela e para quais situações essa tabela é usada?
Respostas:
o que significa mecanismo de reivindicação no novo ASP.NET Identity Core?
Existem duas abordagens de autorização comuns baseadas em Função e Reivindicação.
Segurança baseada em funções
Um usuário é atribuído a uma ou mais funções através das quais o usuário obtém direitos de acesso. Além disso, ao atribuir um usuário a uma função, o usuário obtém imediatamente todos os direitos de acesso definidos para essa função.
Segurança baseada em declarações
Uma identidade baseada em declarações é o conjunto de declarações. Uma declaração é uma declaração que uma entidade (um usuário ou outro aplicativo) faz sobre si mesma, é apenas uma declaração. Por exemplo, uma lista de declarações pode ter o nome do usuário, email do usuário, idade do usuário, autorização do usuário para uma ação. Na segurança baseada em função, um usuário apresenta as credenciais diretamente para o aplicativo. Em um modelo baseado em declarações, o usuário apresenta as declarações e não as credenciais para o aplicativo. Para uma reivindicação ter valor prático, ela deve vir de uma entidade na qual a aplicação confia.
As etapas abaixo ilustram a sequência do que ocorre em um modelo de segurança baseado em declarações:
Mas ainda não consigo entender e encontrar nenhuma informação quando os dados são adicionados ao AspNetUserClaims e para quais situações essa tabela está sendo usada?
Quando você está em uma situação em que uma segurança baseada em funções não é usada e optou por usar a segurança baseada em declarações, seria necessário utilizar a tabela AspNetUserClaims. Para saber como usar declarações na identidade do ASP.NET, consulte o link abaixo para obter mais informações.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Atualizar
Que horas tenho para usar a segurança baseada em função e quando baseada em declaração? Você poderia escrever alguns exemplos?
Não há uma situação muito clara em que você usaria ou não a segurança baseada em funções ou em declarações, não como um caso em que você usaria A em vez de B.
Porém, o controle de acesso baseado em declarações permite uma melhor separação das regras de autorização da lógica comercial principal. Quando as regras de autorização são alteradas, a lógica de negócios principal permanece inalterada. Em algumas situações, você pode preferir usar a abordagem baseada em declarações.
Às vezes, reivindicações não são necessárias. Este é um aviso importante. As empresas com vários aplicativos internos podem usar a Autenticação Integrada do Windows para obter muitos dos benefícios fornecidos pelas declarações. O Active Directory faz um ótimo trabalho de armazenamento de identidades de usuários e, como o Kerberos faz parte do Windows, seus aplicativos não precisam incluir muita lógica de autenticação. Desde que todos os aplicativos que você construa possam usar a Autenticação Integrada do Windows, você já pode ter atingido sua utopia de identidade. No entanto, existem muitas razões pelas quais você pode precisar de algo diferente da autenticação do Windows. Você pode ter aplicativos voltados para a Web usados por pessoas que não têm contas no domínio do Windows. Outro motivo pode ser que sua empresa se fundiu com outra e você ' está tendo problemas para se autenticar em duas florestas do Windows que não têm (e talvez nunca) tenham um relacionamento de confiança. Talvez você queira compartilhar identidades com outra empresa que não tenha aplicativos .NET Framework ou precise compartilhar identidades entre aplicativos em execução em plataformas diferentes (por exemplo, o Macintosh). Estas são apenas algumas situações em que a identidade baseada em declarações pode ser a escolha certa para você.
Para mais informações, visite http://msdn.microsoft.com/en-us/library/ff359101.aspx
The user presents the credentials to the issuing authority that the RP application trusts.O que você pode usar como esta autoridade / emissor? Alguns exemplos seriam bons. Coloquei o artigo no site msdn (o link que você forneceu), mas eles listam apenas um exemplo: ADFS, existem outras opções? Não é possível encontrar essas informações em qualquer lugar. :(
Apenas para adicionar mais sobre o que o @Lin disse acima. Refiro-me especificamente à pergunta:
Que horas tenho para usar a segurança baseada em função e quando baseada em declaração? Você poderia escrever alguns exemplos?
Considere um caso em que você tenha um sistema de relógio em que tenha um técnico e um gerente. No final de cada semana, o técnico deve organizar relatórios com informações de horário, mostrando as horas de trabalho dos artesãos trabalhados para essa semana, que são consolidados e utilizados pela folha de pagamento. Esses sistemas geralmente precisam ser alterados ou corrigidos antes do envio dos relatórios finais, porque você não deseja pagar a mais ou a menos a seus funcionários. Você pode usar uma Role-Basedabordagem para o gerente e o técnico criando um Manager Rolee Technician Role. Mas Manager Roleé aquele com a capacidade de acessar e editar as informações de relógio dos artesãos. Por outro lado, você pode ter oTechnician Rolesem essas habilidades para acessar essas informações. Mas aqui está a parte interessante; Um gerente pode fazer uma reclamação e permitir que um técnico acesse os sistemas de relógio e faça relatórios. Portanto, uma reivindicação pode ser feita apenas para acesso sem edição ou pode ser feita com recursos de acesso e edição.
É mais como dizer: Bem, por padrão, como gerente, posso acessar algumas informações que meu técnico não pode acessar. Mas eu nem sempre estou no escritório? o que posso fazer para que ele ainda possa fazer o trabalho mesmo quando não estou por perto? Para resolver isso, o sistema pode ter o recurso para os gerentes criarem reivindicações para pessoas sem acesso a algumas informações específicas. Muitas vezes vemos isso em todos os lugares em nossos sistemas ERP. Um usuário sem acesso a alguns módulos e, quando eles são promovidos, estão dando permissão para mais módulos do sistema ERP, às vezes mantendo a mesma função de usuário.
Este é um exemplo que você pode considerar para entender mais reivindicações e funções.
Existem dois tipos de autenticação na identidade do ASP.Net.
Você pode usar um deles ou ambos ao mesmo tempo. Use função com base quando você tiver coisas muito definidas. Por exemplo, você cria dois rolea professor e aluno. Somente o professor pode adicionar disciplinas. Assim, você atribuiu a função de professor aos usuários aos quais deseja ter acesso para adicionar disciplinas.
A reivindicação é baseada em mais flexibilidade. Suponha que você tenha um requisito: alguns alunos também podem adicionar assuntos. Nesse caso, você precisa criar mais uma função, que pode ser aluno e acesso para adicionar assunto. Mas se você estiver usando uma reivindicação, seria muito fácil. Basta criar uma declaração como addSubject e atribuí-la a qualquer usuário que você deseja acessar para adicionar um objeto.