Grupos de aplicaciones en IIS

Me he propuesto realizar una serie de posts relativos a IIS y ASP.NET.

El primero de ellos es este mismo y tratará sobre los grupos de aplicaciones y las identidades de usuarios que intervienen en el proceso autenticación, autorización, suplantación y respuesta a un recurso solicitado.

En realidad este post es casi un copy/paste (pero con todo el cariño del mundo) de este otro post que igualmente recomiendo leer. http://web.archive.org/web/20080210135951/http://www.microsoft.com/spanish/msdn/articulos/archivo/111002/voices/IIS6ASPNET.asp

¿En qué momento aparecen en escena los grupos de aplicaciones?

Cuando IIS recibe una petición a un recurso, el primer componente que aparece en escena es el módulo del kernel de Windows llamando HTTP.sys. Una vez que este módulo comprueba que la petición es válida y no tiene ninguna versión válida en cache que servir, redirecciona la petición al grupo de aplicaciones (ApplicationPool) que atiende a dicha petición y lo añade a su cola de peticiones.

¿Qué es un grupo de aplicaciones?

Un grupo de aplicaciones encapsula uno o varios procesos que sirven uno o varios sitios web o aplicaciones. Por norma, un grupo de aplicaciones está compuesto por un solo proceso pero en el caso de estar compuesto por varios procesos estaríamos hablando de un Web Garden. Este concepto es especialmente útil en máquinas multiprocesador donde se puede especificar la afinidad de cada proceso del grupo de aplicaciones con un procesador concreto.

Cada uno de los procesos que gestiona el grupo de aplicaciones se denominan Worker Process (w3wp.exe) y se ejecutan bajo la identidad de usuario especificada en las propiedades del grupo de aplicaciones. Cabe mencionar que estos procesos no se arrancan hasta que el grupo de aplicaciones recibe una petición y que pueden detenerse o reciclarse en función de la configuración del grupo de aplicaciones.

¿Qué ventajas suponen la aparición de los grupos de aplicaciones?

Aislamiento de aplicaciones. Esto quiere decir que si una aplicación contenido en un grupo de aplicaciones falla no podrá afectar al resto de aplicaciones en otros grupos de aplicaciones distintos, esto es que se establecen unos límites para las aplicaciones que no se podrán rebasar al estar contenidas en un grupo de aplicaciones.

Monitorización o control de recursos. Al ejecutarse siempre una aplicación en un grupo de aplicaciones resulta más sencillo monitorizar el uso de recursos que realiza el grupo de aplicaciones en el servidor, a la par que en entornos multiprocesador se puede crear afinidad del grupo de aplicaciones con un procesador determinado estableciendo, si fuera necesario, unos límites de uso y carga del procesador.

Tolerancia a fallos. Además del ya comentado aislamiento de aplicaciones, un grupo de aplicaciones puede programarse para reciclarse bajo determinadas circunstancias.

Configuración de la identidad del Worker Process. Es posible configurar el grupo de aplicaciones para especificar bajo que cuenta de usuario ejecutará su proceso o procesos asociados. De este modo, si un proceso o aplicación fuera comprometido por un usuario malintencionado sólo podría tener acceso a los recursos a los que pueda acceder la identidad del grupo de aplicaciones.

Algunas de las cuentas sugeridas por defecto para un grupo de aplicaciones son:

• Sistema local.
• Servicio local.
• Servicio de red (por defecto).
• ApplicationPoolIdentity (ver más en http://learn.iis.net/page.aspx/624/application-pool-identities/)
• Cualquier otra cuenta válida especificada por el usuario.

¿En qué momento aparece ASP.NET en escena?

Cuando el grupo de aplicaciones recibe una petición a través de la cola que lo une con HTTP.SYS, decide cómo resolverla en función del tipo o extensión de la URL solicitada. Por ejemplo, en el caso de páginas .aspx éstas van dirigidas a la ISAPI de ASP.NET (aspnet_isapi.dll), asociación especificada en el mapeo de extensiones en el servidor.

Las responsabilidades de esta ISAPI son las siguientes y en el orden descrito:

• Compilar el código. este paso se realiza exclusivamente en caso necesario, es decir, si no está previamente compilado en la caché o se ha modificado algún archivo. Esta caché se almacena en <%windows%>\Microsoft.NET\Framework\<%version%>\Temporary ASP.NET Files.
• Ejecutar el código. En este paso se ejecuta el código compilado de la página .aspx y se genera la respuesta HTML.
• Devolver el resultado al cliente. Se pasa la respuesta a HTTP.SYS para que lo devuelva al cliente.

Autenticación y autorización

Como vimos en una entrada anterior (http://panicoenlaxbox.blogspot.com/2010/09/autenticacion-autorizacion-y.html) este proceso es llevado a cabo conjuntamente por IIS y ASP.NET. Ahora intentaremos dar un repaso a estos pasos de la forma más clara y concisa posible:

Un usuario realiza una petición desde su navegador.

• IIS autentica al usuario (de forma anónima, Windows integrada, etc.).
• IIS autoriza el acceso al recurso solicitado bajo la cuenta del usuario anterior. Es aquí donde entra por primera vez en juego los permisos NTFS. En caso de que la petición no sea autorizada veremos el típico error de “Acceso denegado”.
• ASP.NET autentica al usuario si es preciso (si por ejemplo está activa la autenticación Forms, ya que en caso de ser Windows no realiza ningún paso extra).
• ASP.NET autoriza al usuario si es preciso, mediante los permisos asociados al modo de autenticación Forms.
• Por último, el acceso al recurso solicitado es realizada a través de la cuenta de usuario especificada en la configuración del grupo de aplicaciones (la cuenta bajo la que se ejecuta el Worker Process) y de nuevo tiene que superar la autorización que supone NTFS.

Un saludo!