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