Supposons qu'un développeur à grande vitesse ait été chargé de construire une demande bancaire qui serait accessible par de nombreuses personnes différentes. Chaque personne voudrait accéder à ses propres informations de compte, mais ne voudrait pas que les autres y accédent. J'aimerais connaître la meilleure pratique pour restreindre l'accès dans une application MVC afin que seul l'utilisateur possède l'information (ou un administrateur) puisse y accéder.
L'attribut ActionFilters semble offrir la possibilité d'un peu plus de contrôle granulaire et pourrait probablement être utilisé pour accomplir la tâche. Cependant, je ne suis pas clair pour savoir s'il s'agit de l'approche recommandée.
Tout conseiller ou idées sont les bienvenus. autoriser nous permet de restreindre le rôle. Bien qu'il s'agisse d'un point de départ, il semble que tout utilisateur authentifié puisse accéder à toutes les informations de l'autre utilisateur.
4 Réponses :
Je pense que vous en avez raison, l'approche d'actionFilter est un son.
Je créerais un ensemble de filtres d'action personnalisés qui hérités de Authorizeattribute.
En plus de la fonctionnalité de l'attribut Authorize, vous pouvez implémenter une stratégie de propriétaire plus stricte uniquement.
hth,
dan
Merci dan! Quelles sont vos suggestions pour mettre en œuvre une "politique plus stricte du propriétaire unique"? Est-ce que cela ressemble quelque chose à quelle marque a décrit ci-dessus?
Exactement Anthony, le dernier paragraphe en particulier de la réponse de Mark. Je dérangerais vos filtres personnalisés à partir du filtre Authorize, car vous aurez besoin d'un Iprincipal autorisé pour vérifier l'ACL.
Actionfilter est probablement un bon point de départ, mais en fonction de votre architecture, vous voudrez peut-être déterminer si la défense périmétrique est suffisamment bonne.
Si vous construisez essentiellement une application ASP.NET MVC à une seule couche (et il peut y avoir des raisons parfaitement raisonnables de le faire), un facteur d'action fournira une défense suffisamment bonne alors qu'il s'agit tout simplement d'appliquer.
D'autre part, si votre application est une application multicouche, la défense en profondeur est plus appropriée. Dans ce cas, vous devriez envisager d'appliquer la logique d'autorisation dans le modèle de domaine, ou peut-être même dans la couche d'accès aux données. Cela garantira que si vous développez une autre application basée sur le même modèle de domaine (par exemple un service Web), la logique d'autorisation s'appliquerait toujours.
Peu importe ce que vous faites, je vous recommande vivement de baser la mise en œuvre actuelle de l'autorisation sur Iprincipal.
sur une note plus spécifique, ce que vous demandez ici est mieux modélisé avec ACL Autorisation: définissez une liste de contrôle d'accès sur chaque profil d'utilisateur qui accède par défaut accessible à l'utilisateur uniquement à l'utilisateur et à l'administrateur. Si / Lorsque vous devez développer plus tard l'application pour permettre un accès délégué aux profils d'autres utilisateurs (je ne sais pas si cela est même réaliste à distance dans votre cas spécifique), vous pouvez simplement le faire en ajoutant une nouvelle entrée à la CAF.
Dans un tel cas, l'évaluation de l'accès implique la récupération de l'ACL pour la ressource demandée et la vérification si l'utilisateur actuel (iprincipal) est inclus dans cette ACL. Une telle opération est très susceptible d'impliquer des opérations hors traitement (recherchant l'ACL dans une base de données), alors l'avoir comme une partie implicite d'une application en le masquant derrière un sons d'action d'action comme il pourrait potentiellement cacher certaines problèmes de performance. Dans un tel cas, je envisagerais de rendre le modèle d'autorisation un peu plus explictif / visible.
Mark, c'est une excellente stratégie! Merci! Dans la plupart de mes projets précédents, nous avons écrit nos propres composants de sécurité pour la gestion des permanentes, des utilisateurs, des groupes, des rôles, etc. et contourné l'architecture d'adhésion ASP.NET spécifiquement pour accueillir le contrôle d'accès à des niveaux inférieurs. J'avais espéré qu'il était plus facile de mettre en œuvre des autorisations dans MVC que de rouler le mien. Depuis mon poste initial, j'ai fini par écrire quand même mais j'ai pris une approche hybride. J'ai utilisé les fournisseurs d'adhésion et de rôle ASP.NET pour la permission de base et le rôle de MGMT de base, mais développé ma propre gestion de groupe et d'autorisation pour un meilleur contrôle granulaire.
Lorsqu'un utilisateur tente d'effectuer une action (sur un contrôleur), je vérifie ses rôles pour s'assurer qu'il a un accès "de base". Sinon, je le redirige. S'il a un accès de base, j'appelle une fonction plus granulaire pour vérifier ses autorisations réelles contre le type d'objet et / ou l'instance spécifique qu'il tente d'accéder. À l'heure actuelle, je n'ai pas encore mis en œuvre cela comme filtre d'action, mais je l'appelais simplement dans chaque action. Je vais le refroidir sous peu.
Heureux que vous puissiez utiliser la réponse - vous pouvez également vouloir vérifier cette réponse qui est quelque peu liée: Stackoverflow.com/questions/1335315/...
En fonction de mon point de vue Si vous avez une application à une couche unique, l'autorisation est la meilleure option et l'actionFilter est bien meilleure et plus simple à utiliser. Mais si votre application est multicouche, vous utilisez la liste de contrôle d'accès [ACL].
Si vous souhaitez extérioriser l'autorisation, vous pouvez consulter les implémentations basées sur XACML.
Qu'est-ce qu'un "développeur à grande vitesse"?