Seguridad en Web Services

Transcripción

1 Seguridad en Web Services Seguridad de la Información Depto. De Computación Facultad de Ciencias Exactas y Naturales Universidad de Buenos Aires Julio 2006 Hernán Garrido (hgarrido@dc.uba.ar) Cristian Zunino (czunino@dc.uba.ar)

2 Indice 1 Acerca de este documento Introducción a Web Services Tecnología de Web Services Roles en Web Services Stack de protocolos en Web Services Perspectivas Perspectiva del usuario Perspectiva del proveedor XML: Gramática de Web Services XML-RPC Estructura XML-RPC Modelo de datos Estructura del XML-RPC Request Estructura del XML-RPC Response WSDL: Descripción de Web Services Especificación WSDL Ejemplo SOAP: Acceso a Web Services UDDI: Publicación y Descrubimiento de Web Services Conceptos Básicos de Seguridad en Web Services XML-Signature: Firma Digital en XML Estructura básica de XML Signature Enveloping Signature Enveloped Signature Detached Signature Esquema detallado del elemento Signature Ejemplo completo Proceso de Generación de la firma Generación de las referencias Generación de la firma Proceso de Verificación de la firma Verificación de las referencias Verificación de la firma Algoritmos Disponibles XML-Encryption: Encriptación en XML Estructura de XML Encryption Ejemplo completo Proceso de Encriptación Proceso de Desencriptación Algoritmos disponibles Combinando XML Encryption y XML Signature SAML: Autenticación en XML Modo de trabajo de SAML Aserciones Aserciones de Autenticación Aserciones de Atributos Aserciones de Autorización... 37

3 12.3 Protocolo Authentication Request Attribute Request Authorization Request SAML Protocol Response Bindings WS-Security: Seguridad en SOAP Seguridad de Mensaje vs Seguridad de Transporte Extendiendo la Seguridad en SOAP Security Tokens en WS-Security Ejemplo de token username/password Ejemplo de ticket Kerberos Ejemplo de certificado X Ejemplo de token SAML Assertion Flujo de mensajes XML Encryption en WS-Security XML Signature en WS-Security Firmando parte o todo el mensaje Firmando un Security Token Ejercicio Práctico Enunciado Resolución Referencias...51

4 1 Acerca de este documento El presente documento analiza el uso de los métodos existentes para implementar seguridad en Web Services. En primer lugar se presentan a grandes rasgos los conceptos básicos de Web Services, luego se entrará más en detalle en estos conceptos y se irán agregando conceptos de seguridad en XML, que serán necesarios para poder brindar seguridad en Web Services. Por último se presenta un problema de ejemplo y se procede a analizarlo utilizando los conceptos descriptos en este documento. 1

