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

Quels sont les principaux avantages de l'utilisation du CBAC par rapport au RBAC ? Quand est-il préférable d'utiliser CBAC et quand est-il préférable d'utiliser RBAC?

J'essaie de comprendre les concepts généraux du modèle du CCCB, mais l'idée générale n'est toujours pas claire pour moi.

Je vais essayer de montrer comment vous pouvez bénéficier 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 voulez que les personnes qui sont dans 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 vous êtes rendu compte que, parfois, des personnes du rôle «Marketing» devraient pouvoir créer des clients. Ensuite, vous mettez à jour votre méthode Action comme ça

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Maintenant, vous vous êtes rendu compte que certaines des personnes chargées du marketing ne doivent pas être en mesure de créer un client, mais qu'il n'est pas possible d'attribuer un rôle différent aux personnes qui travaillent dans le marketing. Vous êtes donc obligé de permettre à tous les responsables marketing de créer des clients.

vous avez repéré un autre problème, chaque fois que vous décidez que les gens du marketing devraient être autorisés à créer des clients, vous devez mettre à jour toutes vos méthodes d'action MVC attribut Authorize, compiler votre application, tester et déployer. Quelques jours plus tard, vous avez décidé, pas le marketing, mais un autre rôle devrait être autorisé à faire la tâche, donc vous recherchez dans votre base de code et supprimez tout 'Marketing' de l'attribut Autoriser et ajoutez votre nouveau nom de rôle dans l'attribut Autoriser ... Pas un solution saine. À ce stade, vous réalisez 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 attribué diverses autorisations à différents utilisateurs, vous vous rendez compte que vous devez autoriser certains utilisateurs à exécuter du code si l'utilisateur possède des propriétés telles que «Facebook User», «Long time User», etc. Permettez-moi de 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 autorisation «Facebook» pour cet utilisateur? Non, «Facebook» ne ressemble pas à une permission. Le fait-il? Cela ressemble plutôt à une réclamation. Dans le même temps, les autorisations peuvent également ressembler à une revendication !! Il est donc préférable de vérifier les réclamations et d'autoriser l'accès.

Maintenant, revenons à 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é dans la bibliothèque de classes MVC, je montre juste à titre d'exemple, vous pouvez utiliser une bibliothèque de classes qui a une telle définition de classe d'attribut)

Maintenant, vous pouvez voir que la méthode d'action CreateCustomer aura toujours besoin de l'autorisation «CanCreateCustomer» et qu'elle ne changera jamais ou à peine changer. Ainsi, dans votre base de données, vous créez une table des autorisations (revendications) et de la relation utilisateur-autorisation. Depuis votre panneau d'administration, vous pouvez définir l'autorisation (revendication) pour chaque utilisateur qui peut faire quoi. Vous pouvez attribuer l'autorisation (réclamation) 'CanCreateCustomer' à toute personne que vous aimez et seul l'utilisateur autorisé pourra créer un client et l'utilisateur autorisé pourra créer uniquement un client et rien d'autre (à moins que vous n'attribuiez d'autres autorisations au même utilisateur).

Ce modèle de sécurité vous offre une pratique de 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 utilise cette méthode aura la permission (réclamation) appropriée donnée par l'administrateur. Ensuite, l'administrateur peut décider qui sera en mesure de faire quoi. Pas vous en tant que développeur. C'est ainsi que votre logique métier est séparée de la logique de sécurité.

Chaque fois que quelqu'un se connecte, votre application vérifiera les autorisations disponibles pour cet utilisateur et cet ensemble d'autorisations (revendication) 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é), vous n'avez donc pas à vérifier le jeu d'autorisations en permanence à partir de la base de données. L'essentiel est que vous contrôlez davantage votre logique de sécurité dans votre application si vous appliquez un accès basé sur les revendications plutôt que sur un accès basé sur les rôles. En fait, un rôle peut également être considéré comme une réclamation.

Si votre application est une toute petite application où il n'y aurait que 2 rôles: Client et Administrateur et qu'il n'y a aucune chance que le Client puisse faire autre chose que ce qu'il est censé faire dans votre application, alors peut-être, Basé sur le rôle le contrôle d'accès servira cet objectif, mais à mesure que votre application se développera, vous commencerez à ressentir le besoin d'un contrôle d'accès basé sur les revendications à un moment donné.

J'ai mis en œuvre des modèles de sécurité à plusieurs reprises maintenant et j'ai également dû me concentrer sur ces concepts. Après l'avoir fait à plusieurs reprises, voici ma compréhension de ces concepts.

