que signifie le mécanisme de revendication dans le nouvel ASP.NET Identity Core?
Il existe deux approches d'autorisation courantes basées sur le rôle et la revendication.
Sécurité basée sur les rôles
Un utilisateur est affecté à un ou plusieurs rôles grâce auxquels l'utilisateur obtient des droits d'accès. De plus, en affectant un utilisateur à un rôle, l'utilisateur obtient immédiatement tous les droits d'accès définis pour ce rôle.
Sécurité basée sur les revendications
Une identité basée sur les revendications est l'ensemble des revendications. Une revendication est une déclaration qu'une entité (un utilisateur ou une autre application) fait sur elle-même, ce n'est qu'une revendication. Par exemple, une liste de revendications peut avoir le nom de l'utilisateur, l'adresse e-mail de l'utilisateur, l'âge de l'utilisateur, l'autorisation de l'utilisateur pour une action. Dans la sécurité basée sur les rôles, un utilisateur présente les informations d'identification directement à l'application. Dans un modèle basé sur les revendications, l'utilisateur présente les revendications et non les informations d'identification à l'application. Pour qu'une revendication ait une valeur pratique, elle doit provenir d'une entité à laquelle l'application fait confiance.
Les étapes ci-dessous illustrent la séquence de ce qui se produit dans un modèle de sécurité basé sur les revendications:
- L'utilisateur demande une action. L'application de partie de confiance (RP) demande un jeton.
- L'utilisateur présente les informations d'identification à l'autorité émettrice que l'application RP approuve.
- L'autorité émettrice émet un jeton signé avec des revendications, après avoir authentifié les informations d'identification de l'utilisateur.
- L'utilisateur présente le jeton à l'application RP. L'application valide la signature du jeton, extrait les revendications et, en fonction des revendications, accepte ou refuse la demande.
Mais, je ne peux toujours pas comprendre et trouver des informations, quand les données s'ajoutent à AspNetUserClaims et quelles situations cette table utilise-t-elle?
Lorsque vous êtes dans une situation où une sécurité basée sur les rôles n'est pas utilisée et que vous avez choisi d'utiliser la sécurité basée sur les revendications, vous devez utiliser la table AspNetUserClaims. Pour savoir comment utiliser les revendications dans ASP.NET Identity, consultez le lien ci-dessous pour plus d'informations.
http://kevin-junghans.blogspot.com/2013/12/using-claims-in-aspnet-identity.html
Mettre à jour
Quelle heure ai-je pour utiliser la sécurité basée sur les rôles et quand basée sur les revendications? Pourriez-vous s'il vous plaît écrire quelques exemples?
Il n'y a pas de situation très claire où vous utiliseriez ou non la sécurité basée sur les rôles ou les revendications, pas comme un cas où vous utiliseriez A plutôt que B.
Cependant, le contrôle d'accès basé sur les revendications permet une meilleure séparation des règles d'autorisation de la logique métier principale. Lorsque les règles d'autorisation changent, la logique métier de base reste inchangée. Il y aura des situations dans lesquelles vous préférerez peut-être utiliser l'approche basée sur les revendications.
Parfois, les réclamations ne sont pas nécessaires. Ceci est un avertissement important. Les entreprises disposant d'une multitude d'applications internes peuvent utiliser l'authentification Windows intégrée pour bénéficier de nombreux avantages fournis par les revendications. Active Directory fait un excellent travail de stockage des identités des utilisateurs, et comme Kerberos fait partie de Windows, vos applications n'ont pas besoin d'inclure beaucoup de logique d'authentification. Tant que chaque application que vous créez peut utiliser l'authentification Windows intégrée, vous avez peut-être déjà atteint votre utopie d'identité. Cependant, il existe de nombreuses raisons pour lesquelles vous pourriez avoir besoin d'autre chose que l'authentification Windows. Vous pouvez avoir des applications Web utilisées par des personnes qui n'ont pas de compte dans votre domaine Windows. Une autre raison pourrait être que votre entreprise a fusionné avec une autre entreprise et que vous vous rencontrez des difficultés pour vous authentifier sur deux forêts Windows qui n'ont pas (et peuvent ne jamais avoir) de relation d'approbation. Vous souhaitez peut-être partager des identités avec une autre société qui possède des applications non.NET Framework ou vous devez partager des identités entre des applications exécutées sur différentes plates-formes (par exemple, le Macintosh). Ce ne sont là que quelques situations dans lesquelles l'identité basée sur les revendications peut être le bon choix pour vous.
Pour plus d'informations, veuillez visiter http://msdn.microsoft.com/en-us/library/ff359101.aspx