Servicios Web

FECHA:

Diciembre 2011

Asignatura:

Programación Web

Alumnas:

Cruz Mendoza Lidia

Remigio Pantaleón Ana Gabriela

Romualdo Osorio Liliana

“Excelencia en la educación, fortaleza del país.”

¿Qué es un web service?

Un web service es una aplicación que puede ser descripta, publicada, localizada e invocada a través de una red, generalmente Internet. Combinan los mejores aspectos del desarrollo basado en componentes y la Web. Al igual que los componentes, los web services son funcionalidades que se encuentran dentro de una caja negra, que pueden ser reutilizados sin preocuparse de cómo fueron implementados. A diferencia de la actual tecnología de componentes, no son accedidos por medio de protocolos específicos del modelo de objetos como ser RMI, DCOM o IIOP; sino que son accedidos utilizando protocolos web como ser HTTP y XML. La interface de los web services está definida en términos de los mensajes que el mismo acepta y retorna, por lo cual los consumidores de los web services pueden ser implementados en cualquier plataforma y en cualquier lenguaje de programación, solo tiene que poder crear y consumir los mensajes definidos por la interface de los web services.

El modelo de web services.

La arquitectura básica del modelo de web services describe a un consumidor, un proveedor y ocasionalmente un corredor (broker). Relacionados con estos agentes están las operaciones de publicar, encontrar y enlazar. La idea básica consiste en que un proveedor publica su servicios en un corredor, luego un consumidor se conecta el corredor para encontrar los servicios deseados y una vez que lo hace se realiza un lazo entre el consumidor y el proveedor. Cada entidad puede jugar alguno o todos los roles.

Por todo lo anterior hay ciertos requerimientos a la hora de desarrollar o consumir un web services:

Una forma estándar de representar los datos. XML es la opción obvia para este requerimiento.

Un formato común y extensible de mensajes. SOAP es el elegido en este caso; SOAP es un protocolo liviano para el intercambio de información. Más adelante en este documento lo veremos con más detalle.

Un lenguaje común y extensible para describir los servicios. La opción en este caso es WSDL. Es un lenguaje basado en XML desarrollado en forma conjunta por IBM y Microsoft. Lo veremos con más detalle más adelante en este documento.

Una forma de descubrir los servicios en Internet. UDDI se utiliza en este caso; el mismo especifica un mecanismo para publicar y localizar los servicios por parte de los proveedores y consumidores respectivamente. Se verá con más detalle más adelante en este documento.

Ventajas y retos.

Los web services apuntan a ser la piedra fundamental de la nueva generación de sistemas distribuidos. Estos son algunos puntos para fundamentar esta afirmación:

Interoperabilidad: Cualquier web service puede interactuar con otro web service. Como los web services pueden ser implementados en cualquier lenguaje, los desarrolladores no necesitan cambiar sus ambientes de desarrollo para producir o consumir web services.

Encapsular reduce la complejidad Todos los componentes en un modelo de web services son web service. Lo importante es la interface que el servicio provee y no como esta implementado, por lo cual la complejidad se reduce.

Fácil de utilizar: El concepto detrás de los web services es fácil de entender, incluso existen toolkits de vendedores como IBM o Microsoft que permiten a los desarrolladores crear web services en forma rápida y fácil.

Soporte de la Industria: Todas las empresas de software importantes soportan SOAP, e incluso están impulsando el desarrollo de web services. Por ejemplo la nueva plataforma de Microsoft .NET esta basada en web services, haciendo muy simple el desarrollo de los mismos que luego podrían ser consumidos por un web service desarrollado utilizando VisualAge de IBM y viceversa.

A la vez hay ciertos retos técnicos que los web services tienen que sortear para poder tener éxito. Muchos de estos retos están relacionados con el ambiente abierto en el que tienen que sobrevivir. Estos son algunos de esos puntos:

· Descubrimiento: ¿Cómo un web service se anuncia para ser descubierto por otro servicio? ¿Qué pasa si el servicio se cambió o se movió luego de ser anunciado? WSDL y UDDI son dos nuevos estándares que manejan este punto.

