asp.net - sesiones - mvc roles y permisos
ASP.NET MVC Authorization: Permisos en lugar de roles (2)
Sé que esta es una pregunta que se ha formulado una y otra vez, pero estoy tratando de implementar permisos basados en autorizaciones basadas en roles en una aplicación MVC de ASP.NET. Entonces, en lugar de tener roles de alto nivel como Administrador, Administrador o Usuario, necesito tener permisos como ViewTask, AddTask, DeleteTask. He leído un montón de comentarios sobre esto y parece que la solución más sencilla es simplemente tratar los roles como permisos y definir los "roles" de ViewTask, AddTask y DeleteTask.
¿Es tal enfoque realmente una buena idea? Algunas de mis preocupaciones son que podría terminar con más de 100 roles, dependiendo del tamaño de la aplicación, lo que a su vez descartaría la capacidad de realizar el almacenamiento en caché de roles en las cookies y, por lo tanto, cada llamada a User.IsInRole llega a la base de datos. Si cada método de acción se va a decorar con [Autorizar (Roles = "XXXX")], ¿voy a ver problemas serios de rendimiento?
Mi otro problema es que todavía quiero mantener el concepto de una función para que un administrador pueda simplemente asociar a un usuario con una función que tenga un conjunto predefinido de permisos. El uso del enfoque anterior pensaba en crear una entidad separada en mi aplicación llamada Grupo y ese Grupo sería responsable de realizar un seguimiento de los roles de ASP.NET asignados a ese Grupo. Entonces, cuando un usuario está asociado a un grupo, puedo recuperar los roles de ASP.NET que deben asignarse al usuario y agregar todos los roles.
¿Alguien ha implementado un sistema de esa manera? Cualquier opinión o pensamiento sobre este enfoque sería apreciado.
Gracias
Estoy de acuerdo con @jlew sobre el almacenamiento en caché de los datos del usuario y cuando la memoria caché caduque, simplemente vuelva a cargarla. No sirve de nada intentar forzar esta información para que permanezca persistente. Además, si desea alejarse de los proveedores de rol de ASP.net, puede rodar su propia seguridad como lo describí en esta respuesta . Esto tiene la ventaja de permitir soluciones de seguridad muy personalizadas para roles / permisos individuales.
La siguiente es solo una idea con la que he estado jugando últimamente (solo algo para pensar). ¿Por qué no usar las urls RESTful de MVC para definir "permisos"? Por ejemplo:
/tasks/add podría definir el permiso para agregar tareas. De alguna manera, estos podrían ser jerárquicos, de modo que otorgar permisos a un usuario en /tasks/add también les otorga permisos en /tasks . Luego, podría usar un filtro de acción global que construiría la URL dados los valores de la ruta. Esto también permitiría un enfoque realmente interesante para la seguridad de elementos individuales configurables a través del tiempo de ejecución. Por ejemplo, /tasks/edit/23 alguna manera podría otorgar permisos de edición en la tarea con id 23 . De todos modos, esto podría no ser útil en absoluto ... pero es solo que pensé que tal vez te gustaría considerar.
¡Aclamaciones!
Resolvemos el problema almacenando en caché el principal en el lado del servidor, para que los "roles de permisos" no tengan que estar en la cookie y no tengamos que volver a cargar en cada solicitud. En realidad, puede sortear la limitación del tamaño de las cookies dividiendo sus datos de cookies en varias cookies (Windows Identity Framework hace esto). Sin embargo, es posible que tenga ancho de banda u otras preocupaciones con las cookies grandes.