Está en la página 1de 54

Seguridad en Web Services

Seguridad de la Informacin

Depto. De Computacin
Facultad de Ciencias Exactas y Naturales
Universidad de Buenos Aires

Julio 2006

Hernn Garrido (hgarrido@dc.uba.ar)


Cristian Zunino (czunino@dc.uba.ar)
Indice

1 Acerca de este documento............................................................................................. 1


2 Introduccin a Web Services ........................................................................................ 2
2.1 Tecnologa de Web Services ..................................................................................... 2
2.2 Roles en Web Services............................................................................................... 3
2.3 Stack de protocolos en Web Services...................................................................... 3
2.4 Perspectivas................................................................................................................. 4
2.4.1 Perspectiva del usuario ..................................................................................... 4
2.4.2 Perspectiva del proveedor................................................................................ 4
3 XML: Gramtica de Web Services ............................................................................... 5
4 XML-RPC........................................................................................................................ 6
4.1 Estructura XML-RPC................................................................................................ 6
4.1.1 Modelo de datos ................................................................................................ 7
4.1.2 Estructura del XML-RPC Request ................................................................. 7
4.1.3 Estructura del XML-RPC Response .............................................................. 7
5 WSDL: Descripcin de Web Services ......................................................................... 9
5.1 Especificacin WSDL ............................................................................................... 9
5.2 Ejemplo ..................................................................................................................... 10
6 SOAP: Acceso a Web Services .................................................................................. 13
7 UDDI: Publicacin y Descrubimiento de Web Services ........................................ 15
8 Conceptos Bsicos de Seguridad en Web Services .................................................. 16
9 XML-Signature: Firma Digital en XML .................................................................... 18
9.1 Estructura bsica de XML Signature..................................................................... 18
9.1.1 Enveloping Signature...................................................................................... 19
9.1.2 Enveloped Signature....................................................................................... 19
9.1.3 Detached Signature ......................................................................................... 20
9.2 Esquema detallado del elemento Signature .......................................................... 21
9.3 Ejemplo completo.................................................................................................... 22
9.4 Proceso de Generacin de la firma........................................................................ 23
9.4.1 Generacin de las referencias........................................................................ 23
9.4.2 Generacin de la firma ................................................................................... 24
9.5 Proceso de Verificacin de la firma....................................................................... 24
9.5.1 Verificacin de las referencias ....................................................................... 24
9.5.2 Verificacin de la firma .................................................................................. 25
9.6 Algoritmos Disponibles .......................................................................................... 25
10 XML-Encryption: Encriptacin en XML ................................................................. 26
10.1 Estructura de XML Encryption ........................................................................ 27
10.2 Ejemplo completo ............................................................................................... 28
10.3 Proceso de Encriptacin..................................................................................... 28
10.4 Proceso de Desencriptacin............................................................................... 29
10.5 Algoritmos disponibles ....................................................................................... 29
11 Combinando XML Encryption y XML Signature................................................... 30
12 SAML: Autenticacin en XML................................................................................... 33
12.1 Modo de trabajo de SAML................................................................................. 34
12.2 Aserciones............................................................................................................. 34
12.2.1 Aserciones de Autenticacin..................................................................... 35
12.2.2 Aserciones de Atributos ............................................................................ 36
12.2.3 Aserciones de Autorizacin ...................................................................... 37
12.3 Protocolo .............................................................................................................. 37
12.3.1 Authentication Request ............................................................................. 38
12.3.2 Attribute Request........................................................................................ 38
12.3.3 Authorization Request ............................................................................... 39
12.3.4 SAML Protocol Response......................................................................... 39
12.4 Bindings................................................................................................................. 40
13 WS-Security: Seguridad en SOAP .............................................................................. 42
13.1 Seguridad de Mensaje vs Seguridad de Transporte......................................... 42
13.2 Extendiendo la Seguridad en SOAP ................................................................. 43
13.3 Security Tokens en WS-Security........................................................................ 44
13.3.1 Ejemplo de token username/password................................................... 44
13.3.2 Ejemplo de ticket Kerberos ...................................................................... 44
13.3.3 Ejemplo de certificado X.509 ................................................................... 45
13.3.4 Ejemplo de token SAML Assertion......................................................... 45
13.3.5 Flujo de mensajes ....................................................................................... 45
13.4 XML Encryption en WS-Security ..................................................................... 45
13.5 XML Signature en WS-Security......................................................................... 46
13.5.1 Firmando parte o todo el mensaje ........................................................... 46
13.5.2 Firmando un Security Token .................................................................... 47
14 Ejercicio Prctico.......................................................................................................... 48
14.1 Enunciado............................................................................................................. 48
14.2 Resolucin ............................................................................................................ 48
15 Referencias..................................................................................................................... 51
1 Acerca de este documento
El presente documento analiza el uso de los mtodos existentes para implementar
seguridad en Web Services.
En primer lugar se presentan a grandes rasgos los conceptos bsicos de Web Services,
luego se entrar ms en detalle en estos conceptos y se irn agregando conceptos de
seguridad en XML, que sern 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
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.1 Tecnologa de Web Services


