1 Introducción - Ayuntamiento de Madrid

ANEXO a la Guía de Estándares
Manual de Servicios web
1
Índice
1
2
3
Introducción _________________________________________________ 3
1.1
Resumen general _______________________________________________ 3
1.2
Uso del documento _____________________________________________ 3
Resumen de recomendaciones __________________________________ 3
2.1
Requisitos de infraestructura y transporte___________________________ 3
2.2
Requisitos de interoperabilidad, estándares y desarrollo _______________ 4
2.3
Requisitos de gobierno __________________________________________ 6
Proxy corporativo de servicios web. ______________________________ 7
3.1
Políticas de seguridad de Tibco APM _______________________________ 8
3.2
Entornos _____________________________________________________ 10
Tablas e ilustraciones
Tabla 1. Elementos de SOAP-Fault ................................................................... 5
Tabla 2 Políticas de Seguridad .......................................................................... 9
Ilustración 1 Arquitectura de TIBCO APM.......................................................... 8
2
1 Introducción
1.1 Resumen general
Este documento contiene el conjunto de recomendaciones técnicas y de
gobierno que debe cumplir cualquier servicio web implantado o utilizado dentro del
contexto de la arquitectura SOA del IAM.
Cualquier servicio web, ya sea desarrollado y puesto en marcha por el área de
Informática del Ayuntamiento de Madrid, o proporcionado de manera externa, debe
ceñirse a los mismos, con el objetivo de:

Favorecer la interoperabilidad entre sistemas y aplicaciones.

Facilitar la reutilización de los servicios.

Simplificar la operativa de gestión.
1.2 Uso del documento
Este documento está orientado en primera instancia a analistas y
desarrolladores; puede ser foco de interés para jefes de proyecto y responsables de
áreas.
2 Resumen de recomendaciones
Los requisitos cubiertos en este documento son:

Requisitos de infraestructura y transporte.

Requisitos de interoperabilidad, estándares y desarrollo.

Requisitos de gobierno.
2.1 Requisitos de infraestructura y transporte

De manera general, se recomienda el uso de transporte HTTP en lugar
de JMS.

Se debe minimizar al máximo el “payload” contenido en el “body” de un
mensaje SOAP.
3
2.2 Requisitos de interoperabilidad, estándares y desarrollo

Utilizar estándares completamente cerrados y ampliamente aceptados.
Los estándares básicos recomendados son SOAP 1.1, WSDL 1.2, UDDI
3.0, y HTTP 1.1.
o Se recomienda el uso de estas versiones de todos ellos, aunque
esto no es un requisito bloqueante.
o Están soportados, además SOAP 1.2, WSDL 2.0, UDDI 2.0,
UDDI 1.0. Si se usan, debe indicarse la versión usada del
protocolo, y justificar su utilización de manera adecuada.

Las transformaciones de transporte, mapeos, transformaciones de datos
o enrutamientos no deben llevarse a cabo en el servicio, dado que no
es algo funcional del negocio. Al no ser algo funcional, ninguna de estas
funcionalidades debe considerarse dentro del ámbito de implementación
de los servicios, siendo responsabilidad de la capa de mediación de la
infraestructura. Como ejemplo de acciones que no debe realizar el
servicio podemos enumerar:
o Transformación para protocolo de transporte.
o Servicio de enrutamiento y gestión de versiones de los servicios.
o Transformaciones de datos de una solicitud de entrada al
formato que se espera por el servicio proveedor.
o Reutilización de uso de ciertas funcionalidades como son la
validación, el registro y el control de errores.

El versionado de servicios debe ser tratado adecuadamente dentro del
ciclo de vida de un servicio, dado que de otra forma se está forzando a
los clientes a migrar a la versión nueva. Las recomendaciones son:
o Cambiar la versión de los nombres de los ficheros de los
WSDLS’s.
o No cambiar la versión en los nombres de namespaces.
o El servicio se añade al registro de servicios con la categoría
uddi:servicios-ayuntamiento.versioning.Vxx.yy.zzz. La policita de
numeración de versiones será la misma que se indica la guía de
estándares.

La gestión de errores de un servicio web debe usar SOAP-FAULT
prioritariamente.
4
o SOAP-FAULT se compone de los elementos que aparecen en la
siguiente tabla. En tiempo de desarrollo, se puede complementar
este esquema con campos de error adicionales, siendo, como
mínimo, los elementos integrantes los siguientes:
Titulo
Descripción
<faultcode>
Código que identifica el fallo, los posibles valores son los siguientes:

VersionMismatch: Si se encuentra un namespace inválido en el
mensaje SOAP.

MustUnderstand: No se ha encontrado un elemento en la
cabecera del mensaje cuyo atributo “mustunderstand” tiene valor
1.

Client: El mensaje está incorrectamente formado o tiene
información incorrecta.

Server: Se ha producido un error en el servidor y el mensaje no
se ha podido procesar.
<faultstring>
Descripción legible del mismo.
<faultactor>
Información acerca de quién causo el error.
<detail>
Guarda información específica de la aplicación
Tabla 1. Elementos de SOAP-Fault

De manera general, debe utilizarse el patrón de intercambio de
mensajes (MEP) de invocación/respuesta ("in/out"), siendo el conjunto
completo de patrones de intercambio de menajes el siguiente:
o In-Only: este patrón consta de un solo mensaje, de entrada. En
este caso el patrón describe la llegada de un mensaje a un
punto de entrada a un servicio. El servicio no envía respuesta.
o In-Out: este patrón consta de dos mensajes, uno de entrada y
otro de salida. En este caso el patrón describe la llegada de un
mensaje a un punto de entrada a un servicio y dicho servicio
envía una respuesta.
o Request-Response: este patrón es exactamente igual que el Inout con la salvedad de que el mensaje de respuesta se envía a
través del mismo canal que el de entrada.
o In-Multi-Out: este patrón consta de al menos dos mensajes, uno
de entrada y al menos otro de salida. En este, caso el patrón
describe la llegada de un mensaje a un conjunto de servicios;
dichos servicios envían cada uno una respuesta, y dado que hay
5
varias instancias de ellos, puede recibirse más de una
respuesta.
o Multicast-Solicit-Response: en este caso se tiene un mensaje
de salida, que tiene su correspondiente respuesta, a la que
sigue una la salida de otro mensaje. Es poco usado por lo que
no se incide más en su detalle.

Evitar el uso de mensajes multipart en el portType del WSDL, dado que
su uso no está suficientemente maduro.

Utilizar “SOAP explicit headers”.
o La especificación WSDL ofrece dos formas diferentes de
especificar el uso de campos de cabecera SOAP: explicit
headers e implicit headers.
o En explicit headers, se añade toda la información de encabezado
al portType del servicio, y esa información de encabezado queda
como parámetros adicionales (para el cliente que usa el
servicio).
o El uso de cabeceras explícitamente definidas a nivel soapenvelope, da soporte para una mejor interoperabilidad y un
menor coste de implementación.

Utilizar inline WSDLs siempre que sea posible, no utilizar include. El uso
de sentencias include en WSDLs puede suponer problemas para
algunas herramientas de diferentes fabricantes. Con el fin de eliminar
este riesgo, se recomienda definir los esquemas en el propio XML del
WSDL, sin utilizar la sentencia include, siempre que ello sea posible.

Los WSDLs siempre deben tener namespaces definidos, para evitar
problemas de interoperabilidad.
2.3 Requisitos de gobierno

Los desarrollos de los servicios no deben contener elementos como
seguridad, validaciones de esquema, auditoría: debe utilizarse un proxy
delegado que se encargue de aplicar las políticas estipuladas,
obteniendo un código "no contaminado" con implementaciones no
funcionales del negocio.
o Los aspectos de cifrado, firma digital, autenticación, autorización,
censura de datos, validación de esquemas y auditoría, en
runtime, queda en manos de un componente que hace de proxy
6
de los servicios, enriqueciéndose la funcionalidad de negocio,
con todo un conjunto de funcionalidades externas adyacentes.

Todo servicio nuevo, existente, modificado o reutilizado dentro del IAM
debe ser publicado en el registro global de servicios del IAM para
favorecer su visibilidad, proporcionando una herramienta de gobierno
que facilite la reutilización de los servicios y minore su duplicidad.

Siempre utilizar nombres completamente cualificados (QFN) en los web
services, con el fin de aislar la arquitectura de cambios en la
infraestructura, evitando el uso de IPs.

