Cómo manejar mejor los permisos (no los roles) en la membresía de asp.net, específicamente en ASP.NET MVC

Question

Hay muchas preguntas (e información) sobre cómo configurar la membresía de asp.net, proveedores de roles y similares.Si debe o no utilizar la plataforma integrada proporcionada por Microsoft, o ampliar las clases base y crear las suyas propias.

He decidido ampliar los proveedores predeterminados e implementar mi propia membresía y proveedores de funciones.Ahora mi pregunta se refiere específicamente a la autenticación de roles.

Tradicionalmente, crearía roles como "Gerente, Administrador, Empleado, Superusuario" o lo que tenga.Pero, ¿qué haría/debería hacer con respecto a los permisos que considero un control más fino?Déjame explicarte....

Dentro de mi sitio asp.net mvc tengo diferentes áreas como administración, gestión, mensajería, informes, etc.Crearía roles para cada uno de estos, como "Administrador", "Gerente", "Reportero", etc.Sin el rol adecuado, no podrá acceder a esa área del sitio.Entonces bloquearía todos los controladores con esto a nivel de clase.

Pero tomemos ahora un área como ejemplo;mensajería y digo que quería tener permisos más detallados para CRUD;crear un mensaje, ver/leer mensajes, editar mensajes, eliminar mensajes, etc.

Finalmente mi pregunta.¿Cómo sería mejor implementar este control más fino?Un enfoque que veo (no estoy seguro si es bueno) es simplemente crear roles de membresía de asp.net para todo.Entonces podría haber....

Messenger (rol de nivel amplio), CreateMessage, ReadMessage, EditMessage, DeleteMessage.

Por un lado, me gustaría que algunos usuarios pudieran leer/ver mensajes.Pero no necesariamente crearlos o eliminarlos.A las acciones individuales del controlador se podrían aplicar roles específicos.

¿Ves algún problema con este enfoque?Tienes una mejor idea?

Solución hasta ahora

Decidí crear mi propio esquema e implementar proveedores de roles y membresía personalizados.Mi esquema incluye;

• Usuario
• Perfil del usuario
• Permiso
• Asignación de permiso
• Role
• Asignación de roles

Estaré fuera durante uno o dos días, pero actualizaré con más información cuando tenga la oportunidad.

Answer 1

Creo que deberías olvidarte de los roles en el mecanismo de autorización y, en su lugar, solicitar permisos (al final, un rol es una agrupación de permisos), así que si lo ves de esa manera, tu Authorize El atributo debe solicitar una entidad y una acción, no un rol en particular.Algo como:

[Authorize(Entities.Message, Actions.Create)]
public ActionResult CreateMessage()

[Authorize(Entities.Message, Actions.Edit)]
public ActionResult EditMessage()

[Authorize(Entities.Message, Actions.View)]
public ActionResult ViewMessage()

De esa manera, sus roles hacen lo que mejor saben hacer: recopilar permisos abstractos en lugar de determinar una forma inflexible de nivel de acceso.

EDITAR: Para manejar reglas específicas como la señalada por David Robbins, el Gerente A no puede eliminar mensajes creados por el Gerente B, suponiendo que ambos tengan el permiso requerido para acceder a esta Acción del Controlador, el Autorizado no es responsable de verificar este tipo de reglas. e incluso si intenta verificar eso en el nivel de Filtro de acción será una molestia, entonces lo que puede hacer es extender la validación de Autorización a ActionResult (inyectando un parámetro de acción que contiene el resultado de la validación) y dejar que ActionResult tome la decisión lógica. ahí con todos los argumentos en su lugar.

Este es una pregunta similar, no es exactamente el caso que se señala aquí, pero es un buen punto de partida para ampliar la validación de autorización con parámetros de acción.

Answer 2

Con respecto a su ejemplo de CRUD, ¿no está realmente hablando de autorización, y la autorización varía entre los roles de membresía "Gerente" y "Reportero"?Creo que necesita crear un mecanismo separado para aquellas actividades más finas de grano si los roles no distinguen entre una autorización de lectura y escritura entre los mensajes.

Si desea crear un papel para cada acción: EditMessage, DelleMessage - ¿Qué va a hacer en el caso cuando el administrador A no pueda eliminar mensajes para el administrador B?

Answer 3

así como agregando [Authorize(Roles="Administrator")], etc. sobre su controlador.También puede Poner ese atributo en las acciones indiviuales también