Quels sont les rôles

Rôle = L' union des utilisateurs et des autorisations.

D'une part, un rôle est une collection d'autorisations. J'aime l'appeler un profil d'autorisation. Lors de la définition d'un rôle, vous ajoutez essentiellement un ensemble d'autorisations à ce rôle, de sorte qu'en ce sens, un rôle est un profil d'autorisation.

D'un autre côté, un rôle est également une collection d'utilisateurs. Si j'ajoute Bob et Alice au rôle «Managers», alors «Managers» contient maintenant 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 réunies. Visuellement, cela peut être considéré comme un diagramme de Venn.

Qu'est-ce qu'un groupe

Groupe = Collection d'utilisateurs

Un «Groupe» est strictement un ensemble d'utilisateurs. La différence entre un groupe et un rôle est qu'un rôle a également une collection d'autorisations, mais un groupe n'a qu'une collection d'utilisateurs.

Qu'est-ce qu'une permission

Permission = ce qu'un sujet peut faire

Qu'est-ce qu'un ensemble d'autorisations

Ensemble d'autorisations = une collection d'autorisations

Dans un système RBAC robuste, les autorisations peuvent également être regroupées comme des utilisateurs. Alors que les groupes sont une collection d'utilisateurs uniquement, un ensemble d'autorisations est une collection d'autorisations uniquement. Cela permet à un administrateur d'ajouter des collections complètes d'autorisations aux rôles en une seule fois.

Comment les utilisateurs, les groupes, les rôles et les autorisations se réunissent

Dans un système RBAC robuste, les utilisateurs peuvent être ajoutés individuellement à un rôle pour créer la collection d'utilisateurs dans le rôle ou des groupes peuvent être ajoutés à un rôle pour ajouter une collection d'utilisateurs au rôle à la fois. Dans tous les cas, le rôle obtient sa collection d'utilisateurs en étant ajouté 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.

Les autorisations peuvent être ajoutées individuellement aux rôles 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 tous les cas, le rôle obtient sa collection d'autorisations en étant ajouté individuellement ou en ajoutant des ensembles d'autorisations à un rôle.

Le but général des rôles est de marier les utilisateurs à des autorisations. Par conséquent, un rôle est l'union d'utilisateurs et d'autorisations.

Que sont les réclamations

Réclamation = Qu'est-ce qu'un sujet "est"

Les revendications ne sont PAS des autorisations. Comme indiqué dans les réponses précédentes, une allégation 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, ce sont des informations supplémentaires que l'on peut utiliser pour prendre une décision d'autorisation.

Quand utiliser les revendications

J'ai trouvé que les réclamations é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 à l'autorisation. L'exemple d'un utilisateur Facebook en est la cause. Un utilisateur Facebook peut ne pas être quelqu'un qui est ajouté à un «rôle» ... il s'agit simplement d'un visiteur authentifié via Facebook. Bien que cela ne rentre pas parfaitement dans RBAC, il s'agit d'un élément d'information sur lequel prendre une décision d'autorisation.

@CodingSoft a utilisé la métaphore de la boîte de nuit dans une réponse précédente, que j'aimerais étendre. Dans cette réponse, le permis de conduire a été utilisé comme exemple contenant un ensemble de réclamations où la date de naissance représente l'une des réclamations et la valeur de la réclamation DateOfBirth est utilisée pour tester la règle d'autorisation. Le gouvernement qui a délivré le permis de conduire est l'autorité qui donne l'authenticité de la demande. Par conséquent, dans un scénario de boîte de nuit, le videur à la porte regarde 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 pièce d'identité (c'est-à-dire qu'elle doit être une pièce d'identité valide émise par le gouvernement), examine ensuite la date de naissance (l'une des nombreuses revendications sur un permis de conduire), puis utilise cette valeur pour déterminer si la personne est assez âgée pour entrer dans le club. Si c'est le cas,

Maintenant, avec cette base à l'esprit, je voudrais maintenant étendre cela plus loin. Supposons que le bâtiment où se trouve la boîte de nuit contient des bureaux, des chambres, 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 peuvent avoir accès à certains endroits que d'autres employés n'ont pas. Par exemple, un gestionnaire peut avoir accès à un étage de bureau au-dessus auquel les autres employés ne peuvent pas accéder. Dans ce cas, il y a deux rôles. Gestionnaire et employé.

