Download - Asegura Webservices

De la seguridad en Servicios Web para .Net

Este escrito se centra en la seguridad de los servicios Web en el nivel de la plataforma, mediante las características subyacentes de IIS y ASP.NET. Para la seguridad de los mensajes, Microsoft está desarrollando el kit de desarrollo de servicios Web, que permite generar soluciones de seguridad conforme a la especificación WS-Security, que forma parte de la iniciativa Global XML Architecture (GXA).

Contenido Modelo de seguridad para los servicios Web

Arquitectura de seguridad para plataformas/transporte

Estrategias de autenticación y autorización

Configurar la seguridad

Transmitir credenciales para la autenticación de servicios Web

Transferir el llamador original

Subsistema de confianza

Obtener acceso a recursos del sistema

Obtener acceso a recursos de red

Obtener acceso a los objetos COM

Utilizar certificados de cliente con los servicios Web

Comunicación segura

Resumen

En este capítulo se describe cómo desarrollar y aplicar las técnicas de autenticación, autorización y comunicación seguras para proteger los servicios Web de ASP.NET y los mensajes de los servicios Web. También se describe la seguridad desde el punto de vista de los servicios Web y se explica cómo autenticar y autorizar los llamadores, además de cómo transferir el contexto de seguridad a través de los servicios Web. Encontrará también información, desde la perspectiva del cliente, para llamar a los servicios Web mediante credenciales y certificados para admitir la autenticación por parte del servidor.

Modelo de seguridad para los servicios Web La seguridad de los servicios Web puede aplicarse en tres niveles distintos:

� Seguridad (de punto a punto) para plataformas/transporte

� Seguridad (personalizada) para aplicaciones

� Seguridad (de extremo a extremo) para mensajería

Cada enfoque ofrece una serie de beneficios y desventajas, que se detallan a continuación. La elección del enfoque depende en gran medida de las características de la arquitectura y las plataformas que vayan a utilizarse para el intercambio de los mensajes.

Nota: tenga en cuenta que este capítulo se centra en la seguridad de plataformas y aplicaciones. La seguridad de los mensajes se efectúa mediante la iniciativa de arquitectura de servicios Web XML global (GXA) y, en especial, la especificación de seguridad WS-Security. Durante el período de escritura de este documento, Microsoft ha lanzado una versión de tecnología de prueba de Web Services Development Kit (WSDK). De este modo podrá desarrollar soluciones de seguridad para mensajería conformes a la especificación de seguridad WS-Security. Si desea obtener más información, consulte http://msdn.microsoft.com/webservices/building/wsdk/ (en inglés).

Seguridad (de punto a punto) para plataformas/transporte Puede utilizarse el canal de transporte entre dos puntos finales (cliente de servicios Web y servicios Web) para garantizar la seguridad de punto a punto. La ilustración 10.1 refleja este escenario.

{Insert figure: CH10 – Web Services Security – Transport Level.gif}

Ilustración 10.1 Seguridad para plataformas/transporte

Cuando se utiliza la seguridad de plataformas, que presupone un entorno de sistema operativo Microsoft® Windows® estrechamente integrado, por ejemplo, en intranets corporativas:

� El servidor Web (IIS) proporciona autenticación básica, implícita, integrada y mediante certificados.

� El Servicio Web de ASP.NET hereda algunas funciones de autenticación y autorización de ASP.NET.

� Puede utilizarse SSL y/o IPSec para aplicar capacidades de integridad y confidencialidad para los mensajes.

Escenarios de uso El modelo de seguridad para transporte es sencillo, bien diseñado y adecuado para una gran variedad de escenarios (básicamente para intranets), en los que los

mecanismos de transporte y la configuración del punto final pueden controlarse de forma exhaustiva.

Los principales aspectos que deben tenerse en cuenta con relación a la seguridad del transporte son los siguientes:

� La seguridad se integra estrechamente con la plataforma subyacente, el mecanismo de transporte y el proveedor de servicios de seguridad (NTLM, Kerberos, etc.), de los que también depende.

� La seguridad se aplica de punto a punto, sin crear provisiones para saltos múltiples ni enrutamiento a través de nodos de aplicación intermedios.

Seguridad para aplicaciones Con este enfoque, la aplicación se hace cargo de la seguridad y utiliza las funciones de seguridad personalizadas. Por ejemplo:

� Una aplicación puede utilizar un encabezado SOAP personalizado para transferir las credenciales de usuario y autenticar al usuario con cada solicitud de Servicio Web. Un enfoque habitual consiste en transferir un vale (o nombre de usuario o licencia) con el encabezado SOAP.

� La aplicación tiene la flexibilidad de generar su propio objeto IPrincipal con funciones incluidas. Puede ser una clase personalizada o la clase GenericPrincipal que se proporciona con .NET Framework.

� La aplicación cifra de forma selectiva lo que sea necesario, aunque requiere un almacenamiento seguro de la clave y que los desarrolladores tengan conocimientos de las API de criptografía pertinentes. Una técnica alternativa consiste en utilizar SSL para ofrecer confidencialidad e integridad, además de combinar SSL con encabezados SOAP personalizados para llevar a cabo la autenticación.

Escenarios de uso Utilice este enfoque si:

� Desea aprovechar un esquema existente de base de datos de usuarios y funciones que se utiliza con la aplicación actual.

� Desea cifrar partes de un mensaje en lugar de la cadena de datos completa.

Seguridad (de extremo a extremo) para mensajería Se trata del enfoque más flexible y eficaz y el que utiliza la iniciativa GXA, en especial para la especificación de seguridad WS-Security. La seguridad de mensajes queda esbozada en la ilustración 10.2.

{Insert figure: CH10 - Web Services Security Message Level.gif}

Ilustración 10.2 Seguridad de mensajes

Las especificaciones de seguridad WS-Security describen las mejoras realizadas en la mensajería SOAP y que permiten disfrutar de integridad, confidencialidad y autenticación para los mensajes.

� La autenticación se obtiene mediante testigos de seguridad, que se transfieren en encabezados SOAP. La especificación de seguridad WS-Security no requiere ningún tipo de testigo específico. Los testigos de seguridad pueden incluir vales Kerberos, certificados X.509 o un testigo binario personalizado.

� La comunicación segura se obtiene mediante firmas digitales que garantizan la integridad de los mensajes y el cifrado XML para la confidencialidad de los mensajes.

Escenarios de uso La especificación de seguridad WS-Security puede utilizarse para crear un marco de intercambio de mensajes seguros en un entorno de servicios Web heterogéneo. Resulta idónea para entornos y escenarios heterogéneos en los que no se detenta el control directo ni de la configuración de los puntos finales ni de los nodos de aplicación intermedios.

Seguridad de mensajes:

� Puede ser independiente del transporte subyacente.

� Permite una arquitectura de seguridad heterogénea.

� Proporciona seguridad de extremo a extremo y permite el enrutamiento de mensajes a través de nodos de aplicación intermedios.

� Admite varias tecnologías de cifrado.

� Admite el método de no rechazo.

Web Services Development Kit (WSDK) Web Services Development Kit ofrece las API necesarias para administrar la seguridad, además de otros servicios tales como referencias de enrutamiento y de mensajes. Este kit cumple los estándares más recientes de los servicios Web como la especificación de seguridad WS-Security, lo cual permite la interoperabilidad con otros proveedores que aplican las mismas especificaciones.

Más información � Para obtener las últimas novedades acerca de Web Services Development Kit

y la especificación de seguridad WS-Security, consulte la página del centro de desarrolladores XML de MSDN en http://msdn.microsoft.com/webservices/ (en inglés).