Los web services proveen un mecanismo estndar para que las aplicaciones puedan
publicar y subscribirse a servicios de software a travs 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 estndar Universal
Distribution Discovery and Integration (UDDI), obtener la definicin de la interfase
usando Web Services Description Language (WSDL), e intercambiar datos usando
documentos XML a travs de SOAP sobre protocolos universales tales como HTTP, FTP,
y SMTP.
El funcionamiento de los web services es comparable al de la web estndar en la que
un servidor HTTP responde pedidos de un web browser envindole pginas 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 descripcin en formato WSDL de los web services disponibles en el servidor, un
mensaje de estado tal como la indicacin de que un recurso no est disponible o que una
transaccin fue exitosa, o datos encapsulados en un documento XML.
Para la aplicacin cliente de un web service, ste aparece como una llamada a un
mtodo local, slo que la llamada es traducida a XML (basndose en el estndar SOAP) y
enviada a travs de la red a la aplicacin proveedora del servicio.
Debido a que los web services son accesibles usando URLs, HTTP, y XML, estn al
alcance de cualquier aplicacin 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 mensajera XML estandarizado y no se encuentre atado
a ningn sistema operativo ni lenguaje de programacin. Adems, hay dos propiedades
adicionales que son deseables: un web service debera ser self-describing -si se publica el
servicio tambin se debera publicar su interfase y alguna documentacin mnima- que se
logra mediante WSDL, y descubrible -discoverable, si se crea un web service debe haber un
mecanismo fcil de publicacin- que se logra gracias a UDDI.

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:

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 ms
nuevos (como BEEP)
Mensajera XML: es la capa responsable de codificar mensajes en un formato XML
comn para que pueda ser entendido por ambos extremos; los protocolos ms
usados son SOAP y XML-RPC (XML Remote Procedure Call), aunque tambin se
pueden usar los mtodos GET/POST de HTTP y pasar documentos XML
arbitrarios.
Descripcin del servicio: es la capa responsable de describir la interface pblica de
un web service especfico; se utiliza WSDL (Web Service Description Language)
Descubrimiento del servicio: es la capa responsable de centralizar web services en
un lugar comn y proveer funcionalidades de publicacin y bsqueda; se utiliza
UDDI (Universal Description, Discovery and Integration).

El siguiente diagrama muestra el stack de protocolos de un web service:

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.

2.4.1 Perspectiva del usuario


La perspectiva del usuario del servicio (service requestor) es la siguiente:
1. Identificar y descubrir los servicios relevantes a la aplicacin buscndolos en el
directorio UDDI.
2. Una vez identificado el servicio, localizar su descripcin. Si es un servicio
SOAP hallar el documento WSDL, y si es un servicio XML-RPC hallar
documentacin human-readable para conocer detalles de la integracin.
3. Crear la aplicacin cliente en algn lenguaje de programacin (generalmente
utilizando alguna herramienta automtica).
4. Ejecutar la aplicacin cliente para que invoque el web service.

2.4.2 Perspectiva del proveedor


La perspectiva del proveedor del servicio (service provider) es la siguiente:
1. Implementar el servicio en algn lenguaje.
2. Desarrollar un wrapper del servicio, ya sea en XML-RPC o en SOAP.
3. Proveer documentacin 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 especificacin del servicio (en un directorio UDDI
global o uno privado de la compaa).

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.

