Contrôle d'accès basé sur les rôles (RBAC) et contrôle d'accès basé sur les revendications (CBAC) dans ASP.NET MVC
Je vais essayer de montrer comment tirer parti du contrôle d'accès basé sur les revendications dans un contexte ASP.NET MVC.
Lorsque vous utilisez l'authentification basée sur les rôles, si vous avez une action pour créer un client et que vous souhaitez que les personnes ayant le rôle 'Vente' puissent le faire, vous écrivez un code comme celui-ci:
[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
return View();
}
Plus tard, vous avez compris que, parfois, les personnes du rôle 'Marketing' devraient être capables de créer un client. Ensuite, vous mettez à jour votre méthode d'action comme ça
[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
return View();
}
Vous avez maintenant compris que certains spécialistes du marketing ne doivent pas être en mesure de créer un client, mais il n’est pas possible d’attribuer un rôle différent à ceux qui travaillent dans le marketing. Vous devez donc autoriser tous les responsables du marketing à créer des clients.
vous avez repéré un autre problème, chaque fois que vous décidez que les responsables du service Marketing doivent être autorisés à créer des clients, vous devez mettre à jour tous vos attributs d'autorisation de méthodes d'action MVC, compiler votre application, tester et déployer. Quelques jours plus tard, vous avez décidé de ne pas utiliser le marketing, mais qu'un autre rôle devrait être autorisé. Vous devez donc effectuer une recherche dans votre base de code et supprimer tous les attributs "Marketing" de l'autorisation, puis ajouter votre nouveau nom de rôle dans l'attribut Autoriser ... solution saine. À ce stade, vous réaliseriez un besoin de contrôle d'accès basé sur les autorisations.
Le contrôle d'accès basé sur les autorisations est un moyen d'attribuer diverses autorisations à différents utilisateurs et de vérifier si un utilisateur est autorisé à exécuter une action à partir du code au moment de l'exécution. Après avoir affecté diverses autorisations à différents utilisateurs, vous réalisez que vous devez autoriser certains utilisateurs à exécuter du code si l'utilisateur possède des propriétés telles que "Utilisateur Facebook", "Utilisateur de longue date", etc. Laissez-moi vous donner un exemple. Supposons que vous souhaitiez autoriser l'accès à une page spécifique si l'utilisateur est connecté via Facebook. Maintenant, créeriez-vous une permission "Facebook" pour cet utilisateur? Non, 'Facebook' ne sonne pas comme une permission. Le fait-il? Cela ressemble plutôt à une revendication. Dans le même temps, les autorisations peuvent également ressembler à Revendiquer !! Il est donc préférable de vérifier les demandes et d'autoriser l'accès.
Revenons maintenant à l'exemple concret du contrôle d'accès basé sur les revendications.
Vous pouvez définir un ensemble de revendications comme ceci:
"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. etc ..
Maintenant, vous pouvez décorer votre méthode d'action comme ceci:
[ClaimAuthorize(Permission="CanCreateCustomer")]
public ActionResult CreateCustomer()
{
return View();
}
(Veuillez noter que [ClaimAuthorize (Permission = "CanCreateCustomer")]] peut ne pas être intégré à la bibliothèque de classes MVC. Je montre simplement, à titre d'exemple, que vous pouvez utiliser une bibliothèque de classes ayant une telle définition de classe Attribute.
Vous voyez maintenant que la méthode d'action CreateCustomer aura toujours besoin de l'autorisation 'CanCreateCustomer' et qu'elle ne changera jamais ou presque. Ainsi, dans votre base de données, vous créez une table de permissions (revendications) et de relations utilisateur-permission. À partir de votre panneau d’administration, vous pouvez définir une autorisation (revendication) pour chaque utilisateur pouvant faire quoi. Vous pouvez attribuer une autorisation (demande) 'CanCreateCustomer' à votre choix. Seul un utilisateur autorisé pourra créer un client et un utilisateur autorisé ne pourra créer que le client et rien d'autre (sauf si vous attribuez d'autres autorisations au même utilisateur).
Ce modèle de sécurité vous offre la pratique du code propre. De plus, lorsque vous écrivez votre méthode d'action, vous n'avez pas à penser à qui peut utiliser cette méthode, mais vous pouvez toujours être assuré que quiconque l'utilisera aura l'autorisation appropriée (réclamation) donnée par l'administrateur. Ensuite, l'administrateur peut décider qui pourra faire quoi. Pas vous en tant que développeur. C’est ainsi que votre logique d’entreprise est séparée de la logique de sécurité.
Chaque fois que quelqu'un se connecte, votre application vérifie les autorisations disponibles pour cet utilisateur et cet ensemble d'autorisations (revendications) sera disponible en tant que propriétés supplémentaires de l'utilisateur actuellement connecté (généralement l'ensemble de revendications est stocké en tant que cookie pour l'utilisateur connecté), de sorte que vous n'avez pas à vérifier l'autorisation définie tout le temps de la base de données. En bout de ligne, vous obtenez un meilleur contrôle de votre logique de sécurité dans votre application si vous appliquez un accès basé sur une revendication plutôt qu'un accès basé sur un rôle. En fait, un rôle peut également être considéré comme une revendication.
Si votre application est une très petite application où il n'y aurait que deux rôles: Client et Administrateur et s'il n'y a aucune chance que le Client puisse faire autre chose que ce qu'ils sont censés faire dans votre application, alors peut-être, Basé sur les rôles le contrôle d'accès servira à cela, mais à mesure que votre application grandira, vous commencerez à ressentir le besoin d'un contrôle d'accès basé sur les revendications à un moment donné.
Je ne suis pas tout à fait d'accord avec la réponse d'Emran
[Authorize(Roles="Sale")]
Est naïf
La question est de savoir comment
[Authorize(Roles="CustomerCreator")]
est différent de
[ClaimAuthorize(Permission="CanCreateCustomer")]
Si les deux sont également bons, pourquoi avons-nous besoin de réclamer?
Je pense parce que
Le concept de revendications est plus générique que le rôle
Dans le contexte de l'exemple ci-dessus, nous pouvons dire que "CustomerCreator" est une revendication de type "role" fournie par "Asp.NETroleProvider".
Exemples supplémentaires de revendications.
"AAA" est une revendication de type "MYExamSite.Score" fournie par "MYExamSite.com".
"Gold" est une revendication de type "MYGYM.Membershiptype" fournie par "MYGYMApp"
La réponse acceptée semble positionner les rôles comme un objet contondant et les revendications comme un outil flexible, mais leur donne une apparence presque identique. Malheureusement, ce positionnement nuit à la notion de réclamation et peut fondamentalement refléter une légère incompréhension de leur objectif.
Les rôles n'existent et n'ont de sens que dans une portée implicite. En règle générale, il s’agit d’une application ou d’une portée organisationnelle (c'est-à-dire, rôle = administrateur). Les revendications, en revanche, peuvent être faites par n'importe qui. Par exemple, l'authentification Google peut générer des revendications incluant le "courrier électronique" d'un utilisateur, ce qui permet de joindre ce courrier à une identité. Google fait la demande, l'application choisit si elle comprend et accepte cette demande. L'application elle-même peut ultérieurement associer une revendication appelée "authenticationmethod" (comme le fait ASP.NET MVC Core Identity) avec la valeur "Google". Chaque revendication inclut une étendue permettant d'identifier si une revendication a une signification externe, locale ou les deux (ou plus fine si nécessaire).
Les points clés sont que toutes les revendications sont explicitement attachées à une identité et incluent une portée explicite. Ces revendications peuvent bien sûr être utilisées pour l'autorisation - et ASP.NET MVC fournit une prise en charge à cet effet via l'attribut Autoriser, mais ce n'est pas le seul ou nécessairement même l'objectif principal des revendications. Cela ne la distingue certainement pas des rôles, qui peuvent être utilisés exactement de la même manière pour une autorisation portée localement.
On peut donc choisir d’utiliser des rôles, ou des revendications, ou les deux à des fins d’autorisation, sans aucun avantage ni désavantage inhérent, dans la mesure où ces rôles et revendications sont définis localement. Mais si, par exemple, l'autorisation dépend de revendications d'identité externes, les rôles seront alors inadéquats. Vous devez accepter la revendication externe et la traduire en un rôle défini localement. Il n’ya pas nécessairement de mal à cela, mais cela introduit une couche d’indirection et un contexte de rejet.
J'ai implémenté plusieurs fois des modèles de sécurité et j'ai également dû comprendre ces concepts. Après l'avoir fait plusieurs fois, voici ma compréhension de ces concepts.
Que sont les rôles
Role = The union des utilisateurs et des autorisations.
D'une part, un rôle est une collection d'autorisations. J'aime l'appeler un profil de permission. Lorsque vous définissez un rôle, vous ajoutez en gros un ensemble d'autorisations à ce rôle. Dans ce sens, un rôle est un profil d'autorisation.
D'autre part, un rôle est également une collection d'utilisateurs. Si j'ajoute Bob et Alice au rôle "Gestionnaires", "Gestionnaires" contient désormais une collection de deux utilisateurs, un peu comme un groupe.
La vérité est qu'un rôle est à la fois une collection d'utilisateurs et une collection d'autorisations assemblées. Visuellement, cela peut être vu comme un diagramme de Venn.
Qu'est-ce qu'un groupe
Groupe = Collection d'utilisateurs
Un "groupe" est strictement une collection d'utilisateurs. La différence entre un groupe et un rôle est qu'un rôle a également une collection d'autorisations, mais qu'un groupe n'a qu'une collection d'utilisateurs.
Qu'est-ce qu'une autorisation
Permission = Qu'est-ce qu'un sujet peut faire
Qu'est-ce qu'un jeu d'autorisations
Ensemble d'autorisations = Collection d'autorisations
Dans un système RBAC robuste, les autorisations peuvent également être regroupées comme des utilisateurs. Alors que les groupes sont uniquement une collection d'utilisateurs, un jeu d'autorisations est une collection d'autorisations uniquement. Cela permet à un administrateur d'ajouter des collections complètes d'autorisations à des rôles simultanément.
Assemblage des utilisateurs, des groupes, des rôles et des autorisations
Dans un système RBAC robuste, les utilisateurs peuvent être ajoutés à un rôle individuellement pour créer la collection d'utilisateurs du rôle. Des groupes peuvent également être ajoutés à un rôle pour ajouter simultanément une collection d'utilisateurs au rôle. Dans les deux cas, le groupe de rôles obtient son ensemble d'utilisateurs ajoutés individuellement ou en ajoutant des groupes au rôle ou en ajoutant un mélange d'utilisateurs et de groupes au rôle. Les autorisations peuvent être considérées de la même manière.
Des autorisations peuvent être ajoutées à des rôles individuellement pour créer la collection d'autorisations à l'intérieur du rôle ou des ensembles d'autorisations peuvent être ajoutés à un rôle. Enfin, un mélange d'autorisations et d'ensembles d'autorisations peut être ajouté à un rôle. Dans les deux cas, le rôle obtient sa collection d'autorisations ajoutée individuellement ou en ajoutant des jeux d'autorisations à un rôle.
Le rôle principal des rôles est de marier les utilisateurs aux autorisations. Par conséquent, un rôle est l'union des utilisateurs et des autorisations.
Que sont les revendications
Revendication = Quel sujet "est"
Les revendications ne sont PAS des autorisations. Comme indiqué dans les réponses précédentes, une revendication est ce qu'un sujet "n'est" pas ce qu'un sujet "peut faire".
Les revendications ne remplacent pas les rôles ou les autorisations, elles constituent des éléments d'information supplémentaires que l'on peut utiliser pour prendre une décision d'autorisation.
Quand utiliser les revendications
J'ai trouvé que les revendications étaient utiles lorsqu'une décision d'autorisation doit être prise lorsque l'utilisateur ne peut pas être ajouté à un rôle ou que la décision n'est pas basée sur l'association de l'utilisateur à la permission. L'exemple d'un utilisateur de Facebook est la cause. Un utilisateur de Facebook ne peut pas être ajouté à un "rôle" ... il ne s'agit que de visiteurs authentifiés par Facebook. Bien que cela ne rentre pas parfaitement dans RBAC, c'est une information sur laquelle une décision d'autorisation doit être prise.
@CodingSoft a utilisé la métaphore de la boîte de nuit dans une réponse précédente que je voudrais développer. Dans cette réponse, le permis de conduire était utilisé à titre d'exemple. Il contenait un ensemble de revendications dans lesquelles la date de naissance représentait l'une des revendications et la valeur de la revendication DateOfBirth était utilisée pour vérifier la validité de la règle d'autorisation. Le gouvernement qui a délivré le permis de conduire est l’autorité qui donne l’authenticité de la revendication. Par conséquent, dans un scénario de boîte de nuit, le videur à la porte examine le permis de conduire de la personne, s'assure qu'il a été délivré par une autorité de confiance en examinant s'il s'agit ou non d'une fausse carte d'identité (c.-à-d. Doit être une carte d'identité valide émise par le gouvernement), examine ensuite la date de naissance (l'une des nombreuses revendications figurant sur le permis de conduire), puis utilise cette valeur pour déterminer si la personne est suffisamment âgée pour entrer dans le club. Si tel est le cas, la personne passe la règle d’autorisation en vertu de la validité de sa revendication et non en raison de son rôle.
Maintenant, avec cette base en tête, je voudrais maintenant aller plus loin. Supposons que le bâtiment où se trouve la boîte de nuit contient des bureaux, des pièces, une cuisine, d'autres étages, des ascenseurs, un sous-sol, etc., où seuls les employés du club peuvent entrer. De plus, certains employés pourraient avoir accès à certains endroits que d’autres employés ne pourraient pas. Par exemple, un responsable peut avoir accès à un étage de bureaux au-dessus duquel les autres employés ne peuvent pas accéder. Dans ce cas, il y a deux rôles. Directeur et employé.
Bien que l'accès des visiteurs à la zone de boîte de nuit publique soit autorisé par une seule revendication, comme expliqué ci-dessus, les employés doivent pouvoir accéder par rôle à d'autres salles d'accès non publics. Pour eux, un permis de conduire ne suffit pas. Ce dont ils ont besoin, c'est d'un badge d'employé qu'ils numérisent pour entrer dans les portes. Quelque part, il existe un système RBAC qui attribue aux badges du rôle de gestionnaire l'accès au dernier étage et aux badges du rôle d'employé d'accéder à d'autres salles.
Si, pour une raison quelconque, certaines pièces doivent être ajoutées/supprimées par rôle, vous pouvez utiliser RBAC, mais cela ne convient pas à une revendication.
Autorisations dans le logiciel
Coder des rôles dans l'application est une mauvaise idée. Cela code l’objet du rôle dans l’application. Ce que l’application devrait avoir, c’est simplement des autorisations qui agissent comme des fanions de fonctionnalités. Lorsque les configurations sont rendues accessibles par configuration, les autorisations sont rendues accessibles par le contexte de sécurité utilisateur dérivé de la collection d'autorisations DISTINCT collectées à partir de tous les rôles dans lesquels l'utilisateur a été placé. C'est ce que j'appelle les "autorisations effectives". L’application doit uniquement présenter un menu des autorisations possibles pour les fonctionnalités/actions. Le système RBAC doit associer ces autorisations aux utilisateurs via des rôles. De cette façon, il n'y a pas de codage en dur des rôles et le seul cas où une autorisation est modifiée est son retrait ou l'ajout d'une nouvelle. Une fois qu'une autorisation est ajoutée au logiciel, elle ne devrait jamais être modifiée. Il ne doit être supprimé que lorsque cela est nécessaire (c'est-à-dire lorsqu'une fonctionnalité est abandonnée dans une nouvelle version) et que de nouvelles peuvent être ajoutées.
Une dernière note.
Accorder ou refuser
Un système RBAC robuste et même un système CBAC doivent faire la distinction entre les subventions et les refus.
L'ajout d'une autorisation à un rôle doit s'accompagner d'une attribution GRANT ou DENY. Lorsque les autorisations sont cochées, toutes les autorisations accordées doivent être ajoutées à la liste des autorisations effectives des utilisateurs. Ensuite, après tout ce qui est fait, une liste d'autorisations DENIED devrait amener le système à supprimer ces autorisations de la liste des autorisations effectives.
Cela permet aux administrateurs de "modifier" les autorisations finales d'un sujet. Il est préférable que des autorisations puissent également être ajoutées directement aux utilisateurs. De cette façon, vous pouvez ajouter un utilisateur à un rôle de responsable et celui-ci aura accès à tout, mais vous voudrez peut-être refuser l'accès aux toilettes de la fille parce que l'utilisateur est un homme. Vous ajoutez donc l'utilisateur masculin au rôle de responsable, puis ajoutez une autorisation à l'objet Utilisateur avec DENY afin qu'il ne supprime que l'accès à la chambre de cette fille.
En fait, ce serait un bon candidat pour une réclamation. Si l'utilisateur a une revendication "genre = homme", le rôle de gestionnaire donne accès à toutes les pièces, mais les toilettes de la fille requièrent également une revendication genre = femme et les toilettes des hommes requièrent une revendication genre = homme. De cette manière, il ne serait pas nécessaire de configurer une autorisation DENY pour les utilisateurs de sexe masculin, car l'application des demandes de règlement s'en charge pour tout le monde avec une seule règle d'autorisation. Cependant, cela pourrait être fait de toute façon.
Le fait est qu'avec DENIAL of Permissions, cela facilite la gestion des rôles car des exceptions peuvent être implémentées.
Vous trouverez ci-dessous un diagramme que j'ai réalisé il y a longtemps et qui illustre le modèle RBAC. Je n'ai pas de graphique pour les revendications, mais vous pouvez imaginer qu'il ne s'agit que d'attributs attachés aux utilisateurs, où qu'ils soient. En outre, le diagramme ne montre pas les groupes (je dois le mettre à jour à un moment donné).
J'espère que ça aide.
Ceci est un diagramme du RBAC décrit ci-dessus
Mise à jour du 7 avril 2019 D'après les commentaires de @Brent (merci) ... Suppression des références inutiles aux réponses précédentes et explication de la base d'origine de la métaphore "night club" fournie par @CodingSoft afin de rendre cette réponse compréhensible sans avoir à lire d'autres réponses.
Plus généralement, vous devriez envisager un contrôle d’accès basé sur les attributs (ABAC). RBAC et ABAC sont les deux concepts définis par le NIST, l'Institut national de la normalisation et de la technologie. CBAC, en revanche, est un modèle proposé par Microsoft très similaire à ABAC.
Lire la suite ici:
Le rôle n'est qu'un type de revendication. De même, il peut y avoir beaucoup d'autres types de revendications, par exemple le nom d'utilisateur est l'un des types de revendications.
L’essentiel entre le CCNP et le CCCB est que:
RBAC : un utilisateur doit être affecté à un rôle pour être autorisé à effectuer une action.
CBAC : l'utilisateur doit avoir une revendication avec la valeur correcte, comme prévu par l'application, pour être autorisée. Le contrôle d'accès basé sur les revendications est élégant à écrire et plus facile à gérer.
En outre, les revendications sont émises pour l'application par un service d'autorisation émetteur (Security Service Token STS) approuvé par votre application (partie de confiance).
Il est important d’abord d’analyser les besoins de l’authentification avant de décider de la meilleure méthode. Dans la documentation Microsoft ci-dessous, il est indiqué "Une réclamation n’est pas ce que le sujet peut faire. Par exemple, vous pouvez posséder un permis de conduire, délivré par un permis de conduire local. Votre permis de conduire porte la date de naissance. Dans ce cas, le nom de la revendication serait DateOfBirth, la valeur de la revendication serait votre date de naissance, par exemple le 8 juin 1970 et l'émetteur serait l'autorité de délivrance du permis de conduire.L'autorisation basée sur les revendications, dans sa forme la plus simple, contrôle la valeur d'une demande et permet l'accès Par exemple, si vous souhaitez accéder à une boîte de nuit, le processus d'autorisation peut être le suivant: 6 "L'agent de sécurité de la porte évaluera la valeur de votre demande de date de naissance et déterminera s'il fait confiance à l'émetteur (l'autorité du permis de conduire). ) avant de vous accorder l'accès.
À partir de cet exemple, nous pouvons voir que l’accès à un club proche avec une autorisation basée sur les revendications est différent du type d’autorisation requis par le personnel travaillant dans la boîte de nuit. Dans ce cas, le personnel de la boîte de nuit devra une autorisation basée sur les rôles qui n'est pas requise pour les visiteurs de la boîte de nuit car les visiteurs de la boîte de nuit ont tous un but commun dans la boîte de nuit et, dans cette situation, une autorisation basée sur les revendications convient aux visiteurs de la boîte de nuit.
Autorisation basée sur les rôles https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/roles 14/10/2016 Lorsqu'une identité est créée, elle peut appartenir à un ou plusieurs les rôles. Par exemple, Tracy peut appartenir aux rôles d’administrateur et d’utilisateur, tandis que Scott ne peut appartenir qu’au rôle d’utilisateur. La manière dont ces rôles sont créés et gérés dépend du magasin de sauvegarde du processus d'autorisation. Les rôles sont exposés au développeur par le biais de la méthode IsInRole sur la classe ClaimsPrincipal.
Autorisation basée sur les revendications https://docs.Microsoft.com/en-us/aspnet/core/security/authorization/claims 10/14/2016 Lorsqu'une identité est créée, elle peut être attribuée à un ou plus de réclamations émises par une partie de confiance. Une revendication est une paire nom-valeur qui représente ce qu'est le sujet, pas ce que le sujet peut faire. Par exemple, vous pouvez avoir un permis de conduire, délivré par une autorité de permis de conduire locale. Votre permis de conduire porte votre date de naissance. Dans ce cas, le nom de la revendication serait DateOfBirth, la valeur de la revendication serait votre date de naissance, par exemple le 8 juin 1970 et l'émetteur serait le responsable du permis de conduire. L'autorisation basée sur les revendications, dans sa forme la plus simple, vérifie la valeur d'une revendication et permet l'accès à une ressource en fonction de cette valeur. Par exemple, si vous souhaitez accéder à une boîte de nuit, le processus d'autorisation peut être le suivant:
L'agent de sécurité de la porte évaluera la valeur de votre demande de date de naissance et déterminera s'il fait confiance à l'émetteur (l'autorité du permis de conduire) avant de vous accorder l'accès.
Une identité peut contenir plusieurs revendications avec plusieurs valeurs et peut contenir plusieurs revendications du même type.
Il est également possible de gérer les rôles de manière revendiquée.
Au lieu de créer des rôles d’autorisation qui reflètent un rôle d’entreprise, créez des rôles qui reflètent des rôles d’action, par exemple, CreateCustomer, EditCustomer, DeleteCustomer. Annotez les méthodes selon vos besoins.
Il n’est pas simple de faire correspondre des personnes à un ensemble de rôles d’action, d’autant plus que la liste des rôles s’allonge. Par conséquent, vous devez gérer les rôles d’entreprise à un niveau de granularité inférieur (par exemple, Ventes, Marketing) et mapper le rôle d’entreprise aux rôles d’action requis. Par exemple, ajoutez un utilisateur à un rôle utilisateur et il les mappe aux rôles (actions) requis dans la table d'autorisation existante.
Vous pouvez même remplacer le rôle utilisateur et ajouter directement une personne à un rôle d'action.
Parce que vous bâtissez sur ce qui fonctionne déjà, vous n'annulez pas le processus d'autorisation existant. Vous n'avez besoin que de quelques tables supplémentaires pour implémenter cette approche.
Je pense que l'on pourrait répondre à cette question à partir de la base de données prospective. si vous avez remarqué comment les tables impliquées dans cette implantation, vous trouverez ce qui suit
- AspNetUsers: chaque utilisateur a une ligne avec tous les attributs requis par tous les utilisateurs comme email, adresse téléphone, mot de passe .....
- AspNetRoles; définit différents rôles en fonction des exigences de l'application, telles que GM, CTO, GRH, ADMIN, EMP.). Chaque rôle défini correspond aux besoins de l'application.
- AspNetUserRoles: chaque ligne relie AspNetUsers et AspNetRoles et relie efficacement un utilisateur à plusieurs rôles.
- AspNetUserClaims: chaque ligne a une clé pour AspNetUsers et un type et une valeur. si efficacement ajouter un attribut pour chaque utilisateur qui pourrait être ajouté/supprimé au moment de l'exécution.
L'utilisation de ces tables peut être modifiée à un moment donné de la vie de l'utilisateur/de l'application pour répondre à des besoins spécifiques.
Considérons le stade précoce de "Responsable des achats" (PM), nous pourrions avoir trois approches
Application remplit AspNetUserRoles avec une ligne pour accorder le droit d'achat du "PM". Pour émettre une commande avec n'importe quel montant, l'utilisateur n'a besoin que du rôle "PM".
Application remplit AspNetUserRoles avec une ligne pour accorder le droit d'achat de "PM" et remplit AspNetUserClaims avec une revendication de type TYPE "Montant de l'achat" et une valeur "<1000" pour définir la limite de montant. Pour émettre un ordre d'achat, l'utilisateur doit avoir un "PM" et le montant de la commande doit être inférieur à la valeur de réclamation du type de réclamation "Montant de l'achat".
L'application remplit AspNetUserClaims avec une revendication de type TYPE 'Montant d'achat' et d'une valeur "<1000". Tout utilisateur peut émettre un ordre d'achat, étant donné que le montant doit être inférieur à la valeur de réclamation de la réclamation TYPE 'Montant de l'achat' pour cet utilisateur.
Comme on peut le constater, le rôle est basé sur un ensemble de droits rigides qui simplifieraient la vie de l'utilisateur de l'application du point de vue de la gestion du système. Cependant, cela limite les capacités de l'utilisateur du point de vue des exigences de l'entreprise. D'autre part, les droits fondés sur les revendications sont très précis et doivent être attribués à chaque utilisateur. Fondée sur les réclamations Poussez l’entreprise aussi au maximum, mais cela rendra la gestion du système très complexe.