� Para obtener más información acerca de la especificación de seguridad WS-Security, consulte la página de índice de la especificación de seguridad WS-Security en http://msdn.microsoft.com/webservices/default.asp?pull=/library/en-us/dnglobspec/html/wssecurspecindex.asp (en inglés).

� Para obtener más información acerca de la arquitectura GXA, consulte el artículo "Understanding GXA" (en inglés) de MSDN.

� Para obtener acceso a las discusiones del tema, consulte el grupo de noticias de interoperabilidad GXA en MSDN.

Arquitectura de seguridad para plataformas/transporte

La ilustración 10.3 muestra la arquitectura de seguridad de la plataforma de servicios Web de ASP.NET.

{Insert figure: CH10 - Web Services Security Architecture.gif}

Ilustración 10.3 Arquitectura de seguridad de servicios Web

La ilustración 10.3 muestra los mecanismos de autenticación y autorización que incluyen los servicios Web de ASP.NET. Cuando un cliente llama a un servicio Web, se desencadena la siguiente secuencia de eventos de autenticación y autorización:

1. Se recibe la solicitud SOAP de la red. Dicha solicitud puede o no contener credenciales de autenticación, lo que depende del tipo de autenticación que se esté utilizando.

2. Opcionalmente, IIS autentica al llamador mediante la autenticación básica, implícita, integrada (NTLM o Kerberos) o mediante certificados. En entornos heterogéneos en los que no es posible aplicar la autenticación de IIS (Windows), IIS se configura para la autenticación anónima. En este escenario, el cliente puede autenticarse mediante atributos de los mensajes tales como vales transferidos a través del encabezado SOAP.

3. IIS también puede configurarse para que acepte solicitudes únicamente de los equipos cliente con unas direcciones IP específicas.

4. IIS transfiere el testigo de acceso a Windows del llamador autenticado a ASP.NET (que puede ser el testigo de acceso del usuario de Internet anónimo si se ha configurado el servicio Web para la autenticación anónima).

5. ASP.NET autentica al llamador. Cuando ASP.NET se configura para la autenticación de Windows, no se efectúa ningún otro tipo de autenticación adicional en esta etapa e IIS se limita a autenticar al llamador. En caso de utilizare un método de autenticación distinto de Windows, el modo de autenticación de ASP.NET se establece en ninguno a fin de permitir la autenticación personalizada.

Nota: la autenticación mediante Formularios y la autenticación de Passport no son compatibles con los servicios Web.

6. ASP.NET autoriza el acceso al servicio Web solicitado (archivo .asmx) mediante la autorización de direcciones URL y de archivos, que utilizan los permisos NTFS asociados con el archivo .asmx para determinar si debe concederse el acceso al llamador autenticado.

Nota: la autorización de archivos sólo es compatible para la autenticación de Windows.

A fin de disfrutar de una autorización de granularidad precisa, también pueden utilizarse las funciones .NET (mediante declaraciones o programación) para garantizar que el llamador reciba autorización para obtener acceso al recurso solicitado o para llevar a cabo la operación solicitada.

7. El código del servicio Web obtiene acceso a los recursos locales o remotos mediante una identidad determinada. De forma predeterminada, los servicios Web de ASP.NET no llevan a cabo ninguna suplantación, por lo que es la cuenta de proceso ASP.NET configurada la que proporciona la identidad. Otras opciones alternativas incluyen la identidad del llamador original o una identidad de servicio configurada.

Equipos selectores Los equipos selectores del servicio Web de ASP.NET son:

� IIS

� Si se deshabilita la autenticación anónima de IIS, los servicios IIS sólo permitirán solicitudes de usuarios autenticados.

� Restricciones de dirección IP IIS puede configurarse para que acepte solicitudes únicamente de equipos con unas direcciones IP específicas.

� ASP.NET

� El módulo HTTP de autorización de archivos (exclusivamente para la autenticación de Windows)

� El módulo HTTP de autorización mediante direcciones URL

� Peticiones de permisos Principal y comprobaciones de funciones explícitas

Más información � Para obtener más información acerca de los equipos selectores, consulte

"Equipos selectores" en el capítulo 8, "Seguridad de ASP.NET". � Para obtener más información acerca de cómo configurar la seguridad,

consulte el apartado "Configurar la seguridad" que figura más adelante en este mismo capítulo.

Estrategias de autenticación y autorización En esta sección se exponen las opciones de autorización (tanto configurables como programáticas) disponibles para un conjunto de esquemas de autenticación utilizados de forma habitual.

Los esquemas de autenticación que van a describirse se indican a continuación:

� Autenticación de Windows con suplantación

� Autenticación de Windows sin suplantación

� Autenticación de Windows con identidad fija

Autenticación de Windows con suplantación Los siguientes elementos de configuración muestran cómo habilitar la autenticación de Windows (IIS) y la suplantación mediante declaraciones en los archivos Web.config o Machine.config.

Nota: es recomendable configurar la autenticación en función de cada servicio Web en el archivo Web.config del servicio Web correspondiente.

<authentication mode="Windows" />

<identity impersonate="true" />

Con esta configuración, el código del servicio Web suplanta al llamador autenticado por IIS. Para suplantar al llamador original es preciso desactivar el acceso anónimo en IIS. En caso de utilizar el acceso anónimo, el código del servicio Web suplanta la cuenta de usuario de Internet anónimo (que, de manera predeterminada, es IUSR_MACHINE).

Seguridad configurable El empleo de la autenticación de Windows junto con la funcionalidad de suplantación ofrece las siguientes opciones de autorización:

� Listas ACL de Windows

� Archivo del servicio Web (.asmx). La autorización de archivos lleva a cabo comprobaciones de acceso para los recursos ASP.NET solicitados (que incluye el archivo del servicio Web .asmx) mediante el contexto de seguridad del llamador original. Es preciso que el llamador original reciba, como mínimo, acceso de lectura al archivo .asmx.

� Recursos a los que obtiene acceso el servicio Web. Las listas ACL de Windows de los recursos a los que obtiene acceso el servicio Web (archivos, carpetas, claves de registro, objetos de servicio del directorio Active Directory®, etc.) deben incluir una entrada de control de acceso (ACE) que conceda acceso de lectura al llamador original (puesto que el subproceso del servicio Web utilizado para el acceso a los recursos ejecuta la suplantación del llamador).

� Autorización mediante direcciones URL. Se configura en el archivo Machine.config o Web.config. Con la autenticación de Windows, los nombres de usuario adoptan la forma DomainName\UserName (NombreDominio\NombreUsuario) y las funciones se asignan una a una a los grupos de Windows.

<authorization>

<deny user="DomainName\UserName" />

<allow roles="DomainName\WindowsGroup" />

</authorization>

Seguridad mediante programación La seguridad mediante programación hace referencia a las comprobaciones de seguridad ubicadas en el código del servicio Web. Las siguientes opciones de seguridad mediante programación están disponibles cuando se utilizan la autenticación de Windows y la suplantación.

� Peticiones de permisos Principal � Imperativas (en las líneas del código de un método)

PrincipalPermission permCheck = new PrincipalPermission(

null, @"DomainName\WindowsGroup");

permCheck.Demand();

� Declarativas (estos atributos pueden figurar antes de los métodos o las clases Web)

// Demand that the caller is a member of a specific role (for Windows

// authentication this is the same as a Windows group)

[PrincipalPermission(SecurityAction.Demand,

Role=@"DomainName\WindowsGroup)]

// Demand that the caller is a specific user


Name=@"DomainName\UserName")]

