ASP.NET MVC4 Seguridad, Autenticación y Autorización

Question

Estoy trabajando en un nuevo proyecto asp.net mvc4 con Visual Studio 2011 beta y estoy tratando de entender todo el tema de seguridad. Es una aplicación interna de Intranet que inicialmente utilizará el inicio de sesión único, por lo que al usuario (todavía) no se le solicitará una ID/contraseña de Windows. La compañía tiene una aplicación personalizada para almacenar roles para diferentes aplicaciones y estará disponible a través de una llamada de procedimiento almacenado. Tomará la identificación de inicio de sesión de un usuario y devolverá algún tipo de colección que contenga roles, p. "MyApp.Data", "MyApp.User", MyApp.Admin ". Entonces, ¿a qué se refiere esto? ¿Es este un proveedor de Membresía personalizado, proveedor de Roles personalizado u otra cosa?

He estado leyendo en todos los pormenores de Autorización, Autenticación, Membresía, Roles, etc., y no puedo ver la madera de los árboles en este momento. He leído que los objetos de Seguridad ASP.NET existentes han sido probados y comprobados, y a menos que haya requisitos muy complejos, los incorporados serán suficientes, por lo que me complace utilizar lo que ya está allí.

Entonces, si un usuario ya ha iniciado sesión en la red, significa que están autenticados, ¿correcto? Si es así entonces solo necesito implementar Autorización. ¿Es necesario decorar cada Controlador o Acción con el atributo Autorizar? De ser así, ¿cómo funciona? la parte "ABC" de [Autorizar (Roles = "ABC")] se establece si recupero roles de mi aplicación de almacenamiento de roles personalizada?

He leído varios artículos y blogs, incluyendo éste de Jon Galloway pero se perdió hacia el final:

Customizing Authentication and Authorization The Right Way

Tantas preguntas ... si alguien sabe de una buena descripción de alto nivel de cómo todo esto se mantiene unido, entonces soy todo oídos :)

Answer 1

Ok, a falta de una respuesta que proporcione una visión de alto nivel de cómo todo esto se junta, pensé que lo haría garabatear mis resultados hasta ahora:

• La compañía utiliza Active Directory para almacenar datos de inicio de sesión de usuario, de modo que este se utiliza como Miembro no necesito un proveedor de suscripciones personalizado. Una vez que un usuario inicia sesión en la red de la empresa, se autentica. Agregar un filtro Autorización global garantiza que cualquier usuario que acceda al sistema necesitará ser autenticado.Hasta la fecha información de Rick Anderson en MSDN:

  http://blogs.msdn.com/b/rickandy/archive/2012/03/23/securing-your-asp-net-mvc-4-app-and-the-new-allowanonymous-attribute.aspx

Así que en Global.asax Yo añadiría:

public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
{ 
    filters.Add(new HandleErrorAttribute()); 
    filters.Add(new System.Web.Mvc.AuthorizeAttribute()); //new 
} 

• Una vez autenticado el usuario entonces necesito cuidar la Autorización La compañía tiene un almacén de datos global existente para roles a los que no tendré acceso de actualización, solo acceso de lectura, por lo que puedo recuperar los roles para un usuario dado a través de una llamada de proceso almacenada. El servicio de ayuda puede tardar de unos días a un par de semanas en crear roles después de realizar una solicitud, por lo que inicialmente se crearán 2 roles estándar, Usuario y Administrador, y los roles posteriores se almacenarán en nuestra base de datos de aplicaciones. .

• Junto con estos 2 roles estándar se requieren roles posteriores como Superusuario, etc. Estos roles tendrán varios derechos según las reglas comerciales, etc. y deberán almacenarse en nuestra base de datos de aplicaciones. Por lo tanto, para este escenario, tendré que crear un proveedor de roles personalizado, agregar las tablas de roles asp.net apropiadas a la base de datos de mi aplicación y conectarlo a web.config. Aquí hay una página ms titulado Gestión de Autorización de Uso de roles que estoy recogiendo trozos de:

  http://msdn.microsoft.com/en-us/library/9ab2fxh0.aspx

