De la seguridad en Servicios Web para .Net - Willy .Net

De la seguridad en Servicios Web para .NetEste escrito se centra en la seguridad de los servicios Web en el nivel de laplataforma, mediante las características subyacentes de IIS y ASP.NET. Para laseguridad de los mensajes, Microsoft está desarrollando el kit de desarrollo deservicios Web, que permite generar soluciones de seguridad conforme a laespecificación WS-Security, que forma parte de la iniciativa Global XML Architecture(GXA).ContenidoModelo de seguridad para los servicios WebArquitectura de seguridad para plataformas/transporteEstrategias de autenticación y autorizaciónConfigurar la seguridadTransmitir credenciales para la autenticación de servicios WebTransferir el llamador originalSubsistema de confianzaObtener acceso a recursos del sistemaObtener acceso a recursos de redObtener acceso a los objetos COMUtilizar certificados de cliente con los servicios WebComunicación seguraResumenEn 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 ylos mensajes de los servicios Web. También se describe la seguridad desde el puntode 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 losservicios Web mediante credenciales y certificados para admitir la autenticación porparte del servidor.Modelo de seguridad para los servicios WebLa seguridad de los servicios Web puede aplicarse en tres niveles distintos:Seguridad (de punto a punto) para plataformas/transporteSeguridad (personalizada) para aplicaciones

Seguridad (de extremo a extremo) para mensajeríaCada enfoque ofrece una serie de beneficios y desventajas, que se detallan acontinuación. La elección del enfoque depende en gran medida de las característicasde la arquitectura y las plataformas que vayan a utilizarse para el intercambio de losmensajes.Nota: tenga en cuenta que este capítulo se centra en la seguridad de plataformasy aplicaciones. La seguridad de los mensajes se efectúa mediante la iniciativa dearquitectura de servicios Web XML global (GXA) y, en especial, la especificaciónde 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 ServicesDevelopment Kit (WSDK). De este modo podrá desarrollar soluciones deseguridad para mensajería conformes a la especificación de seguridad WS-Security. Si desea obtener más información, consultehttp://msdn.microsoft.com/webservices/building/wsdk/ (en inglés).Seguridad (de punto a punto) paraplataformas/transportePuede utilizarse el canal de transporte entre dos puntos finales (cliente de serviciosWeb y servicios Web) para garantizar la seguridad de punto a punto. La ilustración10.1 refleja este escenario.{Insert figure: CH10 – Web Services Security – Transport Level.gif}Ilustración 10.1Seguridad para plataformas/transporteCuando se utiliza la seguridad de plataformas, que presupone un entorno de sistemaoperativo Microsoft® Windows® estrechamente integrado, por ejemplo, en intranetscorporativas:El servidor Web (IIS) proporciona autenticación básica, implícita, integrada ymediante certificados.El Servicio Web de ASP.NET hereda algunas funciones de autenticación yautorización de ASP.NET.Puede utilizarse SSL y/o IPSec para aplicar capacidades de integridad yconfidencialidad para los mensajes.Escenarios de usoEl modelo de seguridad para transporte es sencillo, bien diseñado y adecuado parauna gran variedad de escenarios (básicamente para intranets), en los que los

mecanismos de transporte y la configuración del punto final pueden controlarse deforma exhaustiva.Los principales aspectos que deben tenerse en cuenta con relación a la seguridaddel transporte son los siguientes:La seguridad se integra estrechamente con la plataforma subyacente, elmecanismo 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 saltosmúltiples ni enrutamiento a través de nodos de aplicación intermedios.Seguridad para aplicacionesCon este enfoque, la aplicación se hace cargo de la seguridad y utiliza las funcionesde seguridad personalizadas. Por ejemplo:Una aplicación puede utilizar un encabezado SOAP personalizado paratransferir las credenciales de usuario y autenticar al usuario con cada solicitudde Servicio Web. Un enfoque habitual consiste en transferir un vale (o nombrede usuario o licencia) con el encabezado SOAP.La aplicación tiene la flexibilidad de generar su propio objeto IPrincipal confunciones incluidas. Puede ser una clase personalizada o la claseGenericPrincipal que se proporciona con .NET Framework.La aplicación cifra de forma selectiva lo que sea necesario, aunque requiereun almacenamiento seguro de la clave y que los desarrolladores tenganconocimientos de las API de criptografía pertinentes.Una técnica alternativa consiste en utilizar SSL para ofrecer confidencialidad eintegridad, además de combinar SSL con encabezados SOAP personalizadospara llevar a cabo la autenticación.Escenarios de usoUtilice este enfoque si:Desea aprovechar un esquema existente de base de datos de usuarios yfunciones 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íaSe trata del enfoque más flexible y eficaz y el que utiliza la iniciativa GXA, enespecial para la especificación de seguridad WS-Security. La seguridad de mensajesqueda esbozada en la ilustración 10.2.{Insert figure: CH10 - Web Services Security Message Level.gif}

Ilustración 10.2Seguridad de mensajesLas especificaciones de seguridad WS-Security describen las mejoras realizadas enla mensajería SOAP y que permiten disfrutar de integridad, confidencialidad yautenticación para los mensajes.La autenticación se obtiene mediante testigos de seguridad, que se transfierenen encabezados SOAP. La especificación de seguridad WS-Security norequiere ningún tipo de testigo específico. Los testigos de seguridad puedenincluir vales Kerberos, certificados X.509 o un testigo binario personalizado.La comunicación segura se obtiene mediante firmas digitales que garantizan laintegridad de los mensajes y el cifrado XML para la confidencialidad de losmensajes.Escenarios de usoLa especificación de seguridad WS-Security puede utilizarse para crear un marco deintercambio 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 elcontrol directo ni de la configuración de los puntos finales ni de los nodos deaplicació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 demensajes 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 laseguridad, además de otros servicios tales como referencias de enrutamiento y demensajes. Este kit cumple los estándares más recientes de los servicios Web comola especificación de seguridad WS-Security, lo cual permite la interoperabilidad conotros proveedores que aplican las mismas especificaciones.Más informaciónPara obtener las últimas novedades acerca de Web Services Development Kity la especificación de seguridad WS-Security, consulte la página del centro dedesarrolladores XML de MSDN en http://msdn.microsoft.com/webservices/ (eninglé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/enus/dnglobspec/html/wssecurspecindex.asp(en inglés).Para obtener más información acerca de la arquitectura GXA, consulte elartículo "Understanding GXA" (en inglés) de MSDN.Para obtener acceso a las discusiones del tema, consulte el grupo de noticiasde interoperabilidad GXA en MSDN.