· Confiabilidad: Algunos web services son más confiables que otros. ¿Cómo puede ser medida esa confiabilidad y comunicada? ¿Qué pasa cuando un web service esta off-line en forma temporaria? ¿Localizamos y utilizamos un servicio alternativo brindado por otra empresa o esperamos a que el servicio este de nuevo on-line?

· Seguridad: Muchos web services son publicados para ser utilizados sin ninguna restricción, pero muchos otros van a necesitar autenticación para que los utilicen solo los usuarios autorizados. ¿Cómo autentifica a los usuarios un web service? ¿Lo hace a nivel del método que lo implementa o utiliza otro web service para realizar la autenticación?

· Responsabilidad En caso de que el web service no sea de acceso libre, ¿Cómo puedo definir cuantas veces un consumidor puede acceder al web service una vez contratado? ¿Cómo se cobra su uso? ¿Cómo se indica que un servicio ya no está más en línea?

CARACTERÍSTICAS DE LOS WEB SERVICES

Los servicios web son la revolución informática de la nueva generación de aplicaciones que trabajan colaborativamente en las cuales el software está distribuido en diferentes servidores. La informática se inició con programas monousuarios implantados en grandes ordenadores. Posteriormente estas primeras aplicaciones alcanzaron la capacidad de atender a diferentes usuarios. Pasaron los años y llego la arquitectura cliente-servidor, que gracias a este modelo de desarrollo, la aplicación se dividía en una parte que interaccionaba con el usuario y otra parte destinada al procesamiento de información. En este acercamiento se consiguió que cada una de las partes que constituían la aplicación pudiera residir en computadoras distintas. Con el paso del tiempo, la computación aumento y llego la era de las aplicaciones distribuidas en las cuales los procesos se realizaban en diferentes unidades. De este paso surgió la tecnología Internet para solventar las problemáticas asociadas a fallo de aplicación centralizado.

Un desarrollador puede incluir en sus sitios soluciones sentencias, es decir, instrucciones que consuman Web Services de terceros o propios como por ejemplo aquellos que proporcionan los datos meteorológicos para una localidad determinada, las cotizaciones de determinadas monedas, la cartelera de películas, el calendario o agenda de un especialista médico, etc.

Pensando en forma comercial, ¿Qué pasaría si por ejemplo estuvieras trabajando en tu procesador de texto en un idioma para el cual no tienes un corrector ortográfico ni sintáctico instalado (quizás no exista para instalar), pero deseas realizar la revisión del documento a toda costa? Bien, perfectamente podría haber una opción en el menú de este procesador que de alguna forma localice un Web Service en Internet que brinde esta funcionalidad, y lo más interesante aún para quien lo haya desarrollado es que puede solicitar al usuario que se subscriba para su uso. Como ves, todos ganan en esta transacción.

El ejemplo anterior muestra una realidad a la que no podemos estar ajenos. Es un replanteo de la estrategia utilizada por los desarrolladores quienes ahora, al realizar una aplicación, no deben pensar únicamente en el lugar físico donde la misma va a ejecutarse sino en que esa aplicación deberá estar interconectada con otras computadoras, corriendo otras aplicaciones quizás en otras plataformas y lenguajes, pero usando protocolos y estándares universales. El intercambio se intensificará muchísimo más y quizás existan por ejemplo “proveedores de dominios de datos” como ser los países, de forma tal que la aplicación que yo realice en lugar de crear toda la lógica para manejar las tablas y el cargado de los datos para el concepto PAIS, se limite a consumir un Web Service que me tome esta información de algún lugar en Internet. Imagino una reutilización aún mayor de funcionalidades y una colaboración e intercambio de lógica a nivel mundial.

Existen algunas consideraciones y conceptos que son necesarios mencionar para comenzar a entender el tema:

