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

Question

Hay muchas preguntas (e información) sobre la configuración de miembros de asp.net, proveedores de funciones y similares. Independientemente de si debe usar la plataforma integrada proporcionada por microsoft, o ampliar las clases base y el rol propio.

He decidido extender los proveedores predeterminados e implementar mi propia membresía y proveedores de roles. Ahora mi pregunta es específicamente sobre la autenticación de roles.

Tradicionalmente, crearía roles como 'Administrador, Administrador, Empleado, Superusuario' o lo que sea que tenga. Pero, ¿qué haría/debería hacer con respecto a los permisos que considero que son un control más fino? Permítanme elaborar ...

Dentro de mi sitio asp.net mvc tengo diferentes áreas como administración, administración, mensajería, informes, etc. Me gustaría crate roles para cada uno de estos como 'Administrador', 'Administrador', ' Reportero, etc. Sin la función adecuada, no puede obtener acceso a esa área del sitio. Así que bloquearía todos los controladores con esto en el nivel de clase.

Pero ahora tome un área como ejemplo; mensajes, y dicen que quería tener permisos de grano más finos para CRUD; crear un mensaje, ver/leer mensajes, editar mensajes, eliminar mensajes, etc.

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

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

Por un lado, me gustaría que algunos usuarios puedan leer/ver mensajes. Pero no necesariamente los crea o borra. Las acciones individuales del controlador podrían tener los roles específicos aplicados.

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

Solución hasta ahora

he decidido crear mi propio esquema e implementar suscripciones personalizado y proveedores de papel. Mi esquema incluye;

• usuario
• PerfilUsuario
• Permiso
• PermissionAssignment
• papel
• RoleAssignment

Yendo a estar fuera durante un día o dos, pero se actualizará con más información cuando Tengo una oportunidad.

Answer 1

Creo que debes olvidarte de los roles en el mecanismo de autorización, pide permisos en su lugar (al final un rol es una agrupación de permisos), así que si lo miras de esa manera, tu Authorize Atributo debería solicitar una entidad y acción, no para un rol particular. Algo así 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 funciones hacen lo que hacen mejor colección, permisos abstractos en lugar de determinar de manera inflexible del nivel de acceso.

EDIT: Manejar normas específicas como el señalado por David Robbins, no se permite el Administrador de A a eliminar los mensajes creados por el Administrador de B, suponiendo que ambos tienen el permiso necesario para acceder a este controlador de Acción, el Autorizar no es responsable de comprobar este tipo de reglas, e incluso si intentas comprobar que en el nivel del Filtro de Acción va a ser un problema, entonces lo que puedes hacer es extender la validación de Autorizar a la AcciónResultado (inyectando un parámetro de acción que contiene el resultado de validación), y deje que ActionResult tome la decisión lógica allí con todos los argumentos en su lugar.

This es una pregunta similar, no es exactamente el caso señalado aquí, pero es un buen punto de partida para ampliar la validación de autorizar con los parámetros de acción.

Answer 2

Además de agregar [Authorize(Roles="Administrator")] etc. arriba de su controlador. También puede poner ese atributo en las acciones individuales también

Answer 3

Con respecto a su ejemplo CRUD, ¿no está realmente hablando de autorización, y la autorización podría variar entre los roles de miembros "Administrador" y "Reportero"?Creo que es necesario crear un mecanismo separado para esas actividades de grano más fino si los roles no distinguen entre una autorización de lectura y escritura entre los mensajes.

Si creara un rol para cada acción - EditMessage, DeleteMessage - ¿qué haría en caso de que el Administrador A NO deba eliminar mensajes para el Administrador B?