� Comprobaciones de funciones explícitas. Puede realizar la comprobación de funciones mediante la interfaz IPrincipal.

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

Escenarios de uso Utilice la autenticación de Windows y la suplantación cuando se den las siguientes condiciones:

� Los clientes del servicio Web pueden identificarse mediante cuentas de Windows, que a su vez puede autenticar el servidor.

� Debe transferirse el contexto de seguridad del llamador original al siguiente nivel a través del servicio Web. Por ejemplo, a un conjunto de componentes revisados que utilizan funciones de Servicios Empresariales (COM+) o a un nivel de datos que precisa autorización de granularidad fina (por usuario).

� Debe transferir el contexto de seguridad del llamador original a los niveles indirectos a fin de admitir la auditoría de nivel del sistema operativo.

Importante: el uso de la suplantación reduce la escalabilidad porque incide en la agrupación de conexiones de bases de datos. A modo de enfoque alternativo, es recomendable plantearse la posibilidad de utilizar un modelo de subsistema de confianza en el que el servicio Web autorice a los llamadores y, a continuación, utilice una identidad fija para obtener el acceso a la base de datos. La identidad del llamador se transfiere desde la aplicación; por ejemplo, mediante los parámetros de procedimiento almacenados.

Más información � Si desea obtener más información acerca de la autenticación de Windows y la

suplantación, consulte el capítulo 8 "Seguridad de ASP.NET".

� Para obtener más información acerca de la autorización mediante direcciones URL, consulte "Notas acerca de la autorización mediante direcciones URL" en el capítulo 8, "Seguridad de ASP.NET".

Autenticación de Windows sin suplantación Los siguientes elementos de configuración muestran cómo habilitar la autenticación de Windows (IIS) sin suplantación de forma declarativa en el archivo Web.config.




<identity impersonate="false" />

Seguridad configurable El empleo de la autenticación de Windows sin la suplantación ofrece las siguientes opciones de autorización:

� Listas ACL de Windows

� Archivo del servicio Web (.asmx). La autorización de archivos lleva a cabo comprobaciones de acceso para los recursos ASP.NET solicitados (que incluye el archivo del servicio Web .asmx) mediante el llamador original. No se requiere la suplantación.

� Recursos a los que obtiene acceso la aplicación. Las listas ACL de Windows de los recursos a las que obtiene acceso la aplicación (archivos, carpetas, claves de registro, objetos de Active Directory) deben incluir una entrada ACE que conceda acceso de lectura a la identidad del proceso de ASP.NET (la identidad predeterminada que utiliza el subproceso del servicio Web para obtener acceso a los recursos).

� Autorización de URL Se configura en los archivos Machine.config y Web.config. Con la autenticación de Windows, los nombres de usuario adoptan la forma DomainName\UserName (NombreDominio\NombreUsuario) y las funciones se asignan una a una a los grupos de Windows.

<authorization>

<deny user="DomainName\UserName" />

<allow roles="DomainName\WindowsGroup" />

</authorization>

Seguridad mediante programación La seguridad mediante programación hace referencia a las comprobaciones de seguridad ubicadas en el código del servicio Web. Las siguientes opciones de seguridad mediante programación están disponibles cuando se utiliza la autenticación de Windows sin suplantación.

� Peticiones de permisos Principal � Imperativas

PrincipalPermission permCheck = new PrincipalPermission(

null, @"DomainName\WindowsGroup");

permCheck.Demand();

� Declarativas

// Demand that the caller is a member of a specific role (for Windows

// authentication this is the same as a Windows group)


Role=@"DomainName\WindowsGroup)]

// Demand that the caller is a specific user


Name=@"DomainName\UserName")]

� Comprobaciones de funciones explícitas. Puede realizar la comprobación de funciones mediante la interfaz IPrincipal.

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

Escenarios de uso Utilice la autenticación de Windows sin suplantación cuando se den las siguientes condiciones:

� Los clientes del servicio Web pueden identificarse mediante cuentas de Windows, que a su vez puede autenticar el servidor.

� Desea utilizar el modelo de subsistema de confianza y autorizar a los clientes desde el servicio Web para, a continuación, utilizar una identidad fija para obtener acceso a los recursos indirectos (bases de datos por ejemplo) a fin de admitir la agrupación de conexiones.




Autenticación de Windows con identidad fija El elemento <identity> del archivo Web.config es compatible con los atributos opcionales de nombre de usuario y contraseña, lo cual le permite configurar una identidad fija específica para que la suplante el servicio Web. Este enfoque se muestra en el siguiente fragmento del archivo de configuración.

<identity impersonate="true" userName="DomainName\UserName"

password="ClearTextPassword" />

Escenarios de uso No se recomienda el uso de este enfoque en entornos seguros por dos motivos:

� Los nombres de usuario y las contraseñas no deberían almacenarse en formato de texto sin cifrar en los archivos de configuración.

� En Windows 2000, este enfoque obliga a conceder a la cuenta de proceso ASP.NET el privilegio “Actuar como parte del sistema operativo”. De este modo se reduce la seguridad del servicio Web y aumenta el riesgo de

amenaza en caso de que un intruso pusiera en peligro el proceso del servicio Web (Aspnet_wp.exe).




Configurar la seguridad En esta sección encontrará los pasos que debe realizar para configurar la seguridad de un servicio Web ASP.NET. Dichos mecanismos se reflejan en la Ilustración 10.4.

{Insert figure: CH08 – Configuring ASP.NET Security.gif}

Ilustración 10.4 Configurar la seguridad de un servicio Web ASP.NET

Configurar los parámetros de IIS Para obtener información pormenorizada acerca de cómo configurar los parámetros de seguridad de IIS, consulte el apartado "Configurar la seguridad" del capítulo 8, "Seguridad de ASP.NET"; la información que encontrará es válida también para los servicios Web ASP.NET.

Configurar los parámetros de ASP.NET Los parámetros de configuración de la aplicación se almacenan en archivos Web.config, ubicados en el directorio raíz virtual del servicio Web. Es preciso configurar los siguientes parámetros:

1. Configure la autenticación. Debe establecerse para cada servicio Web (no en el archivo Machine.config) del archivo Web.config ubicado en el directorio raíz virtual del servicio Web.

<authentication mode="Windows|None" />

Nota: los servicios Web no son compatibles actualmente con la autenticación mediante Formularios y la autenticación de Passport. Si decide utilizar la autenticación personalizada o de mensajes, establezca el modo en ninguna.

2. Configure la suplantación y la autorización. Si desea obtener información detallada, consulte "Configurar la seguridad" en el capítulo 8, "Seguridad de ASP.NET."

Más información Para obtener más información acerca de la autorización mediante direcciones URL, consulte "Notas acerca de la autorización mediante direcciones URL" en el capítulo 8, "Seguridad de ASP.NET".

Proteger recursos Debería utilizar las mismas técnicas que se describen en el capítulo 8, "Seguridad de ASP.NET", para proteger los recursos Web Además, valore la posibilidad de eliminar los protocolos HTTP-GET y HTTP-POST del archivo Machine.config de los servidores de producción cuando utilice los servicios Web.

Deshabilitar HTTP-GET y HTTP-POST De forma predeterminada, los clientes se comunican con los servicios Web ASP.NET mediante tres protocolos: HTTP-GET, HTTP-POST y SOAP a través de HTTP. Deshabilite la compatibilidad para los protocolos HTTP-GET y HTTP-POST en el nivel de equipo de los equipos de producción en los que no sean necesarios. De esta forma conseguirá evitar posibles problemas de seguridad que podrían permitir que una página Web mal intencionada obtenga acceso a un servicio Web interno que se ejecute detrás de un servidor de seguridad.