Un Web Service puede ser registrado para poder dejarlo a disposición de otros usuarios y para que los mismos puedan localizarlo. Un mecanismo para registrar estos servicios es por medio de UDDI, sigla que corresponde a Universal Description , Discovery and Integration, un “repositorio de Web Services”. Para registrar un servicio tendrás que tener en cuenta que debes suministrar la información de tu empresa, en qué categorías ubicarías tu servicio y la interfaz a utilizar para consumir este servicio.

El mecanismo utilizado por un Web Service para especificar de qué forma hay que proporcionarle los datos, de manera tal que cualquiera pueda interaccionar con el mismo, es por medio de lenguaje XML. Esta información se almacena en un archivo llamado WSDL (Web Services Description Language), el cual contiene un documento XML junto con la descripción de ciertos mensajes SOAP y cómo deben intercambiarse, así como también dónde está el recurso del servicio y con qué protocolo debe dialogar quien lo consume.

El protocolo de comunicación utilizado es el SOAP generalmente, el cual es relativamente sencillo de utilizar.

Los Web Services utilizan protocolos comúnmente conocidos y difundidos tales como el formato XML, TCP/IP como protocolo de transporte y HTTP como protocolo de transferencia de hipertexto.

Microsoft para conseguir este propósito con su tecnología .NET emplea como protocolo de comunicación, una aplicación XML, llamada SOAP. ¿Qué es SOAP? Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado por David Winer, XML-RPC en 1998. En su sitio web, Userland, http://ww.userland.com se puede encontrar multitud de documentación acerca de este primer protocolo de comunicación bajo http mediante XML. Con este protocolo se podian realizar RPC o remote procedure calls, es decir, podiamos bien en cliente o servidor realizar peticiones mediante http a un servidor web. Los mensajes debían tener un formato determinado empleando XML para encapsular los parámetros de la petición. Con el paso del tiempo el proyecto iniciado por David Winer interesó a Importantes multinacionales entre las que se encuentran IBM y Microsoft y de este interés por XML-RPC se desarrolló SOAP. SOAP es un protocolo más completo que XML-RPC pero cabe decir que más complejo. La siguiente tabla comparativa muestra las diferencias entre ambos protocolos:

Caracteristicas XML-RPC

SOAP

Escalarares básicos. yes yes

Estructuras. yes yes

Arrays. yes yes

Estructuras nombradas y Arrays. no yes

Manejo de fallos. yes yes

Curva de aprendizaje. yes no

Conjunto de caracteres. no yes (US-ASCII, UTF-8, UTF-16)

Tipos de datos definidos por usuario. no yes

Requiere entendimiento del cliente. no yes

Instrucciones de procesamiento Especificas.

no yes

A continuación se muestra un ejemplo de SOAP:

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "http://example.org/2001/06/quotes" env:encodingStyle="http://www.w3.org/2001/06/soap-encoding" xmlns:m="http://example.org/2001/06/quotes"> DIS

GOOGLE

Plataforma de desarrollo

Para la implementación de la aplicación se ha escogido el entorno de desarrollo web Cocoon.

Cocoon es un producto open source perteneciente al proyecto Apache Cocoon La versión de

Cocoon utilizada, 2.1.5, incluye todo lo necesario para su puesta en marcha (servidor web y

contenedor de servlets), excepto el entorno de desarrollo de Java (J2SE) que debe estar

instalado previamente. En nuestro caso, utilizamos la versión 1.4.2 de J2SE. El entorno puede

desplegarse tanto en una máquina Windows como en un sistema Unix.

Cocoon es un entorno basado en Java enfocado a la construcción de aplicaciones web

basadas en componentes y en la separación de presentación y contenido. El elemento de

construcción de las aplicaciones es el pipeline o tubería, el cual realiza una serie de

transformaciones a una petición hasta generar un documento de salida. La representación

intermedia de los datos es en XML. Estos datos atraviesan una serie de elementos de

procesado hasta producir el documento de salida. La salida normalmente será una página

HTML, aunque también podría ser un archivo PDF o tener otros formatos.

Interfaz WSDL de Google