5 2 Introducción a Web Services Casi todas las empresas, instituciones y organismos gubernamentales cuentan con distintas áreas o departamentos que usan sistemas informáticos y bases de datos específicos para realizar sus tareas y administrar su información. En la gran mayoría de los casos estos sistemas no fueron desarrollados para trabajar juntos y en muchos casos ni siquiera fueron desarrollados por el mismo equipo de desarrolladores. Sin embargo, tarde o temprano surge la necesidad natural de integrarlos, ya sea porque se necesita una interfase unificada que permita cruzar información de diferentes fuentes, evitar la duplicación de información y los problemas de consistencia asociados, o bien ofrecer servicios que utilicen Internet, e- commerce u otras tecnologías nuevas. Por este motivo surgen los Web Services que proveen un mecanismo de comunicación débilmente acoplado e independiente de la plataforma definidos sobre una gramática XML estándar que facilita la integración de los datos. 2.1 Tecnología de Web Services Los web services proveen un mecanismo estándar para que las aplicaciones puedan publicar y subscribirse a servicios de software a través de Internet o de una intranet. Las aplicaciones clientes (usuarios de web services) pueden localizar los servicios que proveen los servidores de aplicaciones (proveedores de web services) usando el estándar Universal Distribution Discovery and Integration (UDDI), obtener la definición de la interfase usando Web Services Description Language (WSDL), e intercambiar datos usando documentos XML a través de SOAP sobre protocolos universales tales como HTTP, FTP, y SMTP. El funcionamiento de los web services es comparable al de la web estándar en la que un servidor HTTP responde pedidos de un web browser enviándole páginas HTML. En contraste, en los web services existe un servidor SOAP basado en HTTP que escucha pedidos SOAP de aplicaciones cliente. El servidor SOAP interpreta los pedidos (que incluyen datos en formato XML) y luego responde al cliente. La respuesta puede consistir de una descripción en formato WSDL de los web services disponibles en el servidor, un mensaje de estado tal como la indicación de que un recurso no está disponible o que una transacción fue exitosa, o datos encapsulados en un documento XML. Para la aplicación cliente de un web service, éste aparece como una llamada a un método local, sólo que la llamada es traducida a XML (basándose en el estándar SOAP) y enviada a través de la red a la aplicación proveedora del servicio. Debido a que los web services son accesibles usando URLs, HTTP, y XML, están al alcance de cualquier aplicación desde cualquier plataforma de software o hardware. Resumiendo, un web service es cualquier servicio que esté disponible en Internet o en una red privada, use un sistema de mensajería XML estandarizado y no se encuentre atado a ningún sistema operativo ni lenguaje de programación. Además, hay dos propiedades adicionales que son deseables: un web service debería ser self-describing -si se publica el servicio también se debería publicar su interfase y alguna documentación mínima- que se logra mediante WSDL, y descubrible -discoverable, si se crea un web service debe haber un mecanismo fácil de publicación- que se logra gracias a UDDI. 2

6 2.2 Roles en Web Services Hay tres grandes roles en la arquitectura de web services: El Service provider es el proveedor del web service, que lo implementa y lo disponibiliza Un Service requestor es cualquier consumidor del web service, que lo accede a través de una conexión de red enviando un XML request Un Service registry es un directorio de servicios lógicamente centralizado donde los desarrolladores pueden publicar nuevos servicios o encontrar otros ya existentes El siguiente diagrama muestra los roles en un web service y la interacción entre ellos: 2.3 Stack de protocolos en Web Services El stack de protocolos en la arquitectura de web services tiene cuatro grandes capas: Servicio de transporte: es la capa responsable de transportar mensajes entre aplicaciones; pueden utilizarse los protocolos HTTP, SMTP, FTP u otros más nuevos (como BEEP) Mensajería XML: es la capa responsable de codificar mensajes en un formato XML común para que pueda ser entendido por ambos extremos; los protocolos más usados son SOAP y XML-RPC (XML Remote Procedure Call), aunque también se pueden usar los métodos GET/POST de HTTP y pasar documentos XML arbitrarios. Descripción del servicio: es la capa responsable de describir la interface pública de un web service específico; se utiliza WSDL (Web Service Description Language) Descubrimiento del servicio: es la capa responsable de centralizar web services en un lugar común y proveer funcionalidades de publicación y búsqueda; se utiliza UDDI (Universal Description, Discovery and Integration). El siguiente diagrama muestra el stack de protocolos de un web service: 3

7 2.4 Perspectivas Para entender con mayor claridad la interacción entre estos elementos, se puede ver el proceso desde la perspectiva del proveedor del servicio o desde la del usuario Perspectiva del usuario La perspectiva del usuario del servicio (service requestor) es la siguiente: 1. Identificar y descubrir los servicios relevantes a la aplicación buscándolos en el directorio UDDI. 2. Una vez identificado el servicio, localizar su descripción. Si es un servicio SOAP hallar el documento WSDL, y si es un servicio XML-RPC hallar documentación human-readable para conocer detalles de la integración. 3. Crear la aplicación cliente en algún lenguaje de programación (generalmente utilizando alguna herramienta automática). 4. Ejecutar la aplicación cliente para que invoque el web service Perspectiva del proveedor La perspectiva del proveedor del servicio (service provider) es la siguiente: 1. Implementar el servicio en algún lenguaje. 2. Desarrollar un wrapper del servicio, ya sea en XML-RPC o en SOAP. 3. Proveer documentación del servicio (en el caso XML-RPC) o un documento WSDL (en el caso SOAP). 4. Instalar el servicio y disponibilizarlo (deploy). 5. Publicar la existencia y especificación del servicio (en un directorio UDDI global o uno privado de la compañía). 4

