Adhésion .Net à nTier App

Question

Disons que j’ai une application ASP.Net MVC et que cette application (UI) fait référence à une couche de logique applicative (BLL) et que cette dernière fait référence à ma couche d’accès aux données (DAL).

J'utilise un fournisseur d'adhésion et de rôle personnalisé pour l'autorisation.

J'essaie de déterminer quelles couches doivent référencer mon fournisseur d'adhésion.

Dans MVC, vous pouvez effectuer les contrôles d'autorisation de la manière suivante:

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

Et dans mon BLL, je souhaiterais peut-être vérifier si un utilisateur occupe également un rôle:

public static bool IsRoleEditor(User user, Role userRole)
  {
   bool retValue = false;

   if (user.Application.AppID == UserRole.Application.AppID)
   {
        if (Roles.IsUserInRole("ModifyRoles"))
        {
           retValue = true;
        }


    return retValue;
   }

Si je le fais, je devrai référencer et instancier les classes d'appartenance dans les deux couches. Est-ce la bonne façon de créer une application de ce type? Cela semble beaucoup de redondance.

Depuis que j'ai un BLL, j'évite d'utiliser l'option "Autoriser (Roles =" SomeRoleName ")]" attributs et appelle à la place une fonction BLL à partir du code MVC pour vérifier si l’utilisateur joue un rôle? Si je le fais, le MVC a toujours besoin d'une référence au fournisseur d'adhésion pour l'authentification et, dans tous les cas, pour tirer parti de la connexion et des autres contrôles ASP, n'est-ce pas?

Suis-je en dehors de la base et dans la mauvaise direction?

Answer 1

À mon avis, il s’agit d’une faiblesse de la conception des membres / rôles.

Pour résoudre ce problème, par exemple, pour obtenir une autorisation basée sur les rôles sur les niveaux UI et BLL dans une application multiniveau distribuée, vous exposeriez un service du niveau BLL qui expose les bits pertinents (GetRolesForUser etc) et est implémenté en appelant RoleProvider sur le serveur.

Ensuite, implémentez un RoleProvider personnalisé sur le client qui est implémenté en appelant le service exposé par le BLL.

De cette manière, le niveau UI et le niveau BLL partagent le même rôle RoleProvider. Le niveau d'interface utilisateur peut utiliser la connaissance des rôles de l'utilisateur actuel pour améliorer l'interface utilisateur (par exemple, masquer / désactiver les contrôles de l'interface utilisateur correspondant à des fonctionnalités non autorisées), et le BLL peut garantir que les utilisateurs ne peuvent pas s'exécuter. logique métier pour laquelle ils ne sont pas autorisés.

Answer 2

Excellente question, je me suis demandé la même chose aujourd'hui. L’une de mes idées (mais je ne sais pas vraiment si c’est la meilleure solution) est d’utiliser une interface (ex: IRoleProvider) que vous pouvez transmettre à votre BLL pour tester votre accès.

public static bool IsRoleEditor(User user, IRoleProvider rp)
{
     return (rp.IsUserInRole(user,"ModifyRoles"));
}

Avec ceci, vous continuez de vérifier votre accès dans votre BLL, vous pouvez utiliser une simulation dans vos tests unitaires pour vérifier votre logique. Il vous suffit de créer une classe (ou de l’implémenter dans une classe baseController) dans votre site Web MVC. qui implémentera IRoleProvider et effectuera la vérification appropriée à l’aide de l’API d’autorisation ASP.NET.

J'espère que cela vous aidera.

Answer 3

Demandez à votre utilisateur d’implémenter l’interface IPrincipal et transmettez-le autour des calques. Ensuite, vous pouvez toujours utiliser l'attribut [Autoriser] intégré.

Bien qu'écrit il y a plus de 3 ans sur le château, cet article peut aider. Il commence à entrer dans le truc IPrincipal à mi-chemin.

HTHS
Charles

Answer 4

Pourquoi ne pas transférer les rôles dans votre BLL afin que vous n’ayez aucune dépendance vis-à-vis de l’adhésion. Ou utilisez une interface telle que suggérée par MartinB.

Que se passera-t-il dans le futur si vos parties prenantes décident d'utiliser une forme d'authentification différente et que vous ne travaillez plus avec un objet Role ?

Exemple:

IsRoleEditor(User user, string[] roles)
{
  return roles.Contains("ModifyRoles");
}

Answer 5

Ne manquez-vous pas le but de MVC? MVC se scinde naturellement en gradins. Modèle (DAL), contrôleur (BLL), Afficher (Présentation). Ceux-ci peuvent faire partie de différents projets si vous le souhaitez, mais comme le contrôleur dispose de toute la logique métier, vous devez uniquement accéder à RoleProvider.

Ensuite, appliquez des modèles tels que le référentiel, le modèle, etc. pour les séparer davantage si vous le souhaitez.

Davy

Answer 6

Appeler le contrôleur 'MV' du contrôleur MVC est tout à fait génial. Le 'C' dans MVC est une partie de votre BLL, même s'il fait référence à des classes que vous appellerait le BLL. Cependant, ce n’est pas le but de votre question.

Je pense que je résoudrais ce problème en posant la question suivante: "Existe-t-il une exigence réelle en matière de séparation à 100% de votre application" UI "et de votre" BLL "? Si les deux composants partagent une dépendance vis-à-vis des fournisseurs de membres / rôles, laissez-la être ainsi et mettez-vous au travail.

Dans le cas où vous débranchez votre BLL et en connectez une nouvelle, vous pouvez peut-être vivre avec une dépendance partagée sur un fournisseur .NET. Vous savez que c'est probablement correct et que votre application risque de ne pas s'effondrer.

Je pense que la réponse de Joe ci-dessus a beaucoup de sens cependant ...

Answer 7

Je pense que ce que vous faites est bien.

L'autorisation et l'authentification doivent vivre dans une couche de services, qui est peut-être transmise à vos contrôleurs.

Si le contrôleur définit le principal et l'identité et que vous l'utilisez ensuite dans le contrôleur via l'utilisation des attributs MVC, cela semble être une bonne idée.

Il serait bien de cacher votre fournisseur d’appartenance MVC derrière une interface afin de l’échanger contre un fournisseur d’appartenance WinForms (par exemple) et de pouvoir tester vos contrôleurs à l’unité.

Answer 8

Normalement, l’accès au rôle ne devrait pas se trouver dans la BLL. L'accès est une responsabilité de l'interface utilisateur.

Cela dit, utilisez l’interface IPrincipe comme l’affichent les affiches ci-dessus. Vous avez accès à IPrinciple au niveau de la discussion.

Thread.CurrentPrincipal