Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Seguridad de la Informacin
Depto. De Computacin
Facultad de Ciencias Exactas y Naturales
Universidad de Buenos Aires
Julio 2006
1
2 Introduccin a Web Services
Casi todas las empresas, instituciones y organismos gubernamentales cuentan con distintas
reas o departamentos que usan sistemas informticos y bases de datos especficos para
realizar sus tareas y administrar su informacin. En la gran mayora 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 informacin de diferentes fuentes, evitar la duplicacin de informacin
y los problemas de consistencia asociados, o bien ofrecer servicios que utilicen Internet, e-
commerce u otras tecnologas nuevas. Por este motivo surgen los Web Services que
proveen un mecanismo de comunicacin dbilmente acoplado e independiente de la
plataforma definidos sobre una gramtica XML estndar que facilita la integracin de los
datos.
2
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 travs
de una conexin de red enviando un XML request
Un Service registry es un directorio de servicios lgicamente 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 interaccin entre ellos:
3
2.4 Perspectivas
Para entender con mayor claridad la interaccin entre estos elementos, se puede ver el
proceso desde la perspectiva del proveedor del servicio o desde la del usuario.
4
3 XML: Gramtica de Web Services
XML (eXtensible Markup Language) fue desarrollado para representar datos de manera
totalmente independiente de toda aplicacin, protocolo, vocabulario, sistema operativo y
lenguaje de programacin con el objetivo de superar las limitaciones de HTML y, en
particular, mejorar la creacin y el manejo de contenido dinmico. 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 descripcin, descubrimiento e invocacin 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 slo es utilizado para el formato de los mensajes
sino tambin para definir los servicios y cmo 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 definicin 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
validacin automtica (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="http://www.w3.org/1999/XMLSchema">
<xsd:element name="CustomerNumber" type="xsd:integer"/>
5
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
informacin de un cliente a un servidor de la siguiente manera: el cliente especifica el
procedimiento y los parmetros en un XML request y el servidor devuelve un valor o un
error en un XML response. Los parmetros son una lista simple de valores y tipos, y se
debe tener en cuenta que los tipos de datos disponibles ms complejos son los structs y
arrays (XML-RPC no maneja objetos ni mecanismos ms complejos de definicin 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 mdulos dispares. En lugar de crear
protocolos y formatos customizados que requieren testing, documentacin y
debugging, utilizan XML-RPC para conectar programas que corren en distintos
entornos y sistemas, y de esta manera se focalizan en las interfaces especficas y no
en el protocolo de conexin. En este escenario de uso, la distincin entre cliente y
servidor es insignificante: un mismo programa puede tener implementaciones de
cliente y servidor.
Publicacin de servicios: los desarrolladores pueden implementar un web service en
cualquier lenguaje arbitrario y publicarlo a travs 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 tambin ocurre que el desarrollador tiene control sobre el servidor pero no
necesariamente sobre el cliente.
6
4.1.1 Modelo de datos
La siguiente tabla contiene los tipos de datos bsicos de XML-RPC, que pueden ser
combinados en arrays y structs:
Tipo de Dato Valor Ejemplos
Boolean
true (1) o false (0) <boolean>1</boolean>
<boolean>0</boolean>
String
texto ASCII <string>Hello</string>
base64
informacin binaria codificada <base64>
en base 64 (RFC 2045) SGVsbG8sIFdvcmxkIQ==</base64>
<?xml version="1.0"?>
<methodCall>
<methodName>circleArea</methodName>
<params>
<param>
<value><double>2.41</double></value>
</param>
</params>
</methodCall>
7
HTTP/1.1 200 OK
Date: Sat, 06 Oct 2001 23:20:04 GMT
Server: Apache.1.3.12 (Unix)
Connection: close
Content-Type: text/xml
Content-Length: 124
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><double>18.24668429131</double></value>
</param>
</params>
</methodResponse>
HTTP/1.1 200 OK
Date: Sat, 06 Oct 2001 23:20:04 GMT
Server: Apache.1.3.12 (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 mtodo</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
XML-RPC no estandariza los cdigos de error en absoluto, por lo que se debe verificar
cada documentacin en particular para manejar los errores. Adems, 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 tambin se empaquetan en headers HTTP, y por lo tanto
todos los XML-RPC responses usan el cdigo 200 OK, aunque el mensaje contenga un
error.
8
5 WSDL: Descripcin de Web Services
WSDL (Web Service Description Language) es una especificacin en XML que permite
definir web services para que otros servicios sepan cmo invocarlo y dnde encontrarlo.
Bsicamente, describe cuatro tipos importantes de informacin 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
Ubicacin del servicio
9
WSDL tambin define el elemento documentation que puede ser usado para
proveer documentacin human-readable.
La siguiente figura resume la especificacin 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 funcin llamada sayHello que
recibe un parmetro de tipo string y devuelve otro string con un saludo. Luego
presentamos una breve descripcin de la especificacin.
<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>
10
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="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
</service>
</definitions>
11
El elemento binding provee detalles especficos sobre cmo la operacin portType
recientemente definida ser transmitida por la red. Pueden utilizarse varios mtodos de
transporte, incluyendo HTTP GET, HTTP POST o SOAP.
Finalmente, el elemento service especifica la ubicacin del servicio, de tipo SOAP
en este ejemplo. Notar que se incluye tambin un elemento documentation con
documentacin on-line.
12
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 disposicin 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
mensajera) de una computadora a otra a travs de protocolos estndares de transporte, de
los cuales HTTP es el ms comn. SOAP es lo que hace posible la integracin de
aplicaciones ya que una vez definido el contenido del mensaje en XML lo transporta de una
mquina 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 informacin 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 ms 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 aplicacin a otra. Puede ser un documento completo que el receptor decide
cmo procesar o una descripcin a una llamada remota, incluyendo los mtodos y
parmetros.
<env:Body>
<m:alert xmlns:m="http://example.org/alert">
<m:msg>ALERTA!!!</m:msg>
</m:alert>
</env:Body>
</env:Envelope>
13
Cada nodo, ya sea intermediario o final, puede procesar, agregar o eliminar
informacin del header SOAP que puede contener directivas de procesamiento y
seguridad, pero por ningn motivo pueden alterar el cuerpo del mensaje. Si un nodo
intermediario no reconoce algn elemento, puede ignorarlo, desechar el paquete SOAP
completo o realizar un graceful failure, segn 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 informacin crtica de seguridad y el nodo lo ignora
por no entenderlo.
Debido a la popularidad de RPC, SOAP define adems una manera de realizar
llamadas remotas sobre HTTP. En el modo de operacin normal (o sea, orientado a
documento) el cliente enva el documento XML como payload del mensaje SOAP y espera
el mensaje de respuesta del servidor. En este caso el cliente desconoce cmo se encuentra
implementado el servicio y cmo se procesa su mensaje. Por el contrario, en el modo de
operacin RPC se provee un mecanismo de llamada remota transparente para el cliente
donde se traduce la llamada a XML, se la enva al servidor y se toma el mensaje de
respuesta como el valor de retorno. Este modo de operacin es recomendable en
comunicaciones sincrnicas 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 enva
comnmente como un HTTP POST con el content type seteado como text/XML y
un campo SOAPAction seteado en vaco o con el nombre del mtodo, segn el caso. De
esta manera, el receptor detecta el mensaje SOAP y acta en cuestin.
El siguiente ejemplo muestra mensajes SOAP request y SOAP response (se omiten los
headers):
<SOAP-ENV:Envelope
...
<SOAP-ENV:Body>
<m:GetOrderStatus
xmlns:m="www.myservice.com/OrderEntry">
<orderno>43564</orderno>
</m:GetOrderStatus>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<SOAP-ENV:Envelope
...
<SOAP-ENV:Body>
<m:GetOrderStatusReply
xmlns:m="www.myservice.com/OrderEntry">
<orderstatus>Shipped June 18</orderstatus>
</m:GetOrderStatusReply>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
14
7 UDDI: Publicacin y Descrubimiento de Web
Services
Una vez que se definieron los datos en el mensaje (XML), se detallaron las interfaces que
provee y dnde se encuentra el servicio (WSDL) e identificado el mtodo de envo y
recepcin 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 funcin que UDDI
(Universal Distribution, Discovery and Integration) provee: un repositorio administra
informacin 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 categoras:
White Pages: incluye informacin general acerca de una compaa especfica, como
por ejemplo nombre, descripcin y direccin.
Yellow Pages: incluye datos clasificados por categora tanto de servicios como de
compaas, como por ejemplo el tipo industrial.
Green Pages: incluye informacin tcnica sobre el web service: un link a la
especificacin externa (WSDL) y la ubicacin del servicio.
15
8 Conceptos Bsicos de Seguridad en Web
Services
Como ya se ha mencionado, los web services son una tecnologa para integrar fuentes de
informacin y representan la nueva encarnacin de middlewares distribuidos. A diferencia
de los middlewares ya existentes, los web services constituyen una tecnologa simple,
basada en estndares y ms dbilmente 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 an mayor debido a
diversas causas:
integran tanto sistemas internos como fuentes de datos externas (y
eventualmente no confiables) a la organizacin,
poseen el dbil acoplamiento que los caracteriza,
se basan en el pasaje de mensajes XML, que son leibles y auto-descriptivos,
se basan en tecnologas 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
informacin importante acerca de su contenido, tales como quin es el emisor, cmo un
receptor puede confiar en la identidad del emisor y qu operaciones tiene permitidas el
emisor. Estos temas estn relacionados con la identidad y la confianza y deben ser tenidos
en cuenta en el uso de estas tecnologas.
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 cmo aplicar SSL a HTTP.
Sin embargo, este enfoque slo 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 estndar 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 tambin presenta problemas de seguridad: un documento
WSDL publicado permite que cualquier usuario o sistema pueda leer la especificacin y
ubicacin del web service y pueda accederlo. Por lo tanto, se debe utilizar algn mecanismo
de autenticacin 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 mnimo, proteger el URL del documento WSDL mediante
SSL solicitando la autenticacin del cliente en caso de que desee accederlo.
16
Por ltimo, la seguridad es tambin un tema importante en los registros UDDI. Por
ejemplo, quin est autorizado a publicar, utilizar y actualizar las descripciones de los web
services? Las relaciones de negocio requieren confianza y por lo tanto la autora, la
autenticacin y la autorizacin de las entidades que publican y consultan servicios deben ser
explcitamente manejadas por UDDI, especialmente en el caso de Internet pblica. UDDI
confa 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 autorizacin y provee el control de acceso a
los registros UDDI y con XML Encryption controla quin puede ver o utilizar un registro
encriptando sus elementos.
Una vez entendida la problemtica respecto a la seguridad de la informacin 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 bsicos son XML
Signature, XML Encryption y SAML, que sern explicados a lo largo del presente
documento, al igual que sus extensiones a SOAP en el marco de WS-Security.
17
9 XML-Signature: Firma Digital en XML
XML Signature es una extensin 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 estndar 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 pblica del emisor y determinar si el documento
ha sufrido cambios o no. Adems, 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 cmo 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. Adems, la estructura puede aparecer varias
veces dentro de un mismo documento, utilizando distintas claves en cada caso, y permite el
uso de varios mtodos de firma digital y autenticacin, lo que convierte a XML Signature
en un estndar poderoso y flexible.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="http://www.foo.com/secureDocument.html" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...
</KeyInfo>
</Signature>
19
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="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="#po1">
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
</Signature>
</PurchaseOrderDocument>
20
El siguiente ejemplo ilustra el caso externo, donde se observa que la referencia apunta a
un archivo JPEG:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="http://www.foo.com/picture.jpg" />
</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.
elemento del esquema. Si hay exactamente 1 ocurrencia no se utiliza ningn indicador; si hay 0 1 ocurrencia
se utiliza el indicador ?; si hay 1 o ms ocurrencias se utiliza el indicador +; y finalmente, si hay 0 o ms
ocurrencias se utiliza el indicador *.
21
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 sern 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 Canonicalizacin XML (CanonicalizationMethod), el
mtodo de firma (SignatureMethod), y uno o ms elementos de referencia. La
estrategia de Canonicalizacin se utiliza para estandarizar las estructuras XML de modo tal
que se puedan comparar a travs de mltiples 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 va usado en el clculo 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 transformacin que sufre el elemento a firmar. La transformacin 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 representacin de los mismos.
Ejemplos de posibles transformaciones son la canonicalizacin de documentos XML y la
representacin 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 slo est considerando las referencias sino que adems est incluyendo en la
firma informacin crtica asociada, como el algoritmo utilizado y el tipo de transformacin
previa, con lo cual stos items estn protegidos.
El elemento KeyInfo contiene la clave pblica necesaria para validar la firma o
informacin sobre cmo obtenerla. Es el elemento ms flexible de toda la especificacin ya
que puede contener directamente la clave, un certificado digital, otro tipos de claves que
soporten estandares criptogrficos, un string con algn significado conocido para el
receptor, un URL a una clave almacena externamente o puede ser omitido por completo.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20001011" />
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="http://www.foo.com/securePage.html">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
</Reference>
</SignedInfo>
22
<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>
23
9.4.2 Generacin 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="http://www.w3.org/TR/2000/WD-xml-c14n-
20001011" />
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-
sha1"/>
<Reference URI="http://www.foo.com/securePage.html">
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
</Reference>
</SignedInfo>
24
comparar el hash obtenido con el correspondiente DigestValue
especificado en la referencia: si son distintos, la validacin falla.
DSA y RSA son estrategias de claves pblica/privada, mientras que HMAC es una
estrategia de hash con clave compartida lo que no es comn en firma digital ya que se
espera validar la integridad y la identidad. Sin embargo, el grupo que defini XML decidi
permitir la situacin donde el nico objetivo sea la integridad e incluy HMAC-SHA1
debido a que es un algoritmo bueno y rpido para este propsito.
25
10 XML-Encryption: Encriptacin en XML
XML Encryption es un estndar que provee encriptacin (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, terminologa, elementos y
esquemas XML, como por ejemplo el elemento KeyInfo. Tambin, 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 estndar poderoso y flexible.
A modo de ejemplo bsico, si se tiene un documento XML con datos sensibles de la
siguiente forma:
<Employee>
<EmployeeID>512-34-4567</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>
XML Encryption permite adems 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>
<!informacin 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 end-
to-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. Ms an, el documento
26
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 captulo de WS-Security.
<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>
27
10.2 Ejemplo completo
El siguiente ejemplo ilustra el caso de encriptacin con clave compartida que a su vez es
encriptada con una clave pblica. El emisor genera una clave de sesin compartida (puede
ser al azar) para encriptar los datos y luego la encripta con la clave pblica del receptor. De
esta manera, se asegura que slo el receptor deseado pueda desencriptar la clave
compartida (pues es el nico que debera tener la clave privada asociada) y utilizarla para
desencriptar el mensaje original.
<EncryptedData>
<EncryptionMethod
Algorithm=http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<CipherData>
<CipherValue>. . .</CipherValue> (*)
</CipherData>
</EncryptedData>
Como puede apreciarse, hay dos elementos KeyInfo dentro del elemento principal
EncryptedData: el primero (ms arriba) hace referencia a la clave compartida utilizada
en la encriptacin del CipherValue principal, hijo del EncryptedData (indicados con
un *). El segundo, hijo de EncryptedKey, hace referencia a la clave pblica utilizada en la
encriptacin de la clave compartida (indicados con **).
El receptor debe tener la clave privada asociada a la pblica 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 encriptacin adecuado (AES y RSA).
28
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 informacin utilizada en el
proceso.
29
11 Combinando XML Encryption y XML Signature
Debido a que XML Signature y XML Encryption proveen funcionalidades de firma digital
y encriptacin por separado, es muy comn querer utilizar ambas caractersticas en
simultneo, lo que lleva a tener que generar un documento XML que incluya ambas
estructuras. La primer opcin (y ms 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 encriptacin y una firma,
donde la firma Signature apunta al elemento encriptado EncryptedData con el ID
encryptedData1. Es decir, la firma protege la informacin en EncryptedData desde
la perspectiva de integridad e identificacin del emisor.
30
Notar que el documento fue preparado por Bob (pues utiliz su clave privada para
firmar) y puede ser ledo slo por Alice (pues tiene la clave privada asociada a la pblica
utilizada en la encriptacin).
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 podra cambiar por otra
falsificada. La solucin 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>43343456343566</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 pblica), reemplazndolo por el elemento correspondiente
EncryptedData (notar la referencia a Alice en el bloque KeyInfo):
31
<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>
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 encriptacin 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 comn es utilizar firma, encriptacin y una
nueva firma, aunque el objetivo principal sea la confidencialidad.
32
12 SAML: Autenticacin en XML
SAML (Security Assertion Markup Language) es un estndar XML para intercambiar datos
de autenticacin y autorizacin entre dominios de seguridad, es decir, entre un proveedor
de identidad y un proveedor de servicio. SAML es producto del Comit Tcnico de
OASIS.
Los mecanismos de creacin y mantenimiento de los certificados digitales, la
especificacin de los permisos de acceso y la forma de identificacin de los sujetos y
entidades no estaban estandarizados hasta el momento, con lo cual compartir identidades o
atributos de seguridad fuera de la organizacin era extremadamente complicado. SAML es
un estndar cuya finalidad es proveer identidades portables a travs de dominios de
confianza (como por ejemplo organizaciones).
Con identidad nos referimos a un individuo o una entidad, por ej. una mquina, que
puede representar a una organizacin. 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 creacin 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 algn tipo de accin, como por
ejemplo una transaccin.
Autenticacin es una asercin donde un sujeto dice quin es, y se prueba verificando que
las credenciales estn legtimamente en posesin del sujeto. Autorizacin es una asercin que
establece si la identidad del sujeto tiene permitida una accin especfica, y se prueba antes
de que las acciones requeridas sean permitidas.
Como hemos visto anteriormente, los web services utilizan SOAP para conectar
mquinas y aplicaciones pasando mensajes entre ellas y generando acciones remotas tanto
en una organizacin como en una integracin Business to Business (B2B). Este tipo de
integracin 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 travs de todo el sistema B2B, donde existen mltiples 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 asercin 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 poltica de seguridad al mensaje recibido basndose en la
informacin de identidad que tiene el mensaje. SAML es el estndar XML creado para
permitir que las identidades sean portables.
33
A diferencia de otros mtodos, no depende de una autoridad central
certificante para garantizar que las comunicaciones sean seguras.
Uno de los problemas ms 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 difcil y ha generado el desarrollo de
tecnologas propietarias que no interoperan entre s. SAML es el estndar para soluciones
SSO en la web.
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 autenticacin
sentencias de atributo
sentencias de autorizacin
Las sentencias de autenticacin notifican al proveedor del servicio que el usuario del
servicio pretende autenticarse utilizando un cierto mtodo de autenticacin. Adems, se
puede incluir otra informacin acerca del usuario, como se puede apreciar en el siguiente
34
ejemplo donde la direccin de email del usuario es presentada al proveedor del servicio
como mtodo de autenticacin.
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1" MinorVersion="1"
AssertionID="..."
Issuer="https://idp.org/saml/"
IssueInstant="2002-06-19T17:05:37.795Z">
<saml:Conditions
NotBefore="2002-06-19T17:00:37.795Z"
NotOnOrAfter="2002-06-19T17:10:37.795Z"/>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2002-06-19T17:05:17.706Z">
<saml:Subject>
<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">user@mail.idp.org
</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 direccin de email puede ser suficiente en muchas situaciones. En algunos casos
puede ser necesaria incluir informacin 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 informacin.
Los tres tipos de sentencias no son mutuamente excluyentes: sentencias de
autenticacin y de atributo puede estar includas en una misma asercin.
35
Los siguientes mtodos de autenticacin 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
<saml:Subject>
<saml:NameIdentifier
Format="urn:oasis:names:tc:SAML:1.0:
assertion#emailAddress">bob@smithco.com
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
...specific to a profile or agreement...
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
36
<saml:Assertion ...>
<saml:AttributeStatement>
<saml:Subject>...</saml:Subject>
<saml:Attribute
AttributeName="PaidStatus"
AttributeNamespace="http://smithco.com">
<saml:AttributeValue>
PaidUp
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute
AttributeName="CreditLimit"
AttributeNamespace="http://smithco.com">
<saml:AttributeValue xsi:type="my:type">
<my:amount currency="USD">500.00
</my:amount>
</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</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 asercin
resultante. El requerimiento contiene el ID del sujeto en cuestin, que tambin est
includo en la respuesta para asegurarse de que tanto el requerimiento como la respuesta
estn hablando del mismo sujeto.
37
12.3.1 Authentication Request
Un requerimiento de autenticacin (Authentication Request) es como preguntar: Qu
aserciones de autenticacin hay disponibles para este sujeto?. La respuesta es una asercin
conteniendo una sentencia de autenticacin.
La autoridad de autenticacin recibe un conjunto de credenciales acerca del sujeto
desde el repositorio de credenciales y las procesa de acuerdo a su poltica. La asercin
define elementos de autenticacin como la identidad del emisor de la credencial y del
sujeto, el tiempo por el que la autenticacin es garantizada y el perodo de validez de la
misma.
El elemento AuthenticationStatement es generado si la autenticacin fue
exitosa y contiene el mtodo usado para ello, el momento y el lugar donde ocurri. A
continuacin presentamos un requerimiento de autenticacin que es firmado usando firma
digital para demostrar que el origen es vlido. La autenticacin es requerida por el sujeto
Bob de Company.com.
<samlp:Request
MajorVersion="1" MinorVersion="0"
RequestID="128.14.234.20.12345678"
IssueInstant="2001-12-03T10: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>
38
<samlp:Request ... >
<samlp:AttributeQuery>
<saml:Subject>...</saml:Subject>
<saml:AttributeDesignator
AttributeName="EstadoPagos"
AttributeNamespace="http://company.com"/>
</samlp:AttributeQuery>
</samlp:Request>
<samlp:Request ...>
<samlp:AuthorizationDecisionQuery
Resource="http://ChosenTravel.com/reserve_hotel.cgi">
<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>
39
<samlp:Response
MajorVersion="1" MinorVersion="0"
ResponseID="128.14.234.20.90123456"
InResponseTo="128.14.234.20.12345678"
IssueInstant="2001-12-03T10:02:00Z"
Recipient="...URI...">
<samlp:Status>
<samlp:StatusCode Value="Success" />
<samlp:StatusMessage> ... </samlp:StatusMessage>
</samlp:Status>
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="128.9.167.32.12345678"
Issuer="Company.com">
<saml:Conditions
NotBefore="2001-12-03T10:00:00Z"
NotAfter="2001-12-03T10: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 estndares de comunicacin. La especificacin SAML establece SOAP
sobre HTTP como uno de los posibles bindings. En este binding, la informacin SAML es
contenida dentro del cuerpo del mensaje SOAP.
Un solicitante SAML puede transmitir un elemento Request a travs del cuerpo del
mensaje SOAP hacia un destinatario SAML. El solicitante incluye solamente un
requerimiento SAML por mensaje SOAP. El destinatario devuelve tambin un slo
elemento Response en el cuerpo de otro mensaje SOAP o bien un cdigo de error.
A continuacin se presenta un ejemplo de un requerimiento SOAP que pregunta por
una asercin conteniendo una sentencia de autenticacin de una autoridad SAML,
mostrando como se transporta la informacin SAML va SOAP sobre HTTP.
41
13 WS-Security: Seguridad en SOAP
WS-Security es un estndar especficamente creado para utilizar las tecnologas 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 cmo 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 especificacin WS-Security fue originalmente propuesta por Microsoft, IBM y
VeriSign en Abril de 2002 y fue aprobada y estandarizada por OASIS en Abril de 2004.
Hoy en da WS-Security se est convirtiendo en el mtodo principal para asegurar Web
Services, y se estn definiendo nuevos estndares sobre esta especificacin, como por
ejemplo WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, y
WS-Authorization.
No es flexible: se aplica a todo el Muy flexible: puede aplicarse slo a una parte del
payload de igual manera durante la sesin mensaje y discriminar entre Requests y Responses
42
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 comn 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 autenticacin o autorizacin.
El siguiente ejemplo muestra el formato bsico de un header WS-Security SOAP:
<S:Envelope>
<S:Header>
<wsse:Security>
Como puede observarse, hay un header de seguridad Security con tres elementos
hijos: un token de seguridad (representa SAML, en este caso hay slo un UsernameToken
pero podra haber 0, 1 o ms tokens, e incluso puede utilizarse otro tipo de autenticacin),
un elemento Signature (que representa XML Signature, puede haber 0, 1 o ms firmas)
y un elemento ReferenceList con referencias a elementos encriptados (representa
XML Encryption, puede haber 0, 1 o ms elementos).
43
Los namespaces utilizados en el ejemplo son los siguientes:
44
13.3.3 Ejemplo de certificado X.509
En este caso tambin hay que utilizar un mtodo de representacin binaria en XML.
<wsse:Security>
<wsse:BinarySecurityToken Id="myX509Token
ValueType="wsse:X509v3
EncodingType="wsse:Base64Binary">
NIFEPzCCA9CrAwIBAgIQEmtJZc0 ... (dato en base 64)
</wsse:BinarySecurityToken>
</wsse:Security>
45
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>
46
13.5.2 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.
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference URI="#mySecurityToken">
<ds:Transforms>
<ds:Transform Algorithm="...#STR-Transform">
<wsse:TransformationParameters>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315" />
</wsse:TransformationParameters>
</ds:Transform>
</Reference>
</SignedInfo>
<SignatureValue></SignatureValue>
</Signature>
47
14 Ejercicio Prctico
14.1 Enunciado
La Polica Federal Argentina lleva una lista de personas inhibidas para entrar o salir del pas.
Esta lista se arma en base a informacin brindada por la Justicia, junto con
informacin provista por Interpol, y es consultada por la Direccin Nacional de
Migraciones para decidir si una persona puede cruzar las fronteras, y registrarlo.
Se deben disear los circuitos necesarios para poder consultar y actualizar la
informacin en forma online, haciendo especial hincapi en la seguridad.
14.2 Resolucin
Existen 4 entidades, cada una de ellas con su base de datos local:
Polica Federal Argentina (PFA)
Direccin 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 estn sincronizados utilizando el protocolo NTP contra un reloj
atmico.
Consideramos que el estado de inhabilitacin de una persona es un dato sensible y
debe viajar encriptado.
ENTIDAD PFA:
Esta entidad tiene desarrollada una aplicacin local que lleva el registro de los estados
de las personas para salir o entrar al pas.
Luego se desarrolla el Web Service (sobre SOAP va HTTP) para que la informacin
pueda ser actualizada y consultada en forma remota.
A continuacin se genera el archivo WSDL (puede ser en forma automtica con algn
software especfico para ello) con la siguiente informacin:
9 Un mtodo (port) de consulta que recibe como parmetro un ID de persona
(por ejemplo el DNI) y devuelve el estado de dicha persona. Este mtodo
define dos mensajes, uno de input y otro de output. (es un mtodo de tipo
Request/Response)
9 Un mtodo que recibe el estado de una persona para registrarlo en la base. El
mtodo define un mensaje de tipo input (es un mtodo de tipo Notification)
9 Un mtodo que peridicamente enva el estado de la conexin con las
entidades JUS e INT. (es un mtodo 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
ENTIDAD MIG:
Esta entidad tambin tiene desarrollada una aplicacin 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 comunicacin
con la entidad PFA, tambin acepta un mensaje de notificacin de parte de esta entidad
para informarle el estado de la conexin y tomar los recaudos necesarios.
Este mismo procedimiento se utiliza en las notificaciones desde JUS e INT hacia PFA
ya que se quiere proteger la informacin de actualizacin.
Para garantizar que no se produzcan ataques de replay cuando utilizamos SOAP, una
de las alternativas es impedir la obtencin de datos del mensaje en trnsito. 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 proteccin 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 despus de) de los requerimientos SAML, que
permiten indicar un intervalo de tiempo por el cual esos requerimientos son vlidos. Para
esta alternativa es necesario que todos los relojes de los equipos involucrados estn
sincronizados. Otra solucin sera utilizar el elemento RequestID que permite distinguir si
el mensaje es un replay o no.
49
50
15 Referencias
A Web Services Primer, Venu Vasudevan,
http://webservices.xml.com/pub/a/ws/2001/04/04/webservices/index.html
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, OReilly, Febrero 2002
Understanding Web Services: XML, WSDL, SOAP and UDDI, Eric
Newcomer, Addison-Wesley, 2002
MSDN Online: WS-Security,
http://www.microsoft.com/spanish/msdn/articulos/archivo/121202/voices
/understw.asp
Integracin 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 200401,
Marzo 2004
Web Services Security: SAML Token Profile 1.1, OASIS Standard, Febrero
2006
Implementing WS-Security, Sam Thompson, IBM, Abril 2003, http://www-
128.ibm.com/developerworks/webservices/library/ws-security.html
Using WSDL in SOAP applications: An introduction to WSDL for SOAP
programmers, Uche Ogbuji, Noviembre 2000, http://www-128.ibm.com/
developerworks/ library/ws-soap/?dwzone=ws
51