Arquitectura de seguridad paraplataformas/transporteLa ilustración 10.3 muestra la arquitectura de seguridad de la plataforma deservicios Web de ASP.NET.{Insert figure: CH10 - Web Services Security Architecture.gif}Ilustración 10.3Arquitectura de seguridad de servicios WebLa ilustración 10.3 muestra los mecanismos de autenticación y autorización queincluyen 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 contenercredenciales de autenticación, lo que depende del tipo de autenticación que seesté utilizando.2. Opcionalmente, IIS autentica al llamador mediante la autenticación básica,implícita, integrada (NTLM o Kerberos) o mediante certificados. En entornosheterogé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 comovales transferidos a través del encabezado SOAP.3. IIS también puede configurarse para que acepte solicitudes únicamente de losequipos cliente con unas direcciones IP específicas.4. IIS transfiere el testigo de acceso a Windows del llamador autenticado aASP.NET (que puede ser el testigo de acceso del usuario de Internet anónimosi se ha configurado el servicio Web para la autenticación anónima).

5. ASP.NET autentica al llamador. Cuando ASP.NET se configura para laautenticación de Windows, no se efectúa ningún otro tipo de autenticaciónadicional 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 modode autenticación de ASP.NET se establece en ninguno a fin de permitir laautenticación personalizada.Nota: la autenticación mediante Formularios y la autenticación de Passport noson 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 lospermisos NTFS asociados con el archivo .asmx para determinar si debeconcederse el acceso al llamador autenticado.Nota: la autorización de archivos sólo es compatible para la autenticación deWindows.A fin de disfrutar de una autorización de granularidad precisa, también puedenutilizarse las funciones .NET (mediante declaraciones o programación) paragarantizar que el llamador reciba autorización para obtener acceso al recursosolicitado o para llevar a cabo la operación solicitada.7. El código del servicio Web obtiene acceso a los recursos locales o remotosmediante una identidad determinada. De forma predeterminada, los serviciosWeb de ASP.NET no llevan a cabo ninguna suplantación, por lo que es lacuenta de proceso ASP.NET configurada la que proporciona la identidad.Otras opciones alternativas incluyen la identidad del llamador original o unaidentidad de servicio configurada.Equipos selectoresLos equipos selectores del servicio Web de ASP.NET son:IISSi se deshabilita la autenticación anónima de IIS, los servicios IIS sólopermitirán solicitudes de usuarios autenticados.Restricciones de dirección IPIIS puede configurarse para que acepte solicitudes únicamente de equiposcon unas direcciones IP específicas.ASP.NETEl módulo HTTP de autorización de archivos (exclusivamente para laautenticación de Windows)El módulo HTTP de autorización mediante direcciones URLPeticiones de permisos Principal y comprobaciones de funciones explícitasMás informaciónPara 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 estemismo capítulo.

Estrategias de autenticación y autorizaciónEn esta sección se exponen las opciones de autorización (tanto configurables comoprogramáticas) disponibles para un conjunto de esquemas de autenticaciónutilizados de forma habitual.Los esquemas de autenticación que van a describirse se indican a continuación:Autenticación de Windows con suplantaciónAutenticación de Windows sin suplantaciónAutenticación de Windows con identidad fijaAutenticación de Windows con suplantaciónLos siguientes elementos de configuración muestran cómo habilitar la autenticaciónde Windows (IIS) y la suplantación mediante declaraciones en los archivosWeb.config o Machine.config.Nota: es recomendable configurar la autenticación en función de cada servicioWeb en el archivo Web.config del servicio Web correspondiente.Con esta configuración, el código del servicio Web suplanta al llamador autenticadopor IIS. Para suplantar al llamador original es preciso desactivar el acceso anónimoen IIS. En caso de utilizar el acceso anónimo, el código del servicio Web suplanta lacuenta de usuario de Internet anónimo (que, de manera predeterminada, esIUSR_MACHINE).Seguridad configurableEl empleo de la autenticación de Windows junto con la funcionalidad de suplantaciónofrece las siguientes opciones de autorización:Listas ACL de WindowsArchivo del servicio Web (.asmx). La autorización de archivos lleva acabo comprobaciones de acceso para los recursos ASP.NET solicitados(que incluye el archivo del servicio Web .asmx) mediante el contexto deseguridad 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 deWindows de los recursos a los que obtiene acceso el servicio Web(archivos, carpetas, claves de registro, objetos de servicio del directorioActive Directory®, etc.) deben incluir una entrada de control de acceso(ACE) que conceda acceso de lectura al llamador original (puesto que elsubproceso del servicio Web utilizado para el acceso a los recursosejecuta la suplantación del llamador).Autorización mediante direcciones URL. Se configura en el archivoMachine.config o Web.config. Con la autenticación de Windows, los nombresde usuario adoptan la forma DomainName\UserName(NombreDominio\NombreUsuario) y las funciones se asignan una a una a losgrupos de Windows.