Nota: deshabilitar estos protocolos implica que los clientes nuevos no podrán comprobar un servicio Web XML mediante el botón Invocar de la página de prueba del servicio Web. En su lugar, deberá crear un programa cliente de comprobación. Para hacerlo, agregue una referencia al servicio Web mediante el sistema de desarrollo Microsoft Visual Studio® .NET. Quizás desee mantener

habilitados estos protocolos en los equipos de desarrollo a fin de que los desarrolladores sean capaces de utilizar la página de comprobación.

�� Para deshabilitar los protocolos HTTP-GET y HTTP-POST en todo un equipo

1. Modifique el archivo Machine.config.

2. Elimine los comentarios de las líneas del elemento <webServices> que agregan compatibilidad para los protocolos HTTP-GET y HTTP-POST. Cuando haya acabado, el archivo Machine.config debería ofrecer el siguiente aspecto.

<webServices>

<protocols>

<add name="HttpSoap"/>





<add name="Documentation"/>

</protocols>

</webServices>

3. Guarde el archivo Machine.config.

Nota: en algunos casos especiales en los que clientes de servicios Web se comunican con un servicio Web que utiliza el protocolo HTTP-GET o HTTP-POST, es posible agregar la compatibilidad necesaria para dichos protocolos desde el archivo Web.config de la aplicación, con sólo crear un elemento <webServices> y agregar compatibilidad para los protocolos con los elementos <protocol> y <add>, tal como se ha mostrado anteriormente.

Más información Si desea obtener información detallada acerca de cómo proteger recursos, consulte "Proteger recursos" en el capítulo 8, "Seguridad de ASP.NET".

Comunicación segura Utilice una combinación de SSL e IPSec para proteger los vínculos de comunicación.

Más información � Para obtener información acerca de cómo llamar a un servicio Web mediante

SSL, consulte "Cómo llamar a un servicio Web con SSL" en la sección de referencia de este manual.

� Para obtener información acerca de cómo utilizar IPSec entre dos equipos, consulte "Cómo utilizar IPSec para garantizar una comunicación segura entre dos servidores" en la sección de referencia de este manual.

Transmitir credenciales para la autenticación de servicios Web

Las llamadas a los servicios Web se efectúan mediante un proxy de servicio Web, un objeto local que expone el mismo conjunto de métodos que el servicio Web de destino.

Puede generar un proxy de servicio Web mediante la utilidad de la línea de comandos Wsdl.exe. Si utiliza Visual Studio .NET también puede generar el proxy agregando una referencia Web al proyecto.

Nota: si el servicio Web para el que desea generar un proxy está configurado para requerir certificados de cliente, deberá deshabilitar temporalmente dicho requisito mientras agrega la referencia; de lo contrario se producirá un error. Una vez agregada la referencia, no olvide volver a configurar el servicio para que exija los certificados. Un enfoque alternativo consiste en mantener fuera de línea un archivo WSDL (Lenguaje de descripción de servicios Web) de los servicios Web para que esté disponible para las aplicaciones de consumidor. Es importante que recuerde actualizarlo si se modifica la interfaz del Servicio Web.

Especificar las credenciales de cliente para la autenticación de Windows El uso de la autenticación de Windows requiere especificar las credenciales que deben utilizarse para la autenticación mediante la propiedad Credentials del proxy de servicio Web. Si no establece esta propiedad de forma expresa, se efectuará la llamada al servicio Web sin utilizar credenciales. Cuando se requiere la autenticación de Windows, se generará un estado HTTP 401, de respuesta de acceso denegado.

Utilizar DefaultCredentials Las credenciales de cliente no se transfieren de forma implícita. Es el consumidor del servicio Web quien debe establecer las credenciales y los detalles de la autenticación en el proxy. Para transferir el contexto de seguridad del contexto de seguridad Windows del cliente (sea desde un testigo de subproceso suplantado sea desde un testigo de proceso) a un servicio Web, establezca la propiedad Credentials del proxy de servicio Web en CredentialCache.DefaultCredentials tal como se muestra a continuación.

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;

Tenga en cuenta los siguientes aspectos antes de utilizar este enfoque:

� Este método transfiere las credenciales del cliente únicamente cuando se utiliza la autenticación NTLM, Kerberos o negociada.

� Si una aplicación de cliente (por ejemplo, una aplicación de formularios de Windows) llama al servicio Web, las credenciales se obtendrán de la sesión de inicio de sesión interactiva del usuario.

� Las aplicaciones de servidor, como las aplicaciones Web de ASP.NET, utilizan la identidad de proceso, salvo que se haya configurado la suplantación, en cuyo caso se utiliza la identidad del llamador suplantado.

Utilizar credenciales específicas Para utilizar un conjunto específico de credenciales de autenticación para llamar a un servicio Web, utilice el siguiente código.

CredentialCache cache = new CredentialCache();

cache.Add( new Uri(proxy.Url), // Web service URL

"Negotiate", // Kerberos or NTLM

new NetworkCredential("username", "password", "domainname") );

proxy.Credentials = cache;

En este ejemplo, el tipo de autenticación negociada solicitada puede ser la autenticación Kerberos o NTLM.

Solicitar siempre un tipo de autenticación específica Es recomendable solicitar siempre un tipo de autenticación específico, tal como se muestra más arriba. Evite el uso directo de la clase NetworkCredential, como se refleja en el siguiente fragmento de código.

proxy.Credentials = new

NetworkCredential("username", "password", "domainname");

Este método debería evitarse en el código de producción porque se pierde el control del mecanismo de autenticación que utiliza el servicio Web y, como consecuencia, se pierde también el control con relación al uso de las credenciales.

Por ejemplo, es probable que se produzca un desafío de autenticación Kerberos o NTLM desde el servidor pero, en su lugar, recibirá un desafío básico. En este caso, el nombre de usuario y la contraseña proporcionados se enviarán al servidor en formato de texto no cifrado.

Establecer la propiedad PreAuthenticate La propiedad PreAuthenticate del proxy puede establecerse como verdadera o falsa. Establézcala en verdadera (true) para proporcionar las credenciales de autenticación específicas para generar un encabezado HTTP WWW-authenticate para transferir con la solicitud Web. Esta propiedad guarda la denegación de acceso del servidor Web en la solicitud y lleva a cabo la autenticación en la siguiente solicitud de reintento.

Nota: la preautenticación sólo se aplica cuando el servicio Web se autentica correctamente la primera vez. La preautenticación no tiene repercusión alguna en la primera solicitud Web.

private void ConfigureProxy( WebClientProtocol proxy,

string domain, string username,

string password )

{

// To improve performance, force pre-authentication

proxy.PreAuthenticate = true;

// Set the credentials


cache.Add( new Uri(proxy.Url),

"Negotiate",

new NetworkCredential(username, password, domain) );


proxy.ConnectionGroupName = username;

}

Utilizar la propiedad ConnectionGroupName Tenga en cuenta que el código anterior establece la propiedad ConnectionGroupName del proxy de servicio Web. Este paso sólo es necesario si el contexto de seguridad utilizado para la conexión con el servicio Web varía de una solicitud a la otra, tal como se describe a continuación.

Si trabaja con una aplicación Web de ASP.NET que se conecta a un servicio Web y transfiere el contexto de seguridad del llamador original (mediante DefaultCredentials o estableciendo las credenciales explícitas, como en el caso anterior), debería establecer la propiedad ConnectionGroupName del proxy de servicio Web de la aplicación Web. Con ello se consigue evitar que un cliente autenticado nuevo vuelva a utilizar una conexión TCP autenticada antigua para el servicio Web asociado con unas credenciales de autenticación de cliente anteriores. La reutilización de conexiones puede tener lugar tras un resultado HTTP KeepAlives y la persistencia de autenticación que se habilita por motivos de rendimiento en IIS.

