Share via


Flujo de datos ASP.NET

Existen muchas formas distintas de diseñar la seguridad en las aplicaciones ASP.NET. En esta sección se describe el flujo de datos de seguridad en dos escenarios comunes: la representación y la autenticación de formularios mediante cookies.

Escenario 1: representación

Este escenario se basa en la autenticación de Servicios de Microsoft Internet Information Server (IIS) y en la seguridad de acceso a archivos de Microsoft Windows NT para minimizar la programación de la seguridad en la aplicación ASP.NET. El flujo de datos se muestra en la ilustración siguiente.

Representación

En esta ilustración se muestra la siguiente secuencia de eventos:

  1. En IIS, se recibe una solicitud de acceso desde un cliente de la red.

  2. IIS autentica al cliente utilizando la autenticación básica, implícita o la Autenticación Integrada de Windows (NTLM o Kerberos).

  3. Si se autentica al cliente, IIS pasa la solicitud autenticada a ASP.NET.

  4. La aplicación ASP.NET representa al cliente que realiza la solicitud utilizando el símbolo (token) de acceso pasado desde IIS, y se basa en los permisos de archivos NTFS para conceder el acceso. La aplicación ASP.NET simplemente debe comprobar en el archivo de configuración de ASP.NET que la directiva que habilita la representación está establecida en true; no es necesario escribir código de seguridad ASP.NET.

    Tenga en cuenta que si no está habilitada la representación, la aplicación se ejecuta con la identidad de procesamiento de IIS. Para Microsoft Windows 2000 Server y Windows XP, la identidad predeterminada es una cuenta de usuario denominada ASPNET que se crea automáticamente al instalar ASP.NET. Para Microsoft Windows Server 2003, la identidad predeterminada es la cuenta de servicio de red. Si se desea restringir el acceso, se deben utilizar otras formas de autorización, como la autorización basada en direcciones URL.

    Para obtener más información sobre el uso de la representación en las aplicaciones ASP.NET, vea Representación y Utilizar la autenticación de IIS con la representación de ASP.NET.

  5. Si se concede el acceso, la aplicación ASP.NET devuelve la página solicitada a través de IIS.

Escenario 2 – Autenticación de formularios

En este escenario, la aplicación utiliza la autenticación mediante formularios ASP.NET, un proceso que permite a la aplicación recopilar las credenciales, como el nombre y la contraseña, directamente del cliente solicitante, así como determinar su autenticidad. La autenticación de IIS no se utiliza en la aplicación, pero las configuraciones de autenticación de IIS son importantes para el proceso de autenticación mediante formularios ASP.NET. A no ser que decida rechazar todas las solicitudes que no cumplan los criterios del método de autenticación de IIS habilitado, deberá habilitar la configuración Anonymous Access de IIS.

Nota   Si no habilita la configuración Anonymous Access de IIS, las solicitudes que no cumplan los criterios de autenticación de IIS, serán rechazadas y no tendrán acceso a la aplicación ASP.NET.

El flujo de datos de este escenario se muestra en la ilustración siguiente.

Autenticación mediante formularios

En esta ilustración se muestra la siguiente secuencia de eventos:

  1. Un cliente genera una solicitud para un recurso protegido.
  2. IIS recibe la solicitud y si autentica al solicitante, o si Anonymous Access de IIS está habilitado, la solicitud se pasa a la aplicación ASP.NET. Como en este caso el modo de autenticación de la aplicación ASP.NET está establecido en formularios, no se utiliza la autenticación de IIS.
  3. Si no hay ninguna cookie asociada a la solicitud, ASP.NET redirige la solicitud a la página de inicio de sesión, cuya ruta de acceso reside en el archivo de configuración de la aplicación. En la página de inicio de sesión, el usuario cliente escribe las credenciales requeridas (por lo general, el nombre y la contraseña).
  4. El código de la aplicación comprueba las credenciales para confirmar su autenticidad, normalmente, en un controlador de eventos. Si se autentican las credenciales, el código de la aplicación asocia un vale (como cookie) que incluye el nombre de usuario, pero no la contraseña. Si la autenticación falla, la solicitud se devuelve normalmente con el mensaje "Access Denied" (Acceso denegado) o se vuelve a presentar el formulario de inicio de sesión.
  5. Una vez que la aplicación emite un vale, ASP.NET sólo comprueba la validez del vale mediante la comprobación de autenticación de mensaje. Las aplicaciones no necesitan las credenciales en archivos *.config. De hecho, ASP.NET no las comprueba después de que se emite una cookie, aunque las haya.
  6. Si se autentica al usuario, ASP.NET comprueba la autorización y puede permitir el acceso al recurso protegido que se ha solicitado en un principio o redirigir la solicitud a otra página, dependiendo del diseño de la aplicación. También puede dirigir la solicitud a un módulo de autorización personalizado donde se prueban las credenciales para autorizar el acceso al recurso protegido. Si la autorización falla, ASP.NET siempre redirige a la página de inicio de sesión.
  7. Si se autoriza al usuario, se concede el acceso al recurso protegido la aplicación puede requerir una prueba adicional de las credenciales antes de autorizar el acceso al recurso protegido, dependiendo del diseño de la aplicación.

Vea también

Seguridad ASP.NET de aplicaciones Web | Proveedor de autenticación mediante formularios | Autenticación sencilla mediante formularios | Autenticación de formularios mediante un archivo de usuarios XML | Representación | Utilizar autenticación de IIS con la representación de ASP.NET