4.1 Estructura XML-RPC


XML-RPC consiste de tres pequeas 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
parmetros, devolver resultados y generar cdigos de error (faults).
Estructura XML-RPC Request: es un HTTP POST request que contiene
informacin del mtodo y los parmetros.
Estructura XML-RPC Response: es un HTTP response que contiene el valor
resultante o informacin de error, segn el caso.

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

int o i4 entero de 32 bits <int>27</int>


<i4>27</i4>
Double
flotants de 64 bits <double>27.31415</double>
<double>-1.1465</double>

Boolean
true (1) o false (0) <boolean>1</boolean>
<boolean>0</boolean>

String
texto ASCII <string>Hello</string>

dateTime.iso8 fecha en formato ISO8601 <dateTime.iso8601>


601 20021125T02:20:04
</dateTime.iso8601>

base64
informacin binaria codificada <base64>
en base 64 (RFC 2045) SGVsbG8sIFdvcmxkIQ==</base64>

4.1.2 Estructura del XML-RPC Request


Los XML-RPC requests son una combinacin 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 parmetros y sus valores. A modo de ejemplo,
presentamos un XML-RPC request a un mtodo llamado circleArea que toma como
parmetro un radio de tipo double y devuelve el rea del crculo:

POST /xmlrpc HTTP 1.0


User-Agent: myXMLRPCClient/1.0
Host: 192.168.124.2
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>

4.1.3 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
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>

Si en cambio hubo algn problema, el elemento methodResponse contiene un elemento


fault (en lugar de params) que indica el error encontrado:

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

Es decir, WSDL define qu funcionalidad provee el web service (interface y tipos de


datos), cmo se comunica (es decir, cmo debe empaquetarse el mensaje en SOAP y cmo
debe transferirse, lo que modifica el header SOAP) y dnde se encuentra. Cada uno de estos
elementos puede ser especificado en un documento XML por separado y luego ser
combinados para crear la descripcin 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 pblicamente.
Existen herramientas WSDL-aware que permiten automatizar este proceso, permitiendo
que las aplicaciones integren fcilmente nuevos servicios automticamente o con muy poco
cdigo.

5.1 Especificacin WSDL


La especificacin define seis grandes elementos:
El elemento definitions debe ser el elemento raz de todo documento WSDL.
Define el nombre del web service, declara los namespaces que utiliza y contiene los
elementos restantes, descriptos a continuacin.
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 especificacin 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 parmetros o valores de retorno del mensaje, segn el
caso.
El elemento portType combina mltiples elementos message para formar una
operacin completa de ida y vuelta. El caso ms comn en servicios SOAP es
combinar un mensaje request con otro mensaje response en una operacin simple
de request/response. Un puerto es bsicamente un endpoint del servicio.
El elemento binding especifica concretamente la implementacin del service en la
red: determina el mtodo de transporte de red que llevar el mensaje a destino.
El elemento service define la direccin para invocar el servicio, comnmente
incluyendo un URL.

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.

<?xml version="1.0" encoding="UTF-8"?>


<definitions name="HelloService"
targetNamespace="http://www.ecerami.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<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="http://schemas.xmlsoap.org/soap/http"/>
<operation name="sayHello">
<soap:operation soapAction="sayHello"/>
<input>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice"
use="encoded"/>
</input>
<output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

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>

El elemento definitions define que el documento es HelloService y especifica


varios namespaces (que empiezan con xmlns:) que son tiles para referenciar mltiples
especificaciones externas, incluyendo las especificaciones WSDL, SOAP y el XML Schema.
Adems, 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 parmetro, 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 operacin 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 bsicos de operacin: 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 ms comunmente usado), Solicit/Response (el service enva
un mensaje y luego recibe una respuesta) y Notification (el service enva un mensaje). El
siguiente esquema muestra los 4 tipos bsicos de operacin:

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.

El esquema del servicio presentado en el ejemplo es el siguiente:

Dada la especificacin WSDL del ejemplo, se puede crear manualmente un servicio


