Autenticación, autorización y suplantación en ASP.NET

La seguridad en ASP.NET es un proceso de 2 capas.

Todas las solicitudes a nuestro servidor web se gestionan en primer lugar por IIS y después por ASP.NET.

De este modo es inicialmente IIS quién podrá aceptar o rechazar la petición solicitada. Si IIS acepta la petición, entonces se pasará a ASP.NET (en forma de token de seguridad representando al usuario autenticado y autorizado por IIS), donde se volverá a examinar atendiendo ahora a los criterios de seguridad de ASP.NET

Los sistemas de seguridad de IIS y ASP.NET son independientes entre sí.
Esto significa que son 2 capas de seguridad bien diferenciadas pero que trabajan de forma coordinada para ofrecer un único resultado.

Para hablar de seguridad en IIS y ASP.NET es necesario manejar los siguientes conceptos:

• Autenticación
  • Proceso por el que se valida las credenciales suministradas por el usuario contra una autoridad válida que pueda confirmar que el usuario es quien dice realmente ser.
• Autorización
  • Después de la autenticación, el proceso de autorización determina si el usuario tiene permiso para acceder o no al recurso solicitado.
• Suplantación, impersonalización
  • Proceso por el que ASP.NET utiliza para acceder a un recurso, una cuenta de usuario distinta de la que arrancó el proceso de ASP.NET.

Si hablamos de la autenticación en IIS podemos encontrar la autenticación anónima, básica, texto integrada, Windows Integrada, etc.

Cabe mencionar que la autenticación anónima podría considerarse como una no autenticación, puesto que IIS aceptará cualquier petición sin solicitar ninguna credencial al usuario ni llevar a cabo ningún tipo de autenticación. Aun así, como todas las solicitudes en IIS tienen que disponer de unas credenciales válidas se asignarán automáticamente a la cuenta IUSR_<NombreMáquina> que IIS crea durante su instalación.

De hecho, la autenticación anónima es el método más rápido pero también el menos seguro (es el más rápido porque no necesita de autenticación contra una autoridad válida pero el menos seguro porque no autentica).

Por otro lado, la autenticación integrada de Windows nos permite utilizar la seguridad integrada del sistema operativo basado en NTFS y pasar como token de seguridad a ASP.NET una cuenta de usuario válida del sistema o dominio (las credenciales del usuario son enviadas automáticamente por el navegador en las cabeceras de la solicitud HTTP cuando se detecta que el servidor requiere las mismas – modo de autenticación Windows Integrado - o bien se presenta un cuadro de diálogo – modo de autenticación básico).

En este punto está claro que si alguien pide una página .aspx a nuestro servidor, la cuenta IUSR_<NombreMáquina> tiene que superar:

• Autenticación.
  • Esto es automático ya que asumimos un escenario de autenticación anónima.
• Autorización.
  • Tiene que poder acceder al fichero .aspx, y esto se traduce en que tiene que tener permisos de lectura sobre el fichero.

Si alguno de estos mecanismos falla ASP.NET simplemente NO entra en escena porque IIS aborta la petición.

Superada con éxito la autenticación y autorización de ISS, ahora es el turno de la autenticación y autorización de ASP.NET.

Si hablamos de la seguridad de ASP.NET es muy importante el concepto de la impersonalización.  

Por defecto ASP.NET no impersonaliza. Esto quiere decir que superada la seguridad de IIS, el acceso a cualquier recurso (disco, red, etc.) se realizará bajo el contexto de seguridad de la cuenta que haya arrancado el proceso de ASP.NET (la cuenta asignada al grupo de aplicaciones en el que se está ejecutando nuestra aplicación ASP.NET).

Si por otro lado hemos decidido que ASP.NET impersonalice, el acceso a los recursos será realizado bajo el contexto de seguridad de la cuenta de usuario que representa el token de seguridad que fue recibido por IIS.

Es decir, si no impersonalizamos (comportamiento por defecto), el acceso a recursos será bajo la cuenta del proceso de ASP.NET. Si impersonalizamos, el acceso será bajo la cuenta de usuario recibida desde IIS (que puede ser IUSR_<NombreMáquina> si está activa la autenticación anónima, Dominio\Usuario si está activa la seguridad de Windows Integrada, etc.)

Volviendo a la capa de seguridad de ASP.NET, lo primero que tenemos que decidir es que método de autenticación queremos activar en ASP.NET. Los posibles valores son Windows (por defecto) o Forms.

Si te fijas, elegir el proveedor de autenticación de ASP.NET es una decisión a tomar de forma conjunta al método de autenticación vigente en IIS. Así, si tenemos activada la autenticación anónima, quizás debiéramos seleccionar el proveedor de autenticación Forms que incluye una gestión completa de usuarios y permisos a través de los ficheros web.config, mientras que si no tenemos la autenticación anónima de IIS activa se debería seleccionar Windows. En cualquier caso, esto es siempre queriendo entrar en la mecánica propuesta de seguridad por ASP.NET porque para gustos los colores.