Google proporciona un archivo WSDL que describe las operaciones soportadas. Este fichero se

encuentra entre los archivos descargados de la API, aunque también se ofrece de forma online.

La descripción WSDL indica que se soportan tres operaciones: doSpellingSuggestion,

doGetCachedPage y doGoogleSearch. La primera permite solicitar a Google una sugerencia

de escritura correcta para un término mal tecleado. La segunda devuelve la caché almacenada

de Google para una URL dada. Por último, doGoogleSearch, se corresponde con el servicio

tradicional de búsquedas en la Web.

Cierto es que Google podría ofrecer un mayor número de operaciones, como el acceso a

grupos de noticias o búsqueda de imágenes. Sin embargo, la API está fechada en 2002 y no

parece que haya más interés que el de ofrecer un número limitado de operaciones como

demostración del sistema.

Operación doSpellingSuggestion

Su manejo es el más sencillo de las tres. Para su invocación requiere dos entradas:

key. Es el número de licencia proporcionado al usuario de la API.

phrase. Término o términos que deseamos verificar su corrección. Su salida es:

return. Término o términos corregidos. O nada, si no ha habido cambios.

Operación doGetCachedPage

Su interfaz también es muy sencilla. Requiere dos entradas (key y url) y devuelve como salida

la caché almacenada para la URL indicada. Entradas:

key. Es el número de licencia proporcionado al usuario de la API.

url. URL de la página o documento. Su salida es:

return. Contenido de la caché para la URL solicitada.

Operación doGoogleSearch

Esta operación es la que admite un mayor número de opciones de configuración. Entre las

entradas, las más importantes son la clave y la consulta solicitada, pero también hay otras que

debemos conocer:

key. Es el número de licencia proporcionado al usuario de la API.

q. Consulta formada por uno o varios términos de búsqueda.

start. Posición (índice) del primer elemento a partir del cual solicitamos la búsqueda.

maxResults. Número máximo de elementos que solicitamos a partir del indicado en la entrada anterior. El número devuelto podrá ser menor si no hay suficientes resultados encontrados.

filter. Tipo lógico que indica si realizamos la búsqueda filtrando los elementos similares a otros mostrados o no.

restrict. Permite restringir la búsqueda a un almacén de búsqueda determinado como, por ejemplo, “linux”.

safeSearch. Permite filtrar contenidos no aptos para menores.

lr. Restringe a un idioma determinado.

ie. Codificación de entrada (obsoleto).

oe. Codificación de salida (obsoleto).

La salida se devuelve mediante el elemento return del tipo complejo GoogleSearchResult. Este

tipo está formado por los siguientes elementos:

documentFiltering. Indica si la búsqueda se realizó con el filtro activo o no. searchComments. Comentarios de la búsqueda como, por ejemplo, cuando se indica que

ciertas palabras no se incluyeron en la búsqueda por ser poco relevantes. estimatedTotalResultsCount. Número de resultados totales. estimateIsExact. Indica si la cantidad devuelta en el elemento anterior es un número exacto o

aproximado. resultElements. Array construido con el tipo complejo ResultElement. Este array contiene un

elemento por cada resultado encontrado según las opciones de búsqueda. searchQuery. Consulta que se ha buscado. startIndex. Índice del primer resultado devuelto. endIndex. Índice del último resultado devuelto. Obsérvese que los resultados comprendidos

entre startIndex y endIndex serán un subconjunto del total de resultados, estimatedTotalResultsCount, sin exceder el número máximo de resultados que se solicitó, maxResults.

searchTips. Consejos de búsqueda como, por ejemplo, “elimine las comillas de la búsqueda para obtener más resultados”.

directoryCategories. Array construido con el tipo complejo DirectoryCategory. Se incluyen las distintas categorías del directorio ODP (Open Directory Project) que tienen relación con la consulta de búsqueda.

searchTime. Tiempo que se ha tardado en ejecutar la búsqueda.

Los elementos anteriores proporcionan información general de toda la búsqueda. Pasamos