SOAP que invoque el service definido o se pueden utilizar herramientas especficas que
automatizan el proceso. De la misma manera, existen herramientas que generan
automticamente las descripciones WSDL a partir de servicios existentes.

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.

El siguiente ejemplo ilustra estos elementos.

<?xml version="1.0" ?>


<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Header>
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2004-06-22T14:00:00-5:00</n:expires>
</n:alertcontrol>
</env:Header>

<env:Body>
<m:alert xmlns:m="http://example.org/alert">
<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 especificacin de SOAP provee un framework flexible
para definir bindings de protocolo arbitrarios y provee un binding explcito para HTTP
debido a su popularidad de forma tal de mantener la interoperabilidad. Ms an, el modelo
de procesamiento de SOAP permite incluso la presencia de mltiples nodos intermediarios,
cada uno con su propio protocolo, como lo ilustra la siguiente figura:

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.

UDDI puede utilizarse dentro de grandes compaas para centralizar la publicacin y


bsqueda de servicios internos o directamente en Internet para hallar web services
pblicos.
Los pedidos UDDI tambin viajan sobre SOAP, tal como muestra el siguiente
ejemplo de consulta que, incluido en el cuerpo de un SOAP envelope, trae informacin
sobre la compaa Microsoft:

<find_business generic="1.0" xmlns="urn:uddi-org:api">


<name>Microsoft</name>
</find_business>

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.

9.1 Estructura bsica de XML Signature


La estructura bsica de XML Signature contiene 4 tems:
Un conjunto de referencias a elementos que sern firmados
La firma actual
La clave (o alguna manera de obtenerla) para verificar la firma (Opcional)
Un elemento Object que contiene tems no includos en los anteriores (Opcional)

A continuacin presentamos un ejemplo muy simplificado de XML Signature para que


se pueda apreciar la estructura descripta ms arriba.

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="http://www.foo.com/secureDocument.html" />
</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 informacin acerca de lo que se firma,
SignatureValue que contiene la firma digital en s y el elemento KeyInfo que
contiene la clave pblica necesaria para validar la firma o informacin sobre cmo
obtenerla.
SignedInfo contiene informacin acerca de QU se firma: est compuesto por
uno o ms elementos Reference que apuntan a elementos internos o externos al
18
documento XML que sern 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.

9.1.1 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="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="#111" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
<Object>
<SignedItem id="111">Stuff to be signed</SignedItem>
</Object>
</Signature>

9.1.2 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="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="#po1">
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
</Signature>
</PurchaseOrder>

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.

9.2 Esquema detallado del elemento Signature


A continuacin presentamos el esquema completo del elemento Signature definido en
la especificacin1 de XML Signature.
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>

1 En la definicin de sintaxis XML se suelen utilizar indicadores de cardinalidad acompaando a cada

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.

9.3 Ejemplo completo


A continuacin presentamos un ejemplo completo de XML Signature, que consiste de una
referencia externa (pgina web a proteger) canonicalizada, hasheada y posteriormente
firmada. Adems, se incluye informacin de la clave pblica necesaria para verificar la firma
(en este caso es un certificado X.509).

<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>

9.4 Proceso de Generacin de la firma


El proceso de generacin de la firma consiste de dos etapas: la generacin de las referencias
(es decir, de los elementos Reference) y la generacin de la firma final (es decir, del
elemento SignatureValue), que sern explicadas a continuacin.

9.4.1 Generacin de las referencias


El proceso consiste en iterar sobre todos los elementos que sern 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 transformacin (en caso de ser necesaria),
calcular el hash de la transformacin (DigestValue) utilizando algn
algoritmo (DigestMethod)
crear el elemento Reference incluyendo los mtodos y el digest:
<Reference URI="http://www.foo.com/securePage.html">
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
</Reference>

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>

canonicalizar el elemento SignedInfo recin creado utilizando el mtodo


CanonicalizationMethod,
calcular el hash de la canonicalizacin 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 Verificacin de la firma


El proceso de verificacin de la firma es el proceso inverso a la generacin y consiste de
dos etapas: la validacin de las referencias y la validacin de la firma, que sern explicadas a
continuacin.

9.5.1 Verificacin 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 transformacin (en caso de ser necesaria),
calcular el hash de la transformacin utilizando el algoritmo especificado en
DigestMethod