Establezca la propiedad ConnectionGroupName en un identificador (como el nombre de usuario del llamador) que distinga un llamador del siguiente, tal como se muestra en el fragmento de código anterior.

Nota: si el contexto de seguridad del llamador original no se transfiere a través de la aplicación Web hasta el servicio Web sino que la aplicación Web se conecta al servicio Web mediante una identidad fija (como la identidad de proceso ASP.NET de la aplicación Web), no será necesario que establezca la propiedad ConnectionGroupName. En este escenario, el contexto de seguridad de conexión permanece constante de un llamador al siguiente.

Llamar a los servicios Web desde clientes que no sean de Windows Existen una serie de enfoques de autenticación que funcionan con los escenarios que implican varios exploradores. Entre ellos figuran:

� Autenticación mediante certificados. Mediante certificados X.509 para varias plataformas.

� Autenticación básica. Si desea obtener un ejemplo de cómo utilizar la autenticación básica con un almacén de datos personalizado (sin que sea necesario Active Directory), consulte http://www.rassoc.com/gregr/weblog/stories/2002/06/26/webServicesSecurityHttpBasicAuthenticationWithoutActiveDirectory.html (en inglés).

� Enfoques para mensajes GXA. Utilice Web Services Development Toolkit para implementar soluciones GXA (WS-Security).

� Enfoques personalizados. Por ejemplo, para transferir las credenciales mediante encabezados SOAP.

Autenticación de servidor proxy La autenticación de servidor proxy no se admite en el cuadro de diálogo Agregar referencia Web de Visual Studio .NET (aunque sí que será compatible en la siguiente versión de Visual Studio .NET). Como resultado puede producirse un estado de HTTP 407: "Autenticación proxy obligatoria" cuando intente agregar una referencia Web.

Nota: quizás no experimente este error si visualiza el archivo .asmx desde un explorador porque los exploradores envían las credenciales automáticamente.

Para solucionar este problema, utilice la utilidad de la línea de comandos Wsdl.exe (en vez del diálogo Agregar referencia Web), como se muestra a continuación.

wsdl.exe /proxy:http://<YourProxy> /pu:<YourName> /pp:<YourPassword>

/pd:<YourDomain> http://www.YouWebServer.com/YourWebService/YourService.asmx

Utilice el código presentado a continuación si necesita establecer mediante programación la información de autenticación del servidor proxy.

YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;

Transferir el llamador original En esta sección se describe cómo transferir el contexto de seguridad del llamador original a través de una aplicación Web de ASP.NET hasta un servicio Web ubicado en un servidor de aplicaciones remoto. Quizás necesite recurrir a este procedimiento para que un servicio Web sea compatible con la autorización por usuario, o bien próximos subsistemas indirectos (como bases de datos en las que se desee autorizar a los llamadores originales con relación a objetos de base de datos individuales).

La ilustración 10.5 refleja el contexto de seguridad del llamador original (Alice) y cómo se transfiere a través del servidor Web de cliente que aloja una aplicación Web de ASP.NET hasta el objeto remoto, alojado por ASP.NET en un servidor de aplicaciones remotas, y finalmente a través de un servidor de bases de datos de servidor.

{Insert figure: CH10 – Flowing original caller with Web Service.gif}

Ilustración 10.5 Transferir el contexto de seguridad del llamador original

Para transferir las credenciales a un servicio Web, el cliente del servicio Web (la aplicación Web de ASP.NET en este escenario en concreto) debe configurar el proxy de servicio Web y establecer de forma expresa la propiedad Credentials del proxy, como se describe en el apartado "Transmitir credenciales para la autenticación de servicios Web" que figura anteriormente en este capítulo.

Tiene a su disposición dos métodos para transferir el contexto del llamador.

� Transferir las credenciales predeterminadas y utilizar la autenticación Kerberos (y la delegación). Este enfoque requiere el uso de la suplantación en la aplicación Web de ASP.NET y la configuración del proxy de objeto remoto con el elemento DefaultCredentials obtenido del contexto de seguridad del llamador suplantado.

� Transferir las credenciales explícitas y utilizar la autenticación básica o mediante Formularios. Este enfoque no requiere el uso de funciones de suplantación en la aplicación Web de ASP.NET. En cambio, es preciso configurar programáticamente el proxy de servicio Web con credenciales explícitas obtenidas bien de variables de servidor (en el caso de la autenticación básica) bien de campos de formularios HTML (en el caso de la autenticación mediante Formularios) disponibles para la aplicación Web. Tanto para la autenticación básica como mediante Formularios, el nombre de usuario y la contraseña están disponibles en formato de texto sin cifrar.

Credenciales predeterminadas con delegación Kerberos Para utilizar la delegación Kerberos, todos los equipos (servidores y clientes) deben ejecutar Windows 2000 o versiones posteriores. Por otra parte, las cuentas de cliente que vayan a delegarse deberán almacenarse en Active Directory y no marcarse nunca como ”Confidencial y no se puede delegar”.

Las tablas que figuran a continuación muestran los pasos de configuración que deben llevarse a cabo en el servidor Web, así como en el servidor de aplicaciones.

Configurar el servidor Web Configurar IIS Paso Más información Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web Habilitar la autenticación integrada de Windows para el directorio raíz virtual de la aplicación Web

La autenticación Kerberos se negociará teniendo en cuenta que tanto los clientes como el servidor ejecutan Windows 2000 o versiones posteriores. Nota: si ya utiliza Internet Explorer 6 en Windows 2000, el valor predeterminado es la autenticación NTLM en vez de la autenticación Kerberos que se precisa en este contexto. Para habilitar la delegación Kerberos, consulte el artículo Q299838, "Unable to Negotiate Kerberos Authentication after upgrading to Internet Explorer 6" (en inglés) en la Knowledge Base de Microsoft.

Configurar ASP.NET Paso Más información Configurar la aplicación Web de ASP.NET para utilizar la autenticación de Windows

Modifique el archivo Web.config del directorio virtual de la aplicación Web. Establezca el elemento <authentication> como se indica a continuación:


Configurar la aplicación Web de ASP.NET para la suplantación

Modifique el archivo Web.config del directorio virtual de la aplicación Web. Establezca el elemento <identity> como se indica a continuación:


Configurar el proxy de servicio Web Paso Más información Establecer la propiedad de credenciales del proxy de servicio Web en DefaultCredentials.

Consulte el apartado "Utilizar DefaultCredentials" que figura más arriba en este capítulo para obtener muestras de código.

Configurar el servidor de aplicaciones remoto Configurar IIS Paso Más información

Deshabilitar el acceso anónimo para el directorio raíz virtual del servicio Web Habilitar la autenticación integrada de Windows para el directorio raíz virtual de la aplicación Web

Configurar ASP.NET (host del servicio Web) Paso Más información Configurar ASP.NET para utilizar la autenticación de Windows

Modifique el archivo Web.config del directorio virtual del servicio Web. Establezca el elemento <authentication> como se indica a continuación:


Configurar ASP.NET para la suplantación

Modifique el archivo Web.config del directorio virtual del servicio Web. Establezca el elemento <identity> como se indica a continuación:


