EDITAR - Reescribí mi pregunta original para dar un poco más de información

Información de fondo
En mi trabajo, estoy trabajando en una aplicación web ASP.Net para nuestros clientes. En nuestra implementación, utilizamos tecnologías como la autenticación de formularios con MembershipProviders y RoleProviders. Todo salió bien hasta que tuve algunas dificultades para configurar los roles, porque los roles no son para todo el sistema, sino que están relacionados con las cuentas y los proyectos de los clientes.

No puedo nombrar nuestra configuración / fórmula exacta, porque creo que nuestra compañía no aprobaría eso ...

¿Qué es un cliente / proyecto?
Nuestra empresa proporciona información de gestión para nuestros clientes de forma anual (u otro intervalo).
En nuestros sistemas, un cliente / contrato consiste en:

una cuenta: información sobre la empresapor Cuenta, uno o más Productos: el paquete de información de administración que proporcionaremospor producto, una o más mediciones: un período de tiempo, en el que recopilamos e informamos los datos

Configuración del sitio de extranet
Finalmente, queremos que todos los clientes puedan acceder a su información de gestión con nuestro sistema en línea. La extranet consta de dos sitios:

Sitio de la empresa: proporciona una descripción general de la información de la cuenta y los productosSitio de medición: después de seleccionar una medición, información detallada sobre ese período de tiempo

El sitio de medición es la parte más interesante de la extranet. Crearemos submódulos para nuevas vistas generales, informes, gestionando y manteniendo recursos que son importantes para la investigación.

Nuestra solución de Visual Studio consta de una serie de proyectos. Una aplicación web llamada Portal para la base. Los sitios y módulos son directorios virtuales dentro de esa aplicación (hace que sea más fácil compartir MasterPages entre otras cosas).

¿Qué tipo de roles?
Los siguientes usuarios (léase: roles) utilizarán el sistema:

Administradores: usuarios de desarrollo :) (no relacionados con el cliente, acceso total)Empleados: empleados de nuestra empresa (no relacionados con el cliente, acceso total)Superusuario del cliente: gerentes de nivel superior (acceso total a su cuenta / medición)Customer ContactPerson: contacto principal (acceso total a sus mediciones)Gerente de clientes: un gerente de departamento (acceso limitado, datos específicos de una medición)

¿Qué pasa con los usuarios de ASP.Net?
El sistema tendrá muchos usuarios ASP.Net, centrémonos en los usuarios clientes:

Los usuarios no se comparten entre cuentasSuperUser X tiene acceso automáticamente a todas (y nuevas) medicionesEl usuario Y podría ser el contacto principal para la Medición 1, pero no tiene ningún papel para la Medición 2El usuario Y podría ser el contacto principal para la medición 1, pero tener un rol de administrador para la medición 2Los gerentes de departamento son muchos usuarios individuales (por Medida), si el Gerente Z tuvo un inicio de sesión para la Medida 1, nos gustaría usar ese inicio de sesión nuevamente si participa en la Medición 2.

Estructura de URL
Estas son las URL típicas en nuestra aplicación:

http: // host / login - la pantalla de inicio de sesiónhttp: // host / project - la pantalla de resumen de cuenta / producto (selección de medición)http: // host / project / 1000 - detalles de medición (id: 1000)http: // host / project / 1000 / planning - resumen de planificación (para contacto principal / superusuario)http: // host / project / 1000 / reports - descargas de informes (el departamento de administración X solo puede acceder al informe X)

También crearemos una URL de documento, donde puede solicitar un documento específico por su GUID. El sistema tendrá que verificar si el usuario tiene derechos sobre el documento. El documento está relacionado con una Medida, el Usuario o roles específicos tienen derechos específicos sobre el documento.

¿Cuál es el problema? (finalmente ;))
Los roles no son suficientes para determinar lo que un usuario puede ver / acceder / descargar un elemento específico. No es suficiente decir que un determinado elemento de navegación es accesible para los gerentes. Cuando el usuario solicita Measurement 1000, debemos verificar que el usuario no solo tenga un rol de Manager, sino también un rol de Manager para Measurement 1000.

Resumido:

¿Cómo podemos limitar a los usuarios a sus cuentas / medidas?
(recuerde que los superusuarios ven todas las medidas, algunos gerentes solo medidas específicas)

¿Cómo podemos aplicar roles a nivel de producto / medición? (el usuario X podría ser el contacto principal para la medición 1, pero solo un administrador para la medición 2)

¿Cómo podemos limitar el acceso del administrador a la pantalla de informes y solo a los informes de su departamento?

Todo con la magia de las clases asp.net, quizás con una implementación personalizada de proveedor de roles.

Pregunta / problema similar de Stackoverflow
ASP.NET, cómo administrar usuarios con diferentes tipos de roles