Quelles données doivent être stockées en tant que «Réclamation»?

Dans ASP.Net Core, je trouve que l' Claimsautorisation est une méthode très peu concrète. Nous pouvons ajouter n'importe quoi au fur ClaimTypeet à mesure ClaimValue; groups, firstname, lastname, brithdate, canAccessThisURI, isEditor, etc. Cependant, cette approche (stockant tout ce qui peut être stocké en tant que revendications) créera un énorme tableau de revendications qui comprend 50% de mes données d'application.

Je me demande, en tant que bonne pratique, quelles sont les données communes qui devraient être stockées en tant que revendications?

Une réclamation est simplement un fait concernant un utilisateur qui peut potentiellement être utilisé pour identifier ou autoriser quelqu'un dans votre système. Ces deux contraintes devraient être suffisantes pour limiter ce que vous mettriez comme réclamation.

Voici quelques idées de réclamations:

• identifiant d'utilisateur
• Nom d'utilisateur
• e-mail de l'utilisateur
• les rôles
• appartenance à un groupe

Les métadonnées de l'utilisateur doivent être limitées à ce qui est nécessaire pour personnaliser l'application pour l'utilisateur et pour associer l'utilisateur à ses données. L'identifiant de l'utilisateur est suffisant pour associer l'utilisateur aux données ou fournir une piste d'audit. Ne soyez pas gourmand.

Les rôles et l'appartenance à un groupe sont des revendications d'autorisation. Par exemple, si vous avez des groupes dans votre application, la liste des groupes auxquels l'utilisateur appartient vous permet de vérifier rapidement s'il peut accéder à un groupe privé ou non. Les rôles sont un peu plus fins et parlent des privilèges d'un utilisateur. Ceux-ci sont généralement spécifiques à l'application, alors n'ajoutez que ce que vous devez appliquer.

Il existe de nombreux systèmes, en particulier les systèmes STS / fédération, qui procèdent de cette façon:

• une revendication qui décrit l'utilisateur de manière unique
• assortiment d'allégations décrivant les choses conceptuelles générales auxquelles ils (et d'autres) ont accès

Les données de «profil» de l'utilisateur dans l'application peuvent ne pas se traduire vers / depuis la source d'authentification que vous utilisez et vous ne pouvez pas utiliser les mêmes points de terminaison à tout moment ou pour tous les utilisateurs.

Si vous connaissiez l'ancienne authentification Forms, elle est analogue au modèle de nom d'utilisateur et de rôles et de nombreux éléments intégrés ressemblent toujours à cela si vous utilisez System.Security.Claims.ClaimTypes de nom et de rôle de manière appropriée.

Ni l'ancien ni le nouveau modèle ne vous ont beaucoup fourni pour l'héritage de revendications ou de rôles, mais cela n'est pas particulièrement difficile à mettre en œuvre et la mise en œuvre vous permet de réduire le volume de revendications ou de rôles que vous devez garder en jeu à partir de la demande demander.

Si votre application doit garder une trace d'un anniversaire, mais n'a pas besoin de l'utiliser dans un mécanisme de sécurité, alors il n'y a vraiment aucun avantage à le garder dans la collection de revendications. Mettez-le dans un jeu de données de profil séparé ou quelque chose.

Si votre application doit obtenir l'anniversaire en tant que revendication d'un autre système, vous envisagez quelque chose de plus comme la personnalisation de l'authentification fédérée ou la persistance de la revendication supplémentaire.