Si vas a compartir este post: por favor utiliza la URL original en JASoft: http://www.jasoft.org/Blog/post/Suplantacion-de-usuarios-en-IIS-y-ASPNET-un-resumen-detallado.aspx
A la hora de desplegar en un entorno real de producción, para ponerlas a disposición de todo el mundo, las aplicaciones web creadas con ASP.NET se albergan en un servidor web. Por regla general éste será Internet Information Server (IIS), incluido en las versiones de servidor de Windows.
IIS no es más que otra aplicación que se ejecuta sobre el sistema operativo, por lo que es Windows el que se ocupa del nivel más bajo de la cadena de la seguridad.
Por ello conviene tener claro que la última palabra a la hora de conceder acceso a un recurso físico del sistema la tiene el propio sistema operativo, no IIS ni ASP.NET.
Contextos de seguridad
En Windows, cada proceso se ejecuta dentro de su propio contexto de seguridad. Cuando un proceso accede, por ejemplo al sistema de archivos NTFS, los permisos se le otorgan en función del contexto en el que se ejecute.
Normalmente si un proceso lanza otro subproceso éste se ejecutará bajo el mismo contexto de seguridad que el primero. Existen casos sin embargo en los que, por razones de seguridad, un proceso puede producir otros procesos que trabajen bajo condiciones de seguridad diferentes.
Esto es lo que ocurre con IIS. Éste trabaja bajo el contexto de seguridad del sistema, es decir, como si se tratase del usuario System, que tiene una capacidad muy amplia de acceder a los recursos del sistema (para algunas cosas incluso más que un administrador).
Sin embargo, por cuestiones de seguridad, cuando IIS ejecuta una aplicación ASP/ASP.NET, la inicia en un nuevo proceso bajo un contexto de seguridad diferente, efectuando lo que se denomina una suplantación de usuario.
De este modo si el código de servidor de una página (o alguno de los componentes que ésta emplee) intenta acceder al disco duro u otro recurso cualquiera del sistema, lo hará con los permisos que tendría el usuario al que está suplantando el proceso bajo el que se ejecuta, es decir, bajo el contexto de seguridad de dicho usuario.
Este párrafo anterior, aunque algo enrevesado, es fundamental para entender las implicaciones de seguridad en el sistema de archivos.
En la práctica lo que quiere decir es que, cuando IIS suplanta a un usuario la aplicación web se ejecutará con los mismos permisos que si dicho usuario se encontrase sentado frente al servidor utilizándolo físicamente. Este es el motivo por el que se deben vigilar mucho los permisos que se asignen a cada uno de los recursos que hay en el servidor.
ASP.NET nos permite controlar con mucho detalle qué usuario del sistema suplanta IIS en cada situación, cuando ponemos una aplicación web a ejecutarse en Internet.
Nota: El lugar más importante donde podemos controlar el usuario que se va a suplantar en el proceso de IIS es en la propiedad "Identidad" del grupo de aplicaciones asociado a nuestra aplicación web (dentro de la Consola de administración de IIS·Grupos de aplicaciones·Propiedades avanzadas.
Suplantación de usuarios en ASP.NET
La cuenta utilizada a la hora de ejecutar las páginas ASP.NET depende del modo de ejecución del grupo de aplicaciones asociado a la aplicación y de los ajustes establecidos en el archivo web.config de nuestra aplicación.
Existe un ajuste específico en el archivo de configuración cuya sintaxis es la siguiente:
<identity impersonate="true|false" userName="dominiousuario" password="clave"/>
Gracias a ella es posible decidir exactamente bajo qué proceso se ejecutará nuestro código ASP.NET. Existen varios posibles casos según los valores que tome este atributo impersonate.
IMPORTANTE: Este ajuste solo se puede poner a "true" cuando el modo del pipeline de ASP.NET en el grupo de aplicaciones de IIS asociado a nuestra aplicación está en modo "clásico".
Suplantación de un usuario concreto
Si en el modo de integración clásico escribimos dentro de web.config lo siguiente:
<identity impersonate="true " userName="MiDominioMiUsuario" password="miclave"/>
lo que conseguiremos es que los procesos de nuestra aplicación ASP.NET se ejecutarán suplantando a la cuenta especificada en los dos últimos atributos y disfrutarán de sus mismos permisos.
De este modo, si por ejemplo pusiésemos las credenciales de un administrador de la máquina, nuestra aplicación tendría los mismos permisos que tendría dicho administrador, pudiendo acceder a recursos muy protegidos del sistema.
Nota: evidentemente jamás deberemos hacer esto. Esta característica se utiliza para ejecutar la aplicación usando una cuenta concreta con unos permisos muy controlados y solamente en situaciones muy específicas que lo requieran. Por no mencionar que introducir las credenciales en texto plano en el archivo de configuración nunca es una buena idea. Si es preciso utilizarlo existe la posibilidad de guardar el nombre de usuario y la clave encriptados en el registro en lugar de ponerlos en web.config. En general, yo escaparía de utilizar esta opción.
Suplantación del usuario actualmente autenticado en la aplicación
En este caso, activamos el atributo de suplantación de usuarios, pero sin especificar unas credenciales, así:
<identity impersonate="true">
Al hacer esto lo que conseguimos es que IIS ejecute la aplicación utilizando las credenciales del usuario actualmente autenticado en el sistema, generalmente mediante autenticación Windows. En caso de que no se use autenticación Windows, entonces se usará el usuario asignado en el grupo de aplicaciones.
Finalmente, si usamos la siguiente sintaxis:
<identity impersonate="false">
es equivalente a no poner nada y obtendremos el comportamiento por defecto, que es suplantar al usuario del grupo de aplicaciones.
Diagrama resumen
El siguiente diagrama ilustra mucho mejor los distintos valores que pueden tomar los diferentes usuarios que podemos consultar desde nuestro código en función del modo del pipeline de IIS, del modo de suplantación de usuarios establecido en el web.config y del modo autenticación especificado para la aplicación.
Es importante saber que el usuario que suplanta IIS es el que viene indicado por WindowsIdentity.getCurrent(). Si tenemos alguna duda sobre qué usuario se está usando, este es el que debemos comprobar.
El diagrama es el siguiente:
(Pulsa para aumentar)
Puedes descargarlo también en PDF (220 KB) para verlo mejor.
Es muy importante tener en cuenta esto si tenemos conflictos a la hora de acceder a algún recurso, sobre todo un archivo en disco, ya que tendremos que tener en cuenta cuál es el usuario bajo el cual se está ejecutando nuestra aplicación para poder otorgar los permisos pertinentes.
¡Espero que te sea útil!
Hoy un truco rápido pero interesante.
