Apéndice 7: Funcionamiento

Publicado: 26 de junio de 2006

Consulte la Página de entrada como punto de partida y para obtener una descripción completa del documento Crear aplicaciones ASP.NET seguras.

Resumen: En este apéndice se proporciona material adicional que explica con mayor detalle el funcionamiento real de algunos de los conceptos y procesos clave que se tratan en esta guía.

En esta página

Procesamiento de ASP.NET e IIS  Procesamiento de ASP.NET e IIS
Aislamiento de aplicaciones Aislamiento de aplicaciones
La extensión ISAPI de ASP.NET La extensión ISAPI de ASP.NET
IIS 6.0 y Windows Server 2003 IIS 6.0 y Windows Server 2003
Anatomía de una solicitud Web Anatomía de una solicitud Web
Procesamiento con autenticación mediante Formularios Procesamiento con autenticación mediante Formularios
Procesamiento con autenticación de Windows Procesamiento con autenticación de Windows
Control de eventos  Control de eventos
Implementar un controlador HTTP personalizado Implementar un controlador HTTP personalizado

Procesamiento de ASP.NET e IIS

Nota

La información de esta sección se aplica a Servicios de Internet Information Server (IIS) 5, en ejecución en Windows 2000.

Las aplicaciones Web ASP.NET y los servicios Web se procesan mediante código que se ejecuta en una única instancia del proceso de trabajo de ASP.NET (aspnet_wp.exe), aunque en equipos de varios procesadores se pueden configurar varias instancias, una por procesador.

IIS autentica a los llamadores y crea un testigo de acceso de Windows para el llamador. Si se habilita el acceso anónimo en IIS, IIS crea un testigo de acceso de Windows para la cuenta de usuario de Internet anónimo (normalmente, IUSR_MACHINE).

Las solicitudes de tipos de archivos ASP.NET se controlan mediante una extensión ISAPI de ASP.NET (aspnet_isapi.dll), que se ejecuta en el espacio de direcciones del proceso de IIS (inetinfo.exe). Utiliza una canalización con nombre para comunicarse con el proceso de trabajo de ASP.NET, tal y como se muestra en la ilustración 1. IIS pasa al proceso de trabajo de ASP.NET el testigo de acceso de Windows que representa al llamador. El módulo de autenticación de Windows de ASP.NET la utiliza para crear un objeto WindowsPrincipal y el módulo de autorización de archivos de ASP.NET la utiliza para ejecutar comprobaciones de acceso a Windows para garantizar que el llamador está autorizado para tener acceso al archivo solicitado.

imagen

Ilustración 1

Comunicación entre IIS y ASP.NET

Nota

Los testigos de acceso dependen del proceso. Como resultado, la DLL de la ISAPI de ASP.NET que se ejecuta en inetinfo.exe llama a DuplicateHandle para duplicar el identificador del testigo en el espacio de direcciones del proceso aspnet_wp.exe y pasa a continuación el valor del identificador a través de la canalización con nombre.

Aislamiento de aplicaciones

Para proporcionar aislamiento se utilizan dominios de aplicación independientes en el proceso de trabajo (uno por cada directorio virtual IIS o, en otras palabras, uno por cada aplicación Web ASP.NET o servicio Web).

Se contrapone a la tecnología ASP clásica, donde el nivel de protección de la aplicación configurado en la metabase IIS determinaba si la aplicación ASP debía ejecutarse en el proceso con IIS (inetinfo.exe), fuera del proceso en una instancia dedicada de Dllhost.exe o en una instancia compartida (agrupada) de Dllhost.exe.

Nota

La configuración de nivel de aislamiento del proceso en IIS no afecta al procesamiento de las aplicaciones Web ASP.NET.

La extensión ISAPI de ASP.NET

La extensión ISAPI de ASP.NET (aspnet_isapi.dll) se ejecuta en el espacio de direcciones del proceso IIS (inetinfo.exe) y reenvía las solicitudes de tipos de archivo ASP.NET al proceso de trabajo de ASP.NET a través de una canalización con nombre.
Los tipos de archivo de ASP.NET se asignan a la extensión ISAPI de ASP.NET mediante asignaciones definidas en la metabase IIS. Las asignaciones de tipos de archivo de ASP.NET estándar (.aspx, .asmx, .rem, .soap) se establecen al instalar .NET Framework.