Una vez hemos superado con éxito la capa de seguridad de IIS (autenticación y autorización) y también la autenticación de ASP.NET (Forms), llega el turno de la autorización de ASP.NET sobre el recurso solicitado (que, recordemos, a no ser que se impersonalice a través de ASP.NET, el acceso el recurso se llevará a cabo a través de la cuenta de usuario en la que se ejecuta el proceso de ASP.NET y no en la cuenta de usuario que IIS suministra a ASP.NET).

Respecto a la autorización de ASP.NET, cabe mencionar que para extensiones asignadas a ASP.NET será el propio ASP.NET quién autorice (por ejemplo, .aspx, .ashx, etc.), pero para cualquier otro tipo de recurso será IIS quién autorice (por ejemplo  recursos estáticos como .jpg, .js, etc.).

Si fuera necesario podría ser ASP.NET quien se encargará de autorizar todos los tipos de recursos, tanto estáticos como los propios, pero ese es otro tema. Aquí es importante saber la versión de IIS en la que estamos ejecutando nuestra aplicación ASP.NET: Si es inferior a 7.x funcionará como lo dicho anteriormente pero si es 7.0 o superior, todas las peticiones son gestionadas por ASP.NET (incluidas aquellas a recursos estáticos).

Hasta ahora hemos hablado del “proceso en el cual se ejecuta ASP.NET”, pero
¿Cuál es ese proceso?

En versiones de IIS 6.0 o superiores el nombre del proceso es w3wp.exe, mientras que en versiones anteriores el nombre es aspnet_wp.exe.

Por otro lado, la cuenta por defecto para el proceso de ASP.NET es la cuenta que tenga configurada el grupo de aplicaciones en el que esté asignada la aplicación.

Por ejemplo, Windows 2003 Server crea por defecto un grupo de aplicaciones llamado DefaultAppPool que se ejecuta bajo el contexto de seguridad de la cuenta NT AUTHORITY\Servicio de red.

Siendo así, si queremos dar permisos de escritura en un directorio (porque por ejemplo generamos algún tipo de fichero), será a esa cuenta a la que tengamos que dar los permisos de escritura.

Aunque Windows 7 crea igualmente un grupo de aplicaciones DefaultAppPool, incorpora un nuevo tipo de cuenta llamada ApplicationPoolIdentity que en realidad es el usuario IIS APPPOOL\DefaultAppPool.

Aquí cabe mencionar que el nombre de usuario DefaultAppPool es simplemente el nombre del grupo de aplicaciones, por lo que si nuestro grupo de aplicaciones se llama ContabilidadAppPool, la cuenta de usuario será IIS APPPOOL\ContabilidadAppPool.

Para saber más sobre este nuevo tipo de cuentas virtuales, recomiendo el siguiente enlace que explica perfectamente todo lo referente a estas cuentas http://learn.iis.net/page.aspx/624/application-pool-identities/

En cualquier caso, cabe mencionar que estas cuentas virtuales (digo virtuales porque no existen y se crean dinámicamente cuando arranca el grupo de aplicaciones) pertenecen a los siguientes grupos:

• Todos
• BUILTIN\Usuarios
• NT AUTHORITY\SERVICIO
• INICIO DE SESIÓN EN LA CONSOLA
• NT AUTHORITY\Usuarios autentificados
• NT AUTHORITY\Esta compañía
• BUILTIN\IIS_IUSRS
• LOCAL

Al respecto de estas cuentas virtuales (ApplicationPoolIdentity) cabe mencionar que si quieres asignarles permisos en una carpeta o fichero concreto, no aparecen como disponibles en el listado de cuentas del equipo o dominio, así que es necesario introducirlas a mano en la pestaña seguridad de los permisos NTFS.

Puedes ver cómo llevar a cabo estar tarea en el siguiente enlace imprescindible http://learn.iis.net/page.aspx/624/application-pool-identities/

Por último sólo nos resta hablar de cómo impersonalizar en ASP.NET.
Para ello tenemos disponibles 2 opciones:

Impersonalizar bajo el contexto de seguridad de la cuenta de usuario recibida desde IIS. Para ello simplemente debemos agregar lo siguiente a nuestro web.config.

<identity impersonate="true"/>

Impersonalizar bajo una cuenta de usuario específica con independencia del token suministrado por IIS.

<identity impersonate="true" userName="Usuario" password="Contraseña"/>

Además de impersonalizar de modo global a través de ficheros de configuración (web.config) también se puede impersonalizar sólo ciertas líneas de código. Imagina que sólo una función de tu código tiene acceso a un fichero para que el necesitas ciertos permisos.

En cualquier caso, hay que reseñar que la impersonalización puede afectar significativamente al rendimiento y escalado de la aplicación.

Un saludo!