rôle autorisation basée dans la couche d'affaires

Question

J'ai une application 3 couches - 1) La couche d'interface utilisateur est une application ASP .NET MVC 2) La couche d'affaires est une bibliothèque de classe 3) La couche d'accès aux données est une bibliothèque de classes. J'ai utilisé l'autorisation basée sur le rôle basée sur des réclamations. Je mis les revendications dans le gestionnaire d'événements Application_AuthenticateRequest

protected void Application_AuthenticateRequest(object sender, EventArgs e) 
{ 
      var authenticationCookie = 
    HttpContext.Current.Request.Cookies[FormsAuthentication.FormsCookieName]; 

      var ticket = FormsAuthentication.Decrypt(authenticationCookie.Value); 
      FormsIdentity formsIdentity = new FormsIdentity(ticket); 
      ClaimsIdentity claimsIdentity = new ClaimsIdentity(formsIdentity); 
      // Get the roles from database 
       ... 
      var role = GetUserRole();  
      claimsIdentity.AddClaim(new Claim(ClaimTypes.Role, role)); 

      ClaimsPrincipal claimsPrincipal = new ClaimsPrincipal(claimsIdentity); 
      Thread.CurrentPrincipal = claimsPrincipal; 
} 

Maintenant, j'ai deux façons d'accéder au rôle dans la couche d'affaires

1) accéder directement au rôle du principal fil

var principal = Thread.CurrentPrincipal as ClaimsPrincipal; 
    var claim = principal.Claims.FirstOrDefault(x => x.Type == 
    ClaimTypes.Role); 

Pour:

• Chaque méthode c un accès implicite au rôle.

Cons

• Difficile à test unitaire, car il dépend d'un objet statique

2) Faire passer le rôle d'un paramètre de la méthode, par exemple, il soit sa

public IUserService { 

    void CreateUser(User user, string role); 
    } 

Pros

• Facile à test unitaire puisque le rôle est explicitement transmis à la méthode

Contre

• Chaque méthode a besoin d'avoir un paramètre
• Si l'autorisation est modifiée en fonction de l'autorisation de rôle à toute forme d'autorisation, il rompt le système

Quelle est l'alternative? Quelle est la manière standard d'implémenter l'autorisation basée sur les rôles dans la couche de gestion?

Answer 1

Il existe une manière standard d'implémenter externalisée, autorisation à granularité fine (pas seulement basée sur les rôles) sur plusieurs couches. Le modèle est appelé abac et représente le contrôle d'accès basé sur un attribut. Il y a un cadre majeur qui l'implémente et qui s'appelle xacml. Une autre alternative est l'autorisation basée sur les revendications dans .Net spécifiquement.

ABAC/XACML définit:

1. un langage politique avec laquelle définit les règles d'autorisation par exemple a manager can view documents they own.

2. une architecture qui définit d'une part

   a.un point de décision politique (PDP) qui traite les demandes d'autorisation et produit les décisions (Autoriser/Refuser)

   b. un PEP (Policy Enforcement Point) qui protège votre application, intercepte les requêtes métier et envoie des demandes d'autorisation au PDP. Ceci est le morceau de code qui siègerait dans votre application soit comme un filtre, intercepteur, annotation ou plus ...

La belle approche avec l'autorisation extériorisée est que vous pouvez appliquer la même autorisation cohérente sur plusieurs couches en une seule fois (du SSO web au niveau business et même au niveau data).

HTH. Il y a d'excellentes ressources sur Wikipedia. Vous pouvez également consulter ce blog J'essaie de rester à jour.