Nota

Para ver asignaciones de aplicación

  1. En el grupo de programas Herramientas administrativas, inicie Servicios de Internet Information Server.

  2. Haga clic con el botón secundario del mouse (ratón) en el sitio Web predeterminado del equipo servidor Web y, a continuación, haga clic en Propiedades.

  3. Haga clic en la ficha Directorio principal y, a continuación, haga clic en Configuración.

    Se mostrará una lista de asignaciones. Puede ver cuáles son los tipos de archivo que están asignados a Aspnet_isapi.dll.

IIS 6.0 y Windows Server 2003

IIS 6.0 en Windows Server 2003 introducirá algunos cambios importantes a la organización del proceso actual.

  • Podrá configurar varios grupos de aplicaciones, a cada uno de los cuales le sirve una o varias instancias del proceso (w3wp.exe). De esta forma se proporcionará una mayor tolerancia a errores y se facilitará la administración, lo que permitirá aislar aplicaciones independientes en procesos independientes.

  • ASP.NET se integra con el agente de escucha HTTP en modo Kernel de IIS 6.0, lo que permitirá pasar solicitudes directamente del sistema operativo al proceso de trabajo de ASP.NET.

Más información

Para obtener más información acerca de IIS6 consulte el artículo "IIS 6 Overview" en TechNet (http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/iis/evaluate/iis6ovw.asp) (en inglés).Procesamiento mediante canalización de ASP.NET
Los mecanismos de autenticación y autorización de ASP.NET se implementan mediante objetos de módulo HTTP, que se invocan como parte del procesamiento mediante canalización de ASP.NET estándar. Cada una de las solicitudes y respuestas Web pasan a través de una canalización de objetos, tal y como se muestra en la ilustración 2.

imagen

Ilustración 2

Procesamiento mediante canalización de ASP.NET

El modelo de canalización de ASP.NET está formado por un objeto HttpApplication, diversos objetos de módulo HTTP y un objeto de controlador HTTP, junto con sus objetos asociados del generador de objetos, que se han omitido en la ilustración 2 por cuestiones de claridad. Un objeto HttpRuntime se utiliza al inicio de la secuencia de procesamiento y un objeto HttpContext se utiliza en todo el ciclo de vida de una solicitud para proporcionar detalles acerca de la solicitud y la respuesta.

En la siguiente lista se explican las responsabilidades y operaciones que ejecutan los objetos asociados a la canalización de procesamiento HTTP:

  • Un objeto HttpRuntime examina la solicitud recibida de IIS y la distribuye a una instancia adecuada del objeto HttpApplication para procesar la solicitud. Hay un grupo de objetos HttpApplication en cada dominio de aplicación de Aspnet_wp.exe. La asignación es de uno a uno entre dominios de aplicación, objetos HttpApplication y directorios virtuales IIS. En otras palabras, ASP.NET trata cada uno de los directorios virtuales IIS como aplicaciones independientes.
    Nota: Hay una instancia de HttpRuntime en cada dominio de aplicación Web

  • Los objetos HttpApplication controlan el procesamiento mediante canalización. Se crea un objeto HttpApplication individual para controlar cada solicitud HTTP simultánea. Los objetos HttpApplication se agrupan para mejorar el rendimiento.

  • Los objetos de módulo HTTP son filtros que procesan mensajes de solicitud y respuesta HTTP mientras se transmiten a través de la canalización. Puede ver o modificar el contenido de los mensajes de solicitud y respuesta. Los módulos HTTP son clases que implementan IHttpModule.

  • Los objetos de controlador HTTP son los extremos de las solicitudes HTTP y proporcionan el procesamiento de solicitudes de determinados tipos de archivo. Por ejemplo, un controlador procesa solicitudes de archivos *.aspx mientras otro procesa solicitudes de archivos *.asmx. Se genera el mensaje de respuesta HTTP y se devuelve desde el controlador HTTP. Los controladores HTTP son clases que implementan IHttpHandler.

  • En toda la canalización se utiliza un objeto HttpContext para representar la solicitud y respuesta Web actual. Está disponible para todos los módulos de la canalización y para el objeto de controlador al final de la canalización. El objeto HttpContext expone diversas propiedades; por ejemplo, la propiedad User que contiene un objeto IPrincipal que representa al llamador.

