Autorizar atributo en ASP.NET MVC

Me está costando entender el uso real del atributo [Authorize] en ASP.NET MVC. Según el concepto, si decoramos un método de controlador con el atributo [Authorize] , solo los usuarios autenticados pueden acceder a los controladores.

Desarrollé una aplicación ASP.NET MVC sin decorar controladores con el atributo [Authorize] . Lo que he observado es que si implemento el mecanismo de autenticación correctamente en mi aplicación usando web.config o de alguna otra forma, no puedo acceder a la URL {controller}/{action}/{id} de un método de acción en particular.

El sistema siempre solicita iniciar sesión. Eso significa que mis controladores están seguros. Mi pregunta es la siguiente: cuando puedo asegurar mis controladores sin usar el atributo [Authorize] , ¿cuál es la necesidad real de ello?

El poder real viene con la comprensión y la implementación del proveedor de membresía junto con el proveedor de roles. Puede asignar usuarios a roles y de acuerdo con esa restricción puede aplicar diferentes roles de acceso para diferentes usuarios a acciones de controlador o controlador.

  [Authorize(Users = "Betty, Johnny")] public ActionResult SpecificUserOnly() { return View(); } 

o puedes restringir de acuerdo al grupo

 [Authorize(Roles = "Admin, Super User")] public ActionResult AdministratorsOnly() { return View(); } 

El uso de atributos [Authorize] puede ayudar a prevenir agujeros de seguridad en su aplicación. La forma en que MVC maneja las URL (es decir, enrutarlas a un controlador en lugar de a un archivo real) hace que sea difícil proteger todo a través del archivo web.config.

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

Existe porque es más conveniente de usar, también es una ideología completamente diferente que usa atributos para marcar los parámetros de autorización en lugar de la configuración xml. No pretendía vencer la configuración de propósito general ni ningún otro marco de autorización, solo la forma de hacerlo de MVC. Estoy diciendo esto, porque parece que estás buscando una característica técnica con ventajas que probablemente no sean … simplemente una excelente conveniencia.

BobRock ya enumeró las ventajas. Solo para agregar a su respuesta, otros escenarios son que puede aplicar este atributo a todo el controlador, no solo a las acciones, también puede agregar diferentes parámetros de autorización de roles a diferentes acciones en el mismo controlador para mezclar y combinar.

Usar el atributo Authorize parece más conveniente y se siente más como ‘MVC way’. En cuanto a las ventajas técnicas, hay algunas.

Un escenario que me viene a la mente es cuando estás usando el almacenamiento en caché de resultados en tu aplicación. Autorizar el atributo maneja bien.

Otro sería extensibilidad. El atributo Authorize es solo un filtro básico, pero puede anular sus métodos y realizar algunas acciones de preautorización, como el registro, etc. No estoy seguro de cómo lo haría a través de la configuración.

Una ventaja es que está comstackndo el acceso a la aplicación, por lo que no puede ser modificado accidentalmente por alguien que modifique el Web.config.

Esto puede no ser una ventaja para usted, y podría ser una desventaja. Pero para algunos tipos de acceso, puede ser preferible.

Además, encuentro que la información de autorización en Web.config lo contamina y hace que sea más difícil encontrar cosas. Entonces, de alguna manera es su preferencia, en otros no hay otra manera de hacerlo.

La etiqueta en web.config se basa en rutas, mientras que MVC funciona con las acciones y rutas del controlador.

Es una decisión arquitectónica que puede no marcar una gran diferencia si solo desea evitar que los usuarios no inicien sesión, pero hace una gran diferencia cuando intenta aplicar una autorización basada en Roles y en casos en los que desea un manejo personalizado de tipos de no autorizados

El primer caso está cubierto por la respuesta de BobRock.

El usuario debe tener al menos una de las siguientes funciones para acceder al controlador o a la acción.

 [Authorize(Roles = "Admin, Super User")] 

El usuario debe tener estos dos roles para poder acceder al controlador o a la acción.

 [Authorize(Roles = "Super User")] [Authorize(Roles = "Admin")] 

El usuario que puede acceder al Controlador o la Acción son Betty y Johnny

 [Authorize(Users = "Betty, Johnny")] 

En ASP.NET Core puede usar los principios de Claims y Policy para la autorización a través de [Authorize] .

 options.AddPolicy("ElevatedRights", policy => policy.RequireRole("Administrator", "PowerUser", "BackupAdministrator")); [Authorize(Policy = "ElevatedRights")] 

El segundo es muy útil en aplicaciones más grandes donde la Autorización podría necesitar ser implementada con diferentes restricciones, procesos y manejo según el caso. Por este motivo, podemos extender el atributo AuthorizeAttribute e implementar diferentes alternativas de autorización para nuestro proyecto.

 public class CustomAuthorizeAttribute: AuthorizeAttribute { public override voidOnAuthorization(AuthorizationContextfilterContext) { } } 

La forma ” correcta y completa ” de hacer una autorización en ASP.NET MVC está utilizando el atributo [Authorize] .