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 ([email protected]) Cristian Zunino ([email protected])

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

19 8 Conceptos Básicos de Seguridad en Web Services Como ya se ha mencionado, los web services son una tecnología para integrar fuentes de información y representan la nueva encarnación de middlewares distribuidos. A diferencia de los middlewares ya existentes, los web services constituyen una tecnología simple, basada en estándares y más débilmente acoplada para interconectar datos, sistemas y organizaciones. Esto facilita la tarea de programadores y arquitectos de software al desarrollar sistemas unificados. Sin embargo, los middlewares necesitan mecanismos fuertes de seguridad, y en el caso de web services esta necesidad es aún mayor debido a diversas causas: integran tanto sistemas internos como fuentes de datos externas (y eventualmente no confiables) a la organización, poseen el débil acoplamiento que los caracteriza, se basan en el pasaje de mensajes XML, que son leibles y auto-descriptivos, se basan en tecnologías subyacentes que ya tienen problemas de seguridad. La seguridad afecta todas las capas y mecanismos asociados a los web services, o sea, XML, SOAP, WSDL y UDDI. En primer lugar, SOAP necesita ser asegurado: el mensaje que transporta debe mantenerse secreto ante receptores no deseados y el servicio remoto que está siendo invocado debe conocer el cliente y saber si está autorizado a realizar la llamada. SOAP es el mecanismo que empaqueta los mensajes y documentos XML, y necesita describir información importante acerca de su contenido, tales como quién es el emisor, cómo un receptor puede confiar en la identidad del emisor y qué operaciones tiene permitidas el emisor. Estos temas están relacionados con la identidad y la confianza y deben ser tenidos en cuenta en el uso de estas tecnologías. Se espera que los procesadores SOAP (tanto intermediarios como finales) autentiquen identidades, implementen seguridad basada en roles respecto a las autorizaciones, encripten o desencripten el contenido del mensaje, validen firmas digitales, implementen protocolos de seguridad extendidos y recurran a terceras partes confiables en caso de ser necesario. Si se utiliza SOAP sobre HTTP se puede asegurar SOAP directamente aplicando SSL debido a que las aplicaciones web y los web servers ya saben cómo aplicar SSL a HTTP. Sin embargo, este enfoque sólo funciona para web services point-to-point. En los casos de web services multi-hops, que incluyan identidad o que requieran asegurar la integridad del mensaje, SSL no alcanza para asegurar SOAP. Este es el motivo por el que se decidió que los headers SOAP sean extensibles con nuevas directivas de seguridad. WS-Security surge como un estándar que utiliza mecanismos de seguridad para proteger mensajes SOAP (y por ende, los web services) incorporando tokens de seguridad en el header SOAP que incluyen identidad y seguridad persistente desde el punto de vista de integridad y confidencialidad. Por otro lado, WSDL también presenta problemas de seguridad: un documento WSDL publicado permite que cualquier usuario o sistema pueda leer la especificación y ubicación del web service y pueda accederlo. Por lo tanto, se debe utilizar algún mecanismo de autenticación para evitar que el servicio sea usado en forma malintencionada (como por ejemplo saturar el servicio o intentar acceder a otros datos de forma ilegal). Las organizaciones deben, como mínimo, proteger el URL del documento WSDL mediante SSL solicitando la autenticación del cliente en caso de que desee accederlo. 16

20 Por último, la seguridad es también un tema importante en los registros UDDI. Por ejemplo, quién está autorizado a publicar, utilizar y actualizar las descripciones de los web services? Las relaciones de negocio requieren confianza y por lo tanto la autoría, la autenticación y la autorización de las entidades que publican y consultan servicios deben ser explícitamente manejadas por UDDI, especialmente en el caso de Internet pública. UDDI confía en los mecanismos de seguridad existentes para XML y web services: con XML Signature establece la identidad de las entidades que publican y se subscriben y firma los documentos WSDL, con SAML establece la autorización y provee el control de acceso a los registros UDDI y con XML Encryption controla quién puede ver o utilizar un registro encriptando sus elementos. Una vez entendida la problemática respecto a la seguridad de la información se puede entrar en detalle en los conceptos y mecanismos existentes para brindar seguridad en XML y extenderlos a los web services en general. Los tres mecanismos básicos son XML Signature, XML Encryption y SAML, que serán explicados a lo largo del presente documento, al igual que sus extensiones a SOAP en el marco de WS-Security. 17

21 9 XML-Signature: Firma Digital en XML XML Signature es una extensión de la infraestructura existente de firma digital que define como garantizar la integridad, la autenticidad y el no-repudio de mensajes XML. XML Signature es uno de los pilares de WS-Security y permite representar firmas digitales como documentos XML. Para asegurar la integridad de un documento XML (o sea, asegurar que el archivo no fue alterado entre el origen y el destino), el estándar le permite al emisor agregar una firma digital al mensaje utilizando su clave privada. Una vez que el mensaje llega al receptor, éste puede validar la firma utilizando la clave pública del emisor y determinar si el documento ha sufrido cambios o no. Además, se garantiza la autenticidad del mensaje (es decir, se asegura que el emisor es quien dice ser) y el no-repudio (el emisor no puede ignorar este hecho) debido a que en la firma se utiliza la clave privada del emisor: si la firma es validada, entonces la identidad es confirmada. Como XML Signature es en sí parte del documento XML, tiene su esquema XML correspondiente que determina cómo debe ser estructurado en el documento. Dentro de la estructura XML Signature hay referencias a los elementos que se van a firmar, que pueden ser ítems del mismo documento o ser externos. Además, la estructura puede aparecer varias veces dentro de un mismo documento, utilizando distintas claves en cada caso, y permite el uso de varios métodos de firma digital y autenticación, lo que convierte a XML Signature en un estándar poderoso y flexible. 9.1 Estructura básica de XML Signature La estructura básica de XML Signature contiene 4 ítems: Un conjunto de referencias a elementos que serán firmados La firma actual La clave (o alguna manera de obtenerla) para verificar la firma (Opcional) Un elemento Object que contiene ítems no incluídos en los anteriores (Opcional) A continuación presentamos un ejemplo muy simplificado de XML Signature para que se pueda apreciar la estructura descripta más arriba. <Signature xmlns=" <SignedInfo> <Reference URI=" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>... </KeyInfo> </Signature> El elemento Signature es obligatorio y contiene todo lo relacionado a la firma. Sus elementos hijos son: SignedInfo que contiene información acerca de lo que se firma, SignatureValue que contiene la firma digital en sí y el elemento KeyInfo que contiene la clave pública necesaria para validar la firma o información sobre cómo obtenerla. SignedInfo contiene información acerca de QUÉ se firma: está compuesto por uno o más elementos Reference que apuntan a elementos internos o externos al 18

22 documento XML que serán incluidos en la firma. Los elementos internos pueden ser parte del elemento Signature o estar afuera, y los elementos externos pueden ser archivos binarios, de texto o incluso otro documento XML. Esto permite una gran flexibilidad ya que pueden mezclarse elementos de diversas fuentes y tipos en una única firma. Existen los siguientes tipos de XML Signatures: Enveloping, Enveloped y Detached, que son casos particulares de uso y definen distintos tipos de firmas Enveloping Signature En este tipo de firma la referencia es a un elemento dentro del elemento Signature, puntualmente incluido en el elemento Object: <Signature xmlns=" <SignedInfo> <Reference URI="#111" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> <Object> <SignedItem id="111">stuff to be signed</signeditem> </Object> </Signature> Enveloped Signature En este tipo de firma, la referencia es a un elemento padre del elemento Signature: <PurchaseOrder id="po1"> <SKU>125356</SKU> <Quantity>17</Quantity> <Signature xmlns=" <SignedInfo> <Reference URI="#po1"> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> </Signature> </PurchaseOrder> 19

