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 WCF Data Services 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 WCF Data Services , 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

WCF Data Services 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 WCF Data Services . 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. Nota: de seguridad Se envían credenciales de autenticación básica (nombre de usuario y contraseña) sin cifrado y se pueden interceptar. La autenticación implícita envía un hash basado en las credenciales proporcionadas. De esta forma, la protección es mayor que la de la autenticación básica. Ambas son susceptibles de sufrir ataques de tipo " Man in the middle". Cuando se usan estos métodos de autenticación, debe plantearse la comunicación cifrada entre el cliente y el servicio de datos mediante el uso de la Capa de sockets seguros (SSL). 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 WCF Data Services , 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 WCF Data Services , 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. Nota: de seguridad De forma predeterminada, la cookie que contiene el vale de autenticación de formularios no está protegido cuando use la autenticación de formularios en una aplicación web de ASP.NET. Debe plantearse exigir SSL para proteger tanto el vale de autenticación como las credenciales de inicio de sesión iniciales. Para obtener un ejemplo de cómo usar la autenticación de formularios con WCF Data Services , 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 WCF Data Services , vea la entrada de blog relacionada con OData y OAuth del programa OData y autenticación.

Autenticación de la biblioteca cliente

De forma predeterminada, la biblioteca de cliente de WCF Data Services 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, WCF Data Services 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 permiten tomar decisiones de autorización basadas en el usuario autenticado que realiza 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. WCF Data Services 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 WCF Data Services nunca analiza ni devuelve cookies. La biblioteca cliente de WCF Data Services tampoco procesa las cookies enviadas en la respuesta.

Requisitos personalizados de hospedaje

De forma predeterminada, WCF Data Services 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 WCF Data Services 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 WCF Data Services 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 WCF Data Services . 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 WCF Data Services 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.

Vea también

Otros recursos

Definir WCF Data Services
Biblioteca de cliente de WCF Data Services