Nota: este paso sólo es necesario si se desea transferir el contexto de seguridad del llamador original al siguiente nivel indirecto (una base de datos por ejemplo) a través del servicio Web. Si está habilitada la suplantación, el acceso a los recursos (tanto local como remoto) utilizará el contexto de seguridad del llamador original suplantado. Si sus necesidades se limitan a permitir comprobaciones de autorización por usuario en el servicio Web, no necesitará utilizar la suplantación.

Más información Para obtener más información acerca de cómo configurar la delegación Kerberos, consulte "Cómo implementar la delegación Kerberos para Windows 2000" en la sección de referencia de este manual.

Credenciales explícitas con autenticación básica o mediante Formularios Como alternativa a la delegación Kerberos, puede utilizar la autenticación básica o mediante Formularios en la aplicación Web para capturar las credenciales del cliente y utilizar a continuación la autenticación básica (o integrada de Windows) para el servicio Web.

Gracias a este enfoque, la aplicación Web tiene a su disposición las credenciales del cliente en formato de texto sin cifrar. Éstas se pueden transferir al servicio Web a través del proxy de servicio Web. Para hacerlo, escriba el código pertinente en la aplicación Web que le permita recuperar las credenciales del cliente y configurar el proxy.

Autenticación básica Gracias a la autenticación básica, las credenciales del llamador original están disponibles para la aplicación Web en formato de variables de servidor. El siguiente fragmento de código muestra cómo recuperarlas y configurar el proxy de servicio Web.

// Retrieve client's credentials (available with Basic authentication)

string pwd = Request.ServerVariables["AUTH_PASSWORD"];

string uid = Request.ServerVariables["AUTH_USER"];

// Associate the credentials with the Web service proxy

// To improve performance, force preauthentication





"Basic",

new NetworkCredential(uid, pwd, domain) );


Autenticación mediante Formularios La autenticación mediante Formularios permite que las credenciales del llamador original están disponibles para la aplicación Web en formato de campos de formulario (en vez de en formato de variables de servidor). En estos casos, utilice el siguiente fragmento de código.

// Retrieve client's credentials from the logon form

string pwd = txtPassword.Text;

string uid = txtUid.Text;

// Associate the credentials with the Web service proxy

// To improve performance, force preauthentication





"Basic",

new NetworkCredential(uid, pwd, domain) );


Las tablas que figuran a continuación muestran los pasos de configuración que deben llevarse a cabo en el servidor Web, así como en el servidor de aplicaciones.

Configurar el servidor Web Configurar IIS Paso Más información Para utilizar la autenticación básica, deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Web y seleccionar la autenticación básica

Tanto la autenticación básica como la autenticación mediante Formularios deberían utilizarse junto con SSL para proteger las credenciales en formato de texto sin cifrar que se envían a través de la red. Si utiliza la autenticación básica, debería utilizar SSL para todas las páginas (no sólo para la página de inicio de sesión inicial), puesto que las credenciales básicas se transmiten con todas y cada una de las solicitudes.

- O bien - Para utilizar la autenticación mediante Formularios, habilitar el acceso anónimo

Del mismo modo, debería utilizar SSL para todas las páginas si utiliza la autenticación mediante Formularios a fin de proteger las credenciales de texto sin cifrar durante el inicio de sesión y de proteger también el vale de autenticación que se transfiere en solicitudes posteriores.

Configurar ASP.NET Paso Más información Si se utiliza la autenticación básica, configurar la aplicación Web de ASP.NET para utilizar la autenticación de Windows - O bien - Si se utiliza la autenticación mediante Formularios, configurar la aplicación Web de ASP.NET para utilizar la autenticación mediante Formularios

Modifique el archivo Web.config del directorio virtual de la aplicación Web. Establezca el elemento <authentication> como se indica a continuación:


- O bien - Modifique el archivo Web.config del directorio virtual de la aplicación Web. Establezca el elemento <authentication> como se indica a continuación:

<authentication mode="Forms" />

Deshabilitar la suplantación de la aplicación Web de ASP.NET

Modifique el archivo Web.config del directorio virtual de la aplicación Web. Establezca el elemento <identity> como se indica a continuación:


Nota: este código equivale a suprimir el elemento <identity>. No se requiere la suplantación, dado que las credenciales del usuario se transferirán de forma expresa al servicio Web a través del proxy.

Configurar el proxy de servicio Web Paso Más información Escribir código para capturar y establecer explícitamente las credenciales del proxy de servicio Web

Consulte los fragmentos de código incluidos en las secciones de autenticación básica y mediante Formularios.

Configurar el servidor de aplicaciones Configurar IIS

Paso Más información Deshabilitar el acceso anónimo para el directorio raíz virtual de la aplicación Habilitar la autenticación básica

Nota: la autenticación básica del servidor de aplicaciones (servicio Web) permite que el servicio Web transfiera el contexto de seguridad del llamador original a la base de datos (dado que el nombre de usuario y la contraseña del llamador están disponibles en formato de texto sin cifrar y pueden utilizarse para responder a los desafíos de autenticación de red desde el servidor de bases de datos). Si no necesita transferir el contexto de seguridad del llamador original más allá del servicio Web, considere la posibilidad de configurar IIS en el servidor de aplicaciones para que utilice la autenticación integrada de Windows, puesto que con ello se mejora la seguridad y las credenciales no se transmiten a través de la red ni están disponibles para el servicio Web.

Configurar ASP.NET (servicio Web) Paso Más información Configurar ASP.NET para utilizar la autenticación de Windows



Configurar el servicio Web de ASP.NET para la suplantación

Modifique el archivo Web.config del directorio virtual del servicio Web. Establezca el elemento <identity> como se indica a continuación:


Nota: este paso sólo es necesario si se desea transferir el contexto de seguridad del llamador original al siguiente nivel indirecto (una base de datos por ejemplo) a través del servicio Web. Si está habilitada la suplantación, el acceso a los recursos (tanto local como remoto) utilizará el contexto de seguridad del llamador original suplantado. Si sus necesidades se limitan a permitir comprobaciones de autorización por usuario en el servicio Web, no necesitará utilizar la suplantación.

Subsistema de confianza El modelo del subsistema de confianza constituye un enfoque alternativo (más sencillo de implementar) para la transmisión del contexto de seguridad del llamador original. En este modelo existe un límite de confianza entre el servicio Web y la aplicación Web. El servicio Web confía en la aplicación Web para que autentique y autorice correctamente a los llamadores, antes de que permitir que las solicitudes

lleguen al servicio Web. En el servicio Web no se lleva a cabo autenticación alguna de los llamadores originales. El servicio Web autentica la identidad fija de confianza utilizada por la aplicación Web para la comunicación con el servicio Web. En la mayoría de los casos, se trata de la identidad del proceso de trabajo de ASP.NET.

El modelo de subsistema de confianza se refleja en la ilustración 10.6.

{Insert figure: CH10 – Trusted subsystem with Web service.gif}

Ilustración 10.6 El modelo de subsistema de confianza

Transmitir la identidad del llamador Si utiliza el modelo de subsistema de confianza, quizás necesite transmitir la identidad del llamador original (el nombre, no el contexto de seguridad), por ejemplo, por motivos de auditoría de la base de datos.

Puede transferir la identidad desde la aplicación mediante un método. Por otra parte, puede utilizar los parámetros de procedimientos almacenados y los parámetros de consulta de confianza (como muestra el siguiente ejemplo) para recuperar datos específicos de usuario de la base de datos.

SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"

Pasos de configuración Las tablas que figuran a continuación muestran los pasos de configuración que deben llevarse a cabo en el servidor Web, así como en el servidor de aplicaciones.

Configurar el servidor Web Configurar IIS Paso Más información Configurar la autenticación de IIS

La aplicación Web puede utilizar cualquier forma de autenticación para autenticar a los llamadores originales.

Configurar ASP.NET Paso Más información Configurar la autenticación y comprobar que la suplantación esté deshabilitada

Modifique el archivo Web.config del directorio virtual de la aplicación Web. Establezca el elemento <authentication> en “Windows”, “Forms” o “Passport”.

<authentication mode="Windows|Forms|Passport" />

Establezca el elemento <identity> como se indica a continuación:


(O BIEN, elimine el elemento <identity>).

Restablecer la contraseña de la cuenta de ASPNET utilizada para ejecutar ASP.NET O BIEN crear una cuenta de dominio con privilegios mínimos para ejecutar ASP.NET y especificar información detallada de la cuenta en el elemento <processModel> del archivo Web.config

Si desea obtener más información acerca de cómo obtener acceso a los recursos de red (incluidos los servicios Web) desde ASP.NET y acerca de cómo seleccionar y configurar una cuenta de proceso para ASP.NET, consulte las secciones "Obtener acceso a recursos de red" e "Identidad del proceso para ASP.NET" en el capítulo 8, "Seguridad de ASP.NET".

Configurar el proxy de servicio Web Paso Más información Configurar el proxy de servicio Web para utilizar las credenciales predeterminadas para todas las llamadas al servicio Web

Utilice la siguiente línea de código:

proxy.Credentials = DefaultCredentials;

Configurar el servidor de aplicaciones Configurar IIS Paso Más información Deshabilitar el acceso anónimo para el directorio raíz virtual del servicio Web Habilitar la autenticación de Windows integrada

Configurar ASP.NET Paso Más información Configurar ASP.NET para utilizar la autenticación de Windows



Deshabilitar la suplantación Modifique el archivo Web.config del directorio virtual de la aplicación. Establezca el elemento <identity> como se indica a continuación:


Obtener acceso a recursos del sistema Para obtener información detallada sobre el acceso a los recursos del sistema (por ejemplo, al registro de sucesos y al registro) de los servicios Web de ASP.NET, consulte el apartado "Obtener acceso a recursos de sistema" del capítulo 8, "Seguridad de ASP.NET". Los enfoques y las restricciones abordados en el capítulo 8 también son válidos para los servicios Web de ASP.NET.

Obtener acceso a recursos de red Cuando obtenga acceso a recursos de red desde un servicio Web, debe tener en consideración la identidad utilizada para responder a los desafíos de autenticación de la red desde el equipo remoto. Existen tres opciones:

� La identidad de proceso (determinada por la cuenta utilizada para ejecutar el proceso de trabajo de ASP.NET)

� Una identidad de servicio (por ejemplo, una creada llamando a la interfaz LogonUser)

� La identidad del llamador original (con el servicio Web configurado para la suplantación)

Para obtener información detallada acerca de los beneficios que reporta cada uno de estos enfoques, junto con información pormenorizada de configuración, consulte el apartado "Obtener acceso a recursos de red" del capítulo 8, "Seguridad de ASP.NET".

Obtener acceso a los objetos COM La directiva AspCompat (utilizada por las aplicaciones Web cuando llaman a objetos COM de subprocesamiento controlado) no está disponible para los servicios Web. Esto significa que cuando se llama a objetos de modelo de subprocesamiento controlado desde servicios Web, se produce un intercambio de subproceso. El resultado es una ligera disminución del rendimiento, y si el servicio Web aplica la suplantación, el testigo de suplantación se perderá al llamar al componente COM. Como consecuencia suele generarse una excepción de acceso denegado.

Más información � Para obtener más información acerca de las excepciones de acceso denegado

cuando se llama a objetos COM de subprocesamiento controlado, consulte el artículo Q325791,"PRB: Access Denied Error Message Occurs When Impersonating in ASP.NET and Calling STA COM Components" (en inglés) en la Knowledge Base de Microsoft.

� Para obtener más información acerca de cómo obtener acceso a los objetos COM y utilizar el atributo AspCompat, consulte el apartado "Obtener acceso a los objetos COM" del capítulo 8, "Seguridad de ASP.NET".

� Para obtener más información acerca de cómo llamar a objetos COM de subprocesamiento controlado desde los servicios Web, consulte el artículo Q303375, "INFO: XML Web Services and Apartment Objects" (en inglés), de la Knowledge Base de Microsoft.

Utilizar certificados de cliente con los servicios Web

En esta sección se describen las técnicas para utilizar los certificados de cliente X.509 para la autenticación de servicios Web.

Puede utilizar la autenticación mediante certificados de cliente desde un servicio Web para autenticar los siguientes elementos:

� Otros servicios Web

� Aplicaciones que se comunican directamente con el servicio Web (por ejemplo, aplicaciones basadas en servidores o aplicaciones de escritorio de cliente)

Autenticar clientes de explorador Web mediante certificados Un servicio Web no puede utilizar certificados de cliente para autenticar a los llamadores si éstos interactúan con una aplicación Web intermedia, puesto que no es posible reenviar el certificado del llamador original al servicio Web a través de la aplicación Web. Mientras que la aplicación Web puede autenticar a sus propios clientes mediante certificados, dichos certificados no pueden utilizarse en el servicio Web para la autenticación.

El motivo por el que da errores este escenario “servidor a servidor” es que la aplicación Web no tiene acceso al certificado del cliente (en especial a la clave privada) de su almacén de certificados. Este problema se muestra en la ilustración 10.7.

{Insert figure: CH10 - Web service server-to-server certificate problem.gif}

Ilustración 10.7 Autenticación mediante certificados de cliente del servicio Web

Utilizar el modelo de subsistema de confianza La solución a esta restricción pasa por utilizar un modelo de subsistema de confianza que, además, reporta compatibilidad para la autenticación mediante certificados en el servicio Web. Con este enfoque, el servicio Web autentica la aplicación Web mediante el certificado de la aplicación Web (no con el certificado del llamador original). El servicio Web confía en la aplicación Web para autenticar a sus usuarios y llevar a cabo la autorización necesaria que garantice que sólo los llamadores autorizados sean capaces de obtener acceso a los datos y las funciones expuestos por el servicio Web.

Este enfoque queda reflejado en la ilustración 10.8.

{Insert figure: CH10 - Web Service Certificate Authentication – Trusted Subsystem.gif}

Ilustración 10.8 El servicio Web autentica la aplicación Web de confianza

Si la lógica de autorización del servicio Web requiere varias funciones, la aplicación Web podrá enviar certificados distintos según la función a la que pertenezca el llamador. Por ejemplo, puede utilizarse un certificado para miembros de un grupo Administradores (con permisos para actualizar los datos de una base de datos servidor) y otro certificado para el resto de los usuarios (con autorización para operaciones de lectura exclusivamente).

Nota: en escenarios como éste existe la posibilidad de utilizar un servidor de certificados local (al que sólo pueden obtener acceso los dos servidores) para administrar todos los certificados de aplicación Web.

En este escenario:

� La aplicación Web autentica a sus usuarios mediante certificados de cliente.

� La aplicación Web actúa como equipo selector y autoriza a sus usuarios, además de controlar el acceso al servicio Web.

� La aplicación Web llama al servicio Web y transmite un certificado distinto que representa a la aplicación (o, quizás, un rango de certificados basados en la pertenencia a funciones del llamador).

� El servicio Web autentica la aplicación Web y confía en la aplicación para ejecutar la autorización de cliente necesaria.