23 9.1.3 Detached Signature En este tipo de firma, la referencia es a un elemento externo al elemento Signature, que puede ser parte del mismo documento XML (interno) o ser externo, ya sea binario, de texto u otro documento XML. El siguiente ejemplo ilustra el caso interno, donde se observa que la referencia apunta a un elemento dentro del mismo documento XML pero que no es ni padre ni hijo del elemento Signature: <PurchaseOrderDocument> <PurchaseOrder id="po1"> <SKU>12366</SKU> <Quantity>17</SKU> </PurchaseOrder> <Signature xmlns=" <SignedInfo> <Reference URI="#po1"> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> </Signature> </PurchaseOrderDocument> 20

24 El siguiente ejemplo ilustra el caso externo, donde se observa que la referencia apunta a un archivo JPEG: <Signature xmlns=" <SignedInfo> <Reference URI=" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> </Signature> Hay que destacar que los tres tipos de firmas presentados pueden coexistir dentro de un mismo documento. Es decir, un XML Signature puede ser Enveloping, Enveloped y Detached al mismo tiempo, lo que significa que el elemento Signature contiene varios elementos Reference de diferentes tipos. 9.2 Esquema detallado del elemento Signature A continuación presentamos el esquema completo del elemento Signature definido en la especificación 1 de XML Signature. <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature> 1 En la definición de sintaxis XML se suelen utilizar indicadores de cardinalidad acompañando a cada elemento del esquema. Si hay exactamente 1 ocurrencia no se utiliza ningún indicador; si hay 0 ó 1 ocurrencia se utiliza el indicador?; si hay 1 o más ocurrencias se utiliza el indicador +; y finalmente, si hay 0 o más ocurrencias se utiliza el indicador *. 21

25 El elemento Signature debe tener al menos un elemento SignedInfo y un elemento SignatureValue; opcionalmente puede tener un elemento KeyInfo y un elemento Object donde se incluyen los elementos que serán firmadas si se utiliza la referencia Enveloping. Como ya se ha dicho, el elemento SignedInfo contiene todo lo que será firmado: debe contener el algoritmo de Canonicalización XML (CanonicalizationMethod), el método de firma (SignatureMethod), y uno o más elementos de referencia. La estrategia de Canonicalización se utiliza para estandarizar las estructuras XML de modo tal que se puedan comparar a través de múltiples plataformas. Los elementos Reference son punteros a lo que se va a firmar: cada uno tiene un atributo URI que apunta a un elemento y un DigestMethod que indica el algoritmo de hashing de una vía usado en el cálculo del digest (DigestValue) del elemento referenciado. El poder y la flexibilidad que brindan las URIs para referenciar a cualquier tipo de recurso son fundamentales en la flexibilidad lograda en XML Signature. Opcionalmente, cada referencia puede contener un elemento Transform que indica el tipo de transformación que sufre el elemento a firmar. La transformación es un proceso útil y necesario (pero potencialmente peligroso) que modifica los datos antes de ser firmados con el objetivo de estandarizar (o canonicalizar) la representación de los mismos. Ejemplos de posibles transformaciones son la canonicalización de documentos XML y la representación de datos binarios en base64, entre otros. El elemento SignatureValue es la firma digital codificada en base64 del bloque SignedInfo. Es importante aclarar que lo que se firma es el contenido del bloque SignedInfo, que a su vez contiene los hashs de todas las referencias. Por lo tanto, al firmar uno no sólo está considerando las referencias sino que además está incluyendo en la firma información crítica asociada, como el algoritmo utilizado y el tipo de transformación previa, con lo cual éstos items están protegidos. El elemento KeyInfo contiene la clave pública necesaria para validar la firma o información sobre cómo obtenerla. Es el elemento más flexible de toda la especificación ya que puede contener directamente la clave, un certificado digital, otro tipos de claves que soporten estandares criptográficos, un string con algún significado conocido para el receptor, un URL a una clave almacena externamente o puede ser omitido por completo. 9.3 Ejemplo completo A continuación presentamos un ejemplo completo de XML Signature, que consiste de una referencia externa (página web a proteger) canonicalizada, hasheada y posteriormente firmada. Además, se incluye información de la clave pública necesaria para verificar la firma (en este caso es un certificado X.509). <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" /> <SignatureMethod Algorithm=" /> <Reference URI=" <DigestMethod Algorithm=" /> <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue> </Reference> </SignedInfo> 22

26 <SignatureValue> hthqjyd3c6ww/ojz07p4bmogjqbdznsuosch6p+0mpf69w2tln/pfldx/ep4/vkx </SignatureValue> <KeyInfo> <KeyValue> <RSAKeyValue> <Modulus> uciukpgoaomrq1fputh3caxxufmpjsms4jntkxrv0w1jkcxtj2m3akav1d/karvj </Modulus> <Exponent>AQBB</Exponent> </RSAKeyValue> </KeyValue> <X509Data> <X509SubjectName>CN=David Remy,O=BEA Systems Inc,ST=WA,C=US </X509SubjectName> <X509IssuerSerial> <X509IssuerName>CN=Test CA,O=GeoTrust Inc,ST=MA,C=US </X509IssuerName> <X509SerialNumber>167355</X509SerialNumber> </X509IssuerSerial> <X509Certificate> MIICeDCCAeGgAwIBAgIEOd3+iDANBgkqhkiG9w0BAQQFADBbMQswCQYDVQQGEwJJ... C/I/k9xGr7fneoIW </X509Certificate> </X509Data> </KeyInfo> </Signature> 9.4 Proceso de Generación de la firma El proceso de generación de la firma consiste de dos etapas: la generación de las referencias (es decir, de los elementos Reference) y la generación de la firma final (es decir, del elemento SignatureValue), que serán explicadas a continuación Generación de las referencias El proceso consiste en iterar sobre todos los elementos que serán firmados, calcular los hashes y crear los elementos Reference. Por cada referencia, el proceso es el siguiente: obtener el elemento especificado en la referencia, aplicarle la transformación (en caso de ser necesaria), calcular el hash de la transformación (DigestValue) utilizando algún algoritmo (DigestMethod) crear el elemento Reference incluyendo los métodos y el digest: <Reference URI=" <DigestMethod Algorithm=" <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue> </Reference> 23

27 9.4.2 Generación de la firma Una vez generadas las referencias, se procede a generar la firma definitiva mediante el siguiente proceso: crear el elemento SignedInfo e incluir las referencias obtenidas en el paso anterior y los elementos CanonicalizationMethod, SignatureMethod, y DigestMethod: <SignedInfo> <CanonicalizationMethod Algorithm=" " /> <SignatureMethod Algorithm=" <Reference URI=" <DigestMethod Algorithm=" <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue> </Reference> </SignedInfo> canonicalizar el elemento SignedInfo recién creado utilizando el método CanonicalizationMethod, calcular el hash de la canonicalización utilizando el DigestMethod, calcular el SignatureValue final utilizando el SignatureMethod sobre el hash calculado en el paso anterior (que es el hash del elemento SignedInfo ya canonicalizado): <SignatureValue> hthqjyd3c6ww/ojz07p4bmogjqbdznsuosch6p+0mpf69w2tln/pfldx/ep4/vkx </SignatureValue> armar el elemento Signature final incluyendo los elementos SignedInfo, SignatureValue y InfoKey (opcional). 9.5 Proceso de Verificación de la firma El proceso de verificación de la firma es el proceso inverso a la generación y consiste de dos etapas: la validación de las referencias y la validación de la firma, que serán explicadas a continuación Verificación de las referencias El proceso consiste en verificar que los elementos indicados en las referencias no han sido modificados. Para esto, primero se canonicaliza el elemento SignedInfo usando el CanonicalizationMethod y luego por cada referencia incluida en SignedInfo se realiza el siguiente proceso: obtener el elemento especificado en la referencia, aplicarle la transformación (en caso de ser necesaria), calcular el hash de la transformación utilizando el algoritmo especificado en DigestMethod 24