Seguridad mediante programaciónLa seguridad mediante programación hace referencia a las comprobaciones deseguridad ubicadas en el código del servicio Web. Las siguientes opciones deseguridad mediante programación están disponibles cuando se utilizan laautenticación de Windows y la suplantación.Peticiones de permisos PrincipalImperativas (en las líneas del código de un método)PrincipalPermission permCheck = new PrincipalPermission(permCheck.Demand();null, @"DomainName\WindowsGroup");Declarativas (estos atributos pueden figurar antes de los métodos o lasclases 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[PrincipalPermission(SecurityAction.Demand,Name=@"DomainName\UserName")]Comprobaciones de funciones explícitas. Puede realizar la comprobaciónde funciones mediante la interfaz IPrincipal.IPrincipal.IsInRole(@"DomainName\WindowsGroup");Escenarios de usoUtilice la autenticación de Windows y la suplantación cuando se den las siguientescondiciones:Los clientes del servicio Web pueden identificarse mediante cuentas deWindows, que a su vez puede autenticar el servidor.Debe transferirse el contexto de seguridad del llamador original al siguientenivel a través del servicio Web. Por ejemplo, a un conjunto de componentesrevisados que utilizan funciones de Servicios Empresariales (COM+) o a unnivel de datos que precisa autorización de granularidad fina (por usuario).Debe transferir el contexto de seguridad del llamador original a los nivelesindirectos 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 laagrupación de conexiones de bases de datos. A modo de enfoque alternativo, esrecomendable plantearse la posibilidad de utilizar un modelo de subsistema deconfianza 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 delllamador se transfiere desde la aplicación; por ejemplo, mediante los parámetrosde procedimiento almacenados.

Más informaciónSi desea obtener más información acerca de la autenticación de Windows y lasuplantación, consulte el capítulo 8 "Seguridad de ASP.NET".Para obtener más información acerca de la autorización mediante direccionesURL, consulte "Notas acerca de la autorización mediante direcciones URL" enel capítulo 8, "Seguridad de ASP.NET".Autenticación de Windows sin suplantaciónLos siguientes elementos de configuración muestran cómo habilitar la autenticaciónde Windows (IIS) sin suplantación de forma declarativa en el archivo Web.config.Seguridad configurableEl empleo de la autenticación de Windows sin la suplantación ofrece las siguientesopciones de autorización:Listas ACL de WindowsArchivo del servicio Web (.asmx). La autorización de archivos lleva acabo comprobaciones de acceso para los recursos ASP.NET solicitados(que incluye el archivo del servicio Web .asmx) mediante el llamadororiginal. No se requiere la suplantación.Recursos a los que obtiene acceso la aplicación. Las listas ACL deWindows de los recursos a las que obtiene acceso la aplicación (archivos,carpetas, claves de registro, objetos de Active Directory) deben incluir unaentrada ACE que conceda acceso de lectura a la identidad del proceso deASP.NET (la identidad predeterminada que utiliza el subproceso delservicio Web para obtener acceso a los recursos).Autorización de URLSe configura en los archivos Machine.config y Web.config. Con laautenticación de Windows, los nombres de usuario adoptan la formaDomainName\UserName (NombreDominio\NombreUsuario) y las funciones seasignan una a una a los grupos de Windows.Seguridad mediante programaciónLa seguridad mediante programación hace referencia a las comprobaciones deseguridad ubicadas en el código del servicio Web. Las siguientes opciones deseguridad mediante programación están disponibles cuando se utiliza laautenticación de Windows sin suplantación.Peticiones de permisos PrincipalImperativasPrincipalPermission 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)[PrincipalPermission(SecurityAction.Demand,Role=@"DomainName\WindowsGroup)]// Demand that the caller is a specific user[PrincipalPermission(SecurityAction.Demand,Name=@"DomainName\UserName")]Comprobaciones de funciones explícitas. Puede realizar la comprobaciónde funciones mediante la interfaz IPrincipal.IPrincipal.IsInRole(@"DomainName\WindowsGroup");Escenarios de usoUtilice la autenticación de Windows sin suplantación cuando se den las siguientescondiciones:Los clientes del servicio Web pueden identificarse mediante cuentas deWindows, que a su vez puede autenticar el servidor.Desea utilizar el modelo de subsistema de confianza y autorizar a los clientesdesde el servicio Web para, a continuación, utilizar una identidad fija paraobtener acceso a los recursos indirectos (bases de datos por ejemplo) a fin deadmitir la agrupación de conexiones.Más informaciónSi desea obtener más información acerca de la autenticación de Windows y lasuplantación, consulte el capítulo 8 "Seguridad de ASP.NET".Para obtener más información acerca de la autorización mediante direccionesURL, consulte "Notas acerca de la autorización mediante direcciones URL" enel capítulo 8, "Seguridad de ASP.NET".Autenticación de Windows con identidad fijaEl elemento del archivo Web.config es compatible con los atributosopcionales de nombre de usuario y contraseña, lo cual le permite configurar unaidentidad fija específica para que la suplante el servicio Web. Este enfoque semuestra en el siguiente fragmento del archivo de configuración.Escenarios de usoNo 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 enformato de texto sin cifrar en los archivos de configuración.En Windows 2000, este enfoque obliga a conceder a la cuenta de procesoASP.NET el privilegio “Actuar como parte del sistema operativo”. De estemodo 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 servicioWeb (Aspnet_wp.exe).Más informaciónSi desea obtener más información acerca de la autenticación de Windows y lasuplantación, consulte el capítulo 8 "Seguridad de ASP.NET".Para obtener más información acerca de la autorización mediante direccionesURL, consulte "Notas acerca de la autorización mediante direcciones URL" enel capítulo 8, "Seguridad de ASP.NET".Configurar la seguridadEn esta sección encontrará los pasos que debe realizar para configurar la seguridadde 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.4Configurar la seguridad de un servicio Web ASP.NETConfigurar los parámetros de IISPara obtener información pormenorizada acerca de cómo configurar los parámetrosde 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 losservicios Web ASP.NET.Configurar los parámetros de ASP.NETLos parámetros de configuración de la aplicación se almacenan en archivosWeb.config, ubicados en el directorio raíz virtual del servicio Web. Es precisoconfigurar los siguientes parámetros:1. Configure la autenticación. Debe establecerse para cada servicio Web (noen el archivo Machine.config) del archivo Web.config ubicado en el directorioraíz virtual del servicio Web.Nota: los servicios Web no son compatibles actualmente con la autenticaciónmediante Formularios y la autenticación de Passport. Si decide utilizar laautenticación personalizada o de mensajes, establezca el modo en ninguna.2. Configure la suplantación y la autorización. Si desea obtener informacióndetallada, consulte "Configurar la seguridad" en el capítulo 8, "Seguridad deASP.NET."Más informaciónPara 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ítulo8, "Seguridad de ASP.NET".Proteger recursosDebería utilizar las mismas técnicas que se describen en el capítulo 8, "Seguridad deASP.NET", para proteger los recursos Web Además, valore la posibilidad de eliminarlos protocolos HTTP-GET y HTTP-POST del archivo Machine.config de losservidores de producción cuando utilice los servicios Web.Deshabilitar HTTP-GET y HTTP-POSTDe forma predeterminada, los clientes se comunican con los servicios Web ASP.NETmediante 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 elnivel de equipo de los equipos de producción en los que no sean necesarios. De estaforma conseguirá evitar posibles problemas de seguridad que podrían permitir queuna página Web mal intencionada obtenga acceso a un servicio Web interno que seejecute detrás de un servidor de seguridad.Nota: deshabilitar estos protocolos implica que los clientes nuevos no podráncomprobar un servicio Web XML mediante el botón Invocar de la página deprueba del servicio Web. En su lugar, deberá crear un programa cliente decomprobación. Para hacerlo, agregue una referencia al servicio Web mediante elsistema de desarrollo Microsoft Visual Studio® .NET. Quizás desee mantener

habilitados estos protocolos en los equipos de desarrollo a fin de que losdesarrolladores sean capaces de utilizar la página de comprobación. Para deshabilitar los protocolos HTTP-GET y HTTP-POST en todo unequipo1. Modifique el archivo Machine.config.2. Elimine los comentarios de las líneas del elemento queagregan compatibilidad para los protocolos HTTP-GET y HTTP-POST. Cuandohaya acabado, el archivo Machine.config debería ofrecer el siguiente aspecto.3. Guarde el archivo Machine.config.Nota: en algunos casos especiales en los que clientes de servicios Web secomunican con un servicio Web que utiliza el protocolo HTTP-GET o HTTP-POST,es posible agregar la compatibilidad necesaria para dichos protocolos desde elarchivo Web.config de la aplicación, con sólo crear un elemento yagregar compatibilidad para los protocolos con los elementos y ,tal como se ha mostrado anteriormente.Más informaciónSi 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 seguraUtilice una combinación de SSL e IPSec para proteger los vínculos de comunicación.Más informaciónPara obtener información acerca de cómo llamar a un servicio Web medianteSSL, consulte "Cómo llamar a un servicio Web con SSL" en la sección dereferencia 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 entredos servidores" en la sección de referencia de este manual.Transmitir credenciales para la autenticación deservicios WebLas llamadas a los servicios Web se efectúan mediante un proxy de servicio Web, unobjeto local que expone el mismo conjunto de métodos que el servicio Web dedestino.

Puede generar un proxy de servicio Web mediante la utilidad de la línea decomandos Wsdl.exe. Si utiliza Visual Studio .NET también puede generar el proxyagregando una referencia Web al proyecto.Nota: si el servicio Web para el que desea generar un proxy está configurado pararequerir certificados de cliente, deberá deshabilitar temporalmente dicho requisitomientras agrega la referencia; de lo contrario se producirá un error. Una vezagregada la referencia, no olvide volver a configurar el servicio para que exija loscertificados.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 recuerdeactualizarlo si se modifica la interfaz del Servicio Web.Especificar las credenciales de cliente para laautenticación de WindowsEl uso de la autenticación de Windows requiere especificar las credenciales quedeben utilizarse para la autenticación mediante la propiedad Credentials del proxyde servicio Web. Si no establece esta propiedad de forma expresa, se efectuará lallamada al servicio Web sin utilizar credenciales. Cuando se requiere la autenticaciónde Windows, se generará un estado HTTP 401, de respuesta de acceso denegado.Utilizar DefaultCredentialsLas credenciales de cliente no se transfieren de forma implícita. Es el consumidor delservicio Web quien debe establecer las credenciales y los detalles de laautenticación en el proxy. Para transferir el contexto de seguridad del contexto deseguridad Windows del cliente (sea desde un testigo de subproceso suplantado seadesde un testigo de proceso) a un servicio Web, establezca la propiedadCredentials del proxy de servicio Web en CredentialCache.DefaultCredentials talcomo 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 seutiliza la autenticación NTLM, Kerberos o negociada.Si una aplicación de cliente (por ejemplo, una aplicación de formularios deWindows) llama al servicio Web, las credenciales se obtendrán de la sesión deinicio de sesión interactiva del usuario.Las aplicaciones de servidor, como las aplicaciones Web de ASP.NET, utilizanla identidad de proceso, salvo que se haya configurado la suplantación, encuyo caso se utiliza la identidad del llamador suplantado.Utilizar credenciales específicasPara utilizar un conjunto específico de credenciales de autenticación para llamar a unservicio Web, utilice el siguiente código.CredentialCache cache = new CredentialCache();cache.Add( new Uri(proxy.Url), // Web service URL"Negotiate", // Kerberos or NTLMnew NetworkCredential("username", "password", "domainname") );proxy.Credentials = cache;

En este ejemplo, el tipo de autenticación negociada solicitada puede ser laautenticación Kerberos o NTLM.Solicitar siempre un tipo de autenticación específicaEs recomendable solicitar siempre un tipo de autenticación específico, tal como semuestra más arriba. Evite el uso directo de la clase NetworkCredential, como serefleja en el siguiente fragmento de código.proxy.Credentials = newNetworkCredential("username", "password", "domainname");Este método debería evitarse en el código de producción porque se pierde el controldel mecanismo de autenticación que utiliza el servicio Web y, como consecuencia, sepierde 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 oNTLM 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 enformato de texto no cifrado.Establecer la propiedad PreAuthenticateLa propiedad PreAuthenticate del proxy puede establecerse como verdadera ofalsa. Establézcala en verdadera (true) para proporcionar las credenciales deautenticación específicas para generar un encabezado HTTP WWW-authenticatepara transferir con la solicitud Web. Esta propiedad guarda la denegación de accesodel servidor Web en la solicitud y lleva a cabo la autenticación en la siguientesolicitud de reintento.Nota: la preautenticación sólo se aplica cuando el servicio Web se autenticacorrectamente la primera vez. La preautenticación no tiene repercusión alguna enla primera solicitud Web.private void ConfigureProxy( WebClientProtocol proxy,string domain, string username,string password ){// To improve performance, force pre-authenticationproxy.PreAuthenticate = true;// Set the credentialsCredentialCache cache = new CredentialCache();cache.Add( new Uri(proxy.Url),"Negotiate",new NetworkCredential(username, password, domain) );proxy.Credentials = cache;proxy.ConnectionGroupName = username;}Utilizar la propiedad ConnectionGroupNameTenga en cuenta que el código anterior establece la propiedadConnectionGroupName del proxy de servicio Web. Este paso sólo es necesario siel contexto de seguridad utilizado para la conexión con el servicio Web varía de unasolicitud 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 ytransfiere el contexto de seguridad del llamador original (medianteDefaultCredentials o estableciendo las credenciales explícitas, como en el casoanterior), debería establecer la propiedad ConnectionGroupName del proxy deservicio Web de la aplicación Web. Con ello se consigue evitar que un clienteautenticado nuevo vuelva a utilizar una conexión TCP autenticada antigua para elservicio Web asociado con unas credenciales de autenticación de cliente anteriores.La reutilización de conexiones puede tener lugar tras un resultado HTTP KeepAlivesy la persistencia de autenticación que se habilita por motivos de rendimiento en IIS.Establezca la propiedad ConnectionGroupName en un identificador (como elnombre de usuario del llamador) que distinga un llamador del siguiente, tal como semuestra en el fragmento de código anterior.Nota: si el contexto de seguridad del llamador original no se transfiere a través dela aplicación Web hasta el servicio Web sino que la aplicación Web se conecta alservicio Web mediante una identidad fija (como la identidad de proceso ASP.NETde la aplicación Web), no será necesario que establezca la propiedadConnectionGroupName. En este escenario, el contexto de seguridad de conexiónpermanece constante de un llamador al siguiente.Llamar a los servicios Web desde clientes que no seande WindowsExisten una serie de enfoques de autenticación que funcionan con los escenariosque implican varios exploradores. Entre ellos figuran:Autenticación mediante certificados. Mediante certificados X.509 paravarias plataformas.Autenticación básica. Si desea obtener un ejemplo de cómo utilizar laautenticación básica con un almacén de datos personalizado (sin que seanecesario Active Directory), consultehttp://www.rassoc.com/gregr/weblog/stories/2002/06/26/webServicesSecurityHttpBasicAuthenticationWithoutActiveDirectory.html (en inglés).Enfoques para mensajes GXA. Utilice Web Services Development Toolkitpara implementar soluciones GXA (WS-Security).Enfoques personalizados. Por ejemplo, para transferir las credencialesmediante encabezados SOAP.Autenticación de servidor proxyLa autenticación de servidor proxy no se admite en el cuadro de diálogo Agregarreferencia Web de Visual Studio .NET (aunque sí que será compatible en lasiguiente versión de Visual Studio .NET). Como resultado puede producirse unestado de HTTP 407: "Autenticación proxy obligatoria" cuando intente agregar unareferencia Web.Nota: quizás no experimente este error si visualiza el archivo .asmx desde unexplorador 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:// /pu: /pp:/pd: http://www.YouWebServer.com/YourWebService/YourService.asmx

Utilice el código presentado a continuación si necesita establecer medianteprogramación la información de autenticación del servidor proxy.YourWebServiceProxy.Proxy.Credentials = CredentialsCache.DefaultCredentials;Transferir el llamador originalEn esta sección se describe cómo transferir el contexto de seguridad del llamadororiginal a través de una aplicación Web de ASP.NET hasta un servicio Web ubicadoen un servidor de aplicaciones remoto. Quizás necesite recurrir a este procedimientopara que un servicio Web sea compatible con la autorización por usuario, o bienpróximos subsistemas indirectos (como bases de datos en las que se deseeautorizar a los llamadores originales con relación a objetos de base de datosindividuales).La ilustración 10.5 refleja el contexto de seguridad del llamador original (Alice) ycómo se transfiere a través del servidor Web de cliente que aloja una aplicación Webde ASP.NET hasta el objeto remoto, alojado por ASP.NET en un servidor deaplicaciones remotas, y finalmente a través de un servidor de bases de datos deservidor.{Insert figure: CH10 – Flowing original caller with Web Service.gif}Ilustración 10.5Transferir el contexto de seguridad del llamador originalPara transferir las credenciales a un servicio Web, el cliente del servicio Web (laaplicación Web de ASP.NET en este escenario en concreto) debe configurar el proxyde servicio Web y establecer de forma expresa la propiedad Credentials del proxy,como se describe en el apartado "Transmitir credenciales para la autenticación deservicios 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ónKerberos (y la delegación). Este enfoque requiere el uso de la suplantaciónen la aplicación Web de ASP.NET y la configuración del proxy de objetoremoto con el elemento DefaultCredentials obtenido del contexto deseguridad del llamador suplantado.Transferir las credenciales explícitas y utilizar la autenticación básica omediante Formularios. Este enfoque no requiere el uso de funciones desuplantación en la aplicación Web de ASP.NET. En cambio, es precisoconfigurar programáticamente el proxy de servicio Web con credencialesexplícitas obtenidas bien de variables de servidor (en el caso de laautenticación básica) bien de campos de formularios HTML (en el caso de laautenticación mediante Formularios) disponibles para la aplicación Web. Tantopara la autenticación básica como mediante Formularios, el nombre de usuarioy la contraseña están disponibles en formato de texto sin cifrar.

Credenciales predeterminadas con delegación KerberosPara utilizar la delegación Kerberos, todos los equipos (servidores y clientes) debenejecutar Windows 2000 o versiones posteriores. Por otra parte, las cuentas de clienteque vayan a delegarse deberán almacenarse en Active Directory y no marcarsenunca como ”Confidencial y no se puede delegar”.Las tablas que figuran a continuación muestran los pasos de configuración quedeben llevarse a cabo en el servidor Web, así como en el servidor de aplicaciones.Configurar el servidor WebConfigurar IISPasoDeshabilitar el accesoanónimo para el directorioraíz virtual de la aplicaciónWebHabilitar la autenticaciónintegrada de Windows parael directorio raíz virtual dela aplicación WebConfigurar ASP.NETPasoConfigurar la aplicaciónWeb de ASP.NET parautilizar la autenticación deWindowsMás informaciónLa autenticación Kerberos se negociará teniendo encuenta que tanto los clientes como el servidor ejecutanWindows 2000 o versiones posteriores.Nota: si ya utiliza Internet Explorer 6 en Windows 2000, elvalor predeterminado es la autenticación NTLM en vez dela autenticación Kerberos que se precisa en este contexto.Para habilitar la delegación Kerberos, consulte el artículoQ299838, "Unable to Negotiate Kerberos Authenticationafter upgrading to Internet Explorer 6" (en inglés) en laKnowledge Base de Microsoft.Más informaciónModifique el archivo Web.config del directorio virtual de laaplicación Web.Establezca el elemento como se indicaa continuación:Configurar la aplicaciónWeb de ASP.NET para lasuplantaciónModifique el archivo Web.config del directorio virtual de laaplicación Web.Establezca el elemento como se indica acontinuación:Configurar el proxy de servicio WebPasoMás informaciónEstablecer la propiedad decredenciales del proxy deservicio Web enDefaultCredentials.Consulte el apartado "Utilizar DefaultCredentials" quefigura más arriba en este capítulo para obtener muestrasde código.Configurar el servidor de aplicaciones remotoConfigurar IISPasoMás información

Deshabilitar el accesoanónimo para el directorioraíz virtual del servicio WebHabilitar la autenticaciónintegrada de Windows parael directorio raíz virtual dela aplicación WebConfigurar ASP.NET (host del servicio Web)PasoConfigurar ASP.NET parautilizar la autenticación deWindowsMás informaciónModifique el archivo Web.config del directorio virtual delservicio Web.Establezca el elemento como se indicaa continuación:Configurar ASP.NET parala suplantaciónModifique el archivo Web.config del directorio virtual delservicio Web.Establezca el elemento como se indica acontinuación:Nota: este paso sólo es necesario si se desea transferir elcontexto de seguridad del llamador original al siguientenivel indirecto (una base de datos por ejemplo) a travésdel servicio Web. Si está habilitada la suplantación, elacceso a los recursos (tanto local como remoto) utilizaráel contexto de seguridad del llamador original suplantado.Si sus necesidades se limitan a permitir comprobacionesde autorización por usuario en el servicio Web, nonecesitará utilizar la suplantación.Más informaciónPara 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 lasección de referencia de este manual.Credenciales explícitas con autenticación básica omediante FormulariosComo alternativa a la delegación Kerberos, puede utilizar la autenticación básica omediante Formularios en la aplicación Web para capturar las credenciales del clientey utilizar a continuación la autenticación básica (o integrada de Windows) para elservicio Web.Gracias a este enfoque, la aplicación Web tiene a su disposición las credenciales delcliente en formato de texto sin cifrar. Éstas se pueden transferir al servicio Web através del proxy de servicio Web. Para hacerlo, escriba el código pertinente en laaplicación Web que le permita recuperar las credenciales del cliente y configurar elproxy.

Autenticación básicaGracias a la autenticación básica, las credenciales del llamador original estándisponibles para la aplicación Web en formato de variables de servidor. El siguientefragmento de código muestra cómo recuperarlas y configurar el proxy de servicioWeb.// 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 preauthenticationproxy.PreAuthenticate = true;// Set the credentialsCredentialCache cache = new CredentialCache();cache.Add( new Uri(proxy.Url),"Basic",new NetworkCredential(uid, pwd, domain) );proxy.Credentials = cache;Autenticación mediante FormulariosLa autenticación mediante Formularios permite que las credenciales del llamadororiginal están disponibles para la aplicación Web en formato de campos deformulario (en vez de en formato de variables de servidor). En estos casos, utilice elsiguiente fragmento de código.// Retrieve client's credentials from the logon formstring pwd = txtPassword.Text;string uid = txtUid.Text;// Associate the credentials with the Web service proxy// To improve performance, force preauthenticationproxy.PreAuthenticate = true;// Set the credentialsCredentialCache cache = new CredentialCache();cache.Add( new Uri(proxy.Url),"Basic",new NetworkCredential(uid, pwd, domain) );proxy.Credentials = cache;Las tablas que figuran a continuación muestran los pasos de configuración quedeben llevarse a cabo en el servidor Web, así como en el servidor de aplicaciones.Configurar el servidor WebConfigurar IISPasoPara utilizar laautenticación básica,deshabilitar el accesoanónimo para el directorioraíz virtual de la aplicaciónWeb y seleccionar laautenticación básicaMás informaciónTanto la autenticación básica como la autenticaciónmediante Formularios deberían utilizarse junto con SSLpara proteger las credenciales en formato de texto sincifrar que se envían a través de la red. Si utiliza laautenticación básica, debería utilizar SSL para todas laspáginas (no sólo para la página de inicio de sesión inicial),puesto que las credenciales básicas se transmiten contodas y cada una de las solicitudes.

- O bien -Para utilizar laautenticación medianteFormularios, habilitar elacceso anónimoConfigurar ASP.NETPasoSi se utiliza la autenticaciónbásica, configurar laaplicación Web deASP.NET para utilizar laautenticación de Windows- O bien -Del mismo modo, debería utilizar SSL para todas laspáginas si utiliza la autenticación mediante Formularios afin de proteger las credenciales de texto sin cifrar duranteel inicio de sesión y de proteger también el vale deautenticación que se transfiere en solicitudes posteriores.Más informaciónModifique el archivo Web.config del directorio virtual de laaplicación Web.Establezca el elemento como se indicaa continuación:Si se utiliza la autenticaciónmediante Formularios,configurar la aplicaciónWeb de ASP.NET parautilizar la autenticaciónmediante Formularios- O bien -Modifique el archivo Web.config del directorio virtual de laaplicación Web.Establezca el elemento como se indicaa continuación:Deshabilitar la suplantaciónde la aplicación Web deASP.NETModifique el archivo Web.config del directorio virtual de laaplicación Web.Establezca el elemento como se indica acontinuación:Configurar el proxy de servicio WebPasoMás informaciónEscribir código paracapturar y establecerexplícitamente lascredenciales del proxy deservicio WebNota: este código equivale a suprimir el elemento.No se requiere la suplantación, dado que las credencialesdel usuario se transferirán de forma expresa al servicioWeb a través del proxy.Consulte los fragmentos de código incluidos en lassecciones de autenticación básica y medianteFormularios.Configurar el servidor de aplicacionesConfigurar IIS

PasoDeshabilitar el accesoanónimo para el directorioraíz virtual de la aplicaciónMás informaciónHabilitar la autenticaciónbásicaNota: la autenticación básica del servidor de aplicaciones(servicio Web) permite que el servicio Web transfiera elcontexto de seguridad del llamador original a la base dedatos (dado que el nombre de usuario y la contraseña delllamador están disponibles en formato de texto sin cifrar ypueden utilizarse para responder a los desafíos deautenticación de red desde el servidor de bases de datos).Si no necesita transferir el contexto de seguridad delllamador original más allá del servicio Web, considere laposibilidad de configurar IIS en el servidor de aplicacionespara que utilice la autenticación integrada de Windows,puesto que con ello se mejora la seguridad y lascredenciales no se transmiten a través de la red ni estándisponibles para el servicio Web.Configurar ASP.NET (servicio Web)PasoConfigurar ASP.NET parautilizar la autenticación deWindowsMás informaciónModifique el archivo Web.config del directorio virtual delservicio Web.Establezca el elemento como se indicaa continuación:Configurar el servicio Webde ASP.NET para lasuplantaciónModifique el archivo Web.config del directorio virtual delservicio Web.Establezca el elemento como se indica acontinuación:Nota: este paso sólo es necesario si se desea transferir elcontexto de seguridad del llamador original al siguientenivel indirecto (una base de datos por ejemplo) a travésdel servicio Web. Si está habilitada la suplantación, elacceso a los recursos (tanto local como remoto) utilizaráel contexto de seguridad del llamador original suplantado.Si sus necesidades se limitan a permitir comprobacionesde autorización por usuario en el servicio Web, nonecesitará utilizar la suplantación.Subsistema de confianzaEl modelo del subsistema de confianza constituye un enfoque alternativo (mássencillo de implementar) para la transmisión del contexto de seguridad del llamadororiginal. En este modelo existe un límite de confianza entre el servicio Web y laaplicación Web. El servicio Web confía en la aplicación Web para que autentique yautorice 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 algunade los llamadores originales. El servicio Web autentica la identidad fija de confianzautilizada por la aplicación Web para la comunicación con el servicio Web. En lamayorí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.6El modelo de subsistema de confianzaTransmitir la identidad del llamadorSi utiliza el modelo de subsistema de confianza, quizás necesite transmitir laidentidad 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 deconsulta de confianza (como muestra el siguiente ejemplo) para recuperar datosespecíficos de usuario de la base de datos.SELECT x,y,z FROM SomeTable WHERE UserName = "Alice"Pasos de configuraciónLas tablas que figuran a continuación muestran los pasos de configuración quedeben llevarse a cabo en el servidor Web, así como en el servidor de aplicaciones.Configurar el servidor WebConfigurar IISPasoConfigurar la autenticaciónde IISConfigurar ASP.NETPasoConfigurar la autenticacióny comprobar que lasuplantación estédeshabilitadaMás informaciónLa aplicación Web puede utilizar cualquier forma deautenticación para autenticar a los llamadores originales.Más informaciónModifique el archivo Web.config del directorio virtual de laaplicación Web.Establezca el elemento en “Windows”,“Forms” o “Passport”.Establezca el elemento como se indica acontinuación:

Restablecer la contraseñade la cuenta de ASPNETutilizada para ejecutarASP.NET O BIEN crearuna cuenta de dominio conprivilegios mínimos paraejecutar ASP.NET yespecificar informacióndetallada de la cuenta en elelemento del archivo Web.configConfigurar el proxy de servicio WebPasoConfigurar el proxy deservicio Web para utilizarlas credencialespredeterminadas paratodas las llamadas alservicio Web(O BIEN, elimine el elemento ).Si desea obtener más información acerca de cómoobtener acceso a los recursos de red (incluidos losservicios Web) desde ASP.NET y acerca de cómoseleccionar y configurar una cuenta de proceso paraASP.NET, consulte las secciones "Obtener acceso arecursos de red" e "Identidad del proceso para ASP.NET"en el capítulo 8, "Seguridad de ASP.NET".Más informaciónUtilice la siguiente línea de código:proxy.Credentials = DefaultCredentials;Configurar el servidor de aplicacionesConfigurar IISPasoDeshabilitar el accesoanónimo para el directorioraíz virtual del servicio WebMás informaciónHabilitar la autenticación deWindows integradaConfigurar ASP.NETPasoConfigurar ASP.NET parautilizar la autenticación deWindowsMás informaciónModifique el archivo Web.config del directorio virtual delservicio Web.Establezca el elemento como se indicaa continuación:Deshabilitar la suplantaciónModifique el archivo Web.config del directorio virtual de laaplicación.Establezca el elemento como se indica acontinuación:

Obtener acceso a recursos del sistemaPara obtener información detallada sobre el acceso a los recursos del sistema (porejemplo, 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ítulo8 también son válidos para los servicios Web de ASP.NET.Obtener acceso a recursos de redCuando obtenga acceso a recursos de red desde un servicio Web, debe tener enconsideración la identidad utilizada para responder a los desafíos de autenticaciónde la red desde el equipo remoto. Existen tres opciones:La identidad de proceso (determinada por la cuenta utilizada para ejecutar elproceso de trabajo de ASP.NET)Una identidad de servicio (por ejemplo, una creada llamando a la interfazLogonUser)La identidad del llamador original (con el servicio Web configurado para lasuplantación)Para obtener información detallada acerca de los beneficios que reporta cada uno deestos enfoques, junto con información pormenorizada de configuración, consulte elapartado "Obtener acceso a recursos de red" del capítulo 8, "Seguridad deASP.NET".Obtener acceso a los objetos COMLa directiva AspCompat (utilizada por las aplicaciones Web cuando llaman a objetosCOM de subprocesamiento controlado) no está disponible para los servicios Web.Esto significa que cuando se llama a objetos de modelo de subprocesamientocontrolado desde servicios Web, se produce un intercambio de subproceso. Elresultado es una ligera disminución del rendimiento, y si el servicio Web aplica lasuplantació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ónPara obtener más información acerca de las excepciones de acceso denegadocuando se llama a objetos COM de subprocesamiento controlado, consulte elartículo Q325791,"PRB: Access Denied Error Message Occurs WhenImpersonating in ASP.NET and Calling STA COM Components" (en inglés) enla Knowledge Base de Microsoft.Para obtener más información acerca de cómo obtener acceso a los objetosCOM y utilizar el atributo AspCompat, consulte el apartado "Obtener acceso alos objetos COM" del capítulo 8, "Seguridad de ASP.NET".Para obtener más información acerca de cómo llamar a objetos COM desubprocesamiento controlado desde los servicios Web, consulte el artículoQ303375, "INFO: XML Web Services and Apartment Objects" (en inglés), de laKnowledge Base de Microsoft.Utilizar certificados de cliente con los serviciosWebEn esta sección se describen las técnicas para utilizar los certificados de clienteX.509 para la autenticación de servicios Web.

Puede utilizar la autenticación mediante certificados de cliente desde un servicioWeb para autenticar los siguientes elementos:Otros servicios WebAplicaciones que se comunican directamente con el servicio Web (porejemplo, aplicaciones basadas en servidores o aplicaciones de escritorio decliente)Autenticar clientes de explorador Web mediantecertificadosUn servicio Web no puede utilizar certificados de cliente para autenticar a losllamadores si éstos interactúan con una aplicación Web intermedia, puesto que no esposible reenviar el certificado del llamador original al servicio Web a través de laaplicación Web. Mientras que la aplicación Web puede autenticar a sus propiosclientes mediante certificados, dichos certificados no pueden utilizarse en el servicioWeb para la autenticación.El motivo por el que da errores este escenario “servidor a servidor” es que laaplicación Web no tiene acceso al certificado del cliente (en especial a la claveprivada) de su almacén de certificados. Este problema se muestra en la ilustración10.7.{Insert figure: CH10 - Web service server-to-server certificate problem.gif}Ilustración 10.7Autenticación mediante certificados de cliente del servicio WebUtilizar el modelo de subsistema de confianzaLa solución a esta restricción pasa por utilizar un modelo de subsistema de confianzaque, además, reporta compatibilidad para la autenticación mediante certificados en elservicio Web. Con este enfoque, el servicio Web autentica la aplicación Webmediante el certificado de la aplicación Web (no con el certificado del llamadororiginal). El servicio Web confía en la aplicación Web para autenticar a sus usuariosy llevar a cabo la autorización necesaria que garantice que sólo los llamadoresautorizados sean capaces de obtener acceso a los datos y las funciones expuestospor el servicio Web.Este enfoque queda reflejado en la ilustración 10.8.

{Insert figure: CH10 - Web Service Certificate Authentication – TrustedSubsystem.gif}Ilustración 10.8El servicio Web autentica la aplicación Web de confianzaSi la lógica de autorización del servicio Web requiere varias funciones, la aplicaciónWeb podrá enviar certificados distintos según la función a la que pertenezca elllamador. Por ejemplo, puede utilizarse un certificado para miembros de un grupoAdministradores (con permisos para actualizar los datos de una base de datosservidor) y otro certificado para el resto de los usuarios (con autorización paraoperaciones de lectura exclusivamente).Nota: en escenarios como éste existe la posibilidad de utilizar un servidor decertificados local (al que sólo pueden obtener acceso los dos servidores) paraadministrar 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 querepresenta a la aplicación (o, quizás, un rango de certificados basados en lapertenencia a funciones del llamador).El servicio Web autentica la aplicación Web y confía en la aplicación paraejecutar la autorización de cliente necesaria.Se utiliza IPSec entre el servidor de aplicaciones Web y el servidor deservicios Web a fin de proporcionar un control de acceso adicional. IPSec evitalos intentos de acceso no autorizado desde otros equipos. La autenticaciónmediante certificados del servidor de servicios Web también evita el acceso noautorizado.Implementación de solucionesPara 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 elcertificado. 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 usuariocargado ni de almacén de certificados asociado. El proceso independiente debeconfigurarse para que se ejecute con una cuenta dotada de un perfil de usuarioasociado (y almacén de certificados). Existen dos opciones básicamente:Utilizar una aplicación de servidor de Servicios EmpresarialesUtilizar un servicio WindowsLa ilustración 10.9 muestra este escenario con una aplicación servidor de ServiciosEmpresariales.{Insert figure: CH10 - Web Service Certificate Authentication.gif}Ilustración 10.9Autenticación mediante certificados con servicios WebA 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 decliente.2. La aplicación Web es el equipo selector y, por lo tanto, responsable deautorizar el acceso a determinadas áreas de funcionalidad (incluidas aquéllasque suponen interacción con el servicio Web).3. La aplicación Web llama a un componente revisado mediante la ejecución deuna aplicación de Servicios Empresariales fuera de proceso.4. La cuenta utilizada para ejecutar la aplicación de Servicios Empresarialesdispone de un perfil de usuario asociado. El componente obtiene acceso alcertificado del cliente desde su almacén de certificados, que lo utiliza elservicio Web para autenticar la aplicación Web.5. El componente revisado llama al servicio Web y transmite el certificado delcliente en cada solicitud de método. El servicio Web autentica la aplicaciónWeb mediante este certificado y confía en la aplicación Web para que autoricecorrectamente a los llamadores originales.¿Por qué utilizar un proceso adicional?La necesidad de un proceso adicional (en vez de utilizar el proceso WebAspnet_wp.exe para ponerse en contacto con el servicio Web) se debe a que serequiere 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 aninguno de los certificados del servidor Web. El motivo radica en que los almacenesde certificados se conservan en los perfiles de usuario asociados a las cuentas deusuario interactivas. Los perfiles de usuario se crean exclusivamente para lascuentas interactivas cuando se inicia una sesión física con dichas cuentas. Elobjetivo de la cuenta ASPNET no consiste en actuar como una cuenta de usuariointeractiva y se configura con el privilegio "Denegar inicio de sesión interactivo" a finde mejorar la seguridad.Importante: no vuelva a configurar la cuenta ASPNET para eliminar este privilegioy convertirla en una cuenta de inicio de sesión interactivo. Utilice un procesoindependiente con una cuenta de servicio configurada para obtener acceso a loscertificados, como se ha descrito anteriormente en este capítulo.Más informaciónPara obtener más información acerca de cómo implementar este enfoque,consulte "Cómo llamar a un servicio Web mediante certificados de cliente deASPNET" 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 dosservidores" en la sección de referencia de este manual.Comunicación seguraLa comunicación segura hace referencia a la protección de la integridad y laconfidencialidad de los mensajes del servicio Web conforme se transmiten deaplicación en aplicación a través de la red. Se han desarrollado dos enfoques parasolucionar este problema: opciones para el transporte y opciones para los mensajes.Opciones para el transporteLas opciones para el transporte incluyen:SSLIPSecEstas opciones resultan apropiadas cuando se cumplen las siguientes condiciones:Se envía un mensaje directamente desde la aplicación a un servicio Web sinque 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 latransferencia del mensaje.Opciones para los mensajesLos enfoques relativos a los mensajes permiten proteger la confidencialidad eintegridad de los mensajes cuando pasan por un número arbitrario de sistemasintermedios. 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 sereenvíe a otros servicios Web o que se enrute a través de sistemasintermedios.No se tiene control sobre la configuración de los dos puntos finales; porejemplo, porque se envían mensajes de una empresa a otra.

Más informaciónWeb Service Development Toolkit incluirá funciones para el cifrado demensajes compatibles con la especificación de seguridad WS-Security.Si desea obtener más información acerca de SSL e IPSec, consulte el capítulo4, "Comunicación segura".ResumenEste capítulo se centra en la seguridad de los servicios Web (punto a punto) relativatanto a la plataforma como al transporte que pueden ofrecer los serviciossubyacentes de ASP.NET, IIS y el sistema operativo. Mientras que la seguridad de laplataforma permite soluciones seguras para escenarios de intranet estrechamentevinculados, no resulta conveniente para escenarios heterogéneos. Es por estemotivo precisamente por el que se requiere la seguridad que ofrece la especificaciónde seguridad WS-Security de la arquitectura GXA. Utilice Web Services DevelopmentKit 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 Webde ASP.NET a un servicio Web remoto, la aplicación Web de ASP.NETdebería utilizar la autenticación Kerberos (con cuentas configuradas para ladelegación), básica o mediante Formularios.Si utiliza la autenticación Kerberos, habilite la suplantación con laaplicación Web y configure la propiedad Credentials del proxy de servicioWeb mediante DefaultCredentials.Si utiliza la autenticación básica o mediante Formularios, capture lascredenciales del llamador y establezca la propiedad Credentials del proxyde 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 elproxy de cliente.Utilice una aplicación de Servicios Empresariales o un servicio de Windowsfuera de proceso para que manipule los certificados X.509 desde lasaplicaciones Web.En la medida de lo posible, utilice las comprobaciones de autorización desistema como, por ejemplo, la autorización mediante archivos y direccionesURL.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 servidoresde producto.Utilice la seguridad de transporte si no le preocupa transferir los mensajes deforma 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 ServicesDevelopment kit para desarrollar soluciones para mensajes.