Proteger WCF Data Services
En este tema se describen consideraciones de seguridad específicas del desarrollo. de la implementación y la ejecución de Servicios de datos de Microsoft WCF y de aplicaciones que acceden a servicios compatibles con Open Data Protocol (OData). También debe seguir las recomendaciones para crear aplicaciones de .NET Framework seguras.
Cuando planee cómo proteger un servicio de OData basado en Servicios de datos de Microsoft WCF, debe tratar tanto la autenticación, el proceso para detectar y comprobar la identidad de una entidad de seguridad, como la autorización, el proceso para determinar si una entidad de seguridad autenticada puede acceder a los recursos solicitados. También debe plantearse si va a cifrar el mensaje mediante SSL.
Autenticar las solicitudes de clientes
Servicios de datos de Microsoft WCF no implementa ningún tipo de autenticación proprio, sino que confía en las medidas de autenticación del host de servicio de datos. Es decir, el servicio asume que cualquier solicitud recibida ya la ha autenticado el host de red y que este ha identificado correctamente la entidad de seguridad para la solicitud adecuadamente a través de las interfaces proporcionadas por Servicios de datos de Microsoft WCF. Estas opciones de autenticación y los distintos enfoques se describen en el Programa sobre OData y autenticación.
Opciones de autenticación para un servicio de datos de WCF
En la siguiente tabla se enumeran algunos de los mecanismos de autenticación disponibles para ayudar al usuario a autenticar solicitudes en el servicio de datos de WCF.
Opciones de autenticación |
Descripción |
||
|---|---|---|---|
Autenticación anónima |
Cuando está habilitada la autenticación HTTP anónima, cualquier entidad de seguridad puede conectarse al servicio de datos. No se necesitan credenciales para el acceso anónimo. Use esta opción solo cuando desee permitir a alguien el acceso al servicio de datos. |
||
Autenticación básica e implícita |
Se necesitan credenciales formadas por un nombre de usuario y una contraseña para la autenticación. Admite autenticación de clientes que no sean de Windows.
Microsoft Internet Information Services (IIS) proporciona una implementación de la autenticación tanto básica como implícita para solicitudes HTTP en una aplicación ASP.NET. Esta implementación del proveedor de autenticación de Windows permite que una aplicación cliente de .NET Framework proporcione credenciales en el encabezado HTTP de la solicitud al servicio de datos para negociar sin ningún problema la autenticación de un usuario de Windows. Para obtener más información, vea Referencia técnica de autenticación implícita. Cuando desee que el servicio de datos use la autenticación básica basada en algún servicio de autenticación personalizado y no en las credenciales de Windows, debe implementar un módulo HTTP de ASP.NET personalizado para autenticación. Para obtener un ejemplo de cómo usar un esquema personalizado de autenticación básica con Servicios de datos de Microsoft WCF, vea la entrada de blog relacionada con la autenticación básica personalizada del programa de OData y autenticación. |
||
Autenticación de Windows |
Las credenciales basadas en Windows se intercambian mediante el uso de NTLM o Kerberos. Este mecanismo es más seguro que la autenticación básica o implícita, pero requiere que el cliente sea una aplicación basada en Windows. IIS también proporciona una implementación de autenticación de Windows para solicitudes HTTP en una aplicación de ASP.NET. Para obtener más información, vea ASP.NET Forms Authentication Overview. Para obtener un ejemplo de cómo usar la autenticación de Windows con Servicios de datos de Microsoft WCF, vea la entrada de blog relacionada con la autenticación de Windows del programa de OData y autenticación. |
||
Autenticación de formularios de ASP.NET |
La autenticación de formularios permite autenticar a los usuarios mediante su propio código y, a continuación, conservar un token de autenticación en una cookie o en la dirección URL de la página. Autentique el nombre de usuario y la contraseña de los usuarios que usen un formulario de inicio de sesión que cree. Las solicitudes no autenticadas se redirigen a una página de inicio de sesión, en la que el usuario proporciona las credenciales y envía el formulario. Si la aplicación autentica la solicitud, el sistema emite un vale que contiene una clave con el fin de restablecer la identidad para posteriores solicitudes. Para obtener más información, vea Forms Authentication Provider.
Para obtener un ejemplo de cómo usar la autenticación de formularios con Servicios de datos de Microsoft WCF, vea la entrada de blog relacionada con la autenticación de formularios del programa de OData y autenticación. |
||
Autenticación basada en notificaciones |
En la autenticación basada en notificaciones, el servicio de datos confía en un servicio de proveedor de identidad de “terceros” de confianza para autenticar al usuario. El proveedor de identidad autentica positivamente al usuario que solicita acceso a los recursos del servicio de datos y emite un token que concede acceso a los recursos solicitados. A continuación, este token se presenta en el servicio de datos, que concede acceso al usuario basándose en la relación de confianza con el servicio de identidad que emitió el token de acceso. La ventaja de usar un proveedor de autenticación basado en notificaciones es que se pueden usar para autenticar distintos tipos de clientes en dominios de confianza. Si se usan tales proveedores de terceros, un servicio de datos puede descargar los requisitos de mantenimiento y autenticación de usuarios. OAuth 2.0 es un protocolo de autenticación basado en notificaciones compatible con el Control de acceso de AppFabric de Windows Azure para autorización federada como servicio. Este protocolo admite servicios basados en REST. Para obtener un ejemplo de cómo usar OAuth 2.0 con Servicios de datos de Microsoft WCF, vea la entrada de blog relacionada con OData y OAuth del programa de OData y autenticación. |
.gif "Nota de seguridad")
Nota de seguridadAutenticación de la biblioteca cliente
De forma predeterminada, la biblioteca de cliente de Servicios de datos de Microsoft WCF no proporciona credenciales cuando se realiza una solicitud a un servicio de OData. Cuando el servicio de datos necesita credenciales de inicio de sesión para autenticar a un usuario, estas credenciales se puedan proporcionar en una clase NetworkCredential a la que se accede desde la propiedad Credentials de la clase DataServiceContext, como en el ejemplo siguiente:
' Set the client authentication credentials.
context.Credentials = _
New NetworkCredential(userName, password, domain)
// Set the client authentication credentials.
context.Credentials =
new NetworkCredential(userName, password, domain);
Para obtener más información, vea Cómo: especificar las credenciales de cliente para una solicitud de servicio de datos (Servicio de datos de WCF).
Cuando el servicio de datos necesite credenciales de inicio de sesión que no se puedan especificar mediante el uso de un objeto NetworkCredential, como un token basado en notificaciones o una cookie, debe establecer manualmente los encabezados en la solicitud HTTP, que suelen ser los encabezados Authorization y Cookie. Para obtener más información sobre este tipo de escenario de autenticación, vea la entrada de blog relacionada con OData y autenticación: enlaces del lado cliente. Para obtener un ejemplo de cómo establecer encabezados HTTP en un mensaje de solicitud, vea Cómo: establecer los encabezados en la solicitud de cliente (Servicios de datos de WCF).
Suplantación
Por lo general, el servicio de datos accede a los recursos necesarios, como los archivos del servidor o de la base de datos, mediante el uso de las credenciales del proceso de trabajo que hospeda el servicio de datos. Al usar la suplantación, las aplicaciones ASP.NET se pueden ejecutar con la identidad de Windows (cuenta de usuario) del usuario que realiza la solicitud. La suplantación se suele usar en aplicaciones que confían en IIS para autenticar al usuario y las credenciales de esta entidad de seguridad se usan para obtener acceso a los recursos necesarios. Para obtener más información, vea ASP.NET Impersonation.
Configurar la autorización del servicio de datos
La autorización es la concesión de acceso a los recursos de la aplicación a una entidad de seguridad o a un proceso que se identifique basándose en una autenticación correcta previa. Como regla general, solo debe conceder los derechos estrictamente necesarios a los usuarios del servicio de datos para realizar las operaciones que necesiten las aplicaciones cliente.
Restringir el acceso a los recursos del servicio de datos
De forma predeterminada, Servicios de datos de Microsoft WCF permite conceder acceso común de lectura y escritura a los recursos del servicio de datos (conjunto de entidades y operaciones de servicio) a cualquier usuario que pueda acceder al servicio de datos. Las reglas que definen el acceso de lectura y escritura se pueden definir por separado para cada conjunto de entidades expuesto por el servicio de datos, así como a las operaciones de servicio. Se recomienda limitar el acceso tanto de lectura como de escritura a solo los recursos que necesite la aplicación cliente. Para obtener más información, vea Configuring the Data Service (WCF Data Services).
Implementar interceptores basados en roles
Los interceptores permiten interceptar solicitudes en los recursos del servicio de datos antes de que actúe en ellos dicho servicio. Para obtener más información, vea Interceptores (WCF Data Services). Los interceptores le permiten tomar decisiones de autorización basadas el usuario autenticado que está realizando la solicitud. Para obtener un ejemplo de cómo restringir el acceso a los recursos del servicio de datos basándose en la identidad de un usuario autenticado, vea Cómo: Interceptar mensajes del servicio de datos (WCF Data Services).
Restringir el acceso al almacén de datos persistentes y a los recursos locales
A las cuentas que se usan para acceder al almacén persistente se les deben conceder solo los derechos estrictamente necesarios en una base de datos o en el sistema de archivos para admitir los requisitos del servicio de datos. Cuando se usa la autenticación anónima, se trata de la cuenta usada para ejecutar la aplicación de hospedaje. Para obtener más información, vea Cómo: Desarrollar un servicio de datos WCF que se ejecuta en IIS. Cuando se usa la suplantación, a los usuarios autenticados se les debe conceder acceso a estos recursos, normalmente como parte de un grupo de Windows.
Otras consideraciones de seguridad
Proteger los datos de la carga
OData se basa en el protocolo HTTP. En un mensaje HTTP, el encabezado puede contener valiosas credenciales de usuario, en función de la autenticación implementada por el servicio de datos. El cuerpo del mensaje también puede contener datos valiosos de clientes que se deben proteger. En ambos casos, se recomienda que use SSL para proteger esta información a través de la conexión.
Cookies y encabezados del mensaje ignorados
Los encabezados de solicitudes HTTP, que no sean los que declaran los tipos de contenido y las ubicaciones de los recursos, se ignoran y nunca los establece el servicio de datos.
Las cookies se pueden usar como parte de un esquema de autenticación, por ejemplo, con la autenticación de los formularios de ASP.NET. Servicios de datos de Microsoft WCF ignora, sin embargo, las cookies HTTP establecidas en una solicitud entrante. El host de un servicio de datos puede procesar la cookie, pero el tiempo de ejecución de Servicios de datos de Microsoft WCF nunca analiza ni devuelve cookies. La biblioteca cliente de Servicios de datos de Microsoft WCF tampoco procesa las cookies enviadas en la respuesta.
Requisitos personalizados de hospedaje
De forma predeterminada, Servicios de datos de Microsoft WCF se crea como aplicación de ASP.NET hospedada en IIS. De esta forma, el servicio de datos puede sacar provecho de los comportamientos seguros de esta plataforma. Puede definir los Servicios de datos de Microsoft WCF hospedados por un host personalizado. Para obtener más información, vea Hospedar el servicio de datos (WCF Data Services). Los componentes y la plataforma que hospedan un servicio de datos deben asegurar los siguientes comportamientos de seguridad para impedir ataques contra el servicio de datos:
Limitar la longitud del URI aceptada en una solicitud del servicio de datos para todas las operaciones posibles.
Limitar el tamaño de los mensajes HTTP tanto entrantes como salientes.
Limitar el número total de solicitudes pendientes en cualquier momento dado.
Limitar la longitud de los encabezados HTTP y sus valores, así como proporcionar acceso a Servicios de datos de Microsoft WCF a los datos del encabezado.
Detectar y contraatacar los ataques conocidos, como ataques SYN de TCP y de reproducción de mensajes.
Los valores ya no se codifican
Los valores de propiedad enviados al servicio de datos ya no los codifica el tiempo de ejecución de Servicios de datos de Microsoft WCF. Por ejemplo, cuando una propiedad de cadena de una entidad contiene contenido HTML con formato, el servicio de datos no codifica las etiquetas en HTML. Además, el servicio de datos ya no codifica los valores de propiedad de la respuesta. Asimismo, la biblioteca cliente ya no efectúa ningún tipo de codificación adicional.
Consideraciones sobre aplicaciones cliente
Las consideraciones de seguridad siguientes se aplican a las aplicaciones que usan el cliente de Servicios de datos de Microsoft WCF para acceder a los servicios de OData:
La biblioteca cliente asume que los protocolos usados para acceder al servicio de datos proporcionan un nivel de seguridad adecuado.
La biblioteca cliente usa todos los valores predeterminados para las opciones de tiempos de espera y de análisis de las pilas de transporte proporcionadas por la plataforma subyacente.
La biblioteca cliente no lee la configuración a partir de los archivos de configuración de la aplicación.
La biblioteca cliente no implementa los mecanismos de acceso entre dominios. En su lugar, confía en los mecanismos proporcionados por la pila HTTP subyacente.
La biblioteca cliente no dispone de elementos de interfaz de usuario y nunca intenta mostrar o presentar los datos que recibe o envía.
Se recomienda que las aplicaciones cliente siempre validen la entrada del usuario, así como los datos aceptados de servicios que no sean de confianza.