8 3 XML: Gramática de Web Services XML (extensible Markup Language) fue desarrollado para representar datos de manera totalmente independiente de toda aplicación, protocolo, vocabulario, sistema operativo y lenguaje de programación con el objetivo de superar las limitaciones de HTML y, en particular, mejorar la creación y el manejo de contenido dinámico. Usando XML se pueden definir elementos que asocien significado a los datos, es decir, se describen los datos y qué hacer con ellos. XML es la base de descripción, descubrimiento e invocación de web services, a tal punto que WSDL, SOAP, XML Signature, XML Encryption y SAML se basan en XML. Por lo tanto, en nuestro contexto XML no sólo es utilizado para el formato de los mensajes sino también para definir los servicios y cómo utilizarlos. Dos partes que intercambian datos XML tienen que poder entenderlos e interpretarlos en la misma manera. Esto ocurre únicamente si ambos comparten la misma definición de los elementos que componen los datos. Para evitar que los nombres en un documento XML se confundan con otros, los XML namespaces proveen un mecanismo para mantenerlos separados y seguros, permitiendo que se creen los propios elementos y nombres de atributos sin que existan colisiones con otros ya existentes. Un esquema XML (XML Schema) define las reglas de un documento XML y permite que sea posible la validación automática (utilizando alguna herramienta para tal fin) del documento. Los esquemas definen los tipos de datos y su orden en el documento. Generalmente el prefijo de namespace xsd: identifica un elemento como parte de un esquema XML, como puede verse en el siguiente ejemplo: <xsd:schema xmlns:xsd=" <xsd:element name="customernumber" type="xsd:integer"/> 5

9 4 XML-RPC XML-RPC provee un mecanismo basado en HTTP y XML para hacer llamados a procedimientos o funciones remotos en una red. Utiliza el protocolo HTTP para pasar información de un cliente a un servidor de la siguiente manera: el cliente especifica el procedimiento y los parámetros en un XML request y el servidor devuelve un valor o un error en un XML response. Los parámetros son una lista simple de valores y tipos, y se debe tener en cuenta que los tipos de datos disponibles más complejos son los structs y arrays (XML-RPC no maneja objetos ni mecanismos más complejos de definición de tipos). Aunque XML-RPC posee ciertas limitaciones, su simplicidad es de mucha utilidad cuando los desarrolladores necesitan integrar sistemas de tipos muy diferentes. Al basarse en HTTP y XML, XML-RPC es independiente de la plataforma y se utiliza mayormente en dos escenarios, que a veces se superponen: Glue Code: los programadores e integradores de sistemas distribuidos suelen utilizar XML-RPC como glue code para conectar módulos dispares. En lugar de crear protocolos y formatos customizados que requieren testing, documentación y debugging, utilizan XML-RPC para conectar programas que corren en distintos entornos y sistemas, y de esta manera se focalizan en las interfaces específicas y no en el protocolo de conexión. En este escenario de uso, la distinción entre cliente y servidor es insignificante: un mismo programa puede tener implementaciones de cliente y servidor. Publicación de servicios: los desarrolladores pueden implementar un web service en cualquier lenguaje arbitrario y publicarlo a través de XML-RPC definiendo las interfaces apropiadas. Una vez disponible en la web, cualquier cliente que interprete XML-RPC puede utilizar el servicio. Este escenario es similar a las publicaciones webs, y también ocurre que el desarrollador tiene control sobre el servidor pero no necesariamente sobre el cliente. 4.1 Estructura XML-RPC XML-RPC consiste de tres pequeñas partes, que combinadas definen una llamada completa a un procedimiento remoto: Modelo de datos XML-RPC: es el conjunto de tipos de datos usados para pasar parámetros, devolver resultados y generar códigos de error (faults). Estructura XML-RPC Request: es un HTTP POST request que contiene información del método y los parámetros. Estructura XML-RPC Response: es un HTTP response que contiene el valor resultante o información de error, según el caso. 6