• Por lo que he leído hasta ahora las únicas tablas que necesito para un proveedor de papel personalizados están Roles y UsersInRoles .

  crear roles TABLA ( roleName Texto (255) NOT NULL, ApplicationName Texto (255) NOT NULL, CONSTREÑIMIENTO PKRoles PRIMARY KEY (nombre de rol, ApplicationName) )

  CREAR UsersInRoles TABLA ( nombre de usuario texto (255) NOT NULL, roleName de texto (255) NOT NULL, ApplicationName texto (255) NOT NULL, CONSTREÑIMIENTO PKUsersInRoles PRIMARY KEY (nombre de usuario, nombre de rol, ApplicationName) )

• Una vez que todo esto está configurado necesito encontrar la manera de fusionar los 2 roles estándar (Usuario y Administrador) del almacén de datos global con los roles personalizados almacenados en la base de datos de mi aplicación, y si puedo usar (ej. Authorize (Roles = "Admin, Superuser")] en un Controlador/Acción o si necesito crear una subclase AuthoriseAttribute y hacer algo más inteligente.

• Me acabo de dar cuenta de que como utilizo AD para la autenticación, necesito una forma de agregar/insertar la colección de roles de los que el usuario actual es miembro. Entonces, aunque no necesito ninguna funcionalidad de proveedor de membresía personalizada, aún tengo que interactuar con httpContext.User para actualizar su colección Roles.

Answer 2

Si su autenticación ya está siendo manejada por Windows (estoy adivinando a través de Active Directory), entonces lo que está buscando es un mecanismo de autorización que coincida con los roles usuarios. Una opción que tiene es cargar los roles de usuario en la sesión actual una vez con éxito. A continuación, crear un atributo personalizado que se autorizan comprobar si la sesión actual tiene los papeles necesarios que usted está trabajando con

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited=true, AllowMultiple=true)] 
public class CustomAuthorizationAttribute : AuthorizeAttribute 
{ 
    protected override bool AuthorizeCore(HttpContextBase httpContext) 
    {   
     IPrincipal user = httpContext.User; 
     if (!user.Identity.IsAuthenticated) 
     { 
      return false; 
     } 

    //check your users against a database and return true or false 
     return base.AuthorizeCore(httpContext); 
    } 
} 

continuación, puede utilizar el atributo como esto

[CustomAuthorization] 
public ActionResult SomeAction() 
{ 
    return View(); 
} 

ACTUALIZACIÓN

AuthorizeCore es el método que se utilizará para verificar si este usuario debe tener acceso al respectivo Método de acción. Dentro de este método, puede verificar la propiedad httpContext.User.Identity.Name en su base de datos o dónde están almacenados sus roles. Si usa la Autenticación de Windows a través de Active Directory, HttpContext.User.Identity debe ser una instancia de WindowsIdentity

Answer 3

Su RolePrincipal, actualizado en concierto con su RoleProvider, debería ser todo lo que se necesita para traer la lista de roles asociados al usuario autenticado. Recuerde, RolePrincipal ya contendrá el WindowsIdentity adecuado.

No necesita un atributo Autorizar personalizado. RolePrincipal/RoleProvider obtendrá los roles necesarios y trabajará con el atributo Autorizar estándar.

Lo que parece un poco extraño es que desea tener funciones propias de su aplicación, pero también dice que desea roles asociados con los usuarios de Windows en una tienda corporativa separada. Como dijiste, quieres unirlos. Esto no me parece correcto. O desea administrar roles a nivel corporativo para su aplicación o desea administrarlos a nivel local. En general, no harías ambas cosas.

Pero si eso es lo que realmente desea hacer, entonces parece que su RoleProvider necesita realizar una llamada de servicio (por ejemplo, WCF) o una llamada AD para obtener información adicional. Tal vez los nombres de "grupos" a los que pertenece el usuario de Windows puedan servir como "roles". A continuación, filtrará solo los grupos que le interesan a su aplicación y los combinará con las funciones que encontró en las bases de datos de roles locales.

Una vez recopilada toda esa información, asegúrese de ordenar al roleManager que almacene la información de roles en una cookie. No tiene sentido pasar por ese alboroto con cada solicitud que haga el usuario.