Anatomía de una solicitud Web

La biblioteca ISAPI de ASP.NET (Aspnet_isapi.dll) se ejecuta en el espacio de direcciones del proceso IIS (Inetinfo.exe). Distribuye las solicitudes al objeto HttpRuntime en el proceso de trabajo de ASP.NET (Aspnet_wp.exe). El siguiente conjunto de acciones se produce como respuesta a cada solicitud Web que recibe ASP.NET:

  • El objeto HttpRuntime examina la solicitud y la reenvía a una instancia de un objeto HttpApplication.

    Hay al menos una instancia del objeto HttpApplication por cada dominio de aplicación (los objetos se agrupan) y un dominio de aplicación por cada directorio virtual IIS. La solicitud inicial de un archivo en un determinado directorio virtual conlleva la creación de un dominio de aplicación y un nuevo objeto HttpApplication.

  • Se lee una lista de módulos HTTP del archivo Machine.config (contenidos en el elemento <httpModules>). Se pueden agregar al archivo Web.config módulos HTTP adicionales para una aplicación concreta. El elemento <httpModules> predeterminado en Machine.config se muestra en el siguiente miniprograma de código.

    <httpModules>
       <add name="OutputCache" 
       type="System.Web.Caching.OutputCacheModule"/>
       <add name="Session" 
       type="System.Web.SessionState.SessionStateModule"/>
       <add name="WindowsAuthentication" 
       type="System.Web.Security.WindowsAuthenticationModule"/>
       <add name="FormsAuthentication" 
       type="System.Web.Security.FormsAuthenticationModule"/>
       <add name="PassportAuthentication" 
       type="System.Web.Security.PassportAuthenticationModule"/>
       <add name="UrlAuthorization" 
       type="System.Web.Security.UrlAuthorizationModule"/>
       <add name="FileAuthorization" 
       type="System.Web.Security.FileAuthorizationModule"/>
       </httpModules>
    

    Los módulos de autenticación enlazan el evento AuthenticateRequest, mientras que los módulos de autorización enlazan el evento AuthorizeRequest.

    La solicitud pasa por cada módulo de la canalización, aunque sólo se carga un único módulo de autenticación. Depende de la configuración del elemento <authentication> en el archivo Web.config. Por ejemplo, el elemento <authentication> siguiente provoca la carga de WindowsAuthenticationModule.

    <authentication mode="Windows" />
    
  • El módulo de autenticación activado es responsable de la creación de un objeto IPrincipal y de su almacenamiento en la propiedad HttpContext.User. Es fundamental, ya que los módulos de autorización indirectos utilizan este objeto IPrincipal para tomar decisiones de autorización.

    Si no hay autenticación (por ejemplo, cuando se habilita el acceso anónimo en IIS y se configura ASP.NET con <authentication mode="None" />), hay un módulo no configurado especial que incluye un principal anónimo predeterminado en la propiedad HttpContext.User. Como resultado, HttpContext.User tiene siempre un valor distinto de NULL tras la autenticación.

    Si implementa un módulo de autenticación personalizado, el código del módulo personalizado debe crear un objeto IPrincipal y almacenarlo en HttpContext.User.

    Nota

    ASP.NET también conecta Thread.CurrentPrincipal según el valor de HttpContext.User tras el evento AuthenticateRequest.

  • HttpApplication activa el evento AuthenticateRequest, que puede enlazarse en global.asax. De esta forma se puede insertar código de procesamiento personalizado, por ejemplo, para cargar el conjunto de funciones asociadas al usuario actual. Sin embargo, tenga en cuenta que WindowsAuthenticationModule lo realiza automáticamente. La lista de funciones se obtiene del conjunto de grupos de Windows a los que pertenece el usuario de Windows autenticado.

  • Una vez que el módulo de autenticación adecuado finaliza el procesamiento, se llama a los módulos de autorización si no se ha anulado la solicitud.

  • Cuando se llama a UrlAuthorizationModule, comprueba la existencia de la etiqueta <authorization> en Machine.config y Web.config. Si existe, recupera el objeto IPrincipal de HttpContext.User y comprueba si el usuario está autorizado para tener acceso al recurso solicitado mediante el verbo especificado (GET, POST, etc.).

    Si el usuario no está autorizado, UrlAuthorizationModule llama a HttpApplication.CompleteRequest, que anula el procesamiento normal del mensaje. UrlAuthorizationModule devuelve un código de estado HTTP 401.

  • A continuación, se llama a FileAuthorizationModule. Comprueba si el objeto IIdentity de HttpContext.User.Identity es una instancia de la clase WindowsIdentity.

    Si el objeto IIdentity no es de la clase WindowsIdentity, FileAuthorizationModule no sigue procesando.

    Si existe la clase WindowsIdentity, FileAuthorizationModule llama a la API AccessCheck (mediante P/Invoke) para ver si el llamador autenticado (cuyo testigo de acceso ha sido pasado a ASP.NET por IIS y expuesto por el objeto WindowsIdentity) está autorizado para tener acceso al archivo solicitado. Si el descriptor de seguridad del archivo contiene al menos una entrada ACE de lectura en su DACL, la solicitud puede proseguir. De lo contrario, FileAuthorizationModule llama a HttpApplication.CompleteRequest y devuelve un código de estado 401.