10 4.1.1 Modelo de datos La siguiente tabla contiene los tipos de datos básicos de XML-RPC, que pueden ser combinados en arrays y structs: Tipo de Dato Valor Ejemplos int o i4 entero de 32 bits <int>27</int> <i4>27</i4> flotants de 64 bits <double> </double> Double <double> </double> true (1) o false (0) <boolean>1</boolean> Boolean <boolean>0</boolean> texto ASCII <string>hello</string> String datetime.iso8 601 base64 fecha en formato ISO8601 información binaria codificada en base 64 (RFC 2045) Estructura del XML-RPC Request <datetime.iso8601> T02:20:04 </datetime.iso8601> <base64> SGVsbG8sIFdvcmxkIQ==</base64> Los XML-RPC requests son una combinación de headers HTTP con contenido XML. Cada request contiene un único documento XML cuyo elemento raiz es un methodcall, que a su vez contiene un elemento methodname que identifica el procedimiento a llamar y un elemento params que especifica los parámetros y sus valores. A modo de ejemplo, presentamos un XML-RPC request a un método llamado circlearea que toma como parámetro un radio de tipo double y devuelve el área del círculo: POST /xmlrpc HTTP 1.0 User-Agent: myxmlrpcclient/1.0 Host: Content-Type: text/xml Content-Length: 169 <?xml version="1.0"?> <methodcall> <methodname>circlearea</methodname> <params> <param> <value><double>2.41</double></value> </param> </params> </methodcall> Estructura del XML-RPC Response Los XML-RPC responses son muy parecidos a los requests pero con un par de detalles extra: el elemento methodcall se reemplaza por el elemento methodresponse y desaparece el elemento methodname. Si el llamado fue exitoso (es decir: el procedimiento fue encontrado, se ejecutó correctamente y devolvió un resultado), el elemento methodresponse contiene el resultado del procedimiento: 7

11 HTTP/ OK Date: Sat, 06 Oct :20:04 GMT Server: Apache (Unix) Connection: close Content-Type: text/xml Content-Length: 124 <?xml version="1.0"?> <methodresponse> <params> <param> <value><double> </double></value> </param> </params> </methodresponse> Si en cambio hubo algún problema, el elemento methodresponse contiene un elemento fault (en lugar de params) que indica el error encontrado: HTTP/ OK Date: Sat, 06 Oct :20:04 GMT Server: Apache (Unix) Connection: close Content-Type: text/xml Content-Length: 124 <?xml version="1.0"?> <methodresponse> <fault> <value> <struct> <member> <name>code</name> <value><int>26</int> </member> <member> <name>message</name> <value><string>no existe el método</string></value> </member> </struct> </value> </fault> </methodresponse> XML-RPC no estandariza los códigos de error en absoluto, por lo que se debe verificar cada documentación en particular para manejar los errores. Además, un XML-RPC response puede devolver un único valor, por lo que es necesario armar un struct si se desean devolver varios valores, como se muestra en el ejemplo anterior. Notar que al igual que los request, los responses también se empaquetan en headers HTTP, y por lo tanto todos los XML-RPC responses usan el código 200 OK, aunque el mensaje contenga un error. 8