24
comparar el hash obtenido con el correspondiente DigestValue
especificado en la referencia: si son distintos, la validacin falla.

9.5.2 Verificacin de la firma


Si todas las referencias son vlidas, 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 pblica del emisor (mediante KeyInfo o de alguna otra
manera),
calcular el hash de la canonicalizacin de SignedInfo,
desencriptar el elemento SignedInfo con la clave pblica y comparar el hash
obtenido en el paso previo con el incluido en el SignatureValue: si son
distintos, la validacin falla.

9.6 Algoritmos Disponibles


Los algoritmos que pueden utilizarse en SignatureMethod para firmar y verificar firmas
son los siguientes:
DSA-SHA1 (implementacin de Digital Signature Algorithm (DSA)
HMAC-SHA1
RSA-SHA1 (recomendado)

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>

Este es un ejemplo simplificado para ilustrar la aparicin 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 slo se encript el ID).

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.

10.1 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 raz 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 slo se encripta el contenido del elemento excluyendo los tags externos).
Los elementos principales del prximo nivel son: el mtodo de encriptacin 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 informacin miscelnea acerca del
dato encriptado, como por ejemplo la fecha de encriptacin.
El elemento opcional KeyInfo es similar al de XML Signature: contiene la clave
embebida o informacin sobre cmo obtenerla. En caso de utilizarse un mtodo de
encriptacin de clave pblica, el subelemento EncryptedKey contiene la clave secreta
compartida de sesin encriptada con la clave pblica 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 prximo captulo.

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"/>

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmlsig#" /> (*)


<EncryptedKey>
<EncryptionMethod
Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo xmlns:ds=http://www.w3.org/2000/09/xmlsig# /> (**)
<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 (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).

10.3 Proceso de Encriptacin


Para realizar la encriptacin se realiza el siguiente proceso (simplificado):
elegir el algoritmo de encriptacin y especificarlo en el elemento
EncryptionMethod,
obtener una clave de encriptacin de alguna manera (generalmente se genera
una compartida, lo cual es eficiente) y optativamente, y segn el caso,
especificar informacin para obtenerla en el elemento KeyInfo,

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.

10.4 Proceso de Desencriptacin


Para realizar la desencriptacin se realiza el siguiente proceso (simplificado):
obtener el algoritmo, los parmetros y la informacin de clave desde
EncryptionMethod y KeyInfo,
obtener la clave de alguna manera: o se conoce de antemano o se utiliza la
informacin disponible en KeyInfo para hallarla,
desencriptar segn 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.

10.5 Algoritmos disponibles