Procesamiento con autenticación mediante Formularios

FormsAuthenticationModule se activa cuando se encuentra el siguiente elemento en Web.config.

<authentication mode="Forms" />

Recuerde que en la autenticación mediante Formularios se implementa el evento Application_Authenticate en Global.asax. En la autenticación mediante Formularios se produce la siguiente secuencia:

  • En este código puede crear un objeto IPrincipal y almacenarlo en HttpContext.User, que suele contener la lista de funciones recuperadas del almacén de datos personalizado (normalmente una base de datos de SQL Server o Active Directory). El objeto IPrincipal suele ser una instancia de la clase GenericPrincipal pero también podría ser una clase IPrincipal personalizada.

    FormsAuthenticationModule comprueba si se ha creado un objeto IPrincipal. Si es así, lo utilizan los módulos de autorización indirectos. Si no se ha creado, FormsAuthenticationModule crea un GenericPrincipal (sin funciones) y lo almacena en el contexto.

    Si no hay información de funciones, habrá errores en las comprobaciones de autorización (como las peticiones PrincipalPermssion) que soliciten la pertenencia a una función.

  • UrlAuthorizationModule controla el evento AuthorizeRequest. Sus decisiones de autorización se basan en el objeto IPrincipal contenido en HttpContext.User.

Procesamiento con autenticación de Windows

WindowsAuthenticationModule se activa cuando se encuentra el siguiente elemento en Web.config.

<authentication mode="Windows" />

En la autenticación de Windows se produce la siguiente secuencia:

  1. WindowsAuthenticationModule crea un objeto WindowsPrincipal mediante el testigo de acceso de Windows que IIS pasa a ASP.NET.

  2. Utiliza P/Invoke para llamar a las funciones Win32 para obtener la lista de grupos de Windows a los que pertenece el usuario. Se utilizan para llenar la lista de funciones WindowsPrincipal.

  3. Almacena el objeto WindowsPrincipal en HttpContext.User, para que puedan utilizarlo los módulos de autorización indirectos.

Control de eventos

El objeto HttpApplication activa el conjunto de eventos que aparecen en la tabla 1. Cada uno de los módulos HTTP puede enlazar dichos eventos (proporcionando sus propios controles de eventos).

Tabla 1: Eventos activados por los objetos HttpApplication

Evento

Notas

BeginRequest