12 5 WSDL: Descripción de Web Services WSDL (Web Service Description Language) es una especificación en XML que permite definir web services para que otros servicios sepan cómo invocarlo y dónde encontrarlo. Básicamente, describe cuatro tipos importantes de información asociada al web service: Interfaces de las funciones disponibles Tipos de datos de todos los mensajes request/response Binding information acerca del transporte a usar Ubicación del servicio Es decir, WSDL define qué funcionalidad provee el web service (interface y tipos de datos), cómo se comunica (es decir, cómo debe empaquetarse el mensaje en SOAP y cómo debe transferirse, lo que modifica el header SOAP) y dónde se encuentra. Cada uno de estos elementos puede ser especificado en un documento XML por separado y luego ser combinados para crear la descripción del web service o bien tener todos los elementos definidos en el mismo documento. WSDL es independiente de la plataforma y del lenguaje, y se usa principalmente (aunque no exclusivamente) para describir servicios SOAP. Permite que un cliente pueda localizar un web service e invocar cualquiera de sus funciones disponibles públicamente. Existen herramientas WSDL-aware que permiten automatizar este proceso, permitiendo que las aplicaciones integren fácilmente nuevos servicios automáticamente o con muy poco código. 5.1 Especificación WSDL La especificación define seis grandes elementos: El elemento definitions debe ser el elemento raíz de todo documento WSDL. Define el nombre del web service, declara los namespaces que utiliza y contiene los elementos restantes, descriptos a continuación. El elemento opcional types describe los tipos de datos usados entre el cliente y el servidor. Como ya se ha dicho, WSDL es independiente de la plataforma y del sistema de tipado, pero por defecto se puede utilizar la especificación de tipos W3C XML Schema, en cuyo caso no es necesario declarar el elemento. El elemento message describe un mensaje en un sentido, ya sea un request o un response. Define el nombre del mensaje y contiene cero o varios elementos part que hacen referencia a los parámetros o valores de retorno del mensaje, según el caso. El elemento porttype combina múltiples elementos message para formar una operación completa de ida y vuelta. El caso más común en servicios SOAP es combinar un mensaje request con otro mensaje response en una operación simple de request/response. Un puerto es básicamente un endpoint del servicio. El elemento binding especifica concretamente la implementación del service en la red: determina el método de transporte de red que llevará el mensaje a destino. El elemento service define la dirección para invocar el servicio, comúnmente incluyendo un URL. 9

13 WSDL también define el elemento documentation que puede ser usado para proveer documentación human-readable. La siguiente figura resume la especificación WSDL: 5.2 Ejemplo A modo de ejemplo, presentamos un documento WSDL que describe un servicio muy simple denominado HelloService, el cual provee una única función llamada sayhello que recibe un parámetro de tipo string y devuelve otro string con un saludo. Luego presentamos una breve descripción de la especificación. <?xml version="1.0" encoding="utf-8"?> <definitions name="helloservice" targetnamespace=" xmlns=" xmlns:soap=" xmlns:tns=" xmlns:xsd=" <message name="sayhellorequest"> <part name="firstname" type="xsd:string"/> </message> <message name="sayhelloresponse"> <part name="greeting" type="xsd:string"/> </message> <porttype name="hello_porttype"> <operation name="sayhello"> <input message="tns:sayhellorequest"/> <output message="tns:sayhelloresponse"/> </operation> </porttype> <binding name="hello_binding" type="tns:hello_porttype"> <soap:binding style="rpc" transport=" <operation name="sayhello"> <soap:operation soapaction="sayhello"/> <input> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingstyle=" 10

