Comment gérer au mieux les autorisations (et non les rôles) dans l'adhésion à asp.net, en particulier dans ASP.NET MVC

Question

Il existe de nombreuses questions (et informations) sur la configuration de l'adhésion à asp.net, les fournisseurs de rôles, etc.Que vous deviez ou non utiliser la plate-forme intégrée fournie par Microsoft, ou étendre les classes de base et le rôle le vôtre.

J'ai décidé d'étendre les fournisseurs par défaut et de mettre en œuvre mes propres fournisseurs d'adhésion et de rôles.Maintenant, ma question concerne spécifiquement l’authentification des rôles.

Traditionnellement, vous créez des rôles tels que « Manager, Administrateur, Employé, Super Utilisateur » ou tout autre rôle que vous avez.Mais que feriez/devriez-vous faire en ce qui concerne les autorisations que je considère comme un contrôle plus fin ?Permettez-moi de développer....

Au sein de mon site asp.net mvc, j'ai différents domaines comme l'administration, la gestion, la messagerie, le reporting, etc.Je créerais des rôles pour chacun d'entre eux comme « Administrateur », « Manager », « Reporter », etc.Sans le rôle approprié, vous ne pouvez pas accéder à cette zone du site.Je verrouillerais donc tous les contrôleurs avec cela au niveau de la classe.

Mais prenons maintenant un domaine comme exemple ;messagerie et dire que je voulais avoir des autorisations plus fines pour CRUD ;créer un message, afficher/lire des messages, modifier des messages, supprimer des messages, etc.

Enfin ma question.Quelle serait la meilleure façon de mettre en œuvre ce contrôle plus fin ?Une approche que je vois (je ne sais pas si elle est bonne) consiste simplement à créer des rôles d'adhésion asp.net pour tout.Alors j'aurais peut-être....

Messenger (rôle de niveau général), CreateMessage, ReadMessage, EditMessage, DeleteMessage.

D'une part, j'aimerais que certains utilisateurs puissent lire/afficher les messages.Mais pas nécessairement les créer ou les supprimer.Les actions individuelles du contrôleur peuvent avoir des rôles spécifiques appliqués.

Voyez-vous des problèmes avec cette approche ?As-tu une meilleure idée?

Solution jusqu'à présent

J'ai décidé de créer mon propre schéma et d'implémenter des fournisseurs d'adhésion et de rôles personnalisés.Mon schéma comprend :

• Utilisateur
• Profil de l'utilisateur
• Autorisation
• Attribution d'autorisation
• Rôle
• Attribution de rôle

Je vais être absent un jour ou deux, mais je mettrai à jour avec plus d'informations lorsque j'en aurai l'occasion.

Answer 1

Je pense que vous devriez oublier les rôles sur le mécanisme d'autorisation, et demander des autorisations à la place (en fin de compte, un rôle est une agrupation d'autorisations), donc si vous regardez les choses de cette façon, votre Authorize L'attribut doit demander une entité et une action, pas un rôle particulier.Quelque chose comme:

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

De cette façon, vos rôles font ce qu'ils font de mieux, résumer la collecte des autorisations au lieu de déterminer un niveau d'accès inflexible.

MODIFIER: Pour gérer des règles spécifiques comme celle soulignée par David Robbins, le gestionnaire A n'est pas autorisé à supprimer les messages créés par le gestionnaire B, en supposant qu'ils disposent tous deux de l'autorisation requise pour accéder à cette action du contrôleur, l'autorisation n'est pas responsable de vérifier ce type de règles. et même si vous essayez de vérifier cela au niveau du filtre d'action, ce sera pénible, donc ce que vous pouvez faire est d'étendre la validation Autoriser à ActionResult (en injectant un paramètre d'action contenant le résultat de la validation) et de laisser ActionResult prendre la décision logique là avec tous les arguments en place.

Ce est une question similaire, ce n'est pas exactement le cas souligné ici, mais c'est un bon point de départ pour étendre la validation d'autorisation avec les paramètres d'action.

Answer 2

En ce qui concerne votre exemple de CRUD, ne parlez-vous pas vraiment de l'autorisation et que l'autorisation varie-t-elle entre les rôles de membre "Manager" et "Reporter"?Je pense que vous devez créer un mécanisme séparé pour ces activités fines à grainer si les rôles ne font pas la distinction entre une autorisation de lecture et d'écriture entre les messages.

Si vous deviez créer un rôle pour chaque action - EditMessage, DeleTemessage - Que ferez-vous dans le cas où Gestionnaire A ne devrait pas pouvoir supprimer des messages pour gestionnaire B?

Answer 3

En plus d'ajouter [Authorize(Roles="Administrator")] etc au-dessus de votre contrôleur.Vous pouvez aussi mettre cet attribut sur les actions individuelles aussi