ahora a describir los elementos del tipo complejo ResultElement, con información relativa a un

resultado concreto.

summary. Resumen escrito por un editor del directorio, en caso de que el sitio esté incluido en

el directorio.

URL. Identificador del documento.

snippet. Fragmento de texto del documento donde normalmente aparecerán los términos

buscados.

title. Título del documento.

cachedSize. Tamaño de la página almacenada en caché. Si no está almacenada, no devuelve

nada.

relatedInformationPresent. Indica si está soportada la búsqueda de documentos similares para

la URL de este resultado.

hostName. Indica el nombre del host en caso de que se haya mostrado ya al menos 1 resultado

de ese mismo host.

directoryCategory. Tipo complejo que indica la categoría del directorio donde está incluido el

sitio.

directoryTitle. Título de la categoría del directorio.

Invocación de operaciones desde Java

Google proporciona una API Java formada por una estructura de clases en un archivo .jar y

documentación en formato HTML. También se incluye un ejemplo de uso que funciona bajo

línea de comando.

Las clases Java encapsulan en métodos todo el procesamiento del web service. Por ejemplo,

para comprobar la corrección de un término basta con invocar el método doSpellingSuggestion

(phrase) que recibe un String y devuelve un String con el término corregido. Debido a la

posibilidad de incluir código Java en páginas XSP de Cocoon, resulta sencillo invocar los

métodos y procesar los resultados. Estos resultados se colocarán en elementos XML para que

puedan ser presentados en HTML después de convertirlos mediante una hoja de estilos XSLT.

El archivo googleapi.jar debe ubicarse en un directorio visible por Cocoon. En nuestro caso,

bastó con que estuviese presente en el directorio java/j2sdk/jre/ lib/ext antes de arrancar

Cocoon.

Cada una de las clases requeridas por la aplicación XSP debe incluirse una a una mediante

elementos <xsp:include>. Los archivos de la aplicación corregir.xsp y vercache.xsp utilizan este

procedimiento para comprobar la corrección de un término y ver la caché de una URL,

respectivamente.

Invocación de operaciones desde XSP

El procedimiento descrito en el apartado anterior es válido sólo en el caso del web service de

Google, puesto que se suministran clases Java que encapsulan todo el diálogo SOAP entre las

máquinas. Sin embargo, esto no será lo usual en otros web services, por lo que necesitaremos

confeccionar nosotros mismos los mensajes SOAP y procesar sus respuestas, según la

correspondiente descripción WSDL.

Cocoon facilita esta tarea mediante la funcionalidad “SOAP logicsheet” que se invoca en

páginas XSP con el elemento <soap:call>. Este elemento genera el mensaje SOAP enviando

los elementos que contiene, lo ejecuta e incluye la respuesta en su lugar.

Una vez tenemos la respuesta en formato XML, se puede procesar mediante una hoja de

estilos XSLT y convertirla así a HTML. Este procedimiento se ha utilizado en el archivo

buscar.xsp de la aplicación. En este caso no se utilizan las clases Java contenidas en el

archivo googleapi.jar. De la misma forma, se podrían haber realizado los archivos xsp de las

otras dos operaciones sin necesidad de utilizar las clases Java suministradas por Google, pero

hemos creído conveniente ofrecer ejemplos de ambos mecanismos para ilustrar las

posibilidades de Cocoon y Google Web API.

SEGURIDAD PROYECTO WebScarab OWASP Webscarab es un marco de trabajo para analizar servicios web que se comunica usando los protocolos HTTP y HTTPS. Está escrito en Java, por lo que es portable a muchas plataformas. WebScarab tiene muchos modos de operación, implementados por varios plugins. Su uso más común es operar WebScarab como un proxy de intercepción, que permite al operador revisar y modificar las peticiones creadas por el navegador antes de que sean enviados al servidor, y para revisar y modificar respuestas enviadas por el servidor antes de que sean recibidas por el navegador. Webscarab es capaz de interceptar comunicación en HTTP y HTTPS. El operador puede también revisar las conversaciones (peticiones y respuestas) que hayan pasado por WebScarab.