14 namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding> <service name="hello_service"> <documentation>wsdl File for HelloService</documentation> <port binding="tns:hello_binding" name="hello_port"> <soap:address location=" </port> </service> </definitions> El elemento definitions define que el documento es HelloService y especifica varios namespaces (que empiezan con xmlns:) que son útiles para referenciar múltiples especificaciones externas, incluyendo las especificaciones WSDL, SOAP y el XML Schema. Además, especifica el namespace por default (xmlns=...) para los elementos que no posean un namespace como prefijo y, por ende, se asumen parte del default (como message o porttype). Se definen 2 elementos message: uno representa un mensaje request (SayHelloRequest) cuyo subelemento part especifica el nombre y tipo de parámetro, y el otro representa un mensaje response (SayHelloResponse) cuyo subelemento part especifica el valor y tipo de retorno. Notar que los tipos type hacen referencia al tipo de datos definidos en el esquema XML Schema (xsd:). El elemento porttype define una operación simple (sayhello) combinando los dos elementos message recientemente definidos (SayHelloRequest y SayHelloResponse). Como era de esperar, se definen como request (input) y response (output) respectivamente. En este punto es interesante notar que WSDL soporta 4 tipos básicos de operación: One-way (el service recibe un mensaje), Request/Response (hay un mensaje de ida y otro de vuelta, es el caso ilustrado en el ejemplo y el más comunmente usado), Solicit/Response (el service envía un mensaje y luego recibe una respuesta) y Notification (el service envía un mensaje). El siguiente esquema muestra los 4 tipos básicos de operación: 11

15 El elemento binding provee detalles específicos sobre cómo la operación porttype recientemente definida será transmitida por la red. Pueden utilizarse varios métodos de transporte, incluyendo HTTP GET, HTTP POST o SOAP. Finalmente, el elemento service especifica la ubicación del servicio, de tipo SOAP en este ejemplo. Notar que se incluye también un elemento documentation con documentación on-line. El esquema del servicio presentado en el ejemplo es el siguiente: Dada la especificación WSDL del ejemplo, se puede crear manualmente un servicio SOAP que invoque el service definido o se pueden utilizar herramientas específicas que automatizan el proceso. De la misma manera, existen herramientas que generan automáticamente las descripciones WSDL a partir de servicios existentes. 12

16 6 SOAP: Acceso a Web Services Una vez que está definido el documento WSDL asociado al servicio, debemos definir la forma en la que los mensajes son enviados de una computadora a otra y de qué forma se ponen a disposición del destinatario. SOAP se define en XML y provee un mecanismo simple, independiente de la plataforma, consistente y extensible para transportar mensajes XML (framework de mensajería) de una computadora a otra a través de protocolos estándares de transporte, de los cuales HTTP es el más común. SOAP es lo que hace posible la integración de aplicaciones ya que una vez definido el contenido del mensaje en XML lo transporta de una máquina a otra. SOAP provee un envelope que empaqueta el mensaje XML y puede ser entendido por varios protocolos de transporte evitando que las aplicaciones se preocupen por el transporte. Dentro del elemento envelope hay otros dos grandes elementos: el encabezado (SOAP header) y el cuerpo (SOAP body). El elemento header contiene información acerca del mensaje SOAP en sí (a diferencia del mensaje XML contenido en el cuerpo SOAP) que es utilizada para manejar y asegurar el paquete. (Como se verá más adelante, WS-Security se incluye aquí.) SOAP es extensible, es decir que permite agregar nuevas funcionalidades a futuro, y el área para incluir estas extensiones es justamente el header. El elemento body contiene el payload XML original del mensaje, enviado desde una aplicación a otra. Puede ser un documento completo que el receptor decide cómo procesar o una descripción a una llamada remota, incluyendo los métodos y parámetros. El siguiente ejemplo ilustra estos elementos. <?xml version="1.0"?> <env:envelope xmlns:env=" <env:header> <n:alertcontrol xmlns:n=" <n:priority>1</n:priority> <n:expires> t14:00:00-5:00</n:expires> </n:alertcontrol> </env:header> <env:body> <m:alert xmlns:m=" <m:msg>alerta!!!</m:msg> </m:alert> </env:body> </env:envelope> Como ya se ha dicho, SOAP puede usarse sobre cualquier protocolo de transporte, tales como TCP, HTTP y SMTP. La especificación de SOAP provee un framework flexible para definir bindings de protocolo arbitrarios y provee un binding explícito para HTTP debido a su popularidad de forma tal de mantener la interoperabilidad. Más aún, el modelo de procesamiento de SOAP permite incluso la presencia de múltiples nodos intermediarios, cada uno con su propio protocolo, como lo ilustra la siguiente figura: 13