Se activa antes de iniciar el procesamiento de la solicitud

AuthenticateRequest

Para autenticar al llamador

AuthorizeRequest

Para realizar comprobaciones de acceso

ResolveRequestCache

Para obtener una respuesta de la caché

AcquireRequestState

Para cargar el estado de la sesión

PreRequestHandlerExecute

Se activa inmediatamente antes de enviar la solicitud al objeto de controlador

PostRequestHandlerExecute

Se activa inmediatamente después de enviar la solicitud al objeto de controlador

ReleaseRequestState

Para almacenar el estado de la sesión

UpdateRequestCache

Para actualizar la caché de respuesta

EndRequest

Se activa tras finalizar el procesamiento

PreSendRequestHeaders

Se activa antes de enviar los encabezados de respuesta almacenados en búfer

PreSendRequestContent

Se activa antes de enviar el cuerpo de respuesta almacenado en búfer

Nota

El controlador HTTP se ejecuta entre los eventos PreRequestHandlerExecute y PostRequestHandlerExecute.
Los últimos dos eventos no son deterministas y pueden producirse en cualquier momento (por ejemplo, como resultado de Response.Flush). Todos los demás eventos son secuenciales.

No es necesario implementar un módulo HTTP simplemente para enlazar uno de estos eventos. Puede agregar controladores de eventos a Global.asax. Además de los eventos de la tabla 1 (que pueden enlazarse mediante objetos de módulo HTTP individuales), el objeto HttpApplication activa los controladores Application_OnStart y Application_OnEnd, ya conocidos para los desarrolladores de ASP. Sólo pueden controlarse en Global.asax. Por último, puede implementar además controladores de eventos personalizados en Global.asax para los eventos activados por objetos de módulo HTTP individuales. Por ejemplo, el módulo de estado de la sesión activa los eventos Session_OnStart y Session_OnEnd.

Implementar un módulo HTTP personalizado

Para crear su propio módulo HTTP e insertarlo en la canalización de procesamiento de ASP.NET

  1. Cree una clase que implemente IHttpModule.

  2. Inserte el ensamblado que contiene el módulo en el subdirectorio \bin de la aplicación o instálelo en la caché de ensamblados global.

  3. Agregue un elemento <HttpModules> al archivo Web.config de la aplicación, tal y como se muestra a continuación.

    <system.web>
       <httpModules>
       <add name="modulename"
       type="namespace.classname,assemblyname" />
       </httpModules>
       </system.web>
    

Implementar un controlador HTTP personalizado

Puede que necesite implementar un controlador HTTP personalizado, por ejemplo, para controlar el procesamiento de archivos con la extensión de archivo .data.

Para implementar un controlador HTTP personalizado

  1. Agregue una asignación a la metabase IIS para asignar la extensión de archivo .data a la extensión ISAPI de ASP.NET (Aspnet_isapi.dll).
    Haga clic con el botón secundario del mouse en el complemento MMC de IIS del directorio virtual de la aplicación, haga clic en el botón Configuración y, a continuación, haga clic en Agregar para crear una nueva asignación de los archivos .data en C:\Winnt\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll.

    Nota: Si ha activado la casilla de verificación Comprobar si el archivo existe al agregar la asignación, el archivo debe existir físicamente. Normalmente es lo que se espera, a menos que tenga rutas de acceso virtuales que no estén asignadas a un archivo físico. Las rutas de acceso virtuales que terminan en .rem o .soap se utilizan en .NET Remoting.

  2. Cree una clase que implemente IHttpHandler (y opcionalmente IHttpAsyncHandler si desea controlar solicitudes de forma asíncrona).

  3. Inserte el ensamblado que contiene el controlador en el subdirectorio \bin de la aplicación o instálelo en la caché de ensamblados global.

  4. Agregue el controlador a la canalización de procesamiento; para ello, agregue una sección <httpHandlers> al archivo Web.config de la aplicación.

    <system.web>
       <httpHandlers>
       <add verb="*" path="*.data" type="namespace.classname,    assemblyname" />
       </httpHandlers>
       </system.web>
    
Mostrar: