EXPEDIENTE

Transcripción

1 PLIEG DE PRESCRIPCINES TÉCNICAS PARA LA ADQUISICIÓN DE MÓDUL SFTWARE PARA AMPLIAR CAPACIDADES DE LA PLATAFRMA SA EXPEDIENTE

2 INSPECCI~N GENERAL CIS índice 1. BJET ANTECEDENTES RGANISM PRMTR INTRDUCCIÓN A LA PLATAFRMA SA Principios Concepto de Arquitectura rientada a Servicios (SA) Plataforma de lnteroperabilidad y Gobierno SA ESPECIFICACINES DEL MÓDUL SFTWARE Requisitos no funcionales Integración servicios PSSDEF en la Plataforma SA Integración servicios SPI (Sistema de Prescripción Informatizada del ISFAS) en la Plataforma SA Integración empresas suministradoras de carburantes con SIGECAR (Sistema De Gestión De Carburantes del ET) Integración de los servicios SGCl (Sistema De Gestión De Conocimiento Industrial de la DGAM) en la Plataforma SA Registro de servicios UDDl en la Plataforma SA Integración SA Appliance (Datapower IBM) en Plataforma SA Entorno de desarrollo de la Plataforma SA PRESENTACIÓN DE LA FERTA Condiciones Generales Contenido Criterios de valoración PRESUPUEST MÁXIM Anexo A. ACRÓNIMS... 20

3 INSPECCIN GENERAL CIS Y TtLIECYUMICICIN15 PLIEG DE PRESCRIPCINES TECNICAS PARA LA ADQUISICIN DE MDUL SFTWARE PARA AMPLIAR CAPACIDADES DE LA PLATAFRMA SA (EXP ). l. BJET El objeto del presente expediente consiste en la adquisición de un módulo software para ampliar las capacidades de la plataforma de lnteroperabilidad y de Gobierno SA de la WAN-PG. El módulo permitirá la integración de los sistemas siguientes: PSSDEF SPI del ISFAS. SIGECAR del ET SGCl de la DGAM Por otro lado el módulo posibilitará la integración del Registro de Servicios LIDDI y de un appliance SAIXML (IBM Datapower) en la plataforma SA. 2. ANTECEDENTES La Directiva núm del Ministro de Defensa sobre la elaboración del Plan Director de Sistemas de Información para la modernización 1 profesionalización de las FAS apuesta por el empleo de las Tecnologías de la Información y de las Telecomunicaciones como factor multiplicador de la capacidad operativa y como instrumento para reducir efectivos. Esta Directiva establece además, entre otros factores, la necesidad de homogeneizar y estandarizar los sistemas de información del Ministerio de Defensa para alcanzar la interoperabilidad entre dichos sistemas, tanto operativos como de gestión, y con los sistemas de otros organismos y internacionales. Por otra parte, por rden DEF/315/2002 de 14 de febrero de 2002, el Ministro de Defensa aprobó el Plan Director de Sistemas de Información y Telecomunicaciones en el que se establece la política del Ministerio respecto a las Tecnologías de la Información y Comunicaciones. Según el RD art. 6.5.c, la Inspección General del Plan Director de Sistemas de Información y Telecomunicaciones ejercerá las funciones de definición de las políticas y estrategias corporativas en el ámbito de la Administración Electrónica, las tecnologías de la información, telecomunicaciones y seguridad de la información del Ministerio de Defensa, así como la planificación y coordinación de las actuaciones en estas materias. La M por la que se aprueba el Plan Director CIS del Ministerio de Defensa, dentro del apartado referido a Infraestructura Tecnológica determina que la Plataforma Informática y la Arquitectura Técnica del MllVlSDEF evolucionan a una WAN Corporativa de Propósito General, que da soporte a todos los sistemas de información que no sean especificos para mando y control y se extiende a todos los emplazamientos. Este entorno incluye la conexión a lnternet del Ministerio de Defensa, desde un Único punto de acceso común para todos los usuarios, siendo la única conexión que la WAN de Propósito General

4 tendrá con el exterior. Esta Red se configurará y explotará con una perspectiva corporativa e integrada. En lo referente a Interoperabilidad: Existirá una única plataforma tecnológica de interoperabilidad básica con dos dominios diferenciados para cada una de las dos redes WAN. La ley 11107, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos establece el principio de "cooperación en la utilización de medios electrónicos por las Administraciones Públicas al objeto de garantizar tanto la interoperabilidad de los sistemas y soluciones adoptados por cada una de ellas como, en su caso, la prestación conjunta de servicios a los ciudadanos". Asimismo, en su artículo 41 establece que "las Administraciones Publicas utilizarán las tecnologías de la información en sus relaciones con las demás administraciones y con los ciudadanos, aplicando medidas informáticas, tecnológicas, organizativas, y de seguridad, que garanticen un adecuado nivel de interoperabilidad técnica, semántica y organizativa y eviten discriminación a los ciudadanos por razón de su elección tecnológica". Por último, en el artículo 43 establece que "la Administración General del Estado, [...], adoptarán las medidas necesarias e incorporarán en sus respectivos ámbitos las tecnologías precisas para posibilitar la interconexión de sus redes con el fin de crear una red de comunicaciones que interconecte los sistemas de información de las Administraciones Públicas españolas y permita el intercambio de información y servicios entre las mismas, así como la interconexión con las redes de las Instituciones de la Unión Europea y de otros Estados Miembros." La Instrucción Técnica de IGECIS "Modelo de Arquitectura I*NetM de Mayo de 2006 establece el modelo de arquitectura I*IVet para la Red de Área Extensa de Propósito General (WAN PG) que normaliza los servicios que ofrece dicha red desde o hacia el exterior. El Ministerio de Defensa ha determinado, entre otros, como servicios con el exterior asociados a la WAN PG la publicación de información accesible por Internet, acceso desde el exterior a recursos de la red de Propósito General, acceso a la lntranet Administrativa de la AGE, y acceso mediante líneas dedicadas de otros organismos y entidades al Ministerio de Defensa. Dichas necesidades sumadas a condicionantes de seguridad e interoperabilidad establecidos por el Ministerio de Defensa y normativa vigente del Centro Criptológico Nacional del Centro IVacional de Inteligencia ponen de manifiesto la necesidad de la definición de un modelo de arquitectura que englobe y regule los servicios previamente expuestos. En el contexto anterior del Modelo I*net y de los requisitos establecidos por la aplicación de la Ley es clara la necesidad de establecer una arquitectura de interoperabilidad uniforme y corporativa que permita al MlNlSDEF publicar servicios para el ciudadano y para otras administraciones públicas y, de modo simétrico, consumir los servicios expuestos por otras administraciones públicas, en ambos casos de modo seguro, monitorizado y gestionado de manera uniforme, y conforme a los estándares establecidos por el Ministerio de Defensa. En Diciembre del 2009 se publica la Instrucción Técnica de IGECIS "Modelo de Arquitectura rientada a Servicios del Minisdef'. Esta IT establece un modelo de arquitectura orientada a servicios de alto nivel que satisfaga entre otros los siguientes requisitos:

5 . Definir el concepto de Arquitectura rientada a Servicios (SA) del MlNlSDEF en el ámbito de la red de Propósito General.. Marcar estrategias tecnológicas y principios de diseño aplicables a la infraestructura tecnológica que soporte la SA del MINISDEF, sirviendo como documento maestro para la implantación de SA en el Ministerio de Defensa. Establecer un modelo de arquitectura orientada a servicios que permita cumplir con la política de seguridad del NIIIVISDEF, la normativa aplicable del Centro Criptológico Nacional del Centro Nacional de Inteligencia y la normativa legal vigente. El ámbito de aplicación de la Plataforma SA es la red de Propósito General del MlNlSDEF (WAN-PG) afectando tanto a sistemas funcionales como de plataforma, ya sean corporativos o específicos. La Plataforma SA surge como una solución para resolver los problemas de integración entre sistemas de información dentro del ámbito de la red de Propósito General, así como la interacción de sistemas de la WAN PG con agentes externos al MlNlSDEF vía la infraestructura desplegada por el Modelo I*net, en concreto en el "Nodo de Servicios Web" (acceso a ciudadanos y empleados a servicios del MlNlSDEF mediante portales y aplicaciones web) y en el "Nodo Extranet" (interacción con sistemas de información de terceros vía Internet, red SARA y líneas dedicadas). Los requisitos de integración de sistemas que resuelve la Plataforma SA se restringen a la interacción automática entre sistemas de información para intercambiar datos y reutilizar funcionalidades, quedando fuera de su alcance otros servicios de interoperabilidad tales como correo electrónico interpersonal, mensajería oficial, mensajería instantánea y otras herramientas colaborativas. 3. RGANISM PRMTR El diseño del presente Pliego de Prescripciones Técnicas, estudio de ofertas y adjudicación está promovido por la Inspección General del Plan Director de Sistemas de Información y Telecomunicaciones del Ministerio de Defensa. 4. INTRDUCCIÓN A LA PLATAFRMA SA Para poner en contexto el alcance del módulo software a desarrollar, se describe a continuación de manera resumida la Plataforma de lnteroperabilidad y de Gobierno SA del Ministerio de Defensa. En primer lugar se detallará desde un punto de vista conceptual la Plataforma SA, tal como se especifica en la IT "lblodelo de Arquitectura rientada a Servicios del Minisdef', danto una visión de alto nivel de todos los elementos de la arquitectura y sin entrar en detalles técnicos (productos y estándares) y por último se esbozarán la tecnología y productos adoptados para implementar/desarrollar la Plataforma SA del Ministerio de Defensa. 4.1 PRINCIPIS