Los algoritmos que pueden utilizarse en EncryptionMethod para encriptar y
desencriptar son los siguientes:
Triple-DES (http://www.w3.org/2001/04/xmlenc#tripledes-cbc)
Advanced Encryption Standard (AES) 128-bit key
(http://www.w3.org/2001/04/xmlenc#aes128-cbc)
Advanced Encryption Standard (AES) 256-bit key
(http://www.w3.org/2001/04/xmlenc#aes256-cbc)
Advanced Encryption Standard (AES) 192-bit key
(http://www.w3.org/2001/04/xmlenc#aes192-cbc)

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>

De esta manera se obtienen algunas ventajas:


Se protege el elemento Signature evitando que pueda ser eliminado.
Se oculta completamente la informacin 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 operacin: primero se debe desencriptar y luego
validar la firma (en el primer ejemplo no haba 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 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.

SAML es incorporado al estndar WS-Security (siendo el tercer y ltimo pilar, junto a


XML Encryption y XML Signature) por las siguientes cuatro razones:
Es un formato estndar XML que no depende del protocolo de transporte.
Incluye un protocolo de intercambio de mensajes estndar, donde claramente
se define cmo preguntar por la informacin que uno necesita.
Especifica las reglas sobre cmo debe ser transportado (generalmente ser
SOAP sobre HTTP)

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.1 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 polticas desde las autoridades SAML.
Bindings: son reglas para las aserciones para utilizar los frameworls de
mensajera y transporte.

La relacin entre estos tres mecanismos es ilustrada a continuacin:

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.

12.2.1 Aserciones de Autenticacin


Una autoridad de autenticacin recibe credenciales de un usuario y las procesa de acuerdo a
su poltica. Si el proceso de autenticacin es satisfactorio, la autoridad declara que el usuario
S fue identificado a travs del mtodo M en el instante T, lo cual permite confiar en que la
identidad digital del sujeto representa la identidad fsica del mismo.
Ms especficamente, si la autoridad determina que las credenciales son vlidas se crea
un elemento AuthenticationStatement. Este elemento contiene el mtodo
(AuthenticationMethod) utilizado para la autenticacin, as como el tiempo
(AuthenticationInstant) en el que el proceso de autenticacin ocurri. El elemento
AuthenticationStatement opcionalmente puede contener un SubjectLocality
que especifica el nombre DNS y la direccin IP del sistema de autenticacin.

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

Aunque SAML no provee un modelo de revocacin, 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 expiracin. A continuacin se muestra un ejemplo
simple del elemento AuthenticationStatement para Bob, quien fue autenticado a
travs de un password:
<saml:Assertion ...>
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML: 1.0:am:password"
AuthenticationInstant="2001-12-03T10:02:00Z">

<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>

12.2.2 Aserciones de Atributos


Cuando la autoridad de autenticacin 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 tpicos de atributos son el estado actual de cuenta de un individuo y
su lmite de crdito. A continuacin se presenta una asercin de atributo para una persona
cualquiera especificando los atributos recin mencionados: el estado y el lmite de pago.

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.2.3 Aserciones de Autorizacin


Una autoridad de autenticacin 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 podra ser un humano o bien una
computadora (web service) y el recurso requerido podra ser otro web service.
A continuacin mostramos una sentencia de autorizacin para un usuario cualquiera
que autoriza al sujeto acceder y ejecutar el recurso especificado por la URL.
<saml:Assertion ...>
<saml:AuthorizationStatement
Decision="Permit"
Resource="http://jonesco.com/doit.cgi">
<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 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>

12.3.2 Attribute Request


Un requerimiento de atributos es como preguntar Cuntos atributos disponibles hay para
el sujeto?. La respuesta nuevamente es una asercin conteniendo una sentencia de
atributo. En el requerimiento se puede preguntar por informacin relacionada con un
atributo especfico A, B y C, o bien por todos los atributos.
El requerimiento es enviado a la autoridad de atributo (attribute authority) con la
asercin de autenticacin previamente obtenida. Esta autoridad utiliza una poltica para
determinar los privilegios del sujeto.
El elemento AttributeStatement contiene los subelementos Subject,
Attribute, NameIdentifier, SubjectConfirmation, ConfirmationMethod, y
SubjectConfirmationData.
A continuacin se muestra una consulta de atributo para un sujeto no especificado que
requiere informacin acerca del atributo EstadoPagos para una cuenta determinada,
especificada va un URL a travs del elemento AttributeNameSpace.

38
<samlp:Request ... >
<samlp:AttributeQuery>
<saml:Subject>...</saml:Subject>
<saml:AttributeDesignator
AttributeName="EstadoPagos"
AttributeNamespace="http://company.com"/>
</samlp:AttributeQuery>
</samlp:Request>

12.3.3 Authorization Request


Un requerimiento de autorizacin es como preguntar: Este sujeto, tiene permitido
acceder al recurso requerido mostrando esta evidencia?. La respuesta nuevamente es una
asercin conteniendo una sentencia de autorizacin y decisin.
El elemento AuthorizationDecisionStatement especifica qu decisin se ha
tomado respecto del pedido de autorizacin. Este elemento contiene el URI del recurso
que el sujeto est requeriendo acceso, la decisin de permitir (Permit) o denegar (Deny), una
accin que determina qu usuario est autorizado para hacer lo que se est pidiendo y una
evidencia para poder basar dicha decisin.
En el siguiente ejemplo se presenta un requerimiento de autorizacin para Bob de la
compaa Company.com preguntando si est autorizado a ejecutar un script CGI que
realiza una reserva en un hotel.

<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>

12.3.4 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 continuacin se presenta una respuesta a un requerimiento de autenticacin que
muestra al solicitante de la respuesta como Company.com y especifica por cunto tiempo
durar la autenticacin.

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.

POST /SamlService HTTP/1.1


Host: www.example.com
Content-Type: text/xml
Content-Length: nnn
SOAPAction: http://www.oasis-open.org/committees/security
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<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 continuacin, se presenta un ejemplo del mensaje SOAP de respuesta


correspondiente que provee la asercin conteniendo la sentencia de autenticacin
requerida.
40
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<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
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.

13.1 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 dnde vaya ni por cunto 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 viajarn los mensajes.
La diferencia fundamental es que en Transport Security el mensaje SOAP permanece
seguro slo dentro del canal, mientras que en Message Security el mensaje permanece
seguro (conceptualmente) sin importar dnde vaya debido a que contiene encriptacin,
firma digital y autenticacin 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 Message Security


Point-to-point End-to-end

Estandarizado, relativamente fcil de Nuevo, bastante complejo, con muchas opciones de


implementar seguridad que dificulta la implementacin

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

La seguridad depende del protocolo de La misma seguridad se puede aplicar en diferentes


transporte tecnologas de transporte

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>

<!-- 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 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:

Prefijo Abreviatura de Namespace


ds Digital signature http://www.w3.org/2000/09/xmldsig#
wsse WS-Security extension http://www.docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-secext-1.0.xsd
wsu Web services utility http://www.docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-wssecurity-utility-1.0.xsd
xenc XML Encryption http://www.w3.org/2001/04/xmlenc#

13.3 Security Tokens en WS-Security


Un security token es un elemento de seguridad includo en el mensaje con fines de
autenticacin. El estndar 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 varan segn el tipo de token utilizado.
A continuacin presentamos algunos ejemplos simples de tokens de seguridad donde
pueden observarse las diferencias entre ellos.

13.3.1 Ejemplo de token username/password


Este es el tipo de token ms 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 autenticacin bsica username/password de HTTP).
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>Zoe</wsse:Username>
<wsse:Password>ILoveDogs</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>

13.3.2 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 ms utilizada.
<wsse:Security>
<wsse:BinarySecurityToken wsu:Id="myKerberosToken
ValueType="wsse:Kerberosv5TGT
EncodingType="wsse:Base64Binary">
MIIEZzCCA9CgAwIBAgIQEmtJZc0 ... (dato en base64)
</wsse:BinarySecurityToken>
</wsse:Security>

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>

13.3.4 Ejemplo de token SAML Assertion


Por ltimo presentamos un ejemplo de asercin SAML.
<wsse:Security>
<saml:Assertion
MajorVersion="1"
MinorVersion="0"
AssertionID="SecurityToken-ab12345"
Issuer="yourIssuer"
IssueInstant="2003-03-31T10:31:04.6118148-05:00"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
...
</saml:Assertion>
</wsse:Security>

13.3.5 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.

13.4 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 ms comn 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 ira el texto en plano. En WS-Security, se crea adems

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>

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 podran incluir varias referencias apuntando
a direfentes elementos del documento. Tambin 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 mensajera funcione correctamente.

13.5 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 estndares, 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 propsitos: firmar parte o todo el mensaje (para proveer
integridad) y firmar/verificar un security token (si se lo considera necesario).

13.5.1 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
explcito.

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.

<!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="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>

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 especfico 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
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.

ENTIDADES INT y JUS:


Cada entidad tiene desarrollada una aplicacin local, que ante una actualizacin del
estado de inhibicin para entrar o salir del pas de una persona genera una notificacin al
web service de PFA informando este hecho.
Para que la entidad PFA pueda corroborar el buen estado de la comunicacin con
estas entidades, podemos asumir que cada cierto intervalo de tiempo obligatoriamente se
genera una notificacin 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 notificacin en ese
intervalo de tiempo, puede informar a la entidad MIG este hecho para que acte 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 especificacin y la direccin 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 sesin como
clave simtrica encriptada con el algoritmo AES 128 bits que luego ser protegida mediante
la encriptacin con la clave pblica de MIG.
La respuesta se firma antes de ser encriptada para asegurar la integridad de la misma.
Luego de la encriptacin 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 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.

A continuacin se presenta un esquema del diseo propuesto:

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

También podría gustarte