Consumo. WebScarab, es una herramienta diseñada principalmente para ser usada por personas que pueden escribir código por ellos mismos, o al menos tienen un muy buen conocimiento del protocolo HTTP. WebScarab está diseñado para ser una herramienta que cualquiera que necesite exponer la funcionalidad de una aplicación basada en HTTP(S), ya sea para permitir al desarrollador depurar problemas difíciles o permitir a un especialista en seguridad identificar vulnerabilidades mientras la aplicación está siendo diseñada o implementada.

Características Un marco de trabajo sin ninguna función que no valga la pena, por supuesto, WebScarab provee un número de plugins, cuyo objetivo principal, por el momento, es agregar funcionalidad de seguridad. Estos plugins incluyen:

Proxy - Observa el tráfico entre el navegador y el servidor Web. El proxy de WebScarab es capaz de observar tanto HTTP como trafico HTTPS cifrado al negociar una conexión SSL entre WebScarab y el navegador en vez de simplemente conectar el navegador al servidor y permitir que un flujo de datos cifrado pase por él.

Intercepción Manual - permite al usuario modificar peticiones y respuestas HTTP y HTTPS "al vuelo", antes de que ellas alcancen el servidor o el navegador.

SOAP - hay un plugin que interpreta WSDL, y presenta las varias funciones y los parámetros requeridos, permitiendo que sean editadas antes de que sean enviadas a el servidor.

XSS/CRLF - este plugin de análisis pasivo busca datos controlados por el usuario en los encabezados y cuerpo de las respuestas HTTP para identificar posibles inyecciones CRLF (partición de respuesta HTTP) y vulnerabilidades de secuencia de comandos en sitios cruzados (XSS). WS-SecureConversation Es un Web Services, creado por IBM y otros, que trabaja en conjunto con WS-Security, WS-Trust y WS-Policy para permitir la creación y el intercambio de contextos de seguridad. Ampliación de los casos de uso de WS-Security, con el propósito de WS-SecureConversation es establecer contextos de seguridad de varios intercambios de mensajes SOAP, lo que reduce la sobrecarga de establecimiento de claves.

Características

Establecer un nuevo contexto de seguridad en los modos siguientes: o Token de seguridad contexto creado por un servicio de token de seguridad (WS-

Trust STS) o Token de seguridad contexto creado por una de las partes que se comunican y

se propaga con un mensaje o Token de seguridad contexto creado a través de la negociación / intercambios

Renovar el contexto de seguridad Modificar el contexto de seguridad (agregar notificaciones) Cancelar el contexto de seguridad Derivar clave: las partes pueden usar claves diferentes a cada lado y la función (firmar /

cifrar), y las teclas cambian con frecuencia para evitar los ataques criptográficos

WS-SecureConversation tiene por objeto proporcionar un marco extensible y una sintaxis flexible, con la que se podría poner en práctica diversos mecanismos de seguridad. No garantiza por sí sola la seguridad, pero el ejecutor tiene que asegurarse de que el resultado no es vulnerable a cualquier ataque.

Pros / Contras Siguiendo un patrón similar a TLS, WS-SecureConversation establece una especie de clave de sesión. La sobrecarga de procesamiento para el establecimiento de claves se reduce significativamente en comparación con WS-Security en el caso de intercambios de mensajes con frecuencia. Sin embargo, una nueva capa se coloca en la parte superior de WS-Security, que implica otros protocolos WS-* como WS-Addressing y WS-Trust. Por lo tanto la importancia del desempeño tiene que ser comparado con la complejidad añadida y dependencias. OWASP - WSFuzzer OWASP (Open Web Application Security Project) es una comunidad creada con la finalidad de establecer métodos de trabajo seguro a la hora de desarrollar aplicaciones web. OWASP posee un modelo de mecanismos de seguridad ante amenazas incluyendo recomendaciones al respecto. El proyecto está formado por una amplia colección de guías y herramientas, para ayudar al desarrollo seguro de aplicaciones y auditorias. Dentro de las herramientas de seguridad que engloba OWASP, una de las más interesantes es WSFuzzer. Una herramienta de test de penetración para servicios web basados en HTTP SOAP.