Alors que l'accès des visiteurs à la zone de la boîte de nuit publique est autorisé par une seule réclamation comme expliqué ci-dessus, les employés doivent accéder par rôle à d'autres salles restreintes non publiques. Pour eux, un permis de conduire ne suffit pas. Ce dont ils ont besoin, c'est d'un badge d'employé qu'ils scannent pour entrer dans les portes. Quelque part, il y a un système RBAC qui accorde des badges dans le rôle de gestionnaire l'accès au dernier étage et des badges dans le rôle d'employé l'accès à d'autres salles.

Si, pour une raison quelconque, certaines salles doivent être ajoutées / supprimées par rôle, cela peut être fait à l'aide de RBAC, mais cela ne convient pas pour une réclamation.

Autorisations dans le logiciel

Le codage des rôles dans l'application est une mauvaise idée. Ce code fixe l'objectif du rôle dans l'application. Ce que l'application devrait avoir, ce sont simplement des autorisations qui agissent comme des indicateurs de fonctionnalité. Lorsque les indicateurs de fonctionnalité sont rendus accessibles par la configuration, les autorisations sont rendues accessibles par le contexte de sécurité de l'utilisateur qui est dérivé de la collection DISTINCT d'autorisations recueillies à partir de tous les rôles dans lesquels l'utilisateur a été placé. C'est ce que j'appelle les «autorisations effectives». L'application ne doit présenter qu'un menud'autorisations possibles sur des fonctionnalités / actions. Le système RBAC doit faire le travail d'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 la seule fois qu'une autorisation change, c'est lorsqu'elle est supprimée ou qu'une nouvelle est ajoutée. Une fois qu'une autorisation est ajoutée au logiciel, elle ne doit jamais être modifiée. Il ne doit être supprimé que lorsque cela est nécessaire (c'est-à-dire lorsqu'une fonctionnalité est interrompue dans une nouvelle version) et seules 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 devraient faire la distinction entre les subventions et les refus.

L'ajout d'une autorisation à un rôle doit s'accompagner d'un GRANT ou d'un DENY. Lorsque les autorisations sont cochées, toutes les autorisations accordées doivent être ajoutées à la liste des utilisateurs des autorisations effectives. Ensuite, après tout ce qui est fait, une liste des autorisations REFUSÉES 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 les autorisations puissent également être ajoutées directement aux utilisateurs. De cette façon, vous pouvez ajouter un utilisateur à un rôle de gestionnaire et il aura accès à tout, mais peut-être souhaitez-vous REFUSER l'accès aux toilettes de la dame parce que l'utilisateur est un homme. Vous ajoutez donc l'utilisateur masculin au rôle de gestionnaire, et ajoutez une autorisation à l'objet Utilisateur avec REFUSER afin qu'il ne supprime que l'accès à la salle de cette dame.

En fait, ce serait un bon candidat pour une réclamation. Si l'utilisateur a une réclamation «sexe = homme», alors être dans le rôle de gestionnaire donne accès à toutes les chambres, mais les toilettes de la dame nécessitent également la réclamation gender = female et les toilettes pour hommes nécessitent la réclamation gender = male. De cette manière, il n'est pas nécessaire de configurer une autorisation DENY pour les utilisateurs masculins, car l'application de la revendication s'occupe de cela 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 montre 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 se trouvent. De plus, le diagramme n'affiche 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 Sur la base des commentaires de @Brent (merci) ... a supprimé les références inutiles aux réponses précédentes et a expliqué la base originale de la métaphore du "night club" fournie par @CodingSoft afin de rendre cette réponse compréhensible sans avoir pour lire d'autres réponses.

Je ne suis pas entièrement 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 d'une réclamation?

Je pense parce que

Le concept des revendications est plus générique que celui du 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.

1. "AAA" est une revendication de type "MYExamSite.Score" fournie par "MYExamSite.com"

2. "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 autrement les fait paraître presque identiques. Malheureusement, ce positionnement ne rend pas service au concept de créance et peut refléter fondamentalement une légère incompréhension de leur objet.

Les rôles n'existent et n'ont de sens que dans une portée implicite. Généralement, il s'agit d'une application ou d'une portée organisationnelle (c'est-à-dire Rôle = Administrateur). Les réclamations, en revanche, peuvent être «faites» par n'importe qui. Par exemple, l'authentification Google peut produire des réclamations incluant "l'e-mail" d'un utilisateur, joignant ainsi cet e-mail à une identité. Google fait la réclamation, l'application choisit de comprendre et d'accepter cette réclamation. L'application elle-même peut par la suite joindre une revendication appelée «méthode d'authentification» (comme le fait ASP.NET MVC Core Identity) avec la valeur «Google». Chaque revendication comprend une portée afin qu'il soit possible d'identifier si une revendication a une signification externe, locale ou les deux (ou plus fine selon les besoins).

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 pour cela via l'attribut Authorize, mais ce n'est pas le seul ou nécessairement même le principal objectif des revendications. Cela ne le distingue certainement pas des rôles, qui peuvent être utilisés exactement de la même manière pour une autorisation de portée locale.

Ainsi, on peut choisir d'utiliser des rôles ou des revendications, ou les deux à des fins d'autorisation et ne trouver aucun avantage ou inconvénient inhérent à l'un ou à l'autre, tant que ces rôles et revendications ont une portée locale. Mais si, par exemple, l'autorisation dépend de revendications d'identité externes, alors les rôles seront inadéquats. Vous devrez accepter la revendication externe et la traduire en un rôle à portée locale. Il n'y a nécessairement rien de mal à cela, mais cela introduit une couche d'indirection et élimine le contexte.

Plus largement, vous devriez envisager le contrôle d'accès basé sur les attributs (ABAC). RBAC et ABAC sont tous deux des concepts définis par le NIST, le National Institute of Standards and Technology. CBAC, en revanche, est un modèle poussé par Microsoft qui est très similaire à ABAC.

En savoir plus ici:

• Page NIST de contrôle d'accès basé sur les rôles
• Page NIST de contrôle d'accès basé sur les attributs

Le principe fondamental entre RBAC et CBAC est que:

RBAC : un utilisateur doit être affecté à un rôle pour être autorisé à effectuer une action.

CBAC : l'utilisateur doit avoir une réclamation avec la valeur correcte, comme prévu par l'application, pour être autorisé. Le contrôle d'accès basé sur les revendications est élégant à écrire et plus facile à maintenir.

En outre, les revendications sont émises à l'application par un service d'autorisation émetteur (Security Service Token STS) qui est approuvé par votre application (partie de confiance)

Le rôle n'est qu'un type de réclamation. Comme ça, il peut y avoir de nombreux autres types de revendications, par exemple le nom d'utilisateur est l'un des types de revendication

Il est important d'analyser d'abord ce pour quoi l'authentification est requise 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 avoir un permis de conduire, délivré par une autorité locale en matière de permis de conduire. Votre permis de conduire porte votre date de naissance. Dans ce cas le nom de la réclamation serait DateOfBirth, la valeur de la réclamation serait votre date de naissance, par exemple le 8 juin 1970 et l'émetteur serait l'autorité du permis de conduire. L'autorisation basée sur les revendications, dans sa plus simple expression, vérifie la valeur d'une réclamation et autorise l'accès à une ressource basée sur cette valeur. Par exemple, si vous souhaitez accéder à une boîte de nuit, le processus d'autorisation peut être: 6 "

À partir de cet exemple, nous pouvons voir que l'accès à un club de nuit avec une autorisation basée sur les réclamations est différent du type d'autorisation qui sera requis par le personnel qui travaille dans la boîte de nuit, dans ce cas, le personnel de la boîte de nuit aura besoin 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.Dans ce cas, une autorisation basée sur les réclamations 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 rôles. Par exemple, Tracy peut appartenir aux rôles Administrateur et Utilisateur tandis que Scott ne peut appartenir qu'au rôle Utilisateur. La manière dont ces rôles sont créés et gérés dépend du magasin de stockage du processus d'autorisation. Les rôles sont exposés au développeur via 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 14/10/2016 Lorsqu'une identité est créée, une ou plusieurs revendications peuvent lui être attribuées par une partie de confiance. Une revendication est une paire nom-valeur qui représente ce qu'est le sujet et non ce que le sujet peut faire. Par exemple, vous pouvez avoir un permis de conduire, délivré par une autorité locale en matière de permis de conduire. Votre permis de conduire porte votre date de naissance. Dans ce cas, le nom de la réclamation serait DateOfBirth, la valeur de la réclamation serait votre date de naissance, par exemple le 8 juin 1970 et l'émetteur serait l'autorité du permis de conduire. L'autorisation basée sur les revendications, dans sa plus simple expression, vérifie la valeur d'une revendication et autorise 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:

L'agent de sécurité de la porte évaluerait la valeur de votre demande de date de naissance et s'il faisait 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 revendicative.

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 au besoin.

