En mis proyectos, siempre obtengo roles de la base de datos y los almaceno en una variable de sesión, luego, para verificar si un usuario tiene acceso a las páginas de administración, solo reviso la sesión.
Consideremos que uso un hosting privado ¿cuáles son los inconvenientes de este enfoque?
Supongamos que un usuario no administrador edita su cookie de sesión y cambia de admin=false a admin=true . ¿Es eso un problema, que cualquier usuario puede omitir trivialmente todos sus controles de acceso?
Debería dar a cada usuario un token de sesión como 3f235219b2cca1842b4ae2dd9ec4a1a8570f2edf que se almacena en su base de datos con una vida útil. Comprueba que el token existe por un tiempo constante comparando toda la cadena y si el usuario con un token existe y no está vencido, entonces verifica si el usuario tiene privilegios o no.
También es probable que desee que sea solo HTTP (no editable con javascript) y cookie segura (solo configurada a través de https para evitar MITM).
EDIT: http es un protocolo sin estado. Lo que significa que cada solicitud http que llega a su servidor comienza desde cero; el servidor web no es consciente si ha accedido a esta página por primera vez o si continúa una visita de varias páginas al sitio. La forma básica de crear una sesión es hacer que alguna variable de identificación se transfiera al servidor web con cada solicitud; diga a través de una variable GET / POST oculta, una URL modificada o, más típicamente, una cookie. Se podría configurar una cookie en una respuesta HTTP de un servidor web como:
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: user_role=guest
...
y luego, cuando realice su próxima solicitud al servidor web:
GET /index.html HTTP/1.1
Host: www.example.org
Cookie: user_role=guest
...
Tenga en cuenta que dado que el usuario tiene el control total de su navegador web, realmente no puede confiar en las variables que está enviando. Por ejemplo, podrían cambiar user_role=admin . Entonces, la solución es almacenar la información sobre el usuario en el lado del servidor. Entonces, un usuario se autentica con el servidor, luego le da un token (una cadena aleatoria larga fSFrKtJXAnjo9wacE3XNMy ) y almacena en el servidor que el token = fSFrKtJXAnjo9wacE3XNMy está vinculado a alguien con user=guest (y cualquier otra cosa que necesite Para saber sobre su estado de sesión). Usted quiere cookies de solo http, por lo que es más difícil que los ataques de estilo XSS roben las cookies de sesión, y es seguro para que los intrusos no puedan escucharlos de forma trivial.
Un usuario no autorizado debe detenerse mucho antes de que se realice una llamada para completar los detalles de la sesión. Estaría autentificando y autorizando al usuario en AuthenticateRequest & Eventos de AuthorizeRequest que se activan antes del evento AcquireRequestState. Por lo tanto, si el usuario no está autorizado para ver un recurso, el resto de los eventos no ocurrirán y, por lo tanto, podemos evitar la carga en la base de datos u otros recursos.
El ciclo de vida se muestra en Sección de comentarios de la clase HttpApplication en MSDN
Lea otras preguntas en las etiquetas session-management