6 A continuación se enumeran una serie de principios de alto nivel, de aplicación para el desarrollo de la Plataforma lnteroperabilidad y Gobierno SA del MINISDEF: Solución corporativa. Solución capaz de abarcar las necesidades de integración de los distintos sistemas de información de la WAN PG, independientemente de sus plataformas tecnológicas, tanto en interacciones internas a la WANPG como con el exterior. Robustez y perdurabilidad en el tiempo de la Arquitectura. Se pretende que sea lo más independiente posible de la evolución de la tecnología y los productos software con que se implemente. Adaptabilidad. Arquitectura capaz de adaptarse y evolucionar de acuerdo a los cambios tecnológicos y las nuevas necesidades de integración de los sistemas de la WANPG. Neutralidad tecnológica basada en estándares abiertos, independiente de la plataforma y del lenguaje de programación. De este modo se garantiza soportar las necesidades de integración de la mayor parte de los sistemas, independientemente de su tecnología. Escalabilidad. Debe permitir implantar soluciones técnicas fácilmente escalables de modo que soporte tanto necesidades de integración con requisitos de baja criticidad y volúmenes de datos discretos como necesidades más exigentes en volumen, rendimiento y fiabilidad. 4.2 CNCEPT DE ARQUITECTURA RIENTADA A SERVICIS (SN SA es un modelo de arquitectura de software que proporciona un enfoque modular y flexible para la implementación de requisitos funcionales en los sistemas. En una SA las funciones software de los sistemas se exponen como servicios reutilizables que pueden ser descubiertos e invocados a través de la red. El uso de SA facilita la compartición de aplicaciones y datos, proporcionando un mecanismo flexible para reutilizar los servicios, habilitando el desarrollo de nuevas aplicaciones mediante la composición de servicios ya existentes. Un objetivo fundamental de SA es hacer que los recursos de información estén disponibles en la red para todos los potenciales sistemas consumidores, y soportar el descubrimiento y entrega eficiente de dicha información al sistema consumidor. El desarrollo del concepto SA está ligado a los requisitos cambiantes de los entornos corporativos, lo que provoca la necesidad de adaptarse más rápidamente a los cambios. SA facilita el desarrollo de aplicaciones nuevas basadas en la reutilización de los servicios disponibles en la red. SA es también consecuencia de la búsqueda de acoplamiento débil entre sistemas, de modo que un sistema pueda utilizar las funciones y datos de otro mediante interfaces bien

7 definidos. Este acoplamiento débil debe ser lo más neutral posible desde el punto de vista tecnológico, facilitando la evolución independiente de cada sistema. SA puede definirse como un modelo de arquitectura para la creación de sistemas modulares, que pueden interoperar mediante interfaces bien definidas e independientes de la tecnología en la que estén implementados, que utilizan metadatos estándar y cuya localización es posible gracias a un registro de servicios estandarizado. Estos servicios pueden invocarse de modo independiente o en secuencias definidas para formar procesos de negocio. Los sistemas están débilmente acoplados y se ven los unos a los otros como servicios, accesibles vía interfaces estándar sin conocer la implementación subyacente del servicio. Un bus de servicios gestiona y coordina la interacción entre los servicios. Los datos se intercambian mediante un formato común usando protocolos estándar, lo cual asegura la interoperabilidad. Todo ello permite que se produzcan interacciones sistema-a-sistema no previstas en el momento del diseño de cada sistema. Cualquier SA contiene tres roles básicos: consumidor de servicios, proveedor de servicios e intermediario de servicios. 1. Un proveedor de servicios es responsable de la creación y descripción de un servicio, publicarlo en un intermediario de servicios, y recibir los mensajes de invocación del servicio desde uno o mas consumidores a través del intermediario de servicios. 2. Un consumidor de servicios es responsable de encontrar una descripción de un servicio en un intermediario de servicios, y utilizar la descripción para invocarlo. 3. Un infermediario de servicios es responsable de publicar las descripciones de servicios publicadas por los proveedores y de permitir a los consumidores descubrir e invocar servicios. La Plataforma de lnteroperabilidad y Gobierno SA del MINISDEF debe proporcionar una serie de servicios comunes que permitan a cualquier sistema de información de la WANPG actuar como proveedor o consumidor de servicios, asumiendo esta Plataforma el rol de intermediario de servicios. 4.3 PLATAFRMA DE INTERPERABILIDAD Y GBIERN SA En el diagrama siguiente se resume la arquitectura lógica de alto nivel definida en la Instrucción Técnica de IGECIS "Modelo de Arquitectura rientada a Servicios del Minisdef'. En el diagrama se observa la SA corporativa del MINISDEF, reflejando la relación con los nodos del modelo I*net implicados, los sistemas funcionales y los de Plataforma.

8 lntranet 1 ~nvocaciones sejuma a servicios Agente de \ Políticas Qoyponante : dssrwiclo 1 : Componentes 1 i pam la : e-administmclbn Sistemas Funcionales, Validacid csitlficados, firma, cif do,... " rm-rm_" 1 usua 1 ciutori roles, Notifica iones **." lb Sistemas de Plataforma,,! ' **-.-** m----. * En base al diagrama anterior se describen a continuación los elementos de la arquitectura: Los Sistemas funcionales, legados o nuevas aplicaciones (como en el caso de componentes funcionales para la e-administración), están basados en diferentes plataformas tecnológicas. Mediante componentes de servicio se conectan a la plataforma mediante protocolos de transporte de nivel de aplicación tales como http, SAP, ftp, jdbc, etc. o Siempre que sea posible se utilizarán esquemas XML para especi.ficar los datos intercambiados por los servicios. Dichos esquemas XML forman parte del Modelo de Datos Canónico (común) almacenado en el Registro de Metadatos de Defensa. Los sistemas de plataforma, proporcionan diversos servicios comunes, pero no soportan funcionalmente el "negocio" de la organización. Inicialmente se requiere la integración con los sistemas siguientes: o PSSDEF. Provee servicios de seguridad tales como validación de certificados electrónicos, firma digital y cifrado. DICDEF. Directorio corporativo del MlNlSDEF que gestiona los usuarios,

9 roles y autorizaciones. o Notes. Cuando la operativa lo requiera proporciona envío de notificaciones mediante correo interpersonal. Bus de servicio en intranet. Permite la ejecución de los servicios de la plataforma proporcionando las siguientes características: o o o Mediación de datos: Permite la interacción entre el consumidor y proveedor del servicio. Contiene capacidades para transformación y transporte de datos. Adicionalmente, permite la orquestación de servicios. Servicios core no funcionales. Proporciona gestión de errores y de trazas comunes para todos los servicios, además de una gestión de logs uniforme. Capacidades de monitorización y cumplimiento de SLA's. Registro de Servicios. Repositorio de información donde se publicarán los servicios disponibles en la red para poder ser reutilizados por otras aplicaciones. Existen dos instancias diferentes: o El Registro de Servicios de la lntranet publica los servicios disponibles en la red para ser reutilizados por aplicaciones internas del MINISDEF. o El Registro de Servicios Público del Nodo extranet publica los servicios del MlNlSDEF susceptibles de ser consumidos por una organización externa al Ministerio de Defensa. o En el caso de servicios proporcionados por una organización externa al MINISDEF que susceptibles de ser consumidos por aplicaciones internas del MINISDEF, serán publicados en el Registro de Servicios de la Intranet, aunque siempre mediados por el Bus de Servicios, para garantizar seguridad y monitorización. Registro de Metadatos de Defensa (RMD). Se publican y gestionan los esquemas de datos pertenecientes al Modelo Común de Datos, así como otros esquemas, metadatos y documentación asociada relacionada con la Plataforma. Portales y aplicaciones web del MIhIISDEF en Internet. Son todas aquellas aplicaciones web (incluyendo portales) residentes en el Nodo de Servicios Web que requieren consumir servicios disponible en la Intranet, los cuales están publicados en el Registro de Servicios de la Intranet. Bus de servicios en el nodo extranet. Su función primordial es mediar los servicios publicados por el MlNlSDEF susceptibles de ser consumidos por organizaciones externas, garantizando la seguridad. Autentica y autoriza a las aplicaciones ajenas al MlNlSDEF mediante PPSDEF. Adicionalmente transforma y enruta los mensajes de la aplicación consumidora hacia el servicio final de la intranet, junto con el Agente de Políticas.

10 Agentes de políticas. Aplica las políticas de seguridad que se requieran para permitir la invocación de un servicio. Existirán las instancias requeridas en cada caso, indicadas en el apartado siguiente. Por otro lado la infraestructura técnica SA que se ha utilizado para desarrollar la Plataforma SA se basa fundamentalmente en tecnología TIBC. Los productos que se están actualmente utilizando son los siguientes: 'TIBC Business Works 5.7 TIBC ActiveMatrix Policy Manager 3.0 TlBC ActiveMatrix Policy Agent 3.0 TlBC ActiveMatrix Registry 2.0 TlBC TRA 5.6 TlBC Rendezvous 8.1 TlBC EMS 5.1 TlBC Administrator 5.6 TlBC Hawk El desarrollo del nuevo módulo se efectuará sobre dichos productos TIBC, pero usando configuraciones que respeten al máximo los estándares abiertos de W3C, de modo que los servicios ofrecidos por el nuevo módulo sean potencialmente invocados desde cualquier aplicación, basada en.net o Java. 5.1 Requisitos no funcionales El módulo software objeto del presente pliego deberá ampliar las capacidades de la Plataforma SA descrita en los anteriores apartados. En concreto, las capacidades funcionales a satisfacer se enumeran a continuación: Integración de todos los servicios web PSSDEF en la Plataforma SA Integración servicios web de SPI (Sistema de Prescripción Informatizada del ISFAS) en la Plataforma SA o Integración de información de empresas suministradoras de carburantes con SIGECAR (Sistema De Gestión De Carburantes del ET) mediante la Plataforma SA Integración de los servicios web de SGCl (Sistema De Gestión De Conocimiento Industrial de la DGAM) en la Plataforma SA Ampliación del Registro de servicios UDDl para adaptarlo a necesidades de la Plataforma SA Integración de un appliance SAlXML (IBM Datapower) en la Plataforma SA

11 La funcionalidad de cada una de las nuevas capacidades enumeradas anteriormente se detalla en apartados posteriores. A continuación se especifican una serie de requisitos no funcionales que aplican a todas ellas. Requisitos de documentación técnica Cada una de las integraciones cubiertas por el nuevo módulo deberá ir acompañada de la siguiente documentación conforme a las plantillas de MllVlSDFEF - IGECIS para MS ffice: Diseño de la solución, incluyendo diagramas de arquitectura y diagramas de secuencia detallados Documento de desarrollo e implementación detallado que incluya todas los procesos y configuraciones desplegadas en los componentes de la arquitectura Documento de pruebas en entorno de desarrollo y preproducción Documento de paso a producción que incluya toda la información necesaria para apoyar el paso a explotación. Los diagramas de la documentación se desarrollarán con Microsoft Visio, entregándose adicionalmente junto con los documentos anteriores en MS ffice. Requisitos de estandarización de servicios El desarrollo de las integraciones anteriores dará lugar a interfaces de web services (endpoints) en diversos componentes de la arquitectura (Business Works, Policy Agent,..). Cada uno de los servicios ofrecidos por el nuevo módulo, susceptible de ser consumido por aplicaciones de terceros, debe satisfacer: Descrito por un WSDL autocontenido (sin referencias a esquemas externos, salvo que sea prescrito por una especificación estándar aplicable) Susceptible de ser publicado en un registro LIDDI con toda la información necesaria para ser consumido por cualquier plataforma de desarrollo, basada en.net o java. Incluir en el WSDL o en la descripción del servicio en el registro toda la información de las políticas de seguridad requeridas para consumir el servicio. Para comprobar la validez y neutralidad tecnológica de cada servicio, su documentación y WSDL deberá acompañarse de la configuración y ejemplos de mensajes de invocación con las herramientas gratuitas SAPBox y10 SAPUI. Los principales estándares a implementar relacionados con la seguridad de servicios web al objeto de proporcionar autenticación y autorización son:

12 WS-Security para la invocación de servicios, proporcionando la autenticación de dos modos posibles: usernametoken (usuario y password) o binarytoken (certificado x.509 con firma del mensaje) SAML, en concreto SAML 1.1 token assertions para proporcionar información sobre autenticación/identidad del usuario y10 atributos relacionados con la autorización de acceso al servicio, de modo que esta información progrese hasta el proveedor final del servicio. Los tokens SAML podrán estar firmados, garantizando su integridad. A nivel de transporte https con autenticación mutua (two-way SSL) de modo que se garantice un canal seguro entre cliente y servidor. Los mecanismos de seguridad anteriores se combinarán segun los requisitos exigidos en cada caso de integración. 5.2 Integración servicios PSSDEF en la Plataforma SA El módulo posibilitará la integración con el sistema de plataforma PSSDEF existente en WANPG con el objetivo de establecer un modelo común de seguridad en la autenticación y autorización para el consumo de servicios web del Minisdef por parte de aplicaciones internas así como por aplicaciones externas al Minisdef. PSSDEF en un sistema basado en tecnología TrustedX que ofrece una serie de servicios de seguridad. Los servicios de PSSDEF están basados en tecnología de servicios web (SAP, WSDL). El nuevo módulo soportará la integración en TlBC Bussiness Work de los servicios web ofrecido por PSSDEF. Los servicios web a integrar de PSSDEF serán los siguientes: Servicio de verificación de firma y validación de certi.ficado X.509 Servicio de generación de firma. Servicio de autenticación/autorización Posteriormente estos rnismos procesos se desplegarán en los entornos de preproducción y producción del CCEA. El propósito de integración de los servicios de PSSDEF debe satisfacer dos necesidades complementarias: Permitir a cualquier aplicación consumir los servicios de PSSDEF a través de la Plataforma SA, mediante un interfaz de servicio web completamente estándar, y monitorizados de modo uniforme por la Plataforma SA Facilitar el uso de estos servicios en los procesos de integración desarrollados en la Plataforma, incluyendo los requeridos en las integraciones descritas en este PPT.

13 5.3 Integración servicios SPI (Sistema de Prescripción Informatizada del ISFAS) en la Plataforma SA Con el objetivo de proporcionar seguridad y rendimiento a la aplicación SPI, se pretende mediar una serie de servicios web de SPI en la Plataforma SA del Minisdef. SPI es un aplicación que ofrece servicio a usuarios finales mediante un portal en el nodo I*net. Este portal, basado en tecnología Java, invoca a servicios web de la intranet proporcionados por un sistema de ISFAS y a servicios web proporcionados por MUGEJU (entidad externa al MINISDEF) vía la red SARA. El propósito de la integración de dichos servicios en la Plataforma SA es doble: e e Garantizar la seguridad en las invocaciones a los servicios web (de ISFAS y MUGEJU) Mejorar el rendimiento actual de dichos servicios Las funciones a realizar por la Plataforma SA serán las siguientes: Integrar los servicios web de SPI en la Plataforma SA a través de la creación de los desarrollos correspondientes en TlBC Business Work en Nodo I*net. Validar la firma y certificado de los mensajes WS-Security enviados por SPI contra PSSDEF (Plataforma de Seguridad de Defensa). Redirigir las peticiones de servicio al sistema de ISFAS en la intranet o a los servicios web de MUGEJU en la red SARA, según corresponda. lmplementar la gestión de errores y log estándar en los procesos creados en el bus de servicio. Publicar los servicios web SPI-ISFAS en el Registro UDDl de la Plataforma SA Estandarizar los nuevos servicios web mediados por la Plataforma SA, cumpliendo lo requerido en el apartado 5.1. Despliegue de la integración en los entornos de preproducción y producción del CCEA. El diagrama siguiente resume la arquitectura objetivo de la solución:

14 SPI - lsfas Nodo I'Net lntranet Porta' SAPI i qg SPI https 'S r 1, ~aguridad de red (firewall)]- - - ISFAS SAPlhtips Valldacibn de firmas y certificados SPi PSSDEF.-- ~- '..._ ' Sistemas Funcionales Sistemas de Plataforma

15 El alcance del módulo objeto de este PPT se limita únicamente a los desarrollos dentro de la Plataforma SA (bus de servicio, agente de políticas y registro de servicios) excluyéndose aquellas modificaciones que pudieran tener lugar en el resto de sistemas implicados: portal SPI, SPI-ISFAS, MUGEJU y PSSDEF. 5.4 Integración empresas suministradoras de carburantes con SIGECAR (Sistema De Gestión De Carburantes del ET) Se pretende uniformizar el suministro de datos de consumo por las distintas empresa suministradoras de carburantes al sistema SIGECAR (Sistema de Gestión de Carburantes) del ET (NIINISDEF), a través de un servicio web publicado y gestionado en la Plataforma SA del nodo I*Net del MINISDEF. El diagrama siguiente resume la arquitectura objetivo de la solución. SIGECA R Integración de aplicación de gestión de carburantes del MALE-ET con empresas suministradoras (REPSL, CLH, CEPSA,...). Requisitos empresa suministradoras: -Invocara Web Se~ice público (WSDL, SAPIhttps) j Validación 1 certificados SIGECAR Seguridad! Sistemas Funcionales, ' ' Sistemas de Plataforma A continuación se describen de forma resumida los pasos que se ejecutarán: SistemaIEmpresa suministradora (Repsol, CEPSA, DISARED y CLH) envía información de consumo invocando a un servicio web residente en el bus de servicio público mediante SAPIHTTPS. Este servicio web estará especificado en el WSDL publicado por la Plataforma SA. 2. El bus de servicios público recibe el mensaje SAP y autentica el

16 sistema1empresa contra la Plataforma de Servicios de Seguridad (PSSDEF) (basado en certificado X.509 y.firma digital). Adicionalmente valida los formatos acordados para el envio de la información. 3. Plataforma SA (Agente de políticas) aplica políticas de seguridad (autorización) e invoca al servicio web publicado en el bus de servicio interno del WllNlSDEF en Intranet. En esta invocación el bus de servicio interno recibe la información que contiene el consumo de combustible. 4. El bus de servicio interno envía la información requerida por SIGECAR mediante el protocolo que se defina (ftp, SAPIhttp,..). El alcance del módulo objeto de este PPT se limita únicamente a los desarrollos dentro de la Plataforma SA (bus de servicio, agente de políticas y registro de servicios) excluyéndose aquellas modificaciones que pudieran tener lugar en el sistema final (SIGECAR), en los sistemas externos consumidores o en el sistema de Plataforma PSSDEF. 5.5 Integración de los servicios SGCl (Sistema De Gestión De Conocirriiento Industrial de la DGAM) en la Plataforma SA Se pretende integrar los servicios de la aplicación SGCl en la plataforma SA y para lo cual se han identificado los siguientes pasos: 1. Mediar los servicios web de SGCl en el bus de servicio interno (sin cambiar el interfaz del servicio) de la intranet. 2. Añadir la capa de gestión de errores y de logs a los servicios web mediados. 3. Autenticar y autorizar la invocación del servicio del bus usando el Policy AgentIManager, con el mínimo impacto en la aplicación, para lo cual se plantea utilizar SSL en el transporte y seguridad a nivel de mensaje con usernametoken en cabecera ws-security. El diagrama siguiente resume la arquitectura objetivo de la solución.

17 viclecyuuiclcycl SGCI Acceso seguro a servicios web de intranet desde portal públicoen nodo I*net Requisitos portal SGCI: -Invocar a Web Setvice intranet(wsdl, SAPíhttps) -WS-Security, usernametoken Prf-f-l Portal SGCI I I Websewices j + públlcos j WSDL, j U~eguros" j SAPI I, hnps ' SAPlhttp [,A, *\>i! , Sistemas Funcionales El alcance del módulo objeto de este PPT se limita únicamente a los desarrollos dentro de la Plataforma SA (bus de servicio, agente de políticas y registro de servicios) excluyéndose aquellas modificaciones que pudieran tener lugar en el sistema final SGCI o en el portal SGCI. 5.6 Registro de servicios UDDl en la Plataforma SA Las funcionalidades a incorporar en el módulo en relación al Registro de Servicios UDDI serán las siguientes: e lnterfaz del Registro personalizado con las necesidades del MINISDEF. Gestión de usuarios adaptada a las necesidades del MINISDEF (Administrador, Desarrollador, Gestor de Registro, externo). Integración de la autenticación de usuarios del Registro de Servicios con DICDEF (Directorio ldap corporativo del MINISDEF basado en Critical Path). Publicación de servicios, como mínimo los desarrollados en el contexto del módulo objeto de este PPT.

18 INSPECCIN GENERAL CIS Definición e implementación en el Registro de taxonomías de primer y segundo nivel adecuadas para el MINISDEF, eliminando las precargadas con la herramienta que no sean de aplicación. Integración del servicio de Subscripción con el servicio de correo corporativo 5.7 Integración SA Appliance (Datapower IBM) en Plataforma SA Las funcionalidades a incorporar en el módulo en relación al SA Appliance serán las siguientes: Despliegue de Datapower en el nodo I*Net del Minisdef y soporte a la administración del mismo. Integración de Datapower con PSSDEF para la validación de firmas y certificados tanto de aplicaciones externas como internas al Ministerio de Defensa. El trabajo consistirá en la creación de plantillas XSLT específicas de datapower. Configuración de las medidas de protección contra amenazas XML, incluyendo la generación de un juego de casos de uso de ataques específicos sobre webservices y XML para comprobar dichas medidas. Para el desarrollo de las capacidades anteriores se contara con servicios de consultoría y soporte de IBM proporcionados por el MINISDEF, N incluidos en este PPT. 5.8 Entorno de desarrollo de la Plataforma SA El entorno de desarrollo de la Plataforma SA está basado en los siguientes entornos y tecnologías: Herramientas de integración de TIBC: Designer, Business Works, Policy Agent, EMS y Registry. XML Appliance: Datapower de IBM, Tecnologías de integración java (JCA, JBI, JTA, JMS,...) Tecnologías XML y servicios Web orientadas a la integración de aplicaciones. Middleware orientado a mensajes (MM), JMS, MQ's, etc. Entornos de desarrollo de integración de aplicaciones basados en tecnologías J2EE (sobre servidores de aplicaciones o stand-alone) Registros de Servicios UDDl. Servidores de aplicaciones: Java (racle Weblogic Server, Tomcat, etc.)

19 INSPECCI~N GENERAL CIS RDBMS: racle 6 PRESENTACIÓN DE LA FERTA 6.1 CNDICINES GENERALES La información contenida en la oferta técnica deberá demostrar, de forma clara e inequívoca, la capacidad del contratista de asumir el diseño y desarrollo del módulo propuesto, de modo que la solución cumpla los requisitos expuestos en el presente Pliego de Prescripciones Técnicas. La citada oferta seguirá el formato de este pliego con el fin de facilitar la evaluación de la misma y se hará referencia a todas y cada una de las especificaciones generales y particulares expuestas, no existiendo ningún límite en la longitud de la exposición de la oferta, aunque deberá ser lo más exacta y concisa posible evitando toda información no relevante. La propiedad intelectual del módulo objeto del PPT así como toda la documentación técnica generada corresponderá en exclusiva al Ministerio de Defensa. 6.2 CNTENID La oferta técnica deberá recoger, junto a la documentación exigida en el Pliego de Cláusulas Administrativas Particulares, la información necesaria relacionada con el contenido de este Pliego de Prescripciones Técnicas. Deberá facilitarse una copia de la oferta en soporte CD. El adjudicatario deberá hacer constar en la oferta cualquier necesidad, comentario, requisito, etc. que considere importante poner en conocimiento del Ministerio de Defensa. 6.3 CRITERIS DE VALRACIÓN A continuación se describen los criterios que servirán de base para la valoración de las ofertas: Valoración de la oferta técnica según la adecuación de su contenido a lo solicitado en este Pliego de Prescripciones Técnicas (sin perjuicio de las mejoras que puedan ofertarse). Adecuación de los perfiles del personal técnico ofertado para el diseño y desarrollo del módulo objeto del PPT. Se considera un mínimo de 2 ingenieros de desarrollo expertos en integración con experiencia y conocimientos en las herramientas citadas en el apartado "4.3 Plataforma SA" Valoración del esfuerzo en horaslhombre invertido para el desarrollo del módulo objeto del presente pliego.

20 Se valorará positivamente la inclusión en la oferta técnica de cualquier otra actividad o tarea, sin coste adicional al proyecto y no recogida expresamente en este documento, que el posible adjudicatario ofrezca como complemento a los requisitos de este pliego. En la oferta que presente deberá incluir este hecho, detallando las características de la ampliación y los beneficios buscados. Se valorará satisfactoriamente que el personal encargado del desarrollo del módulo tenga en vigor o en proceso de acreditación la Habilitación Personal de Seguridad tanto la del Ministerio de Defensa como la de la TAN. 7 PRESUPUEST MÁXIM El precio límite es de CIENT VEINTE MIL EURS ( ,00 e), IVA INCLUID, que se distribuirá en una Única anualidad del ejercicio 2.010, atendiendo al siguiente detalle: El Director Técnico del Expediente será el Teniente Coronel, perteneciente al Área de Arquitectura y Modelo de Datos D. Miguel Martín Marcos destinado en la Inspección General CIS, Calle Joaquín Costa, no 6, con no de teléfono , y no de fax Madrid, a 14 de julio de 2010 El Teniente Coronel, Director Técnico - Miguel Martín Marcos -