En todos los Web Services debe crearse un método dummy para
comprobar la disponibilidad del servicio. Para ello se debe crear una
operación con nombre dummy. Esta operación no recibirá ningún input.
Su mensaje de respuesta será dummyResponse de tipo String cuyo
contenido será “CORRECTO” en caso de que no exista fallo. En caso
de que se encuentren problemas en el servicio devolverá un soap-fault.
3 Proxy corporativo de servicios web.
Actualmente está implantado en IAM “Tibco ActiveMatrix Policy Manager”, a
partir de ahora Tibco APM, que actúa como proxy corporativo para los servicios web. A
continuación describiremos las distintas características que Tibco APM aporta al
desarrollo de los servicios web.
Tibco APM ayuda a separar los aspectos transversales (seguridad, auditoría,
login, etc) de un servicio web de los puramente de negocio. Para ello Tibco APM se
establece como proxy del servicio de forma que un cliente consumidor del servicio
interactúa con Tibco APM en lugar de directamente con el servicio.
Tibco APM posibilita definir políticas centralizadas de seguridad, auditoría, login
y acuerdos de nivel de servicio para servicios construidos en java o .NET. Es un
producto que gestiona servicios utilizando políticas, entendiendo por políticas a un
conjunto de instrucciones que utiliza para inspeccionar o modificar los mensajes.
Desde el punto de vista del usuario, las políticas se van a implementar de un modo
declarativo, para especificar un determinado comportamiento.
7
Ilustración 1 Arquitectura de TIBCO APM
3.1 Políticas de seguridad de Tibco APM
La configuración de seguridad en Tibco APM se establece en base a políticas
que detallamos a continuación:
POLÍTICA
Trazas(Logging)
DESCRIPCIÓN
Con ella obtendremos trazas completas de las peticiones
realizadas al servicio.
Esta política permite emparejar los mensajes de petición con
sus respuestas. Los mensajes de salida pueden ser mensajes
de respuesta o SOAP-Fault.
Autenticación
Obliga a la autenticación del usuario que accede al Servicio,
contra un Identity Management Systems (IMS) corporativo.
Puede opcionalmente, autenticarse mediante firma digital en
lugar de usar el IMS corporativo.
1.- Autenticación IMS
Esta política consulta al LDAP corporativo del IAM para
autenticar cada mensaje.
2.- Firma Digital
8
El uso de la firma digital permite la Autenticación de un
mensaje de petición, basándose en técnicas de cifrado de
clave privada (algoritmo asimétrico). Se usan certificados y
firmas X.509.
Autorización
Se permitirá/denegará el acceso al usuario a ciertas
operaciones del Servicio en base al rol al que pertenezca
dicho usuario.
Autorización de operaciones por rol
Permite autorizar la ejecución de las operaciones de un
servicio en función del rol del invocante, identificados mediante
los métodos de autenticación anteriores.
Censura
(censoring)
Cifrado
(Cryptography)
Esta política permite modificar la respuesta de una petición (ya
sea un mensaje correcto o un “Fault message”) para censurar
información sensible sobre el mensaje enviado según el rol del
solicitante.
Las políticas de cifrado protegen la privacidad de los datos y
su integridad al atravesar un mensaje una red, por lo general
una red insegura, como Internet.
Se realizará usará el algoritmo de cifrado asimétrico RSA 1.5
con SHA1
Tabla 2 Políticas de Seguridad
Es necesario disponer de un certificado digital para las políticas de:
-
Autenticación/Firma Electrónica: El emisor del mensaje de petición debe
firmar las peticiones con la clave privada de su certificado. Al llegar éstas al
Tibco APM, éste comprueba la firma contrastando con la parte pública del
certificado que previamente se tiene que haber proporcionado, identificando de
esta manera al peticionario.
-
Autorización o Censura/Firma Electrónica: Una vez autenticado al usuario
se le puede asociar a un rol al que aplicar políticas de autorización/censura.
-
Cifrado: Tibco APM tiene instalado un certificado de servidor. El emisor del
mensaje debe cifrar con la clave pública de dicho certificado el mensaje de
petición.
9
Para detalles sobre el uso y petición de los certificados es conveniente revisar
el apartado de la Guía de Estándares dedicado a certificados.
3.2 Entornos
A continuación se listan los dos entornos disponibles en el IAM donde se ha
instalado, montado y configurado Tibco APM.
- Staging: preparado para proveer seguridad de los servicios desplegados
en los entornos de Desarrollo, Preproducción y Formación.
- Producción: preparado para proveer seguridad de los servicios
desplegados en el entorno de Producción.
10