¿Qué nivel de mi aplicación ASP.NET MVC debo verificar la información de Membresía?

Question

Tengo una aplicación MVC que tiene la estructura (simplificada) de la siguiente manera (de izquierda a derecha)

interfaz de usuario -> CONTROLADORES -> Servicios -> REPOSITORIOS -> BASE DE DATOS

Hemos intentado para mantener cada capa desacoplada de la siguiente. Estamos utilizando la Membresía .NET para administrar la seguridad, y tenemos una función basada en permisos, digamos "Mostrar todos los documentos para mi tipo de usuario".

caso:

1. la capa de servicios no tienen conciencia de nuestra proveedor de pertenencia .NET? Entonces tendríamos los métodos de capa de servicio que se veían como "GetDocumentsByUserType (int UserTypeId) {..}"?

2. El método GetDocumentsByUserType() tenga en cuenta que estamos utilizando Membresía .NET, use métodos de Membresía para obtener el tipo de usuario actual, y devuelva los documentos relevantes?

también:

• ¿Tiene # 1 que mi capa de servicios menos seguro, ya que mi capa del controlador
  podía pasar en cualquier cosa que quería como un UserType?
• ¿El # 2 hace que mi capa de Servicios dependa demasiado de una tecnología específica, concretamente .NET
  ¿Membresía? ¿Hay alguna otra manera de considerar aquí?

Espero que haya proporcionado suficientes detalles. Por favor, grite si no y lo agregaré.

Gracias.

Answer 1

Debe mantener todo el material de membresía dentro de la capa de presentación (controlador). Supongamos que alguna vez quiere agregar otra capa de presentación (o hacer cambios en su capa existente), le costará arreglar esto. Además, está duplicando código entre su capa de presentación y su capa de servicios, lo cual nunca es una buena idea.

Habiendo dicho esto, no hay razón para no realizar comprobaciones de seguridad dentro de su capa de servicios, pero puede hacerlo sin la necesidad de utilizar las clases de membresía. En primer lugar, el usuario autenticado actualmente está disponible en Thread.CurrentPrincipal (dentro de los métodos de la capa de servicio). Puede usar este IPrincipal para realizar comprobaciones de seguridad.

En segundo lugar, puede usar el PrincipalPermissionAttribute para aplicar las reglas de seguridad en los métodos o clases de la capa de servicio. Por ejemplo:

[PrincipalPermission(SecurityAction.Demand, Role="Administrator")] 
public void MySecureServiceLayerMethod() 
{ 
    var p = Thread.CurrentPrincipal; 
    .... 
} 

Para el papel cosas para trabajar, también se tendría que utilizar una aplicación RoleProvider.

ACTUALIZACIÓN: Como explica Wyatt Barnett en un comentario, usar PrincipalPermission tiene algunas desventajas. En primer lugar, probar tu código se vuelve más difícil. Otra desventaja (más grande) es que codifica nombres de rol en su código. Estos nombres generalmente no son propiedad del desarrollador.