Quais dados devem ser armazenados como "Reivindicação"?

No ASP.Net Core, acho que a Claimsautorização é um método muito pouco concreto. Podemos adicionar qualquer coisa como ClaimTypee ClaimValuepar; groups, firstname, lastname, brithdate, canAccessThisURI, isEditor, etc. No entanto, essa abordagem (armazenando tudo o que pode ser armazenado como declarações) criará uma enorme tabela de declarações que inclui 50% dos dados do meu aplicativo.

Gostaria de saber, como uma boa prática, quais são os dados comuns que devem ser armazenados como declarações?

Uma reivindicação é simplesmente um fato sobre um usuário que pode ser potencialmente usado para identificar ou autorizar alguém em seu sistema. Essas duas restrições devem ser suficientes para limitar o que você colocaria como uma reivindicação.

Algumas idéias para reivindicações incluem:

• ID do usuário
• nome do usuário
• email do usuário
• papéis
• participações em grupos

Os metadados do usuário devem limitar-se ao necessário para personalizar o aplicativo e associá-lo aos dados. O ID do usuário é suficiente para associar o usuário aos dados ou fornecer uma trilha de auditoria. Não fique ganancioso.

Funções e participações em grupos são reivindicações de autorização. Por exemplo, se você possui grupos em seu aplicativo, a lista de grupos aos quais o usuário pertence permite verificar rapidamente se eles podem acessar um grupo privado ou não. As funções são um pouco mais refinadas e falam sobre quais privilégios um usuário possui. Geralmente, eles são específicos de aplicativos; portanto, adicione apenas o que você precisa aplicar.

Existem muitos sistemas, especialmente sistemas STS / federação, que fazem dessa maneira:

• uma reivindicação que descreve o usuário exclusivamente
• conjunto de reivindicações que descrevem itens conceituais gerais aos quais eles (e outros) têm acesso a

Os dados de "perfil" do usuário no aplicativo podem não ser traduzidos de / para a fonte de autenticação que você está usando e você não pode usar os mesmos pontos de extremidade o tempo todo ou todos os usuários.

Se você estava familiarizado com a autenticação antiga do Forms, é análogo ao nome de usuário e ao modelo de funções e muitas coisas internas ainda se parecerão com isso se você usar System.Security.Claims.ClaimTypes de nome e função de maneira apropriada.

Nem o modelo antigo nem o novo forneceram muito a você sobre herança de reivindicação ou função, mas isso não é particularmente difícil de implementar e implementar; permite reduzir o volume de reivindicações ou funções que você precisa manter em jogo sob solicitação para solicitar.

Se o seu aplicativo precisar acompanhar um aniversário, mas não precisar usá-lo em um mecanismo de segurança, não haverá realmente nenhum benefício em mantê-lo na coleção de declarações. Coloque-o em um conjunto de dados de perfil separado ou algo assim.

Se o seu aplicativo precisar obter o aniversário como uma reivindicação de outro sistema, você estará procurando algo mais como personalizar a autenticação federada ou permitir que a reivindicação extra persista.