No te lo tomes Im-Personal (impersonate=true) Parte 2/2

Antes de entrar de lleno a lo que es la impersonalización, hay que comentar algunas cosas básicas sobre la configuración de los sitios web (al menos con .Net)

Hay un archivo XML llamado Web.Config que es donde se definen/guardan las configuraciones de las aplicación asp.net. aquí es donde se especifica la impersonalización.

Por otro lado, podemos configurar el comportamiento del Framework de .Net en el servidor, para eso tenemos un archivo muy machín, el archivo Machine.config. Pero aguas!!, las configuraciones que hagamos en el machín, van a afectar a TOOODAS las aplicaciones .Net que estén alojadas en el servidor.

Me llega a la mente la primicia de Homero Simpson, “si no está quebrado, no lo repares”. Si no sabes para que sirve una configuración, por favor, por lo que más quieras… No le muevas!! 

Que es la impersonalización (Hablando de sitios web)?

Las aplicaciones web necesitan accesar a recursos, entiéndase archivos, servicios del sistema operativo, web services, archivos, carpetas, etc. Este recursos no está accesibles a todo el mundo, por seguridad están restringidos y se requiere tener permisos para poder usarlos.
Como hacerle para que una aplicación web que está expuesta a sin número de ataques e intrusiones pueda utilizar recursos tan sensibles como DLL del sistema operativo?

En las aplicaciones que comúnmente llamamos desktop o cliente servidor, para usar la aplicación te tienes que loguear al sistema operativo, por lo tanto la aplicación corre con los permisos de un usuario autentificado por el sistema operativo y por lo tanto tiene permisos para usar los recursos de la maquina (salvo que ingreses como invitado)

Las aplicaciones web no cuentan con un usuario autentificado por el Sistema Operativo,  de hecho como están al alcance de todo el mundo, pueden ser accesadas por personas que no están en nuestra red, en nuestro idioma, en nuestro país, en nuestro planeta (exagere un poco).

Y volvemos a la pregunta, como le hacemos para que cualquier usuario de nuestro sistema web tenga permisos para usar recursos, sin comprometer la seguridad?

Hay 2 formas: El Usuario .Net y la Impersonalización

Como implementar impersonalizacion?
El usuario .Net .- En Asp.Net todas las aplicaciones utilizan un usuario para iniciar, dicho usuario se configura en el archivo Machin del que hablamos allá arriba.

Cada vez que alguien se conecta a la aplicación aumenta el consumo de recursos de ese usuario (léase memoria)

La bronca aquí es que, ese usuario se va a poner muuuy choncho, lo cual no es bueno para el performance de la aplicación y por otro lado ese usuario omnipotente tendría acceso a todos los recursos, lo cual es poco recomendable ya que cada recurso debe tener sus propias restricciones. Por ejemplo no son los mismos permisos que se necesitan para crear un archivo en un folder que ejecutar un CLR en la Base de datos.

Y otro problema es que se tiene un solo usuario para todas las aplicaciones web que estén alojadas en el servidor.

Impersonalización.- La opción B implica que cada aplicación web, cuenta con su archivo de configuración (web.config), dentro de este archivo definimos un usuario con el que se va a conectar la aplicación.  Se agrega una llave al XML en la sección de Identity

<identity impersonate="true|false" userName="username" password="password"/>

Por lo anterior la aplicación se ejecutara bajo el contexto de la identidad del cliente que esta accesando la aplicación.

La cuenta de ASPNET de Windows es usada para accesar recursos de ASP.Net a través del el llamado Worker Process (Aspnet_wp.exe). Esta cuenta esta limitada, en comparación con la cuanta de invitado de Internet (IUSR_ NombreComputadora), la cual se usa por el ASP clásico. 

En ciertas ocasiones se quiere que la aplicación sea ingresada por medio del usuario anónimo IUSR_NombreComputadora, en esos casos se configure la impersonalización, pero sin poner el usuario, los cual le indica al IIS que debe utilizar el usuario anónimo:

<system.web/>
<identity impersonate="true"/>
</system.web/> 


En cambio si se quiere usar un usuario especial, solo basta con especificarlo en la llave del Identity:

<Identity impersonate=”true” 

userName=”misuariodeejemploparaelblog”
password="mipassworddelusuariodeejemploparaelblog " />

Riesgos de impersonalización de sitios web

• La impersonalización puede afectar significativamente la escalabilidad (ni que fuera montaña) y performance de una aplicación. Nos sale más caro hacer la llamada a un recurso por medio de la impersonalización que hacer la llamada o el uso directamente. Se gana en seguridad pero se pierde en uso de recursos.
• Otro detalle es que la impersonalización corre en forma local y sobre un hilo de ejecución. Cuando el código cambia de hilo, por ejemplo cuando se tiene un pool de hilos de ejecución, por default los hilos nuevos se ejecutan usando el identity, es decir, ya no usa el usuario de la impersonalización. Como sabemos el manejo de hilos de ejecución no es cosa sencilla, hay que tener vastos conocimientos sobre hilos e hilasas.
• La impersonalización esta deshabilitada por default, esto es para tener compatibilidad con ASP (el antiguo) y para no vulnerar la seguridad de los sistemas.
• Hay que tener cuidado al usar impersonalización, ya que permite que una aplicación ejecute código usando permisos no vislumbrado originalmente por el programador, aguas con esto.
• Se tiene que poner en el web.config el usuario y el password, dejándolo accesible a cualquier persona que tenga un notepad para abrirlo.