Membresía .NET en la aplicación nTier

Question

Digamos que tengo una aplicación ASP.Net MVC y esta aplicación (UI) hace referencia a una Capa Lógica Empresarial (BLL) y la BLL hace referencia a mi Capa de Acceso a Datos (DAL).

Estoy utilizando un proveedor personalizado de Membresía y Roles para la Autorización.

Estoy tratando de determinar qué capas necesitan hacer referencia a mi proveedor de membresía.

En MVC puede realizar comprobaciones de autorización de la siguiente manera:

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

Y en mi BLL que puede que desee comprobar para ver si un usuario está en un papel así:

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; 
    } 

Tendría que hacer referencia y crear instancias de las clases de Membresía en ambas capas si hago esto. ¿Es esta la forma correcta de diseñar una aplicación como esta? Parece mucha redundancia.

Como tengo un BLL, evito usar los atributos "[Authorize (Roles =" SomeRoleName ")]" y, en su lugar, invoco una función BLL dentro del código MVC para verificar si el usuario tiene un rol? Si hago esto, el MVC aún necesita una referencia al proveedor de membresía para la autenticación y, de todos modos, aprovechar el inicio de sesión y otros controles ASP, ¿verdad?

¿Estoy lejos de la base y voy en la dirección incorrecta?

Answer 1

En mi opinión, esto es una debilidad del diseño de afiliación/papel.

La forma en que lo solucionaría, por ejemplo, para tener autorización basada en roles en niveles UI y BLL en una aplicación distribuida de n niveles, sería exponer un servicio en el nivel BLL que expone los bits relevantes (GetRolesForUser, etc.) y se implementa llamando al RoleProvider en el servidor.

Luego, implemente un RoleProvider personalizado en el cliente que se implementa llamando al servicio expuesto por el BLL.

De esta manera, el nivel UI y el nivel BLL comparten el mismo RoleProvider. El nivel UI puede usar el conocimiento de las funciones actuales del usuario para mejorar la UI (por ejemplo, ocultar/deshabilitar los controles UI correspondientes a funciones no autorizadas) y BLL puede garantizar que los usuarios no puedan ejecutar la lógica comercial para la que no están autorizados.

Answer 2

Obtenga su objeto Usuario para implementar la interfaz IPrincipal y lance alrededor de las capas. Entonces todavía puede usar el atributo incorporado [Autorizar].

Athough escrito hace más de 3 años y sobre castle, this article puede ayudar. Comienza a introducirse en el IPrincipal a mitad de camino.

HTHS
Charles

Answer 3

excelente pregunta, me hice la misma cosa hoy. Una de las ideas que tenía (pero no estoy seguro de si es la mejor manera de hacerlo) es usar una interfaz (por ejemplo, IRoleProvider) que pueda pasar a su BLL para probar su acceso.

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

Con esto, usted todavía verificar su acceso en su BLL, puede utilizar una maqueta en las pruebas unitarias para comprobar su lógica y sólo tiene que crear una clase (o implementen esto de una clase BaseController) en su sitio web de MVC que implementará IRoleProvider y realizará la comprobación adecuada con la API de autorización de ASP.NET.

Espero que esto ayude.

Answer 4

El rol de acceso normalmente no debería estar en el BLL. El acceso es una responsabilidad de la interfaz de usuario.

Dicho esto, aproveche la interfaz IPrinciple como lo han indicado los carteles anteriores. Usted tiene acceso a IPrinciple en el nivel de Subproceso.

Thread.CurrentPrincipal 

Answer 5

¿Por qué no pasar las funciones en su BLL para que no tenga ninguna dependencia en la membresía? O use una interfaz como sugirió MartinB.

¿Qué sucederá en el futuro cuando su (s) interesado (s) decida ir con una forma diferente de autenticación y ya no trabaje con un objeto Rol?

Ejemplo:

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

Answer 6

¿No te estás perdiendo el sentido de MVC? MVC se divide naturalmente en niveles. Modelo (DAL), controlador (BLL), vista (presentación). Estos pueden ir en diferentes proyectos si lo desea, pero como el controlador tiene toda la lógica comercial, solo necesita acceder al RoleProvider allí.

A continuación, aplique patrones como el repositorio, el patrón, etc. para dividirlos más si lo desea.

Davy

Answer 7

Para llamar el controlador MVC 'IU' está muy lejos de la marca .. La 'C' en MVC es parte de su BLL, incluso si se hace referencia a las clases que se llamarían la BLL. Sin embargo, ese no es el punto de tu pregunta.

Creo que resolvería este problema haciendo la pregunta, "¿existe un requisito real de separación del 100% de su aplicación 'UI' y su 'BLL'?". Si ambos componentes comparten una dependencia en los proveedores miembro/rol, entonces déjalo así y ponte a trabajar.

En el caso en que desenchufe su BLL y conecte uno nuevo, quizás tener una dependencia compartida de un proveedor de .NET es algo con lo que puede vivir. Sabes que probablemente esté bien y que tu aplicación simplemente no se rompa.

creo que la respuesta de Joe anterior tiene mucho sentido, aunque ...

Answer 8

creo que lo que está haciendo está bien.

La autorización y la autenticación deben vivir dentro de una capa de servicios, que tal vez se transmita a sus controladores.

Si el controlador establece el Principal y la Identidad y luego lo usa en el controlador mediante el uso de los atributos de MVC, entonces parece una buena idea.

Sería bueno esconder su proveedor de Membresía MVC detrás de una interfaz, de esa manera usted puede cambiarlo por un proveedor de Membresía WinForms (por ejemplo) y podría probar sus controladores en una unidad.