Il n'est pas simple de mapper des individus sur un ensemble de rôles d'action, d'autant plus que la liste de rôles s'agrandit. Par conséquent, vous devrez 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 d'entreprise et il les mappe aux rôles (action) requis dans la table d'autorisation existante.

Vous pouvez même remplacer le rôle d'entreprise et ajouter directement une personne à un rôle d'action.

Comme vous construisez 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 cette question pourrait être répondue à 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

1. AspNetUsers: chaque utilisateur a une ligne avec tous les attributs requis par tous les utilisateurs comme email, adresse téléphone, mot de passe .....
2. AspNetRoles; définit différents rôles selon les exigences de l'application comme GM, CTO, HRM, ADMIN, EMP. ce que chaque rôle définit est selon les besoins de l'application.
3. AspNetUserRoles: chaque ligne relie AspNetUsers et AspNetRoles et relie efficacement un utilisateur et plusieurs rôles.
4. AspNetUserClaims: chaque ligne a une clé pour AspNetUsers et un type et une valeur. ajoutez donc efficacement un attribut pour chaque utilisateur qui pourrait être ajouté / supprimé au moment de l'exécution.

L'utilisation de ces tableaux peut être modifiée à un moment donné de la durée de vie de l'utilisateur / de l'application pour répondre aux besoins spécifiques.

Considérons le stade précoce du «responsable des achats» (PM), nous pourrions avoir trois approches

1. L'application remplit AspNetUserRoles avec une ligne pour accorder le droit d'achat à «PM». Pour émettre un bon de commande avec n'importe quel montant, l'utilisateur n'a besoin que du rôle "PM".

2. L'application remplit AspNetUserRoles avec une ligne pour accorder le droit d'achat à 'PM' et remplit AspNetUserClaims une revendication de type TYPE 'montant d'achat' et une valeur "<1000" pour définir la limite de montant. Pour émettre un bon de commande, l'utilisateur doit avoir «PM» et le montant de la commande doit être inférieur à la valeur de réclamation du TYPE de réclamation «Montant d'achat».

3. L'application remplit AspNetUserClaims avec une réclamation de type TYPE 'montant d'achat' et une valeur "<1000". Tout utilisateur peut émettre un bon de commande, étant donné que le montant est inférieur à la valeur de la réclamation TYPE «Montant d'achat» pour cet utilisateur.

Comme on a pu le remarquer, le rôle basé sur les rôles est à gros grains 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 limitera les capacités de l'utilisateur du point de vue des exigences commerciales. D'autre part, les droits basés sur les revendications sont très fins qui doivent être attribués à chaque utilisateur. basé sur les réclamations poussera l'entreprise trop loin, mais rendra la gestion du système très complexe.

Contrôle d'accès basé sur les rôles (RBAC)

Dans votre organisation, vous pouvez avoir les rôles suivants

Employé

Directeur

HEURE

Selon le ou les rôles auxquels appartient l'utilisateur connecté, vous pouvez ou non autoriser l'accès à certaines ressources de l'application. Étant donné que nous utilisons des rôles pour effectuer des vérifications d'autorisation, cela est communément appelé contrôle d'accès basé sur les rôles (RBAC) ou autorisation basée sur les rôles.

Dans ASP.NET Core pour implémenter l'autorisation basée sur les rôles, nous utilisons l'attribut Authorize avec le paramètre Roles.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Contrôle d'accès basé sur les revendications (CBAC)

Qu'est-ce que la réclamation? Une revendication est une paire nom-valeur. C'est vraiment une information sur l'utilisateur, pas ce que l'utilisateur peut et ne peut pas faire. Par exemple, le nom d'utilisateur, l'e-mail, l'âge, le sexe, etc. sont toutes des revendications. La manière dont vous utilisez ces revendications pour les contrôles d'autorisation dans votre application dépend de votre activité d'application et des exigences d'autorisation.

Par exemple, si vous créez un portail pour les employés, vous pouvez autoriser l'utilisateur connecté à demander un congé de maternité si la valeur de la demande de sexe est une femme. De même, si vous créez une application de commerce électronique, vous pouvez autoriser l'utilisateur connecté à soumettre une commande si la valeur de la réclamation d'âge est supérieure ou égale à 18.

Les réclamations sont basées sur des politiques. Nous créons une politique et incluons une ou plusieurs réclamations dans cette politique. La stratégie est ensuite utilisée avec le paramètre de stratégie de l'attribut Authorize pour implémenter l'autorisation basée sur les revendications.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}