� Se utiliza IPSec entre el servidor de aplicaciones Web y el servidor de servicios Web a fin de proporcionar un control de acceso adicional. IPSec evita los intentos de acceso no autorizado desde otros equipos. La autenticación mediante certificados del servidor de servicios Web también evita el acceso no autorizado.

Implementación de soluciones Para utilizar la autenticación de certificados en el servicio Web de un escenario como éste, utilice un proceso independiente para llamar al servicio Web y transmitir el certificado. No deben manipularse los certificados directamente desde la aplicación

Web de ASP.NET porque dicha aplicación no dispone de ningún perfil de usuario cargado ni de almacén de certificados asociado. El proceso independiente debe configurarse para que se ejecute con una cuenta dotada de un perfil de usuario asociado (y almacén de certificados). Existen dos opciones básicamente:

� Utilizar una aplicación de servidor de Servicios Empresariales

� Utilizar un servicio Windows

La ilustración 10.9 muestra este escenario con una aplicación servidor de Servicios Empresariales.

{Insert figure: CH10 - Web Service Certificate Authentication.gif}

Ilustración 10.9 Autenticación mediante certificados con servicios Web

A continuación se resume la secuencia de eventos que recopila ilustración 10.9.

1. La aplicación Web autentica al llamador original mediante certificados de cliente.

2. La aplicación Web es el equipo selector y, por lo tanto, responsable de autorizar el acceso a determinadas áreas de funcionalidad (incluidas aquéllas que suponen interacción con el servicio Web).

3. La aplicación Web llama a un componente revisado mediante la ejecución de una aplicación de Servicios Empresariales fuera de proceso.

4. La cuenta utilizada para ejecutar la aplicación de Servicios Empresariales dispone de un perfil de usuario asociado. El componente obtiene acceso al certificado del cliente desde su almacén de certificados, que lo utiliza el servicio Web para autenticar la aplicación Web.

5. El componente revisado llama al servicio Web y transmite el certificado del cliente en cada solicitud de método. El servicio Web autentica la aplicación Web mediante este certificado y confía en la aplicación Web para que autorice correctamente a los llamadores originales.

¿Por qué utilizar un proceso adicional? La necesidad de un proceso adicional (en vez de utilizar el proceso Web Aspnet_wp.exe para ponerse en contacto con el servicio Web) se debe a que se requiere un perfil de usuario (que contenga un almacén de certificados).

Una aplicación Web que se ejecuta mediante la cuenta ASPNET no tiene acceso a ninguno de los certificados del servidor Web. El motivo radica en que los almacenes de certificados se conservan en los perfiles de usuario asociados a las cuentas de usuario interactivas. Los perfiles de usuario se crean exclusivamente para las cuentas interactivas cuando se inicia una sesión física con dichas cuentas. El objetivo de la cuenta ASPNET no consiste en actuar como una cuenta de usuario interactiva y se configura con el privilegio "Denegar inicio de sesión interactivo" a fin de mejorar la seguridad.

Importante: no vuelva a configurar la cuenta ASPNET para eliminar este privilegio y convertirla en una cuenta de inicio de sesión interactivo. Utilice un proceso independiente con una cuenta de servicio configurada para obtener acceso a los certificados, como se ha descrito anteriormente en este capítulo.

Más información � Para obtener más información acerca de cómo implementar este enfoque,

consulte "Cómo llamar a un servicio Web mediante certificados de cliente de ASPNET" en la sección de referencia de este manual.

� Para obtener más información acerca de la configuración de IPSec, consulte "Cómo utilizar IPSec para garantizar una comunicación segura entre dos servidores" en la sección de referencia de este manual.

Comunicación segura La comunicación segura hace referencia a la protección de la integridad y la confidencialidad de los mensajes del servicio Web conforme se transmiten de aplicación en aplicación a través de la red. Se han desarrollado dos enfoques para solucionar este problema: opciones para el transporte y opciones para los mensajes.

Opciones para el transporte Las opciones para el transporte incluyen:

� SSL

� IPSec

Estas opciones resultan apropiadas cuando se cumplen las siguientes condiciones:

� Se envía un mensaje directamente desde la aplicación a un servicio Web sin que el mensaje se enrute a través de ningún sistema intermedio.

� Es posible controlar la configuración de los dos puntos finales implicados en la transferencia del mensaje.

Opciones para los mensajes Los enfoques relativos a los mensajes permiten proteger la confidencialidad e integridad de los mensajes cuando pasan por un número arbitrario de sistemas intermedios. Existe la posibilidad de firmar los mensajes para dotarlos de integridad. En cuanto a la confidencialidad, puede elegir entre cifrar la totalidad del mensaje o únicamente una parte del mismo.

Utilice un enfoque para mensajes cuando se cumplan las siguientes condiciones:

� Se envía un mensaje a un servicio Web y es probable que el mensaje se reenvíe a otros servicios Web o que se enrute a través de sistemas intermedios.

� No se tiene control sobre la configuración de los dos puntos finales; por ejemplo, porque se envían mensajes de una empresa a otra.

Más información � Web Service Development Toolkit incluirá funciones para el cifrado de

mensajes compatibles con la especificación de seguridad WS-Security.

� Si desea obtener más información acerca de SSL e IPSec, consulte el capítulo 4, "Comunicación segura".

Resumen Este capítulo se centra en la seguridad de los servicios Web (punto a punto) relativa tanto a la plataforma como al transporte que pueden ofrecer los servicios subyacentes de ASP.NET, IIS y el sistema operativo. Mientras que la seguridad de la plataforma permite soluciones seguras para escenarios de intranet estrechamente vinculados, no resulta conveniente para escenarios heterogéneos. Es por este motivo precisamente por el que se requiere la seguridad que ofrece la especificación de seguridad WS-Security de la arquitectura GXA. Utilice Web Services Development Kit para crear soluciones de seguridad de mensajes para servicios Web.

Para entornos de dominios Windows estrechamente vinculados:

� Si desea transmitir la identidad del llamador original desde una aplicación Web de ASP.NET a un servicio Web remoto, la aplicación Web de ASP.NET debería utilizar la autenticación Kerberos (con cuentas configuradas para la delegación), básica o mediante Formularios.

� Si utiliza la autenticación Kerberos, habilite la suplantación con la aplicación Web y configure la propiedad Credentials del proxy de servicio Web mediante DefaultCredentials.

� Si utiliza la autenticación básica o mediante Formularios, capture las credenciales del llamador y establezca la propiedad Credentials del proxy de servicio Web agregando un nuevo objeto CredentialCache.

Para escenarios “de servicio Web a servicio Web”:

� Utilice la autenticación básica o Kerberos y establezca las credenciales en el proxy de cliente.

� Utilice una aplicación de Servicios Empresariales o un servicio de Windows fuera de proceso para que manipule los certificados X.509 desde las aplicaciones Web.

� En la medida de lo posible, utilice las comprobaciones de autorización de sistema como, por ejemplo, la autorización mediante archivos y direcciones URL.

� Si utiliza la autorización granular (en el nivel de método Web por ejemplo), utilice funciones .NET (tanto de forma declarativa como imperativa).

� Autorice a los usuarios que no sean de Windows mediante funciones .NET (basadas en un objeto GenericPrincipal que contenga funciones).

� Deshabilite los protocolos HTTP-GET y HTTP-POST en todos los servidores de producto.

� Utilice la seguridad de transporte si no le preocupa transferir los mensajes de forma segura a través de sistemas intermedios.

� Utilice la seguridad de transporte si el rendimiento de SSL es adecuado.

� Utilice la especificación de seguridad WS-Security y Web Services Development kit para desarrollar soluciones para mensajes.

Download - Asegura Webservices

Top Related