28 comparar el hash obtenido con el correspondiente DigestValue especificado en la referencia: si son distintos, la validación falla Verificación de la firma Si todas las referencias son válidas, se procede a verificar que el elemento SignedInfo no ha cambiado (integridad) y que se utilizó la clave privada adecuada para generar la firma (no-repudio) mediante el siguiente proceso: obtener la clave pública del emisor (mediante KeyInfo o de alguna otra manera), calcular el hash de la canonicalización de SignedInfo, desencriptar el elemento SignedInfo con la clave pública y comparar el hash obtenido en el paso previo con el incluido en el SignatureValue: si son distintos, la validación falla. 9.6 Algoritmos Disponibles Los algoritmos que pueden utilizarse en SignatureMethod para firmar y verificar firmas son los siguientes: DSA-SHA1 (implementación de Digital Signature Algorithm (DSA) HMAC-SHA1 RSA-SHA1 (recomendado) DSA y RSA son estrategias de claves pública/privada, mientras que HMAC es una estrategia de hash con clave compartida lo que no es común en firma digital ya que se espera validar la integridad y la identidad. Sin embargo, el grupo que definió XML decidió permitir la situación donde el único objetivo sea la integridad e incluyó HMAC-SHA1 debido a que es un algoritmo bueno y rápido para este propósito. 25

29 10 XML-Encryption: Encriptación en XML XML Encryption es un estándar que provee encriptación (es decir, confidencialidad) sobre documentos XML. Es otro de los pilares de WS-Security y debido a que fue desarrollado en conjunto con XML Signature comparten conceptos, terminología, elementos y esquemas XML, como por ejemplo el elemento KeyInfo. También, al igual que XML Signature, XML Encryption puede aplicarse sobre todo el documento, parte del mismo o sobre un documento externo, lo que lo convierte en un estándar poderoso y flexible. A modo de ejemplo básico, si se tiene un documento XML con datos sensibles de la siguiente forma: <Employee> <EmployeeID> </EmployeeID> <Manager>Fred Jones</Manager> <Salary>$50,000</Salary> </Employee> se pueden encriptar los datos reemplazando elementos XML por otros encriptados: <Employee> <EmployeeID> <EncryptedData>A.Ije@OJFdl</EncryptedData> </EmployeeID> <Manager>Fred Jones</Manager> <EncryptedData>J1!%dW2s23#D'?D2@</EncryptedData> </Employee> Este es un ejemplo simplificado para ilustrar la aparición de datos encriptados en el documento XML. Notar que un dato puede ser encriptado incluyendo o no su tag contenedor (en el ejemplo, el salario se encriptó incluyendo su tag Salary mientras que el caso del ID de empleado sólo se encriptó el ID). XML Encryption permite además encriptar diferentes secciones del documento con diferentes claves, logrando que distintas partes del documento sean accesibles por distintos receptores y permanezcan completamente ocultas para otros. Por ejemplo, en un escenario de web services el mensaje SOAP puede incluir una directiva encriptada para firewalls de nodos intermedios (por ejemplo, indicar una prioridad) y datos encriptados para el nodo final, de la siguiente manera: <SOAP:Envelope> <SOAP:Header> <! información para el Firewall--> <EncryptedData>datos binarios</encrypteddata> </SOAP:Header> <SOAP:Body> <EncryptedData>datos binarios</encrypteddata> </SOAP:Body> </SOAP:Envelope> La ventaja es que de esta manera el propio documento SOAP puede ser protegido endto-end y no tener que confiar en los protocolos de transporte subyacentes que hay en los nodos intermedios, como SSL, TLS o IPSEC que son point-to-point. Más aún, el documento 26

30 sigue permaneciendo confidencial una vez almacenado en el destino, lo que se denomina confidencialidad persistente. Los conceptos end-to-end y point-to-point son explicados en mayor detalle en el capítulo de WS-Security Estructura de XML Encryption La estructura de XML Encryption es la siguiente: <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:keyinfo> <EncryptedKey>? <AgreementMethod>? <ds:keyname>? <ds:retrievalmethod>? <ds:*>? </ds:keyinfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData> El elemento EncryptedData es la raíz de la estructura: puede incluir datos encriptados (en cuyo caso el tag ya contiene el dato encriptado) o puede apuntar a algo que está encriptado, en cuyo caso hay una referencia (CipherReference) a un archivo binario, parte de un documento XML o un documento XML completo. El atributo Type del elemento EncryptedData puede ser element (si lo que se encripta incluye los tags) o content (si sólo se encripta el contenido del elemento excluyendo los tags externos). Los elementos principales del próximo nivel son: el método de encriptación en EncryptionMethod y el dato encriptado en CipherData, que a su vez puede tener directamente el valor en CipherValue o apuntar al dato encriptado en CipherReference. El elemento EncryptionProperties contiene información miscelánea acerca del dato encriptado, como por ejemplo la fecha de encriptación. El elemento opcional KeyInfo es similar al de XML Signature: contiene la clave embebida o información sobre cómo obtenerla. En caso de utilizarse un método de encriptación de clave pública, el subelemento EncryptedKey contiene la clave secreta compartida de sesión encriptada con la clave pública del receptor. Es importante aclarar que la integridad de la estructura EncryptedData NO está asegurada. Si se la desea asegurar, hay que combinar XML Encryption con XML Signature, como se verá en el próximo capítulo. 27

31 10.2 Ejemplo completo El siguiente ejemplo ilustra el caso de encriptación con clave compartida que a su vez es encriptada con una clave pública. El emisor genera una clave de sesión compartida (puede ser al azar) para encriptar los datos y luego la encripta con la clave pública del receptor. De esta manera, se asegura que sólo el receptor deseado pueda desencriptar la clave compartida (pues es el único que debería tener la clave privada asociada) y utilizarla para desencriptar el mensaje original. <EncryptedData> <EncryptionMethod Algorithm= <ds:keyinfo xmlns:ds=" /> (*) <EncryptedKey> <EncryptionMethod Algorithm= <ds:keyinfo xmlns:ds= /> (**) <ds:x509data> <ds:x509subjectname>o=mycompany,ou=engineering,cn=alice </ds:x509subjectname> </ds:x509data> </ds:keyinfo> <CipherData> <CipherValue>...</CipherValue> (**) </CipherData> </EncryptedKey> </ds:keyinfo> <CipherData> <CipherValue>...</CipherValue> (*) </CipherData> </EncryptedData> Como puede apreciarse, hay dos elementos KeyInfo dentro del elemento principal EncryptedData: el primero (más arriba) hace referencia a la clave compartida utilizada en la encriptación del CipherValue principal, hijo del EncryptedData (indicados con un *). El segundo, hijo de EncryptedKey, hace referencia a la clave pública utilizada en la encriptación de la clave compartida (indicados con **). El receptor debe tener la clave privada asociada a la pública indicada en SubjectName (**) para desencriptar la clave compartida que está encriptada en el primer CipherValue (**), y una vez obtenida utilizarla para desencriptar el CipherValue (*) hijo del EncryptedData que contiene el mensaje original. Notar que en cada caso se utiliza un algoritmo de encriptación adecuado (AES y RSA) Proceso de Encriptación Para realizar la encriptación se realiza el siguiente proceso (simplificado): elegir el algoritmo de encriptación y especificarlo en el elemento EncryptionMethod, obtener una clave de encriptación de alguna manera (generalmente se genera una compartida, lo cual es eficiente) y optativamente, y según el caso, especificar información para obtenerla en el elemento KeyInfo, 28

32 serializar el dato a encriptar (convertirlo a raw data o a un stream of bytes para que pueda ser operado por el algoritmo), encriptar (ya se tiene un algoritmo, una clave y los datos), generar la estructura EncryptedData con toda la información utilizada en el proceso Proceso de Desencriptación Para realizar la desencriptación se realiza el siguiente proceso (simplificado): obtener el algoritmo, los parámetros y la información de clave desde EncryptionMethod y KeyInfo, obtener la clave de alguna manera: o se conoce de antemano o se utiliza la información disponible en KeyInfo para hallarla, desencriptar según el caso: si existe el elemento CipherValue, decodificar los bytes en base64 como raw data y desencriptar; y si existe el elemento CipherReference, desreferenciarlo, transformarlo y desencriptarlo Algoritmos disponibles Los algoritmos que pueden utilizarse en EncryptionMethod para encriptar y desencriptar son los siguientes: Triple-DES ( Advanced Encryption Standard (AES) 128-bit key ( Advanced Encryption Standard (AES) 256-bit key ( Advanced Encryption Standard (AES) 192-bit key ( 29

33 11 Combinando XML Encryption y XML Signature Debido a que XML Signature y XML Encryption proveen funcionalidades de firma digital y encriptación por separado, es muy común querer utilizar ambas características en simultáneo, lo que lleva a tener que generar un documento XML que incluya ambas estructuras. La primer opción (y más sencilla) que hay disponible es generar el documento como se muestra en el siguiente ejemplo: <MyDocument> <EncryptedData id="encrypteddata1"> <EncryptionMethod Algorithm="..." /> <CipherText> <CipherValue>...</CipherValue> </CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm="..." /> <CipherText> <CipherValue>... </CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject> O=HisCompany,OU=Technology,CN=Alice </X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData> <Signature> <SignedInfo> <CanonicalizationMethod Algorithm="..." /> <SignatureMethod Algorithm="..." /> <Reference URI="#encryptedData1"> <DigestMethod Algorithm="..." /> <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo> <X509Data> <X509Subject>O=MyCompany,OU=Engineering,CN=Bob</X509Subject> </X509Data> </KeyInfo> </Signature> </MyDocument> El ejemplo muestra dos grandes estructuras disjuntas: una encriptación y una firma, donde la firma Signature apunta al elemento encriptado EncryptedData con el ID encrypteddata1. Es decir, la firma protege la información en EncryptedData desde la perspectiva de integridad e identificación del emisor. 30

34 Notar que el documento fue preparado por Bob (pues utilizó su clave privada para firmar) y puede ser leído sólo por Alice (pues tiene la clave privada asociada a la pública utilizada en la encriptación). El problema importante que surge con este modelo es que si se borra todo el elemento Signature no quedan rastros de que hubo firma, e incluso se podría cambiar por otra falsificada. La solución a este problema es embeber el elemento Signature dentro de la estructura EncryptedData, es decir: primero se firma el dato a encriptar y luego se encriptan el dato y la firma. En el siguiente ejemplo, Bob quiere enviarle a Alice un documento XML y quiere proteger el elemento Customer, entonces agrega la firma dentro del elemento (notar la referencia de tipo Enveloped mediante el id customer, y la referencia a Bob como generador de la firma en el bloque KeyInfo): <Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <Customer id="customer" custnum="a2345"> <FirstName>Fred</FirstName> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber> </CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> <Signature> <SignedInfo> <CanonicalizationMethod Algorigthm="..." /> <SignatureMethod Algorithm="..." /> <Reference URI="#customer"> <Transform Algorithm=".../#envelopedSignature" /> <DigestMethod Algorithm="..." /> <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>... </SignatureValue> <KeyInfo> <X509Data> <X509SubjectName> O=MyCompany,OU=Engineering,CN=Bob </X509SubjectName> </X509Data> </KeyInfo> </Signature> </Customer> </Order> y encripta el elemento completo Customer para que lo pueda leer solamente Alice (es decir, utiliza su clave pública), reemplazándolo por el elemento correspondiente EncryptedData (notar la referencia a Alice en el bloque KeyInfo): 31

35 <Order> <LineItem sku="82394" quantity="1"> <ProductName>Birdcage</ProductName> </LineItem> <EncryptedData id="encrypteddata1"> <EncryptionMethod Algorithm="..." /> <CipherText> <CipherValue>... </CipherValue> <CipherText> <KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm="..." /> <CipherText> <CipherValue>...</CipherValue> </CipherText> <KeyInfo> <X509Data> <X509Subject> O=HisCompany,OU=Technology,CN=Alice </X509Subject> </X509Data> </KeyInfo> </EncryptedKey> </KeyInfo> </EncryptedData> </Order> De esta manera se obtienen algunas ventajas: Se protege el elemento Signature evitando que pueda ser eliminado. Se oculta completamente la información sensible incluida en Signature, como por ejemplo la identidad del emisor, aunque el receptor puede validarla una vez que desencripte el bloque EncryptedData. Se establece un orden de operación: primero se debe desencriptar y luego validar la firma (en el primer ejemplo no había un orden claro preestablecido). Sin embargo, con este enfoque surge el problema de que no se asegura la integridad del elemento EncryptedData y de los elementos restantes: alguien puede modificar los valores y romper la encriptación en el destino (reconocible por un humano pero seguramente no por un sistema dedicado), o incluso puede reemplazar directamente el bloque encriptado por otro. Por lo tanto, debe haber un trade-off entre ambos enfoques, o se pueden utilizar varias pasadas : una muy común es utilizar firma, encriptación y una nueva firma, aunque el objetivo principal sea la confidencialidad. 32

36 12 SAML: Autenticación en XML SAML (Security Assertion Markup Language) es un estándar XML para intercambiar datos de autenticación y autorización entre dominios de seguridad, es decir, entre un proveedor de identidad y un proveedor de servicio. SAML es producto del Comité Técnico de OASIS. Los mecanismos de creación y mantenimiento de los certificados digitales, la especificación de los permisos de acceso y la forma de identificación de los sujetos y entidades no estaban estandarizados hasta el momento, con lo cual compartir identidades o atributos de seguridad fuera de la organización era extremadamente complicado. SAML es un estándar cuya finalidad es proveer identidades portables a través de dominios de confianza (como por ejemplo organizaciones). Con identidad nos referimos a un individuo o una entidad, por ej. una máquina, que puede representar a una organización. Establecer una identidad es un prerrequisito para determinar las acciones que un sujeto puede realizar. La identidad de un sujeto es inicialmente establecida y verificada en un dominio de confianza por una tercera parte que resulta en la creación de credenciales. Se dice que la identidad de un sujeto es portable cuando ya ha sido establecida y verificada y quiere establecer su identidad y permisos en otro dominio de confianza. Las credenciales son presentadas como aserciones (assertions) cuando el sujeto que posee la identidad quiere iniciar algún tipo de acción, como por ejemplo una transacción. Autenticación es una aserción donde un sujeto dice quién es, y se prueba verificando que las credenciales estén legítimamente en posesión del sujeto. Autorización es una aserción que establece si la identidad del sujeto tiene permitida una acción específica, y se prueba antes de que las acciones requeridas sean permitidas. Como hemos visto anteriormente, los web services utilizan SOAP para conectar máquinas y aplicaciones pasando mensajes entre ellas y generando acciones remotas tanto en una organización como en una integración Business to Business (B2B). Este tipo de integración puede llegar a incorporar varias organizaciones que ofrecen diferentes servicios, y para ello necesitaremos que todos los participantes sean autenticados de una forma compatible a través de todo el sistema B2B, donde existen múltiples dominios de confianza. Cuando dos entidades pertenecientes a distintos dominios de confianza quieren interactuar, SOAP no tiene estandarizada una forma de comunicar propiedades para asegurar la confianza. Como los mensajes SOAP son enviados de un dominio de confianza a otro, la identidad del emisor del requerimiento y su aserción deben viajar con el mensaje, es decir que la identidad debe ser portable. De esta forma, el dominio de confianza del receptor puede aplicar su política de seguridad al mensaje recibido basándose en la información de identidad que tiene el mensaje. SAML es el estándar XML creado para permitir que las identidades sean portables. SAML es incorporado al estándar WS-Security (siendo el tercer y último pilar, junto a XML Encryption y XML Signature) por las siguientes cuatro razones: Es un formato estándar XML que no depende del protocolo de transporte. Incluye un protocolo de intercambio de mensajes estándar, donde claramente se define cómo preguntar por la información que uno necesita. Especifica las reglas sobre cómo debe ser transportado (generalmente será SOAP sobre HTTP) 33

37 A diferencia de otros métodos, no depende de una autoridad central certificante para garantizar que las comunicaciones sean seguras. Uno de los problemas más importante que SAML trata de resolver es el de web single sign-on (SSO). Si bien hay soluciones SSO en un nivel de intranet (por ejemplo usando cookies), extender este concepto a internet ha sido difícil y ha generado el desarrollo de tecnologías propietarias que no interoperan entre sí. SAML es el estándar para soluciones SSO en la web Modo de trabajo de SAML SAML está basado en tres mecanismos XML: Aserciones: es un esquema XML para las sentencias de seguridad. Esto hace que SAML sea un framework XML que puede ser extendido con nuevas aserciones. Protocolo: es un esquema XML para el protocolo Request/Response. Los requerimientos son para decisiones de políticas desde las autoridades SAML. Bindings: son reglas para las aserciones para utilizar los frameworls de mensajería y transporte. La relación entre estos tres mecanismos es ilustrada a continuación: 12.2 Aserciones Las aserciones SAML son transferidas desde el proveedor de la identidad hacia el proveedor del servicio. Las aserciones contienen sentencias que permiten al proveedor del servicio tomar decisiones de control. SAML provee tres tipos de sentencias: sentencias de autenticación sentencias de atributo sentencias de autorización Las sentencias de autenticación notifican al proveedor del servicio que el usuario del servicio pretende autenticarse utilizando un cierto método de autenticación. Además, se puede incluir otra información acerca del usuario, como se puede apreciar en el siguiente 34

38 ejemplo donde la dirección de del usuario es presentada al proveedor del servicio como método de autenticación. <saml:assertion xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="..." Issuer=" IssueInstant=" T17:05:37.795Z"> <saml:conditions NotBefore=" T17:00:37.795Z" NotOnOrAfter=" T17:10:37.795Z"/> <saml:authenticationstatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant=" T17:05:17.706Z"> <saml:subject> <saml:nameidentifier </saml:nameidentifier> <saml:subjectconfirmation> <saml:confirmationmethod> urn:oasis:names:tc:saml:1.0:cm:artifact </saml:confirmationmethod> </saml:subjectconfirmation> </saml:subject> </saml:authenticationstatement> </saml:assertion> Una dirección de puede ser suficiente en muchas situaciones. En algunos casos puede ser necesaria incluir información adicional para que el proveedor del servicio pueda tomar decisiones de control de acceso. Como ejemplo, supongamos que los estudiantes tienen permitido el acceso a datos escolares. Una sentencia de atributo puede indicar si el usuario es o no un estudiante, lo que permite al proveedor del servicio poder permitir o denegar el acceso a dicha información. Los tres tipos de sentencias no son mutuamente excluyentes: sentencias de autenticación y de atributo puede estar incluídas en una misma aserción Aserciones de Autenticación Una autoridad de autenticación recibe credenciales de un usuario y las procesa de acuerdo a su política. Si el proceso de autenticación es satisfactorio, la autoridad declara que el usuario S fue identificado a través del método M en el instante T, lo cual permite confiar en que la identidad digital del sujeto representa la identidad física del mismo. Más específicamente, si la autoridad determina que las credenciales son válidas se crea un elemento AuthenticationStatement. Este elemento contiene el método (AuthenticationMethod) utilizado para la autenticación, así como el tiempo (AuthenticationInstant) en el que el proceso de autenticación ocurrió. El elemento AuthenticationStatement opcionalmente puede contener un SubjectLocality que especifica el nombre DNS y la dirección IP del sistema de autenticación. 35

39 Los siguientes métodos de autenticación son soportados: Password Ticket Kerberos Secure Remote Password Hardware token SSL Client Certificate X.509 public key PGP public key SPKI public key XKMS public key XML Digital Signature Aunque SAML no provee un modelo de revocación, el hecho de que puedan integrarse certificados y firma digital en el modelo provee una forma de invalidar o revocar la validez de una identidad antes de su expiración. A continuación se muestra un ejemplo simple del elemento AuthenticationStatement para Bob, quien fue autenticado a través de un password: <saml:assertion...> <saml:authenticationstatement AuthenticationMethod="urn:oasis:names:tc:SAML: 1.0:am:password" AuthenticationInstant=" T10:02:00Z"> <saml:subject> <saml:nameidentifier Format="urn:oasis:names:tc:SAML:1.0: assertion# address">[email protected] <saml:subjectconfirmation> <saml:confirmationmethod>...specific to a profile or agreement... </saml:confirmationmethod> </saml:subjectconfirmation> </saml:subject> </saml:authenticationstatement> </saml:assertion> Aserciones de Atributos Cuando la autoridad de autenticación recibe las credenciales del sujeto S, puede querer agregar determinados atributos a la identidad de ese sujeto. Esta autoridad declara que el sujeto S está asociado a los atributos A, B y C con valores a, b y c. Algunos ejemplos típicos de atributos son el estado actual de cuenta de un individuo y su límite de crédito. A continuación se presenta una aserción de atributo para una persona cualquiera especificando los atributos recién mencionados: el estado y el límite de pago. 36

40 <saml:assertion...> <saml:attributestatement> <saml:subject>...</saml:subject> <saml:attribute AttributeName="PaidStatus" AttributeNamespace=" <saml:attributevalue> PaidUp </saml:attributevalue> </saml:attribute> <saml:attribute AttributeName="CreditLimit" AttributeNamespace=" <saml:attributevalue xsi:type="my:type"> <my:amount currency="usd"> </my:amount> </saml:attributevalue> </saml:attribute> </saml:attributestatement> </saml:assertion> Aserciones de Autorización Una autoridad de autenticación recibe las credenciales de un sujeto S requiriendo ser autenticado. Esta autoridad declara que el sujeto S tiene acceso garantizado de tipo A al recurso R utilizando la evidencia E. Este sujeto podría ser un humano o bien una computadora (web service) y el recurso requerido podría ser otro web service. A continuación mostramos una sentencia de autorización para un usuario cualquiera que autoriza al sujeto acceder y ejecutar el recurso especificado por la URL. <saml:assertion...> <saml:authorizationstatement Decision="Permit" Resource=" <saml:subject>...</saml:subject> <saml:action Namespace= "urn:oasis:names:tc:saml:1.0:action:rwedc">execute </saml:action> </saml:authorizationstatement> </saml:assertion> 12.3 Protocolo SAML define un protocolo Request/Response para generar e intercambiar aserciones. Este protocolo es un esquema completamente separado (con un namespace diferente: urn:oasis:names:tc:saml:1.0) del esquema de aserciones. Un requerimiento contiene un claim, y la respuesta de la autoridad contiene la aserción resultante. El requerimiento contiene el ID del sujeto en cuestión, que también está incluído en la respuesta para asegurarse de que tanto el requerimiento como la respuesta están hablando del mismo sujeto. 37

41 Authentication Request Un requerimiento de autenticación (Authentication Request) es como preguntar: Qué aserciones de autenticación hay disponibles para este sujeto?. La respuesta es una aserción conteniendo una sentencia de autenticación. La autoridad de autenticación recibe un conjunto de credenciales acerca del sujeto desde el repositorio de credenciales y las procesa de acuerdo a su política. La aserción define elementos de autenticación como la identidad del emisor de la credencial y del sujeto, el tiempo por el que la autenticación es garantizada y el período de validez de la misma. El elemento AuthenticationStatement es generado si la autenticación fue exitosa y contiene el método usado para ello, el momento y el lugar donde ocurrió. A continuación presentamos un requerimiento de autenticación que es firmado usando firma digital para demostrar que el origen es válido. La autenticación es requerida por el sujeto Bob de Company.com. <samlp:request MajorVersion="1" MinorVersion="0" RequestID=" " IssueInstant=" T10:02:00Z"> <samlp:respondwith>saml:authenticationstatement</samlp:respondwith> <ds:signature>...</ds:signature> <samlp:authenticationquery> <saml:subject> <saml:nameidentifier SecurityDomain="Company.com" Name="Bob" /> </saml:subject> </samlp:authenticationquery> </samlp:request> Attribute Request Un requerimiento de atributos es como preguntar Cuántos atributos disponibles hay para el sujeto?. La respuesta nuevamente es una aserción conteniendo una sentencia de atributo. En el requerimiento se puede preguntar por información relacionada con un atributo específico A, B y C, o bien por todos los atributos. El requerimiento es enviado a la autoridad de atributo (attribute authority) con la aserción de autenticación previamente obtenida. Esta autoridad utiliza una política para determinar los privilegios del sujeto. El elemento AttributeStatement contiene los subelementos Subject, Attribute, NameIdentifier, SubjectConfirmation, ConfirmationMethod, y SubjectConfirmationData. A continuación se muestra una consulta de atributo para un sujeto no especificado que requiere información acerca del atributo EstadoPagos para una cuenta determinada, especificada vía un URL a través del elemento AttributeNameSpace. 38

42 <samlp:request... > <samlp:attributequery> <saml:subject>...</saml:subject> <saml:attributedesignator AttributeName="EstadoPagos" AttributeNamespace=" </samlp:attributequery> </samlp:request> Authorization Request Un requerimiento de autorización es como preguntar: Este sujeto, tiene permitido acceder al recurso requerido mostrando esta evidencia?. La respuesta nuevamente es una aserción conteniendo una sentencia de autorización y decisión. El elemento AuthorizationDecisionStatement especifica qué decisión se ha tomado respecto del pedido de autorización. Este elemento contiene el URI del recurso que el sujeto está requeriendo acceso, la decisión de permitir (Permit) o denegar (Deny), una acción que determina qué usuario está autorizado para hacer lo que se está pidiendo y una evidencia para poder basar dicha decisión. En el siguiente ejemplo se presenta un requerimiento de autorización para Bob de la compañía Company.com preguntando si está autorizado a ejecutar un script CGI que realiza una reserva en un hotel. <samlp:request...> <samlp:authorizationdecisionquery Resource=" <saml:subject> <saml:nameidentifier SecurityDomain="Company.com" Name="Bob" /> </saml:subject> <saml:actions Namespace="urn:oasis:names:tc:SAML: 1.0:action:rwedc"> <saml:action>execute</saml:action> </saml:actions> <saml:evidence> <saml:assertion>...</saml:assertion> </saml:evidence> </samlp:authorizationdecisionquery> </samlp:request> SAML Protocol Response El protocolo de respuesta de SAML es firmado para identificar a la autoridad solicitante y garantizar que la respuesta permanezca sin alteraciones. A continuación se presenta una respuesta a un requerimiento de autenticación que muestra al solicitante de la respuesta como Company.com y especifica por cuánto tiempo durará la autenticación. 39

43 <samlp:response MajorVersion="1" MinorVersion="0" ResponseID=" " InResponseTo=" " IssueInstant=" T10:02:00Z" Recipient="...URI..."> <samlp:status> <samlp:statuscode Value="Success" /> <samlp:statusmessage>... </samlp:statusmessage> </samlp:status> <saml:assertion MajorVersion="1" MinorVersion="0" AssertionID=" " Issuer="Company.com"> <saml:conditions NotBefore=" T10:00:00Z" NotAfter=" T10:05:00Z" /> <saml:authenticationstatement...>... </saml:authenticationstatement> </saml:assertion> </samlp:response> 12.4 Bindings Un binding es una forma de transportar los requerimientos y respuestas SAML entre las autoridades y los sujetos; es decir, es un mapeo de los mensajes SAML de request/response en los protocolos estándares de comunicación. La especificación SAML establece SOAP sobre HTTP como uno de los posibles bindings. En este binding, la información SAML es contenida dentro del cuerpo del mensaje SOAP. Un solicitante SAML puede transmitir un elemento Request a través del cuerpo del mensaje SOAP hacia un destinatario SAML. El solicitante incluye solamente un requerimiento SAML por mensaje SOAP. El destinatario devuelve también un sólo elemento Response en el cuerpo de otro mensaje SOAP o bien un código de error. A continuación se presenta un ejemplo de un requerimiento SOAP que pregunta por una aserción conteniendo una sentencia de autenticación de una autoridad SAML, mostrando como se transporta la información SAML vía SOAP sobre HTTP. POST /SamlService HTTP/1.1 Host: Content-Type: text/xml Content-Length: nnn SOAPAction: <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Body> <samlp:request xmlns:samlp:="..." xmlns:saml="..." xmlns:ds="..."> <ds:signature>... </ds:signature> <samlp:authenticationquery>... </samlp:authenticationquery> </samlp:request> </SOAP-ENV:Body> </SOAP-ENV:Envelope> A continuación, se presenta un ejemplo del mensaje SOAP de respuesta correspondiente que provee la aserción conteniendo la sentencia de autenticación requerida. 40

44 HTTP/ OK Content-Type: text/xml Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Body> <samlp:response xmlns:samlp="..." xmlns:saml="..." xmlns:ds="..."> <Status> <StatusCodevalue="samlp:Success"/> </Status> <ds:signature>... </ds:signature> <saml:assertion> <saml:authenticationstatement>... </saml:authenticationstatement> </saml:assertion> </samlp:response> </SOAP-Env:Body> </SOAP-ENV:Envelope> 41

45 13 WS-Security: Seguridad en SOAP WS-Security es un estándar específicamente creado para utilizar las tecnologías de seguridad descriptas a lo largo de este documento en el contexto de un mensaje SOAP (y por ende, en el contexto de web services). Es decir, WS-Security no inventa un nuevo tipo de seguridad sino que especifica cómo utilizar los mecanismos de tokens de seguridad, XML Encryption y XML Signature para proveer seguridad en mensajes SOAP (o sea, extiende SOAP desde el punto de vista de seguridad). Por este motivo WS-Security hereda el poder y la flexibilidad de dichos mecanismos. La especificación WS-Security fue originalmente propuesta por Microsoft, IBM y VeriSign en Abril de 2002 y fue aprobada y estandarizada por OASIS en Abril de Hoy en día WS-Security se está convirtiendo en el método principal para asegurar Web Services, y se están definiendo nuevos estándares sobre esta especificación, como por ejemplo WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, y WS-Authorization Seguridad de Mensaje vs Seguridad de Transporte Es importante destacar las diferencias entre la seguridad ent-to-end que brinda WS-Security y la seguridad point-to-point que brindan los protocolos de transporte. WS-Security apunta a asegurar el mensaje SOAP de un web service por sí mismo (denominada Message Security) sin importar dónde vaya ni por cuánto tiempo, mientras que la seguridad del transporte HTTP (denominada Transport Security), como en el caso de SSL, apunta a crear un canal seguro entre dos endpoints entre los cuales viajarán los mensajes. La diferencia fundamental es que en Transport Security el mensaje SOAP permanece seguro sólo dentro del canal, mientras que en Message Security el mensaje permanece seguro (conceptualmente) sin importar dónde vaya debido a que contiene encriptación, firma digital y autenticación incluidos directamente en el mensaje. Otra diferencia importante es que en Message Security cada mensaje puede tener su propia estrategia de seguridad, como por ejemplo, se puede encriptar un request y enviar el response en claro, lo cual no es posible dentro de un canal que se comporta de igual manera con todos los mensajes. Finalmente, en la siguiente tabla se presentan otras diferencias entre ambos enfoques: Transport Security Point-to-point Estandarizado, relativamente fácil de implementar No es flexible: se aplica a todo el payload de igual manera durante la sesión La seguridad depende del protocolo de transporte Message Security End-to-end Nuevo, bastante complejo, con muchas opciones de seguridad que dificulta la implementación Muy flexible: puede aplicarse sólo a una parte del mensaje y discriminar entre Requests y Responses La misma seguridad se puede aplicar en diferentes tecnologías de transporte 42

46 13.2 Extendiendo la Seguridad en SOAP WS-Security define un header SOAP donde se incluyen las estructuras de seguridad. El objetivo de WS-Security no es inventar un nuevo tipo de seguridad sino proveer un formato común para incluir seguridad en un mensaje SOAP. El header SOAP está constituido principalmente por tres grandes elementos: tokens de seguridad, XML Encryption y/o XML Signature. Los tokens de seguridad, como por ejemplo username/password o certificados X.509, se utilizan para autenticación o autorización. El siguiente ejemplo muestra el formato básico de un header WS-Security SOAP: <S:Envelope> <S:Header> <wsse:security> <!-- Security Token --> <wsse:usernametoken>... </wsse:usernametoken> <!-- XML Signature --> <ds:signature>... <ds:reference URI="#body">... </ds:signature> <!-- Referencias XML Encryption --> <xenc:referencelist> <xenc:datareference URI="#body"/> </xenc:referencelist> </wsse:security> </S:Header> <S:Body> <!-- XML Body encriptado --> <xenc:encrypteddata Id="body" Type="content">... </xenc:encrypteddata> </S:Body> </S:Envelope> Como puede observarse, hay un header de seguridad Security con tres elementos hijos: un token de seguridad (representa SAML, en este caso hay sólo un UsernameToken pero podría haber 0, 1 o más tokens, e incluso puede utilizarse otro tipo de autenticación), un elemento Signature (que representa XML Signature, puede haber 0, 1 o más firmas) y un elemento ReferenceList con referencias a elementos encriptados (representa XML Encryption, puede haber 0, 1 o más elementos). 43

47 Los namespaces utilizados en el ejemplo son los siguientes: Prefijo Abreviatura de Namespace ds Digital signature wsse WS-Security extension wss-wssecurity-secext-1.0.xsd wsu Web services utility wss-wssecurity-utility-1.0.xsd xenc XML Encryption Security Tokens en WS-Security Un security token es un elemento de seguridad incluído en el mensaje con fines de autenticación. El estándar WS-Security es muy flexible en este aspecto ya que define muchos tipos de tokens posibles y permite extender el modelo a futuro. Algunos ejemplos de tokens disponibles son username/password, certificados X.509, tickets Kerberos, SAML assertions, XrML Tokens, XCBF Tokens y referencias a URIs. El nombre del elemento XML que define el token y sus atributos varían según el tipo de token utilizado. A continuación presentamos algunos ejemplos simples de tokens de seguridad donde pueden observarse las diferencias entre ellos Ejemplo de token username/password Este es el tipo de token más simple. Como la clave viaja en claro, obviamente se debe utilizar y confiar en un protocolo de transporte subyacente encriptado, como SSL (este enfoque es similar a la autenticación básica username/password de HTTP). <wsse:security> <wsse:usernametoken> <wsse:username>zoe</wsse:username> <wsse:password>ilovedogs</wsse:password> </wsse:usernametoken> </wsse:security> Ejemplo de ticket Kerberos En este caso, como los datos del ticket son binarios hay que elegir una manera de representarlos en XML, y base64 es la más utilizada. <wsse:security> <wsse:binarysecuritytoken wsu:id="mykerberostoken ValueType="wsse:Kerberosv5TGT EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0... (dato en base64) </wsse:binarysecuritytoken> </wsse:security> 44

48 Ejemplo de certificado X.509 En este caso también hay que utilizar un método de representación binaria en XML. <wsse:security> <wsse:binarysecuritytoken Id="myX509Token ValueType="wsse:X509v3 EncodingType="wsse:Base64Binary"> NIFEPzCCA9CrAwIBAgIQEmtJZc0... (dato en base 64) </wsse:binarysecuritytoken> </wsse:security> Ejemplo de token SAML Assertion Por último presentamos un ejemplo de aserción SAML. <wsse:security> <saml:assertion MajorVersion="1" MinorVersion="0" AssertionID="SecurityToken-ab12345" Issuer="yourIssuer" IssueInstant=" T10:31: :00" xmlns:saml="urn:oasis:names:tc:saml:1.0:assertion">... </saml:assertion> </wsse:security> Flujo de mensajes La siguiente figura muestra el flujo normal de mensajes entre el cliente del web service, el web service y la autoridad que genera los tokens de seguridad XML Encryption en WS-Security Casi todo lo explicado de XML Encryption se utiliza tal cual en WS-Security, pero hay un par de detalles extras que surgen al aplicarlo en mensajes SOAP. El caso de uso más común es encriptar el body del mensaje SOAP utilizando una clave secreta. En XML Encryption este escenario se representa creando un bloque EncryptedData en el lugar donde iría el texto en plano. En WS-Security, se crea además 45

49 un elemento ReferenceList en el header SOAP que apunta a las partes del mensaje que han sido encriptadas, como se muestra en el siguiente ejemplo: <S:Envelope> <S:Header> <wsse:security> <xenc:referencelist> <xenc:datareference URI="#body"/> </xenc:referencelist> </wsse:security> </S:Header> <S:Body> <xenc:encrypteddata Id="body"> <xenc:cipherdata> <xenc:ciphervalue>...</xenc:ciphervalue> </xenc:cipherdata> </xenc:encrypteddata> </S:Body> </S:Envelope> Notar que se agrega un nuevo elemento denominado DataReference que apunta al bloque encriptado. En este caso hay un único bloque encriptado (el body SOAP) y por ende hay un único DataReference, pero se podrían incluir varias referencias apuntando a direfentes elementos del documento. También es importante notar que los elementos propios del mensaje SOAP (envelope, header y body) nunca son encriptados porque son fundamentales para que la infraestructura de mensajería funcione correctamente XML Signature en WS-Security Al igual que XML Encryption, XML Signature se utiliza en WS-Security de la misma manera en que fue explicado para mensajes XML estándares, aunque hay un par de detalles extras a tener en cuenta al aplicar firmas en mensajes SOAP. XML Signature se utiliza en WS-Security para dos grandes propósitos: firmar parte o todo el mensaje (para proveer integridad) y firmar/verificar un security token (si se lo considera necesario) Firmando parte o todo el mensaje Como ya se ha mencionado, XML Signature tiene 3 modos de uso: Enveloped, Enveloping y Detached, pero debido a que los headers SOAP pueden ir cambiando en los nodos intermedios el único modo que tiene sentido utilizar en mensajes SOAP es el modo Detached. Por lo tanto, en las firmas WS-Security siempre habrá un elemento Reference explícito. 46

50 Firmando un Security Token El siguiente ejemplo ilustra el procedimiento de firma de un security token (en este caso, de tipo BinarySecurityToken). Notar que se realiza una doble referencia. <! Este es el Security Token a firmar: --> <wsse:binarysecuritytoken Id="myX509Token"... </wsse:binarysecuritytoken> <! Esta es la referencia al Security Token: --> <wsse:securitytokenreference wsu:id="mysecuritytoken"> <wsse:reference URI="#myX509Token"/> </wsse:securitytokenreference> <Signature xmlns=" <SignedInfo>... <Reference URI="#mySecurityToken"> <ds:transforms> <ds:transform Algorithm="...#STR-Transform"> <wsse:transformationparameters> <ds:canonicalizationmethod Algorithm=" " /> </wsse:transformationparameters> </ds:transform> </Reference> </SignedInfo> <SignatureValue></SignatureValue> </Signature> La firma se realiza definiendo un ID en el elemento del token (en el ejemplo es myx509token ), creando una referencia al ID en el elemento específico de firma de tokens SecurityTokenReference (en el ejemplo es "mysecuritytoken") y referenciando este último ID desde el elemento Signature. La idea de la referencia intermedia es que la firma NO incluya la referencia sino el contenido de lo que apunta (o sea, el token). 47

51 14 Ejercicio Práctico 14.1 Enunciado La Policía Federal Argentina lleva una lista de personas inhibidas para entrar o salir del país. Esta lista se arma en base a información brindada por la Justicia, junto con información provista por Interpol, y es consultada por la Dirección Nacional de Migraciones para decidir si una persona puede cruzar las fronteras, y registrarlo. Se deben diseñar los circuitos necesarios para poder consultar y actualizar la información en forma online, haciendo especial hincapié en la seguridad Resolución Existen 4 entidades, cada una de ellas con su base de datos local: Policía Federal Argentina (PFA) Dirección Nacional de Migraciones (MIG) Justicia (JUS) Interpol (INT) Asumimos que cada entidad posee un certificado digital otorgado por una Autoridad Certificante (AC) y que cada entidad posee los certificados de las restantes. Se requiere adicionalmente que los equipos donde corren las aplicaciones y la base de datos de cada entidad estén sincronizados utilizando el protocolo NTP contra un reloj atómico. Consideramos que el estado de inhabilitación de una persona es un dato sensible y debe viajar encriptado. ENTIDAD PFA: Esta entidad tiene desarrollada una aplicación local que lleva el registro de los estados de las personas para salir o entrar al país. Luego se desarrolla el Web Service (sobre SOAP vía HTTP) para que la información pueda ser actualizada y consultada en forma remota. A continuación se genera el archivo WSDL (puede ser en forma automática con algún software específico para ello) con la siguiente información: Un método (port) de consulta que recibe como parámetro un ID de persona (por ejemplo el DNI) y devuelve el estado de dicha persona. Este método define dos mensajes, uno de input y otro de output. (es un método de tipo Request/Response) Un método que recibe el estado de una persona para registrarlo en la base. El método define un mensaje de tipo input (es un método de tipo Notification) Un método que periódicamente envía el estado de la conexión con las entidades JUS e INT. (es un método de tipo Notification). Nota: el documento WSDL se firma con la clave privada de PFA para asegurar su integridad y no repudio frente a las otras instituciones. 48

52 ENTIDAD MIG: Esta entidad también tiene desarrollada una aplicación local, que para determinar si una persona puede o no cruzar la frontera genera una consulta al web service de PFA y actualiza los datos de acuerdo a la respuesta. Para poder conocer el estado de comunicación con la entidad PFA, también acepta un mensaje de notificación de parte de esta entidad para informarle el estado de la conexión y tomar los recaudos necesarios. ENTIDADES INT y JUS: Cada entidad tiene desarrollada una aplicación local, que ante una actualización del estado de inhibición para entrar o salir del país de una persona genera una notificación al web service de PFA informando este hecho. Para que la entidad PFA pueda corroborar el buen estado de la comunicación con estas entidades, podemos asumir que cada cierto intervalo de tiempo obligatoriamente se genera una notificación pero en este caso informando que no hubo modificaciones en los datos de las entidades. De esta forma la entidad PFA, al no recibir una notificación en ese intervalo de tiempo, puede informar a la entidad MIG este hecho para que actúe en consecuencia. El web service de PFA no se encuentra publicado mediante UDDI: asumimos que cada entidad ya posee el documento WSDL que contiene la especificación y la dirección del web service. Respecto de la seguridad, se utilizan los aspectos de WS-Security en todos los mensajes. Para autenticar las consultas o bien las actualizaciones hacia el web service se utiliza SAML con los certificados X.509 como tokens de seguridad. Si bien la consulta desde MIG hacia PFA no requiere confidencialidad, la respuesta sí la requiere, y para ello se utiliza XML-Encryption que utiliza una clave de sesión como clave simétrica encriptada con el algoritmo AES 128 bits que luego será protegida mediante la encriptación con la clave pública de MIG. La respuesta se firma antes de ser encriptada para asegurar la integridad de la misma. Luego de la encriptación se firma nuevamente el bloque encriptado para aumentar el nivel de seguridad de la consulta. Este mismo procedimiento se utiliza en las notificaciones desde JUS e INT hacia PFA ya que se quiere proteger la información de actualización. Para garantizar que no se produzcan ataques de replay cuando utilizamos SOAP, una de las alternativas es impedir la obtención de datos del mensaje en tránsito. Esto lo podemos realizar utilizado SSL sobre HTTP. Sin embargo, como en este tipo de ataques el atacante no requiere entender el mensaje para hacer el replay, XML Encryption no provee la protección necesaria para evitarlos. Si el atacante consigue obtener un requerimiento SAML firmado y encriptado, entonces puede hacer el replay de dicho requerimiento cuantas veces quiera sin necesidad de desencriptar el mensaje. Por lo tanto, en este caso es necesario utilizar los elementos conditions NotBefore (no antes de) y NotAfter (no después de) de los requerimientos SAML, que permiten indicar un intervalo de tiempo por el cual esos requerimientos son válidos. Para esta alternativa es necesario que todos los relojes de los equipos involucrados estén sincronizados. Otra solución sería utilizar el elemento RequestID que permite distinguir si el mensaje es un replay o no. A continuación se presenta un esquema del diseño propuesto: 49

53 50

54 15 Referencias A Web Services Primer, Venu Vasudevan, Securing Web Services with WS-Security, Jothy Rosenberg, David L. Remy, Sams Publishing, Mayo 2004 Web Services Essentials: Distributed Applications with XML-RPC, SOAP, UDDI & WSDL, Ethan Cerami, O Reilly, Febrero 2002 Understanding Web Services: XML, WSDL, SOAP and UDDI, Eric Newcomer, Addison-Wesley, 2002 MSDN Online: WS-Security, /understw.asp Integración de Aplicaciones con Web Services, Pablo Cecconi, Diciembre 2004 Yes, you can secure your Web Services documents, Part 1: XML Encryption, Ray Djajadinata, Agosto 2002 Yes, you can secure your Web Services documents, Part 2: XML Signature, Ray Djajadinata, Octubre 2002 Web Services Security: SOAP Message Security 1.0, OASIS Standard , Marzo 2004 Web Services Security: SAML Token Profile 1.1, OASIS Standard, Febrero 2006 Implementing WS-Security, Sam Thompson, IBM, Abril 2003, ibm.com/developerworks/webservices/library/ws-security.html Using WSDL in SOAP applications: An introduction to WSDL for SOAP programmers, Uche Ogbuji, Noviembre 2000, developerworks/ library/ws-soap/?dwzone=ws 51