Características:

Hace pruebas de intrusión en un servicio Web basado en HTTP SOAP ya sea en un WSDL, un punto final (endpoint) o un nombre (namespace).

Puede detectar inteligentemente WSDL. Incluye un scanner de puertos TCP simple. WSFuzzer tiene la habilidad de manipular métodos con múltiples parámetros. Hay 2

modos de ataque: "individual" y "simultaneo". Cada parámetro puede ser tratado como una entidad única (modo individual), o múltiples parámetros son atacados simultáneamente.

La generación de ataques consiste en: una combinación de un archivo de diccionario, algunos grandes patrones de inyección dinámicos opcionales y algunos ataques específicos incluyendo generación de ataques automáticos de XXE y WSSE.

La herramienta también proporciona la opción de usar algunas técnicas de evasión de IDS, lo que lo hace una poderosa experiencia de pruebas de seguridad de infraestructura (IDS/IPS). Realiza una medida de tiempo entre cada petición y respuesta para ayudar potencialmente en el análisis de resultados.

Para cualquier ejecución del programa los vectores de ataque generados son guardados en un archivo XML. El archivo XML es ubicado en el mismo directorio donde se guardan el archivo de resultados HTML.

Un archivo XML previamente generado de vectores de ataque puede ser utilizado en lugar de la combinación de diccionario/automatizado. Esto sirve para cuando se necesitan los mismos vectores para ser usados una y otra vez.

MICROSOFT CREACIÓN DE SERVICIOS WEB Microsoft mantiene su compromiso de fomentar el desarrollo de un rico ecosistema para la creación y gestión de sistemas interconectados. Microsoft ha realizado cuantiosas inversiones en servicios Web, basando por completo su plataforma de desarrollo de última generación en los servicios Web con Microsoft .NET. .NET FRAMEWORK 3.0 .NET Framework pone dentro del sistema operativo soluciones pre-codificadas que anteriormente han sido generadas mediante lenguajes de programación y herramientas de distintos tipos. .NET Framework proporciona el soporte necesario para los servicios Web, de manera que los desarrolladores puedan codificar, descubrir, depurar, instalar y consumir servicios Web utilizando cualquiera de los más de 20 lenguajes de programación soportados por este entorno. La versión 3.0 de .NET Framework, aparecida en 2006, amplía las interfaces de programación de la versión 2.0 con nuevas tecnologías para la creación de aplicaciones a fin de proporcionar comunicaciones interoperables y fluidas, la capacidad de modelizar una gran variedad de procesos de negocio y gestionar la identidad y crear experiencias diferenciadas para los usuarios. Los componentes extendidos de .NET Framework 3.0 para la creación y aprovechamiento de los servicios Web son Windows Communication Foundation (WCF), Windows Workflow Foundation (WF), Windows CardSpace, y Windows Presentation Foundation. Concretamente, WCF y WF incorporan nuevas y muy potentes funcionalidades para el desarrollo de aplicaciones basadas en servicios web y bien integradas: • Windows Communication Foundation es la tecnología de servicios Web de nueva generación de Microsoft, que facilitan la interconexión entre sistemas y aplicaciones dentro de la organización y a lo largo de infraestructuras geográficamente dispersas. Es el primer modelo de programación creado de principio a fin para facilitar el desarrollo de aplicaciones orientadas a servicios.

