Seguridad de IIS y .NET Framework

Artículo
03/05/2012

Microsoft AppFabric 1.1 para Windows Server usa las sólidas características de seguridad de IIS y de .NET Framework versión 4 para proteger los servicios de .NET Framework 4 hospedados en Servicio de activación de procesos de Windows (WAS). Para ayudarle a entender cómo se configura correctamente la seguridad de cliente a servicio con AppFabric, es importante comprender las opciones de seguridad de IIS y .NET Framework.

En general, hay varias capas de opciones de seguridad disponibles, y deben usarse las más apropiadas para la implementación. Cada capa de seguridad proporciona capacidad de proteger recursos específicos. Por ejemplo, las herramientas de IIS normalmente proporcionan los medios para proteger los artefactos de IIS, como sitios y aplicaciones, mientras que la configuración de seguridad de .NET Framework 4 se puede aplicar a conceptos de servicio de WCF/WF, como servicios, extremos y operaciones.

Para obtener más información acerca de la seguridad, vea Seguridad de Windows Communication Foundation (https://go.microsoft.com/fwlink/?LinkId=183157) y Seguridad de IIS (https://go.microsoft.com/fwlink/?LinkId=183159).

Seguridad de IIS y AppFabric

IIS afecta a la seguridad de una aplicación desde el lado del cliente que llama y también cuando el servicio .NET Framework obtiene acceso a los almacenes de datos de seguimiento y persistencia. IIS afecta a la seguridad de AppFabric en las áreas siguientes:

IIS_IUSRS. Grupo de seguridad de Windows que se usa para administrar el acceso en tiempo de ejecución a archivos y carpetas de la instalación de IIS predeterminada.

Seguridad Nota
No debe confundirse el grupo de seguridad de Windows IIS_IUSRS con el nombre de inicio de sesión de SQL Server IIS_IUSRS. Ambos están relacionados, pero son entidades independientes.

Identidad del grupo de aplicaciones. IIS inserta dinámicamente todas las identidades del grupo de aplicaciones en el grupo IIS_IUSRS, en tiempo de ejecución. Este grupo de seguridad tiene permiso para acceder a los almacenes de datos necesarios, especialmente al almacén de datos de persistencia. Para obtener más información, vea Seguridad de SQL Server.

Seguridad de .NET Framework para AppFabric

Cuando se habla de la seguridad de los servicios .NET Framework configurados en AppFabric, realmente se hace referencia a WCF. WCF define el protocolo de transporte que se usa para la comunicación entre un cliente WCF y un servicio .NET Framework (WCF o WF). Es la parte de .NET Framework que proporciona un modelo de programación unificado para una creación rápida de aplicaciones orientadas al servicio, que se comuniquen por la web y la empresa. WCF no solo se integra con las infraestructuras de seguridad existentes, sino que también extiende la seguridad distribuida en dominios exclusivos de Windows, mediante mensajes SOAP seguros. Para obtener más información, vea Seguridad de Windows Communication Foundation (https://go.microsoft.com/fwlink/?LinkId=183157) e Información general sobre seguridad (https://go.microsoft.com/fwlink/?LinkId=183160).

Combinación de la seguridad de IIS y .NET Framework

Para la integridad de una aplicación, es importante garantizar que un mensaje enviado a un servicio no sea visualizado ni modificado durante el proceso de transferencia. Esto puede hacerse mediante el cifrado y la firma. Sin embargo, la transferencia de mensajes sólo es verdaderamente segura si también se puede validar, o autenticar, con total certeza, la identidad de la aplicación cliente que realiza la llamada. Con AppFabric, es importante comprender el funcionamiento conjunto de IIS y WCF, para garantizar que esto suceda.

Para obtener más información acerca de patrones y prácticas relacionados con la seguridad de servicios web, vea Patrones y prácticas: Guía para la mejora de la seguridad de los servicios web (https://go.microsoft.com/fwlink/?LinkId=183161) (en inglés).

Autenticación de IIS en AppFabric

Los mecanismos de seguridad de transporte de WCF en Windows dependen del enlace y el transporte subsiguiente que se usen. Por ejemplo, si se usa la clase WSHttpBinding, el transporte es HTTP, y el mecanismo primario para proteger el transporte es Capa de sockets seguros (SSL) mediante HTTP, lo que se conoce comúnmente como HTTPS. La seguridad de mensajes usa la especificación WS-Security para proteger los mensajes a nivel de mensaje. Supone mejoras en la mensajería SOAP para proteger la confidencialidad, integridad y autenticación en el nivel de mensaje SOAP (y no en el nivel de transporte).

Modos de servicio hospedados

Los servicios hospedados pueden ejecutarse en dos modos: modo de transporte mixto o modo de compatibilidad de ASP.NET. El modo se controla mediante la marca de configuración en el nivel de aplicación aspNetCompatibilityEnabled. También se puede obtener esta marca en tiempo de ejecución desde la propiedad estática ServiceHostingEnvironment.AspNetCompatibilityEnabled. La marca aspNetCompatibilityEnabled es false de forma predeterminada, por lo que los servicios se ejecutan en el modo de transporte mixto, a menos que se modifique explícitamente esta configuración.

<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false"/>
</system.serviceModel>

Modo de transporte mixto

En el modo de transporte mixto, el módulo HTTP intercepta la solicitud en la primera etapa de la canalización: BeginRequest. Cuando entra la solicitud, el módulo HTTP establece HttpContext.Current como nulo y revierte la suplantación si se suplanta el subproceso. Ya que la solicitud del cliente se intercepta en esta primera etapa, el resto de características HTTP se deshabilita automáticamente. De este modo, cuando se ejecuta en modo de transporte mixto, los servicios no tienen acceso a las siguientes características específicas de HTTP ASP.NET:

HttpContext.Current. Esta siempre es nula en este modo. WCF proporciona un equivalente para esta característica: OperationContext.Current.
Autorización de archivo/URL. Esta característica de autorización de capas de transporte se habilita, normalmente, a través de la sección <system.web/authorization> del archivo Web.config de los servicios ASMX. La autorización de transporte está deshabilitada en el modo mixto de WCF. La única opción para autorizar archivos/URL es usar la autorización a nivel de mensaje, implementada en WCF.
Suplantación. La suplantación permite al servicio actuar como cliente, mientras se realiza una acción en el servidor. La característica de suplantación de ASP.NET se habilita, normalmente, a través de la sección <system.web/identity> del archivo Web.config de los servicios ASMX. No está disponible en la capa de transporte de WCF, en el modo mixto.
Estado de sesión. El estado de sesión de ASP.NET no se admite en el modo mixto. WCF tiene su propia implementación de sesión confiable, que permite una administración flexible del estado de sesión. El mayor problema de WCF es que el estado de sesión no sobrevive al reciclado de una aplicación y no funciona en el hospedaje multiproceso en una única máquina ni en granjas de servidores web. Esto es así porque no hay ningún mecanismo para compartir el estado entre aplicaciones o procesos, a diferencia del servicio de estado (deshabilitado) de ASP.NET.
Otras características de HTTP. Otras características de HTTP dependen de HttpContext.Current y no se admiten en el modo mixto. Por ejemplo, no se puede esperar recibir el resultado correcto de ConfigurationManager.AppSettings. La característica de globalización a través de <system.web/globalization> no está disponible.

La autenticación de IIS se ignora en las llamadas de WCF a servicios .NET Framework, cuando se ejecuta en modo de transporte mixto. Esto deja la seguridad WCF como principal mecanismo para autenticar y proteger la transferencia de mensajes entre el cliente WCF y el servicio .NET Framework. En el modo de transporte mixto, todos los transportes se tratan de la misma forma. Un servicio puede tener múltiples extremos WCF, que pueden escuchar al mismo transporte o a diferentes, como HTTP, net.tcp, net.pipe, net.msmq, etc. Sin embargo, los servicios hospedados que se ejecutan en el modo de transporte mixto todavía dependen de ASP.NET e IIS para proporcionar el entorno de hospedaje, la configuración de la aplicación y la implementación.

Modo de compatibilidad ASP.NET

Para usar la autenticación de IIS en cualquier aplicación hospedada en WAS, incluidas evidentemente las aplicaciones hospedadas en AppFabric, debe usar el modo de compatibilidad ASP y la seguridad de transporte WCF. Solo puede aprovechar las siguientes características de seguridad de IIS mediante el modo de compatibilidad ASP:

Controlar los usuarios de Windows y los miembros de cada grupo de Windows que pueden conectarse a un sitio o a una aplicación que hospede servicios mediante el Administrador de IIS.
Convertir un sitio web en un directorio virtual de IIS y, a continuación, establecer la configuración de seguridad de la ruta de acceso física al directorio virtual, de dos formas. La autenticación de paso a través indica a IIS que pase al sistema de archivos de Windows las credenciales del usuario autenticado, cuando obtenga acceso a la ruta de acceso física del directorio virtual. Alternativamente, se puede designar una identidad de usuario específica para el proceso de hospedaje de sus servicios .NET Framework, para obtener acceso a todo el contenido de la ruta de acceso física especificada.
Seleccione el método de autenticación de IIS apropiado (Anónimo, Básico, Formularios, Implícita, Autenticación de Windows o suplantación de formularios ASP.NET) para controlar la seguridad de las llamadas entrantes en los servicios asociados con el sitio web.

Puede aprovechar las siguientes características de seguridad de IIS, independientemente de si el modo de compatibilidad ASP está habilitado o no:

Configurar los valores de SSL para usar el cifrado de 64 o 128 bits, y configurar cómo se tratan los certificados de clientes para las solicitudes de entrada.
Crear reglas de autorización para permitir o denegar el acceso de usuarios a sitios web o aplicaciones.
Usar las capacidades de registro de IIS para crear un registro de auditoría de seguridad de las solicitudes de entrada.
Editar la seguridad relacionada con las cadenas de conexión, en las bases de datos de seguimiento y persistencia.
Administrar la configuración de enlace de los clientes que llamen los servicios.
Configurar los permisos de ejecución de cinco niveles (control total, leer y ejecutar, lista de contenido del archivo, escribir, etc.) en el sitio web contenedor o las aplicaciones de servicio que contiene.
Cambiar la identidad predeterminada NetworkService de un grupo de aplicaciones personalizado, por una identidad específica bajo la que se va a ejecutar. Si se uso la seguridad integrada en SQL Server, esa es la identidad que se usa para realizar llamadas a SQL Server.

Para obtener más información, vea Servicios WCF y ASP.NET (https://go.microsoft.com/fwlink/?LinkId=183163).

Orientación sobre la autenticación

Para habilitar la autenticación de IIS de una aplicación:

Use el modo de compatibilidad ASP
Use un enlace WCF basado en HTTP que sea compatible con el modo de seguridad de transporte (basicHttpBinding, wsHttpBinding y wsFederationHttpBinding)

Una vez cumplidos estos requisitos, configure IIS y el servicio .NET Framework hospedado para usar el IIS compatible y la configuración de seguridad de WCF. Configure los distintos valores de seguridad de la aplicación para que coincidan con la seguridad y los enlaces de todos los servicios. Si se especifica un esquema diferente, se provocará un error de activación del servicio WCF. Los modos de seguridad de WCF (en este caso, el modo de seguridad de transporte) se especifican en los elementos de enlace. Deben ser compatibles con la autenticación, para garantizar que los valores de seguridad de WCF que elija sean compatibles con la configuración de IIS. El transporte se asigna al modo de autenticación de WCF configurado para el enlace. El servicio dicta el modo de autenticación mediante la configuración de enlace, y el cliente WCF debe cumplirlo en el archivo de configuración. El cliente debe configurarse para proporcionar la forma apropiada de credenciales de cliente, para que sea compatible con el esquema de autenticación proporcionado por el servicio. Puesto que AppFabric no proporciona un elemento de UI para realizar este tipo de cambios, debe hacerlo manualmente en el archivo Web.config correspondiente.

Seguridad Nota
wsDualHttpBinding sólo es compatible con la seguridad basada en mensajes, de modo que no puede usarse si se usa la autenticación de IIS en los servicios.

2012-03-05

Compartir a través de