17 Cada nodo, ya sea intermediario o final, puede procesar, agregar o eliminar información del header SOAP que puede contener directivas de procesamiento y seguridad, pero por ningún motivo pueden alterar el cuerpo del mensaje. Si un nodo intermediario no reconoce algún elemento, puede ignorarlo, desechar el paquete SOAP completo o realizar un graceful failure, según lo especifique el emisor. Esto es importante desde el punto de vista de seguridad: uno no quiere que un nodo intermediario forwardee un paquete SOAP si el header contiene información crítica de seguridad y el nodo lo ignora por no entenderlo. Debido a la popularidad de RPC, SOAP define además una manera de realizar llamadas remotas sobre HTTP. En el modo de operación normal (o sea, orientado a documento) el cliente envía el documento XML como payload del mensaje SOAP y espera el mensaje de respuesta del servidor. En este caso el cliente desconoce cómo se encuentra implementado el servicio y cómo se procesa su mensaje. Por el contrario, en el modo de operación RPC se provee un mecanismo de llamada remota transparente para el cliente donde se traduce la llamada a XML, se la envía al servidor y se toma el mensaje de respuesta como el valor de retorno. Este modo de operación es recomendable en comunicaciones sincrónicas entre servicios fuertemente acoplados. Aunque suelen confundirse, request/response no es lo mismo que RPC: si bien es cierto que RPC usa request/response, lo contrario no es cierto. Un request SOAP se envía comúnmente como un HTTP POST con el content type seteado como text/xml y un campo SOAPAction seteado en vacío o con el nombre del método, según el caso. De esta manera, el receptor detecta el mensaje SOAP y actúa en cuestión. El siguiente ejemplo muestra mensajes SOAP request y SOAP response (se omiten los headers): <SOAP-ENV:Envelope... <SOAP-ENV:Body> <m:getorderstatus xmlns:m=" <orderno>43564</orderno> </m:getorderstatus> </SOAP-ENV:Body> </SOAP-ENV:Envelope> <SOAP-ENV:Envelope... <SOAP-ENV:Body> <m:getorderstatusreply xmlns:m=" <orderstatus>shipped June 18</orderstatus> </m:getorderstatusreply> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 14

18 7 UDDI: Publicación y Descrubimiento de Web Services Una vez que se definieron los datos en el mensaje (XML), se detallaron las interfaces que provee y dónde se encuentra el servicio (WSDL) e identificado el método de envío y recepción de los mensajes (SOAP), se necesita una forma de publicar el servicio ofrecido y buscar los servicios que otros ofrecen y uno quisiera usar. Esta es la función que UDDI (Universal Distribution, Discovery and Integration) provee: un repositorio administra información en formato XML acerca de proveedores y tipos de servicios y la disponibiliza a potenciales clientes de web services. Los datos almacenados se dividen en 3 categorías: White Pages: incluye información general acerca de una compañía específica, como por ejemplo nombre, descripción y dirección. Yellow Pages: incluye datos clasificados por categoría tanto de servicios como de compañías, como por ejemplo el tipo industrial. Green Pages: incluye información técnica sobre el web service: un link a la especificación externa (WSDL) y la ubicación del servicio. UDDI puede utilizarse dentro de grandes compañías para centralizar la publicación y búsqueda de servicios internos o directamente en Internet para hallar web services públicos. Los pedidos UDDI también viajan sobre SOAP, tal como muestra el siguiente ejemplo de consulta que, incluido en el cuerpo de un SOAP envelope, trae información sobre la compañía Microsoft: <find_business generic="1.0" xmlns="urn:uddi-org:api"> <name>microsoft</name> </find_business> 15