• Windows Workflow Foundation es un modelo de programación, un motor y herramientas para la creación rápida de aplicaciones con gestión de workflow en entornos Windows. BIZTALK SERVER Como complemento a las tecnologías de desarrollo .NET Framework 3.0, BizTalk Server es un producto de servidor orientado a los profesionales de IT y arquitectos, que permite la integración de sistemas, empleados y partners de negocio. El núcleo de la arquitectura de BizTalk Server se basa en XML y .NET Framework y es plenamente compatible con todos los estándares abiertos en los que se basan los servicios Web. Una solución BizTalk puede consumir los servicios Web actuales y exponer los procesos de negocio (orquestaciones de BizTalk) como servicios Web. BizTalk se posiciona como la capa de gestión que organiza los servicios Web, controlando el flujo y las interacciones entre ellos y agregando los servicios individuales dentro de una solución compuesta de nivel superior. BizTalk Server permite también la integración de aplicaciones y sistemas que no son compatibles con los servicios Web. Mediante el empleo de una gran variedad de adaptadores, BizTalk Server puede hacer que las funcionalidades de sistemas y aplicaciones antiguos queden disponibles de cara a los procesos internos de las organizaciones. BizTalk Server se integra también con Microsoft Office SharePoint Server. Juntos, BizTalk Server y SharePoint facilitan la creación de soluciones de procesos de negocio “preparados para las personas” que afectan a los profesionales de la información. SharePoint permite a estos profesionales recopilar y gestionar datos de negocio (mediante la captura de datos en XML, estructurados y no estructurados), aportando la pieza de desktop esencial en el puzle de las soluciones de procesos de negocio. Biztalk Server, en este caso, actúa como el punto central de orquestación para los procesos de gran envergadura, que abarcan tanto a sistemas de información como a personas. . Microsoft Office SharePoint Server Windows SharePoint Services 3.0 proporciona servicios Web para interaccionar con casi cualquier aspecto de cada servidor, sitio, lista, biblioteca, encuesta o página Web basada en Windows SharePoint Services 3.0. En los procedimientos siguientes se utiliza el servicio Web Webs. El servicio Web Webs proporciona métodos para trabajar con sitios y subsitios de SharePoint. Por ejemplo, puede usar este servicio Web para mostrar y realizar consultas de los títulos y direcciones URL de todos los sitios contenidos en la colección actual de sitios, de los títulos y direcciones URL de todos los sitios ubicados directamente debajo del sitio actual, o de la dirección URL del sitio principal de la dirección URL de la página especificada. También Microsoft Office SharePoint Server 2007 proporciona una experiencia de usuario sencilla y consistente, gracias a aplicaciones de cliente muy conocidas y con ello hace que las tareas de iniciación de procesos de negocio de tipo manual, la participación en estos procesos, su seguimiento y la elaboración de informes sea mucho más sencilla y flexible. Está diseñado para optimizar la forma en que las personas interactúan con los contenidos y los procesos dentro de las organizaciones y a través de ellas. Office SharePoint Server permite aprovechar las ventajas de los workflows para automatizar y mejorar la visibilidad de las actividades de negocio más habituales, como son la revisión y aprobación de documentos, el seguimiento de incidencias y la recogida de firmas. Su excelente integración con aplicaciones

muy conocidas de cliente, el correo electrónico y los navegadores Web simplifica la experiencia del usuario. Los usuarios finales pueden definir y modelar con facilidad sus propios procesos aplicando herramientas de Microsoft muy familiares. Office SharePoint Server contribuye a eliminar los procesos manuales de gestión de la información, ineficientes en general. Los formularios electrónicos se pueden utilizar para recoger información que luego se puede integrar en los sistemas de línea de negocio (LOB), en los archivos documentales, pueden servir para iniciar procesos de workflow o enviarse a servicios Web. Esta automatización permite eliminar las redundancias y errores que afectan a la introducción manual de datos, y garantiza el acceso a datos más exactos y en tiempo real.

BIBLIOGRAFIA

http://translate.google.com.mx/translate?hl=es&langpair=en%7Ces&u=http://en.wikipedia.org/wiki/WS-Security

http://vtroger.blogspot.com/2008/09/auditoria-de-seguridad-de-servicios-web.html

https://www.owasp.org/index.php/Proyecto_WebScarab_OWASP

http://www.blueinfy.com/wsscanner.html