Contract

El objeto de esta contratación es la prestación de servicios de desarrollo, mantenimiento correctivo, soporte a las aplicaciones y control de calidad sobre algunos de los sistemas de información basados en tecnología Java del Consorci Administració Oberta de Catalunya.

1.2 Objetivos

Los objetivos del proyecto son diversos:

• Realización de tareas de desarrollo en tecnología Java de una serie de funcionalidades adicionales a los servicios existentes del Consorci AOC.

• Ofrecer apoyo técnico especializado en cuanto a la detección, diagnóstico y resolución de las incidencias técnicas derivadas del uso de los productos del Consorci AOC.

1.3 Descripción del servicio

Por la diferente naturaleza de los servicios a prestar, el pliego se estructurará en dos lotes diferenciados que pueden ser adjudicados a una misma empresa o bien a diferentes empresas:

• Lote 1: Desarrollo de servicios de administración electrónica e interoperabilidad.

• Lote 2: Desarrollo de servicios de firma electrónica.

1.4 Descripción del Lote 1: desarrollo de servicios de administración electrónica e interoperabilidad

Este lote del contrato consta de una serie de proyectos a desarrollar en paralelo sobre diferentes servicios del Consorci AOC, basados en tecnología Java y valorados globalmente en un total de 7.040 horas que habrá que realizar en su totalidad en el periodo de duración del contrato.

La empresa adjudicataria, en función de la duración del contrato, y del volumen de horas previsto para realizar los proyectos, deberá dimensionar adecuadamente el equipo de trabajo para dar respuesta a los requerimientos valorados, en tiempo y forma. Es decir, la disponibilidad de las horas ejecutadas puede, puntualmente, no ser proporcional a la duración del contrato, sino que deberá adaptarse a las necesidades y requerimientos del servicio, pudiendo fluctuar en función de la carga de las tareas encomendadas, habiendo meses en que se pueda requerir un mayor o menor dimensionamiento del equipo de trabajo.

Las tareas que se realizarán son las siguientes:

• Análisis, diseño, desarrollo, documentación y tests unitarios y de integración.

• Recoger, crear y gestionar la documentación asociada.

• Gestión y control del código fuente. Esta gestión se llevará a cabo con el repositorio de código fuente que dispone el Consorci AOC.

Los proyectos que se realizarán son los siguientes:

1.4.1 Evolutivos sobre la herramienta de firma centralizada

Mantenimiento de la herramienta de firma centralizada basada en Java WebStart y que adicionalmente dispone de una aplicación nativa que permite la ejecución de una herramienta de firma electrónica basada en certificados digitales de usuario final dentro de las aplicaciones que funcionan con un navegador web.

xxxxx://xxxxxxxx.xxx.xxx/xxxxxxxx/xxxx

1.4.2 Evolutivos sobre la aplicación VALId / idCAT Mòbil y desarrollo del nuevo VALId

La Generalitat de Catalunya en Acord de Govern encargó al Consorci AOC la creación de servicios alternativos al uso de los certificados electrónicos.

Para dar respuesta a este encargo, el Consorci AOC desarrolló en 2015 un servicio llamado IdCAT Mòbil y una herramienta que agrupa diferentes servicios de identificación llamada válido.

Tanto los servicios válidos como el idCAT Mòbil se encuentran ya operativos y dando servicio en entornos productivos, pero hay que realizar periódicamente una serie de mejoras enfocadas al rendimiento y la seguridad.

Concretamente hay que seguir con las tareas de mantenimiento del servicio actual, entre otros:

• Realizar evolutivos funcionales para incorporar nuevos mecanismos de identificación (por ejemplo, funcionalidades de personalización del mecanismo de autenticación Mobile Connect de GSMA, entre otros).

• Supervisión de la puesta en marcha del nuevo mecanismo Mobile ID basado en SMS prevista para Septiembre de 2019.

• Adicionalmente hay que realizar tareas de mantenimiento sobre el proceso de autoregistro online de los ciudadanos para el uso del idCAT Mòbil.

En paralelo a estos evolutivos, habrá que seguir trabajando en la evolución de la arquitectura del servicio válidos para que pueda ser desplegado en diferentes CPDs (Centros de Proceso de Datos) y así mejorar la disponibilidad y seguridad del servicio.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/xxxxx/

xxxxx://xxx.xxx.xxx/xxxxxxxxx-xxxx/xxxxxxxx-xxxxxxxxxxx-xxxxx/xxxxxxxx/xxxxxxxxxx/

1.4.3 Integraciones y adaptaciones varias de servicios de la AOC derivadas de requisitos de la Administración General del Estado

• Sistema de Interconexión de Registros con el Estado (SIR): La Administración General del Estado (AGE), con el objetivo de fomentar el concepto de Ventanilla Única, ha creado un sistema que permite el traslado de la documentación que un ciudadano presenta a una Administración Pública

hacia otra Administración Pública, de forma totalmente electrónica y con el correspondiente asiento de entrada.

El servicio está desarrollado, certificado por parte del equipo SIR del MINHAP y operativo a producción desde el 2017 aunque el 2018 este servicio se reimplementaba dentro de la nueva arquitectura EACAT (Liferay 6) y PCI (Weblogic 12). Actualmente esta nueva versión está pendiente de certificar por parte del MINHAP. Se prevé certificar esta nueva versión durante el primer semestre de 2019 de manera que durante la duración del contrato deberán realizarse tanto mantenimientos evolutivos como correctivos sobre esta nueva versión del servicio.

Alcance: EACAT, PCI.

xxxxx://xxxxxxxxxxxxxxxxxxxxxxxxx.xxx.xx/xxx/xxx

• Mantenimiento de los servicios de integración del CAOC con el Punto de Acceso General de Intercambio de Expedientes: realizar las integraciones que permitan incorporar nuevos organismos a este hub de carpetas ciudadanas.

Alcance: PCI.

xxxxx://xxxxxxxxxxxxxxxxxxxxxxxxx.xxx.xx/xxx/xxx

• Adaptación de los servicios de interoperabilidad del CAOC para contemplar los procedimientos administrativos registrados en el Sistema de Información Administrativa (SIA) del Estado. Se prevé que los servicios afectados sean los servicios proporcionados y consumidos por el MINHAP desde su Plataforma de Intermediación.

Alcance: PCI.

1.4.4 Evolutivos del servicio e-Valisa

Actualmente el Consorci AOC ofrece a los usuarios de la Generalitat de Catalunya un servicio de Valija Electrónica que permite ahorrar costes eliminando el gasto en mensajería que inherente al traslado de papel entre las diferentes dependencias de la Generalitat.

Para potenciar el servicio y dar respuesta a nuevos requerimientos planteados se prevé que durante la duración del contrato sea necesario realizar diferentes evolutivos.

Alcance: EACAT.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/x-xxxxxx/

1.4.5 Evolutivos del servicio de Còpia Autèntica

El servicio de Còpia Autèntica tiene como objetivo la generación de copias auténticas que tengan la misma validez y eficacia que los documentos originales, convirtiendo los documentos en papel en documentos electrónicos y que los documentos electrónicos sean también válidos en papel.

Así, se dispone de una aplicación web de generación de copias auténticas que se ha adoptado como solución corporativa y transversal por los diferentes servicios de administración electrónica que ofrece el Consorci AOC. Como tal, se invocada desde las diferentes aplicaciones del Consorci AOC (ERES, e-NOTUM, EACAT, entre otros).

Asimismo, permite dar cumplimiento a los requisitos de la ley 39/2015 y, en concreto, en el artículo 27 que regula la validez y eficacia de las copias realizadas por las administraciones públicas. También tiene en cuenta las especificaciones técnicas que se establecen en la NTI de digitalización de documentos y la NTI de procedimiento de copiado auténtico y conversión de documentos entre documentos electrónicos.

Para potenciar el servicio y dar respuesta a nuevos requerimientos planteados se prevé que durante la duración del contrato sea necesario seguir realizando diferentes evolutivos sobre la herramienta.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/xxxxx/

1.4.6 Evolutivos de otros servicios de la AOC

Algunos de los servicios sobre los que se prevé que habrá que realizar tareas de mantenimiento son los siguientes:

• Via Oberta: bajo la denominación Via Oberta, el Consorci AOC engloba los servicios que ha desarrollado para facilitar la transmisión telemática de datos y documentos electrónicos procedentes de las administraciones y, en general de las instituciones públicas y entidades, posibilitando la sustitución de la aportación de certificados y otros documentos en soporte papel, en los procedimientos administrativos por parte de los interesados.

Periódicamente, hay que ir incorporando al catálogo de consultas disponibles nuevos servicios de interoperabilidad a medida que los diferentes emisores de datos los publican (principalmente organismos de la Administración General del Estado, Departamentos de la Generalidad de Cataluña y Colegios Profesionales).

Asimismo, dentro de los proyectos Vía Abierta, se contempla el mantenimiento correctivo de los webservices conectores xxx Xxxxxx Municipal de Habitantes de los Ayuntamientos que han puesto en línea su padrón (xxxx://xxxxxxxxxxxx.xxx-x.xxx/xxx/xxx_xxx_xxxxx_xx_xxxxx.xxx).

Alcance: PCI, EACAT.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/xxx-xxxxxx/

xxxxx://xxx.xxx.xxx/xxxxxxxxx-xxxx/xxxxx-x-xxxxxxxxx-xxxxxxxxxxx/xxxxxxxx/xxxxxxxxx/

Asimismo, está previsto re-implementar el servicio de Via Oberta DCOC (Documentación de Colegios Oficiales de Cataluña) durante la duración del contrato. Desarrollado originalmente en 2006, actualmente está obsoleto tanto funcional como tecnológicamente y habrá migrar a la arquitectura PCI.

xxxxx://xxx.xxx.xxx/xx-xxxxxxx/xxxxxxx/0000/00/XX-XXXX.xxx

• e-NOTUM / e-NOTUM Lite: servicio que permite realizar notificaciones de actos administrativos (resoluciones, decretos, notificaciones para contratación, notificaciones de sanciones de tráfico, convocatorias de órganos colegiados, etc.) y comunicaciones por medios electrónicos, con todas las garantías jurídicas que establece la normativa vigente.

Con el fin de seguir potenciando el servicio incorporando nuevas funcionalidades y dar respuesta a los requerimientos de disponibilidad que se requieren en un servicio de estas características se prevé que durante la duración del contrato sea necesario seguir realizando diferentes evolutivos sobre la herramienta.

Alcance: PCI, EACAT, frontal ciudadano.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/x-xxxxx/

• e-XXXXXX: servicio del Consorci AOC que permite la publicación y la gestión de edictos electrónicos online. Es una herramienta de publicación certificada con automatismos asociados a la gestión de la publicación de los edictos (control de periodos de exposición, generación de diligencias, etc.). El e-XXXXXX permite gestionar las evidencias electrónicas del proceso de publicación para garantizar los tiempos de exposición y la integridad de la información. No sólo es una herramienta de envío y recepción electrónica de edictos internos, también permite gestionar de externos, provenientes de otras administraciones a través de EACAT. El e-XXXXXX integra en la sede electrónica de las entidades en modalidad marca blanca.

Alcance: PCI, EACAT, frontal ciudadano.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/x-xxxxxx/

• Registro Unificado / MUX: el servicio de Registro Unificado (MUX) permite la integración de los servicios del Consorci AOC con el registro general de entradas y salidas propio del organismo. Con esta integración, las anotaciones de asientos de entrada o salida que generan los servicios AOC se realizan directamente en el registro general del organismo, en lugar de realizarse en el registro electrónico auxiliar de EACAT como se había hecho hasta ahora.

Desarrollado originalmente en 2006, este 2019 se ha iniciado la migración del MUX a la nueva arquitectura PCI. Así, se prevé que esté terminado a lo largo del segundo semestre de 2019 para,

a continuación, proceder a la adaptación de los diferentes servicios de la AOC para que hagan uso del nuevo MUX.

Alcance: PCI, EACAT.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/xxxxxxxx-xxxxxxxx-xxx/

1.4.7 Evolutivos del backoffice del servicio E-TRAM 2.0

E-TRAM es el módulo de gestión municipal de solicitudes y trámites por Internet del Consorci AOC. Actualmente se está trabajando en una versión 2.0 que está prevista que esté terminada este 2019.

Aunque el grueso del proyecto E-TRAM 2.0 queda fuera del alcance de este contrato, el backoffice de la nueva versión de E-TRAM se apoya sobre la PCI. Así, se prevé que durante la duración del contrato, haya que realizar algún tipo de mantenimiento evolutivo y correctivo sobre estos servicios de backoffice derivados de la puesta en marcha del servicio.

Alcance: PCI.

xxxxx://xxx.xxx.xxx/xxxxxxx-xxx/x-xxxx/

1.4.8 Implementar mejoras en la arquitectura de los Servicios de la AOC

En paralelo a las tareas del día a día de las aplicaciones, actualmente se está llevando a cabo una serie de mejoras en la arquitectura de base de los servicios.

Así, se prevé que durante la duración del contrato, haya que llevar a cabo algunas de estas iniciativas, entre las que se contempla:

• Implementar un nuevo IDP (Identity Provider) por los servicios de la AOC orientados al trabajador público. El nuevo IDP se basará en el estándar OAuth2 (similar al empleado en el servicio válidos) y habrá que adaptar las aplicaciones que se apoyan en el IDP actual (principalmente el portal y aplicaciones EACAT) para que hagan uso de la nueva versión.

• Solución de storage centralizado: se prevé adoptar una solución de storage en la nube para dar cobertura a los requerimientos de espacio y de acceso de los documentos y archivos generados por los servicios de la AOC. Así, habrá que adaptar todos los servicios de la AOC para que se apoyen en la nueva arquitectura de repositorio (a priori, todos los servicios recogidos en este pliego).

1.4.9 Perfil profesional del equipo de trabajo

El licitador deberá incluir en su oferta un equipo de trabajo con dominio xxx xxxxxxx, hablado y escrito, compuesto por unos perfiles y dedicación que se señala.

Los miembros del equipo que se ofrezcan a tiempo completo lo harán en exclusividad para este servicio.

Experiencia profesional

• Perfil de Analista-Programador con experiencia en proyectos de desarrollo e implantación de aplicaciones JEE e integración de servicios.

• Experiencia en las tecnologías indicadas en el anexo PCI 3.0 - Arquitectura PCI (resumen) de este Pliego de Prescripciones Técnicas (Weblogic 12c, Tomcat 7 o superior y programación JEE, webservices, base de datos Oracle 12) y conocimientos en herramientas para la gestión y construcción de proyectos (GIT para el control de versiones, Xxxxxx, Xxxxxxx).

• Conocimiento de metodologías ágiles para la planificación, desarrollo y mantenimiento de sistemas de información.

Funciones

• Desarrollo tanto en el lado cliente (EACAT, frontales del ciudadano) como el servidor (servicios de backoffice, módulos comunes y componentes de interoperabilidad).

• Realizar y ejecutar los planes de pruebas.

• Adicionalmente uno de los perfiles deberá actuar de interlocutor entre el equipo de trabajo y los responsables técnicos de cada servicio dentro del alcance de este pliego. Asimismo, deberá dirigir, coordinar, supervisar y representar al equipo técnico de trabajo y velar por el nivel de calidad de los trabajos.

1.5 Descripción del Lote 2: desarrollo de servicios de firma electrónica

Este lote del contrato consta de una serie de proyectos relacionados con firma electrónica basados en tecnología Java EE. Están valorados globalmente en un total de 3.520 horas, que habrá que realizar en su totalidad en el periodo de duración del contrato.

Las tareas que se realizarán son de mantenimiento evolutivo y correctivo de los productos:

• Análisis, diseño, desarrollo, documentación y test unitario y de integración.

• Recoger, crear y gestionar la documentación asociada.

• Gestión y control del código fuente. Esta gestión se llevará a cabo con el sistema centralizado de código fuente que dispone el Consorcio AOC.

Los proyectos sobre los que se realizarán los desarrollos son los siguientes:

1.5.1 Evolutivos de los servicios Validador y Sello de Tiempo (PSIS)

Con el producto PSIS el Consorcio AOC ofrece los servicios del Validador y del Sello de Tiempo:

• El Validador permite realizar la validación de certificados digitales y la validación y completado de firmas electrónicas con todas las garantías, tanto jurídicas como técnicas, que establece la normativa vigente. La mensajería de PSIS sigue las especificaciones DSS (Digital

Signature Services) de OASIS (Organization for the Advancement of Structured Information Standards).

• El servicio del Sello de Tiempo ofrece una marca de tiempo fiable y segura. PSIS es la TSA (Time Stamping Authority) del Consorcio AOC. Permite tanto la creación como la validación de sellos de tiempo, tanto en formato CMS (estándar RFC3161) como XMLTimeStampToken (sello de tiempo en formato XML según el protocolo DSS de OASIS).

PSIS es un servicio transversal al resto de servicios del Consorcio AOC y en general de las AAPP catalanas. Tiene por tanto un consumo muy elevado, con casi 120 millones de operaciones anuales. Es indispensable garantizar el mejor rendimiento posible para continuar ofreciendo un SLA por encima del 99%.

Evolutivos

Con el fin de dotar de nuevas funcionalidades y de más robustez a PSIS, es necesario implementar los siguientes evolutivos:

1. Implementación de los nuevos estándares de firma electrónica del reglamento europeo eIDAS (electronic IDentification, Authentication and trust Services):

a. XAdES (XML Advanced Electronic Signatures) Baseline Profile

ETSI EN 319 132 XML Advanced Electronic Signatures (XAdES)

• Part 1: Building blocks and XAdES baseline signatures

• Part 2: Extended XAdES signatures

b. CAdES (CMS Advanced Electronic Signature) Baseline Profile

ETSI EN 319 122 CMS Advanced Electronic Signatures (CAdES)

• Part 1: Building blocks and CAdES baseline signatures

• Part 2: Extended CAdES signatures

c. PAdES (PDF Advanced Electronic Signature) Baseline Profile

ETSI EN 319 142 PDF Advanced Electronic Signature Profiles (PAdES)

• Part 1: Building blocks and PAdES baseline signatures

• Part 2: Additional PAdES signatures profiles

2. Extender la validación mediante TSL (Trust Service List) a los certificados españoles.

3. Integración de PSIS con una autoridad de sellado de tiempo reconocida. Está previsto sustituir la TSA de PSIS por una TSA cualificada, es decir, que cumpla con los requerimientos del reglamento eIDAS. Será necesario integrar PSIS con la TSA cualificada para llevar a cabo las funciones de completado de firmas.

4. Cambiar el modelo actual de configuración y redistribuirla entre la base de datos (modelo actual) y los recursos propios del war. Modificar la consola de configuración para poder cargar autoridades de certificación, certificados de firma, y políticas de firma, en caliente, es decir, sin necesidad de detener el servicio.

5. Desarrollar un sistema de sincronización entre las bases de datos de los entornos primario y secundario.

6. Poner en marcha el guardado de evidencias de forma asíncrona en base de datos no relacional.

Además de las actividades descritas, el equipo deberá también responder a actividades en los ámbitos siguientes:

• Mantenimiento correctivo.

• Cambios de configuración de la aplicación.

• Soporte avanzado.

Mantenimiento correctivo

Incluye cualquier corrección o modificación de código necesaria para solucionar una incidencia o problema reportados por el Consorcio AOC. La incidencia podrá ser detectada por el propio Consorcio AOC, o por clientes del servicio, pero será únicamente reportada al requirente por el Consorcio AOC, que hará un primer análisis de la misma.

Se incluyen tanto incidencias a nivel funcional, como de rendimiento.

Gestión del cambio de configuración

El servicio de gestión de cambio de configuraciones consiste en realizar todas aquellas tareas necesarias para que la aplicación PSIS incorpore los cambios de configuración solicitados por el Consorcio AOC. Los tipos de cambios de configuraciones pueden ser diversos, pero al menos, el servicio deberá cubrir las siguientes solicitudes:

• Carga de nuevas entidades de certificación (CA s).

• Carga / Renovación de certificados de entidades de respuesta OCSP.

• Carga de nuevos perfiles de certificados (que habrán sido emitidos por alguna entidad de certificación cargada en PSIS).

• Cambios en el parseig los perfiles de certificados para obtener los diferentes atributos de los certificados en función de su perfil (política de certificado).

• Carga de políticas de firma.

• Configuración para cargar nuevas claves dentro de la aplicación PSIS para poder firmar de manera centralizada (funcionalidad ASC).

• Configuración de permisos de autorizaciones de uso de una clave (privada) cargada a PSIS por parte de otra clave (pública).

• Configuraciones y parametrizaciones menores de cualquiera de los módulos de la aplicación PSIS.

Una solicitud consistirá, básicamente, en lo siguiente: El Consorcio AOC notificará al adjudicatario el cambio de configuración que desea que se realice. Dará todos los detalles necesarios para cursar la solicitud, así como los recursos e información necesarios para determinar la validez del cambio una vez aplicado el adjudicatario procederá a hacer lo necesario para que la aplicación PSIS incorpore los cambios de configuraciones solicitados por el Consorcio AOC.

Soporte avanzado

El servicio de soporte avanzado consiste en realizar todas aquellas tareas necesarias para dar respuesta a todas aquellas consultas que plantee el Consorcio AOC en relación a la aplicación PSIS.

Los tipos de consultas pueden ser varias, pero como mínimo, el servicio deberá cubrir las siguientes:

• Consultas relacionadas con cualquier funcionalidad de la aplicación.

• Consultas relacionadas con el diseño de cualquier de los módulos de la aplicación: pe. como está diseñado el mecanismo de actualización de las listas de revocación (CRL)?

• Consultas relacionadas con cómo se utiliza de cualquiera de las funcionalidades de la aplicación. pe. ¿cómo se debe construir una petición desde un cliente para validar una firma avanzada XAdES enveloped?, ¿cómo se construye una petición para pedir a la aplicación un sello de tiempo CMS?

• Consultas relacionadas con respuestas que el Consorcio AOC considere inesperadas de la aplicación ante ciertas peticiones realizadas desde cliente.

• Consultas relacionadas con los mensajes de error obtenidos de la aplicación.

• Consultas relacionadas con la configuración vigente de la aplicación. pe. ¿qué perfiles de certificados están cargados?, ¿en qué campo de la respuesta de la aplicación está el campo CIF de un certificado personal de firma?

• Consultas relacionadas con los estándares y normativas en los que se basa la aplicación.

1.5.2 Evolutivos del servicio PSA

PSA es un software que da solución a cualquier aplicación para la realización de firmas electrónicas. Esta solución se ofrece mediante servicios web.

PSA ofrece también las funcionalidades necesarias para firma en cliente. A tal efecto, PSA dispone de la integración con el firmante (versión APSA-Light), que permite el cifrado de los datos en el cliente, de modo que el usuario puede firmar localmente en posesión de su clave privada. El resto de funcionalidades relacionadas con la generación de la firma quedan delegadas a PSA, la que el cliente consume como servicio web.

El software ofrece también herramientas y mecanismos para que cualquier aplicación pueda realizar

firmas desatendidas en uso de certificados cargados al propio PSA, y firmas múltiples. Las firmas se generan con apoyo de políticas de firma conforme a estándares.

PSA también permite realizar operaciones de cifrado y descifrado de documentos.

Evolutivos

Será necesario desarrollar los siguientes evolutivos en PSA:

1. Para adaptar el servicio a los nuevos certificados SHA-2, hay que continuar con la implementación del algoritmo de firma SHA2withRSA.

2. Habrá que integrar la web de administración de PSA con el Signador del Consorcio AOC. Actualmente la web de administración utiliza todavía tecnología applet java con la APSA-Light (applet java que permite seleccionar el certificado con el que se quiere firmar, así como cifrar posteriormente los datos a firmar). Muchos navegadores han desactivado la tecnología applet java, haciendo que no se puedan ejecutar estas aplicaciones. El Consorcio AOC ha desarrollado una herramienta alternativa, denominada firmante (basada en Java WebStart y adicionalmente con una aplicación nativa), que permite que las mismas funcionalidades que ofrece la APSA-Light ejecuten en una aplicación que funcione en un navegador web.

Además de las actividades descritas anteriormente, el equipo deberá también ofrecer soporte avanzado ante dudas planteadas por el Consorcio AOC, así como ante incidencias en el servicio

Mantenimiento correctivo

Se incluyen tanto incidencias a nivel funcional, como de rendimiento.

Soporte avanzado

El servicio de soporte avanzado consiste en realizar todas aquellas tareas necesarias para dar respuesta a todas aquellas consultas que plantee el Consorcio AOC en relación a la aplicación PSA.

Los tipos de consultas pueden ser varias, pero como mínimo, el servicio deberá cubrir las siguientes:

• Consultas relacionadas con cualquier funcionalidad de la aplicación.

• Consultas relacionadas con el diseño de cualquier de los módulos de la aplicación: pe. ¿cómo está diseñado el mecanismo de autorización de firma?, ¿cómo está implementado el repositorio de documentos?

• Consultas relacionadas con cómo se utiliza de cualquiera de las funcionalidades de la aplicación. pe. ¿cómo se debe construir una petición desde un cliente para utilizar una política de firma concreta? ¿cómo se construye una petición para pedir la respuesta de validación de la firma en la misma petición de creación de firma?

• Consultas relacionadas con respuestas que el Consorcio AOC considere inesperadas de la aplicación ante ciertas peticiones realizadas desde cliente.

• Consultas relacionadas con los mensajes de error obtenidos de la aplicación.

• Consultas relacionadas con los estándares y normativas en las que se basa la aplicación.

1.5.3 Evolutivos del servicio iArxiu

El iArxiu es un servicio de preservación y archivo electrónico que garantiza que los expedientes / documentos que genera o recibe una organización en el ejercicio de sus funciones se mantengan íntegros, fiables, auténticos y accesibles a lo largo de su ciclo de vida. Alcance: tecnología JEE.

Evolutivos

Será necesario desarrollar los siguientes evolutivos:

1. Integración con servicio COPIA del AOC. Llamadas REST y callbacks por parte del servicio para recibir las copias PDF firmadas que se hayan enviado previamente.

2. Modificaciones a XSD de varios WSDL de iArxiu. Estas modificaciones tienen impacto en el código base de iArxiu, los clientes generados por distribuir los integradores, las

herramientas de generación de los ficheros METS (Metadata Encoding and Transmission Standard), etc.

3. Cambiar el funcionamiento de las políticas de disposición para mejorar la gestión. Crear un nuevo apartado a nivel de administración de la plataforma que permita gestionar (dar de alta, modificar, dar de baja e importar desde un archivo CSV) las tablas de evaluación y acceso documental (TAAD). Ampliar los criterios para definir las acciones de disposición utilizando consultas cruzadas por cualquier metadato.

4. Ampliar los elementos de metadatos en los vocabularios estándar de la plataforma.

5. Exportar los PIA (Paquete de Información de Archivo) al formato de intercambio establecido en el ENI (Esquema Nacional de Interoperabilidad).

6. Permitir transferencias de PIT (Paquete de Información de Transferencia) sin contenido

que "simulen" expedientes en papel.

7. Implementar en la web de referencia el preingreso individual a nivel de PIT o permitir carga masiva a partir de un archivo de intercambio (CSV, Excel, XML ...)

Además de las actividades descritas anteriormente, el equipo deberá también ofrecer soporte avanzado ante dudas planteadas por el Consorcio AOC, así como ante incidencias en el servicio.

Mantenimiento correctivo

Se incluyen tanto incidencias a nivel funcional, como de rendimiento.

Soporte avanzado

El servicio de soporte avanzado consiste en realizar todas aquellas tareas necesarias para dar respuesta a todas aquellas consultas que plantee el Consorcio AOC en relación al producto iArxiu.

Los tipos de consultas pueden ser varias, pero como mínimo, el servicio deberá cubrir las siguientes consultas:

• Consultas relacionadas con cualquier funcionalidad de la aplicación.

• Consultas relacionadas con el diseño de cualquier de los módulos de la aplicación: pe. como se lleva a cabo la autenticación en la web de referencia.

• Consultas relacionadas con cómo se utiliza de cualquiera de las funcionalidades de la aplicación. pe. cómo se debe construir una petición desde un cliente para ingresar un archivo con o sin preservación?

• Consultas relacionadas con respuestas que el Consorcio AOC considere inesperadas de la aplicación ante ciertas peticiones realizadas desde cliente.

• Consultas relacionadas con los mensajes de error obtenidos de la aplicación.

• Consultas relacionadas con los estándares y normativas en las que se basa la aplicación.

1.5.4 Perfil profesional del equipo de trabajo

El licitador deberá incluir en su oferta un equipo de trabajo compuesto como mínimo por los perfiles que se señalan a continuación.

Experiencia profesional

• Perfil de Analista-Programador senior con experiencia en proyectos de desarrollo e implantación de aplicaciones J2EE.

• Experiencia en las tecnologías indicadas en los anexos PSIS, PSA, y iArxiu de este Pliego de Prescripciones Técnicas (tecnologías J2EE y webservices).

• Conocimiento y / o experiencia en el ámbito de la firma electrónica, así como en los estándares de firma electrónica y de las librerías java que los implementan.

Estándares de firma electrónica:

• Protocolo DSS d’OASIS

• Estándares de signatura XAdES, CAdES, i PAdES

• Estándares eIDAS de signatura

• Protocolo RFC3161

• Electronic Signature Policies

• Public Key Infrastructure

• Etc. Librerías java:

• BouncyCastle

• Apache XML Security

• Conocimiento de metodologías ágiles para la planificación, desarrollo y mantenimiento de sistemas de información.

Funciones

• Desarrollos tanto en el lado de servidor (PSIS, PSA, y iArxiu) como de cliente (caso de las webs de administración de PSA y iArxiu).

• Realizar y ejecutar los planes de pruebas.

1.6 Metodología

Las tareas a realizar contempladas en el presente pliego se engloban dentro del desarrollo de nuevos servicios así como del mantenimiento evolutivo y correctivo de gran parte de las aplicaciones que

forman parte del catálogo de servicios del Consorci AOC durante la fase continua de su ciclo de vida. Así pues, los servicios existentes objeto de este contrato tienen un alto grado de madurez y se introducen dentro del conjunto de servicios que el Consorci AOC ofrece.

Asimismo, hay que tener en cuenta que los servicios de los que son objeto este contrato presentan una cierta complejidad en su gestión por los siguientes motivos:

• La dirección estratégica de cada uno de los servicios está liderada por un Jefe de Servicio -que el rol de promotor- con unos objetivos y unos plazos, pero ocasionalmente puede presentar una interdependencia con otros servicios.

• Alta dependencia con terceros (p.e. organismos externos a la AOC que pueden impactar tanto en el alcance funcional como con los plazos de ejecución previstos inicialmente).

• Alto solapamiento y concurrencia de tareas de diferentes servicios.

Aunque gran parte de los servicios están a producción desde hace años, podemos considerar cada una de las versiones a desarrollar como un proyecto propio que deberá desarrollar siguiendo el cumplimiento de esta guía metodológica.

A continuación se detallan las fases por las que debe pasar cada una de estas versiones de un determinado servicio desde su definición hasta su puesta en marcha.

Introducción de las tareas en JIRA

El Jefe de Servicio traduce los objetivos estratégicos que marca el comité estratégico en las peticiones de mejora y evolutivos que deben permitir alcanzar estos objetivos. A continuación, introduce como tarea de Servicios a la herramienta JIRA. En el momento de entrar cada tarea (en forma de ticket) indica su prioridad.

Fase de definición

La fase de definición de la versión consiste en seleccionar cuáles son los requerimientos funcionales que deben entrar a formar parte de la próxima versión a desarrollar.

El Jefe de Proyecto (Área de Tecnología) estudia todos aquellos requerimientos que se pueden incluir en una ventana tipo que el Consorci aplica a sus servicios (por servicios grandes, versiones cada 3 meses aproximadamente entre la puesta en marcha de cada versión, aunque en servicios más pequeños esta ventana se reduce).

El Jefe de Proyecto consensua con el Jefe de Servicio al alcance de la versión y se confecciona la lista definitiva de tareas trasladando esta lista de peticiones en tareas de Proyectos JIRA que representa la versión a desarrollar.

En caso de que sea necesario, es el Jefe de Servicio que define el plan de comunicación que deberá llevarse a cabo antes de que la versión llegue a los usuarios finales y dentro de este plan seleccionará los usuarios y organismos que deberán participar en la prueba piloto, si se estima oportuno.

El Jefe de Proyecto introduce toda esta información en los tickets JIRA que conforman la versión. Una vez cerrada el alcance de la versión, no se aceptará ninguna modificación en la lista de funcionalidades a desarrollar hasta la próxima fase de definición de la nueva versión.

Análisis

El adjudicatario partirá de la recopilación de funcionalidades a satisfacer que se han seleccionado en JIRA para la nueva versión y deberá realizar las reuniones de toma de requerimientos para poder hacer la recaudación detallada de todos los requisitos tanto funcionales como tecnológicos solicitados. Será responsabilidad del adjudicatario velar y preocuparse de recaudar todos y cada uno de los requerimientos que afecten al alcance de una determinada versión.

El adjudicatario elaborará un análisis previo de la solución que propone incluyendo una estimación del impacto que supone el evolutivo. En caso de que haya diferentes alternativas, el adjudicatario deberá explicarlas indicando las ventajas e inconvenientes de cada una.

Planificación

El Jefe de Proyecto añadirá al JIRA las tareas técnicas que considera necesarias para poder desarrollar la versión (documentación técnica, plan de pruebas, etc.) y prepara conjuntamente con el adjudicatario la planificación detallada de la versión asignando las tareas entre los diferentes técnicos de desarrollo.

Desarrollo de tareas planificadas

Las tareas que conllevará esta fase son:

• Generación del código.

• Ejecución de pruebas unitarias.

• Ejecución de pruebas de integración.

• Ejecución de pruebas de rendimiento, en su caso.

• Elaboración de la documentación funcional y técnica.

El adjudicatario deberá hacer un uso frecuente de la herramienta de control de versiones de código (GIT y VSSAFE en proyectos más antiguos) del servicio para sincronizar los diferentes desarrollos. La frecuencia ideal de sincronización (tanto para subir al repositorio los cambios realizados como para descargar todos los cambios que han introducido el resto de desarrolladores) sería hacerlo una vez al día (p.e. a primera hora de la mañana) de forma que se detecte cuanto antes los conflictos entre los diferentes desarrollos.

Antes de subir nada al repositorio cada desarrollador deberá garantizar en la medida de lo posible que el código subido es íntegro. Si no es posible subir los cambios de forma diaria, sí que se debe garantizar que cada equipo de desarrollo subirá los cambios al menos con una frecuencia semanal.

Los diferentes técnicos tienen un control total sobre el entorno de desarrollo y pueden desplegar tantas veces como lo necesiten.

Implantación y aceptación

En base a las entregas de la fase anterior se procederá a realizar la implantación del evolutivo sobre los diferentes entornos. En primer término, en el entorno de desarrollo. El adjudicatario procederá a realizar la ejecución del plan de pruebas. En caso de que se supere satisfactoriamente procederá a promocionar el cambio en el entorno de pre-producción y posteriormente al de producción.

En caso de que en este proceso los resultados obtenidos no sean los esperados (es decir, los que se obtuvieron en el entorno de desarrollo) el adjudicatario deberá dar el apoyo necesario, si es necesario presencial, para solucionarlo.

Una vez se haya realizado la ejecución del plan de pruebas con el 100% de las pruebas funcionando en el entorno de pre-producción y producción se dará el proyecto por cerrado. A partir de este instante entrará en vigor el periodo de garantía del evolutivo.

A partir de este momento ya debe entrar en vigor la etapa de apoyo, es responsabilidad del adjudicatario realizar las tareas necesarias de traspaso, formación y documentación del proyecto, de operación, y procedimental para que los nuevos desarrollos ya puedan ser objeto del servicio de soporte 24x7.

Una vez terminada la etapa de codificación y superadas las pruebas de integración en el entorno de pre-producción, el equipo de desarrollo deberá preparar el plan de implantación con la colaboración del equipo de Apoyo de la AOC (también dependiente del Área de Tecnología). El plan de implantación incorpora todas las acciones dirigidas a que la versión llegue a los usuarios finales.

Hay que tener en cuenta que ninguno de los técnicos de desarrollo tiene -por defecto- acceso a los entornos de preproducción y producción.

Para llevar a cabo el plan de implantación cada equipo de desarrollo prepara el paquete de desarrollo y realiza una petición al proyecto Despliegues del JIRA. En la petición de despliegue se indicará la versión de JIRA a la que corresponde el desarrollo.

Los despliegues en el entorno de PRE se realizan los jueves por la tarde y la petición de despliegue debe haber llegado a más tardar el día de antes, para que se pueda preparar junto con el resto de despliegues de otros servicios del Consorci AOC.

Con el objetivo de agilizar y garantizado la corrección de los despliegues, se está implantando un sistema de integración continua y despliegue automático. Actualmente está en fase de pruebas, pero se prevé que éste ya esté completamente operativo en el momento de adjudicación de este contrato.

Una vez desplegado en pre-producción, es el adjudicatario quien deberá ejecutar el plan de pruebas para realizar la validación final. El jefe de proyecto del Consorci AOC decidirá si la versión supera satisfactoriamente el plan de pruebas. En caso afirmativo, el equipo de desarrollo preparará y solicitará a través del JIRA la petición de despliegue en producción (los despliegues en el entorno de producción se realizan los miércoles por la tarde). En caso contrario, el equipo de desarrollo realizará las correcciones necesarias dando todo el apoyo necesario para corregir las incidencias detectadas en la mayor brevedad posible.

Una vez la versión haya desplegado en producción entrará en vigor el periodo de garantía del evolutivo.

Evaluación

Una vez definidos los requerimientos que formarán parte de la versión, el Jefe de Proyecto define las métricas y los indicadores que permitirán evaluar el cumplimiento de los objetivos marcados para la versión.

Después de un cierto tiempo de la puesta en marcha de la versión, el Jefe de Servicio realizará el seguimiento de los indicadores a través de encuestas, auditorías y cualquier otra herramienta de gestión de la calidad que considere adecuada, estableciendo el salpicadero del servicio.

Este cuadro de mando se pondrá a disposición del comité estratégico con el objetivo de mantenerlo informado de la marcha del servicio.

Finalmente, el comité de seguimiento realizará una sesión de retrospectiva analizando conjuntamente qué cosas han ido bien durante la versión y qué cosas han ido mal (desde el punto de vista de todos los actores) para poder aprender y mejorar de cara a la nueva versión.

JIRA

La herramienta corporativa JIRA convierte en la piedra angular de la versión en tanto permite reflejar en detalle el estado actual de la versión, el grado de consecución de la misma, así como la evolución estratégica que seguirá el servicio en un futuro medio. Es por tanto una herramienta fundamental para mantener coordinados todos los actores.

La información del JIRA se hace visible a todos los actores que participan en el servicio, pero dado que cada uno de los actores priorizará un tipo de información diferente, se requiere de un esfuerzo por parte del Jefe de Servicio y del Jefe de Proyecto para reflejar en el JIRA los diferentes puntos de vista. Esta diferente visión se plasma en JIRA a partir de los siguientes proyectos:

• Servicio: evolución estratégica de un servicio a medio / largo plazo. En este proyecto del JIRA los requerimientos agrupan y se ordenan en ideas conceptuales cercanas a las líneas de actuación que marca el comité estratégico. Este proyecto permite obtener una idea global de lo que se pretende conseguir con el servicio a medio o largo plazo.

Para los requerimientos más prioritarios, que inicialmente son los candidatos a ser seleccionados para la próxima versión, el responsable del servicio realizará el análisis funcional detallado.

El Jefe de Servicio es el principal responsable del mantenimiento al JIRA de este proyecto y debe reflejar todos los cambios y documentos con la máxima periodicidad posible.

• Proyecto: vista detallada del futuro inmediato del servicio. En este proyecto del JIRA se descomponen las peticiones de evolutivos en los diferentes requerimientos funcionales y técnicos que debe cumplir la nueva versión. Los asuntos que componen este proyecto se encuentran bien definidos y detallados, disponen de una estimación de su coste, el/los recurso/s que está/n asignado/s, así como su grado de avance. Este proyecto permite obtener una idea detallada del estado actual del servicio y su objetivo es mantener informado con el mayor nivel de detalle posible los diferentes actores que participan en el desarrollo diario del servicio.

El Jefe de Proyecto es el principal responsable del mantenimiento al JIRA de este proyecto y debe reflejar todos los cambios con la máxima periodicidad posible. En este proyecto se incluirán todos los documentos técnicos (diseño técnico, documentos de integración, etc.)

Si procede, cualquiera de estos 2 proyectos principales se pueden complementar con otros proyectos que permitan agrupar líneas de actuación que se llevarán a cabo a largo plazo o bien que se llevarán a cabo en paralelo, pero en fechas diferentes. El objetivo de estos proyectos complementarios debe ser simplemente el de facilitar la lectura del estado presente y futuro del servicio a los diferentes actores.

1.7 Requerimientos técnicos y personales

El licitador deberá disponer en el momento de iniciar el contrato, de los recursos que se han indicado en la descripción del lote del contrato.

Se requiere que estas personas tengan un buen nivel de conocimiento de la lengua catalana, tanto hablada como escrita.

El proveedor debe garantizar que para la resolución de incidencias y para dar respuesta a las peticiones básicas de operación siempre habrá un mínimo de dos personas formadas en cada uno de los entornos y que, como mínimo, siempre hay una disponible.

En caso de baja (temporal de más 4 días de duración o definitiva) de cualquiera de los miembros del equipo, el adjudicatario deberá sustituirlo en menos de 5 días laborables de acuerdo con los responsables del Consorci AOC. Cualquier cambio en uno de los miembros del equipo a instancias del adjudicatario deberá ser validado por el Consorci AOC. Habrá que acordar el calendario de cambio con el Consorci AOC para minimizar el impacto en los desarrollos en curso. Quedan fuera de este compromisos los períodos de vacaciones y permisos de todos los miembros del equipo.

Cuando se cambie un miembro del equipo de trabajo a instancias del adjudicatario, se fijará un tiempo de 2 semanas de formación / adaptación del nuevo miembro que serán a cargo del adjudicatario.

El Consorci AOC se reserva el derecho a solicitar el cambio de cualquiera de los miembros del equipo sin necesidad de justificación con una antelación de 20 días naturales a la fecha de sustitución.

Además de los perfiles descritos para cada lote, se deberá aportar un gestor del servicio de alto nivel sin cargo y que se encargará de las siguientes tareas:

• Interlocución a alto nivel.

• Diseño y seguimiento del plan derivado del contrato.

• Velar para que cada fase del proyecto se realice de forma diligente y dentro de las fechas acordadas.

• Informar de las desviaciones de las fechas de finalización de cada fase en cuanto se detecten.

• Gestionar los recursos asignados, tanto materiales como personales.

1.8 Condiciones de ejecución

1.8.1 Obligaciones básicas

El adjudicatario deberá cumplir las siguientes obligaciones básicas:

• El adjudicatario deberá gestionar cualquier alteración del servicio en las condiciones expresadas en este documento.

• El adjudicatario deberá realizar reuniones periódicas con el Consorci AOC para exponer el cumplimiento del servicio y tratar los posibles problemas o mejoras del servicio.

• El adjudicatario deberá realizar la formación de los técnicos designados, en todos aquellos aspectos que el Consorci AOC crea oportunos y que sean de directa aplicación a los servicios requeridos.

• El adjudicatario deberá proponer la organización general del servicio.

• Toda la documentación generada por el equipo será en catalán y en el formato propuesto por el Consorci AOC.

1.8.2 Horario de servicio

Se deberá cubrir un horario de 40 horas semanales con el calendario laborable que aplique el Consorci AOC. Cualquier cambio o ajuste de este horario deberá pactar con el Consorci AOC.

1.8.3 Herramientas de gestión y control

El adjudicatario será responsable de:

• La ejecución formal de los procesos de gestión tanto para el desarrollo de evolutivos como del mantenimiento correctivo definidos y aprobados por el Consorci AOC.

• Proponer las herramientas adicionales a las herramientas corporativas del Consorci AOC que deben permitir el seguimiento y el control global del contrato.

• El Consorci AOC es reserva el derecho a validar, y en su caso definir, las herramientas que se vayan a utilizar para la gestión y control del servicio.

Asimismo, el adjudicatario elaborará mensualmente un informe en el que detallará, como mínimo, los siguientes datos:

• Informe resumen de las actuaciones ya resueltas (micro-proyectos o explotación) y horas realizadas.

• Informe de situación de las actuaciones en curso y horas realizadas.

• Informe resumen de las actuaciones pendientes y horas estimadas.

• Planificación de las actuaciones a realizar.

• Relación de horas total realizadas en el mes.

• Informe de finalización del contrato con el resumen de horas y tareas realizadas.

Se creará un comité de seguimiento del servicio que se reunirá con periodicidad mensual (como mínimo).

1.8.4 Infraestructura necesaria para llevar a cabo el proyecto

El adjudicatario aportará las infraestructuras informáticas, licencias de desarrollo y cualquier otro componente o medio técnico necesario para la realización de los trabajos.

Los puestos de trabajo estarán ubicados en las oficinas de la empresa adjudicataria. Los miembros del equipo deberán disponer obligatoriamente de ordenadores portátiles por si ocasionalmente, por motivos de formación, toma de requerimientos o reuniones de seguimiento se tuvieran que desplazarse a las oficinas del Consorci AOC.

1.8.5 Garantía

Las tareas objeto del contrato tendrán una garantía de 6 meses. Durante este periodo, el adjudicatario se compromete a resolver satisfactoriamente todas aquellas incidencias o defectos detectados en cualquiera de las actividades llevadas a cabo por sus equipos de trabajo que le sean imputables con él por acción u omisión.

1.8.6 Plan de transición y devolución del servicio

El adjudicatario deberá asumir el plan de transición para hacerse cargo del servicio. Al final del servicio el adjudicatario deberá planificar y ejecutar el plan de devolución del servicio en caso de cambio de proveedor.

El Consorci AOC proporcionará al adjudicatario todas las palabras de paso necesarias para la realización de las tareas. El adjudicatario no podrá modificar las palabras de paso sin el consentimiento explícito del Consorci AOC.

1.9 Acuerdos de Nivel de Servicio

En este apartado se describe el marco contextual de aplicación de los Acuerdos de Nivel de Servicio. Todos los Acuerdos de Nivel de Servicio que se aplicarán con carácter general sobre los servicios descritos en este pliego, con las excepciones y particularidades que se recogen en las descripciones específicas de los mismos.

Las posibles penalizaciones que se deriven del incumplimiento de los ANS, se aplicarán sobre descuento en la siguiente factura emitida después de la penalidad. La aplicación de penalidades será acumulativa.

Los Acuerdos de Nivel de Servicio se podrán revisar y modificar semestralmente siempre y cuando haya acuerdo mutuo entre el adjudicatario y el Consorci AOC.

Para el cálculo del nivel ofrecido por parte del adjudicatario se excluirán los incrementos de tiempo provocados por la actuación ineludible de una tercera parte (pe. Soporte de Oracle).

Requerimientos de nivel de servicio del desarrollo evolutivo

Los requerimientos mínimos de prestación del servicio deberán ser:

• La fecha de entrega planificada es de cumplimiento obligatorio una vez cerrada y acordada la orden de trabajo. Un mínimo del 95% de las peticiones acordadas con la dirección funcional del proyecto deberán ser entregadas y ser aceptadas por la dirección del proyecto en la fecha de entrega prevista.

• Porcentaje de evolutivos sin errores. Un mínimo del 95% de los evolutivos entregados dentro del plazo se entregarán sin errores.

• Plan de pruebas sin errores. Un mínimo del 98% de los evolutivos entregados deberán superar el plan de pruebas ejecutado por personal del Consorci AOC sin errores.

Excepcionalmente y previo aviso, se podrá requerir la ejecución de desarrollos evolutivos urgentes que no seguirán el procedimiento previo de valoración y que deberán comenzar en el mismo día o el día siguiente.

Requerimientos de nivel de servicio en el mantenimiento correctivo y resolución de incidencias

Resolución de incidencias sin errores:

• Porcentaje de la resolución de incidencias sin errores en el plazo.

o Cálculo: (A / B) * 100

A: Número total de incidencias resueltas sin error en el plazo B: Total de incidencias resueltas en el plazo

• Periodicidad: Mensual

• El porcentaje de incidencias sin error en el plazo establecido deberá ser como mínimo del 90%.

• El nivel ofrecido por quien resulte adjudicatario del servicio constituirá un Acuerdo de Nivel de Servicio (ANS), el cumplimiento se medirá durante toda la duración de la prestación del servicio.

ANS pera la gestión de las incidencias

Este ANS aplica a la totalidad del servicio contratado. Definiciones:

Nivel	Descripción
Bloqueante	Una incidencia se catalogará con criticidad bloqueando si impide la utilización total del servicio a todos los usuarios de este.
Alta	Una incidencia se catalogará con criticidad alta si impide la utilización de una parte concreta del servicio, a todos o algunos usuarios, y la afectación por el negocio es elevada.
Media	Una incidencia se catalogará con criticidad media si impide la utilización de una funcionalidad concreta de alguno de los servicios a todos o algunos usuarios externos a la plataforma y la afectación por el negocio es relativamente baja.
Baja	Una incidencia se catalogará con criticidad baja si no impide la utilización ni parcial ni total de alguno de los servicios a ninguno de los usuarios.

El tiempo de respuesta y de resolución se establece según el tipo de incidencia:

• Tiempo de respuesta: Se define como tiempo de respuesta el tiempo que transcurre desde que la incidencia es comunicada, y el usuario recibe el ticket de su incidencia. El tiempo de respuesta se cuenta sobre el horario de soporte de recepción de incidencias.

• Tiempo de resolución: se define el tiempo de resolución de una incidencia como el número de horas que transcurren desde que el usuario recibe el ticket de la incidencia hasta el momento en que la incidencia está solucionada. En el cálculo del tiempo de resolución de una incidencia no se tienen en cuenta los posibles incrementos de tiempo provocados por la intervención inevitable de terceros en el proceso de resolución (por ejemplo, soporte de Oracle, intervención de otros organismos, etc.).

El tiempo máximo permitido por la respuesta y resolución de una incidencia dependerá del nivel de criticidad de la incidencia. En la siguiente tabla se muestran los tiempos máximos permitidos por la resolución de una incidencia en función del nivel de criticidad:

Criticidad Incidencia

Tiempo de respuesta (horas)

Tiempo de resolución (horas)

Xxxxxxx

% de resolución dentro del tiempo comprometido

0 Bloqueante

0,5

24x7

95 %

1 Alta

horario supervisado

95 %

2 Media

horario supervisado

95 %

3 Baja

horario supervisado

95 %

Para el cálculo del tiempo de resolución de una incidencia excluirán los posibles incrementos de tiempo provocados por la intervención inevitable en el proceso de resolución por parte de terceros.

En caso de que el adjudicatario no cumpla el acuerdo de nivel de servicio definido anteriormente por al menos el 95% de las incidencias con criticidad 0 y 1 que hayan ocurrido en el mes se le aplicará las siguientes penalizaciones:

Porcentaje de incidencias con criticidad 0 i 1 al mes que cumplen el ANS	Penalización sobre la cuota mensual de la factura
Superior al 95%	0%
Entre 95% i 80%	5%
Entre 80% i 70%	10%
Inferior al 70%	15%

En caso de que el adjudicatario no cumpla el acuerdo de nivel de servicio definido anteriormente por al menos el 90% de las incidencias con criticidad 2 y 3 que hayan ocurrido en el mes se le aplicará las siguientes penalizaciones:

Porcentaje de incidencias con criticidad 2 i 3 al mes que cumplen el ANS	Penalización sobre la cuota mensual de la factura
Superior al 90%	0%
Entre 90% i 51%	5%
Inferior al 51%	10%

1.10 Propiedad intelectual de los trabajos

El adjudicatario acepta expresamente que la propiedad de todos los entregables, independientemente de su naturaleza y resultados de los trabajos realizados, y en particular los productos y servicios objetos del contrato, corresponden únicamente al Consorci AOC con exclusividad y con carácter general, sin que el adjudicatario pueda conservar, ni obtener copia de los mismos o facilitarlo a terceros.

La empresa adjudicataria no podrá hacer ningún uso o divulgación de los estudios y documentos utilizados o elaborados como resultado de la prestación del servicio objeto del contrato, bien sea en forma total o parcial, directa o extractada, original o reproducida, sin autorización expresa del Consorci AOC, que la daría, en su caso, previa petición formal del adjudicatario con expresión del fin.

Barcelona, 26 xx Xxxxx de 2019

Xxxxx Xxxxxxx Xxxxxxxxx

Jefa de Proyectos de la Unidad de Firma Electrónica del área de Tecnología del Consorci AOC

Xxxxx Xxxxxxx Xxxxx

Responsable de arquitectura del área de Tecnología del Consorci AOC

Anexo 1 - PCI 3.0 - Arquitectura PCI (resumen)

La Plataforma de Col·laboració Administrativa (en adelante PCI) del Consorci AOC es un conjunto de sistemas y componentes orientados a la total disponibilidad de los servicios ofrecidos por las diferentes administraciones con la garantía de la máxima seguridad en el servicio y el acceso a los datos.

Arquitectura lógica

Requeridors

Requeridors / Frontals ciutadà

SIRI / Mòdul de seguretat

Seguretat tècnica - capa d’autenticació

Seguretat lògica - capa d’autorització

Autorització

Consum

SIRI / Registre de serveis

Registre de serveis

MTI / Orquestració

Repositori autoritzacions

Consum

Altres sistemes

Serveis / Productes

E-XXXXXX Serveis de dades

MUX AEAT INEM

DCOC NOTARIS

E-NOTUM XXXXX DGT RELI REG COOP

C. DOMICILI TGSS TFN REME REG ENTIT

. . . DGP ATC RE PROP . . .

Consum

MSC – serveis comuns

MAP -PLATAFORMA DE IINTERMEDIIACIIÓN

PICA

Altres

XXXX

Emissors

. . .

OVER

Comunicació domicili

E-NOTUM

MUX

La arquitectura lógica de la PCI sigue un modelo conceptual orientado a servicios. Hay una separación clara entre requirentes, emisores de datos e intermediación de servicios.

	CSV
	Paraules pas un sol ús
	CATCert - PSIS TrustedX
	Signatura PDFs
	SMS
	Trameses EACAT
	Tiny URL / URL breu
	. . .

La arquitectura lógica de referencia comprende los siguientes componentes:

• SIRI (Sistema de Información de Recursos de Interoperabilidad): componente de seguridad encargado de autenticar y autorizar todos los accesos a PCI de manera centralizada y estandarizada.

Adicionalmente, el SIRI contiene el registro de servicios y productos de interoperabilidad ofrecidos por el Consorci AOC, y proporciona las herramientas para gestionar las autorizaciones de acceso a los servicios, así como para supervisar la actividad de la plataforma.

• MTI (Motor de Transacciones de Interoperabilidad): se encarga de la orquestación y trazabilidad de la ejecución de las peticiones (individuales vs lotes y síncronas vs asíncronas) de los diferentes servicios y controla la intermediación entre requirentes y los emisores finales de los datos de cada uno de los servicios de interoperabilidad y aplicaciones ofrecidos.

• Productos / servicios: cada uno de los servicios que ofrecen funcionalidades de transmisión telemática de datos y documentos electrónicos entre administraciones (Via Oberta) así como de otras aplicaciones ofrecidas por el Consorci AOC (e-NOTUM o e-XXXXXX entre otros).

• MSC (Módulo de Servicios Comunes): publica una serie de componentes y utilidades comunes disponibles para las diferentes plataformas del Consorci AOC (tanto PCI como EACAT o e- TRAM). Por ejemplo: envío de SMS, envío de transmisiones a EACAT, generador de contraseñas de un solo uso o funcionalidades de firma digital, entre otros.

Arquitectura de implementación

La arquitectura de implementación traduce los componentes lógicos de la PCI aplicaciones y productos.

Los productos sobre los que se apoya la PCI son los siguientes:

• Weblogic Application Server 12c, Oracle Service Bus (en adelante WL12).

La implementación de un servicio PCI se puede conseguir con cualquier tecnología, aunque conviene alinearla con el conjunto de tecnologías corporativas. Así, la mayoría de los componentes y servicios de negocio ofrecidos por la PCI han sido modelados como aplicaciones Java alineadas con arquitectura de referencia PCI 3.0 (JAX-WS, JAX-B, JPA y base de datos Oracle 12).

SIRI - IOP

SIRI - OSB

SIRI - APP

MTI

FTP + WEBADMIN

MTI

FTP + WEBADMIN

MTI

FTP + WEBADMIN

HAZELCAST

E-NOTUM LITE

VIA OBERTA (28)

MUX CDOMICILI

E-NOTUM

MOSSC

OVER (6) E-XXXXXX DOGC

SIR

BOE

MSC

CATCERT PAR. PAS

SMS

CATCERT

DESAL

OSB

MSC

IOP

CATCERT PAR. PAS

PSIS

TRUSTED-X

DESAL SMS

BDSEU DIR. CORP. LOGS CERT. REGISTRES

RDBMS

ADMIN

APP

MÒDUL TRAÇABILITAT

Las aplicaciones se distribuyen en tres clústeres con la misma arquitectura lógica según su tipología (servicios de interoperabilidad, servicios de tramitación y otras aplicaciones).

E-TRAM 2.0

CC. EXP. + E-NOTUM

EACAT (CONN.)

REPRESENTA

• Apache Tomcat 6 / 7 / 8: contenedor de aplicaciones web donde se despliegan los frontales de usuario de las aplicaciones que implican relación con el ciudadano (por ejemplo e-NOTUM o e- XXXXXX).

• Oracle 12 - 10 RAC: base de datos para almacenar tanto datos de negocio. Oracle 10 está en fase de extinción y la nueva arquitectura de referencia PCI 3.0 se apoya sobre Oracle 12.

• EACAT / Liferay 6: portal de gestión de contenidos y contenedor de aplicaciones web / portlets donde se despliegan los frontales de trabajador público.

• Apache Tomcat 8: contenedor de aplicaciones web donde se despliegan los frontales de trabajador público que no se desarrollan dentro de la plataforma EACAT (por ejemplo e-NOTUM, e-XXXXXX, BOE o Comunicación de domicilio entre otros). Estas aplicaciones, de reciente factura, se apoyan con las siguientes tecnologías: Frontend basado en Angular 6, librería Angular- material, TypeScript, XHTML + Material, CSS3 i Spring Framework 5 (Spring MVC, Spring Core, Spring Data JPA).

Anexo 2 - PSIS

Descripción funcional

Las principales funcionalidades de la aplicación PSIS son las siguientes:

1. Validación de certificados digitales: permite consultar el estado de un certificado. La aplicación responde si es válido o no es válido (por ejemplo, porque está revocado). En la misma respuesta también puede devolver información adicional, como por ejemplo, datos útiles del certificado digital (pe. nombre y apellidos, DNI, etc.) y el nivel de seguridad asociado al certificado digital (pe. nivel 3 en caso del certificado idCAT, nivel 4 en caso de un certificado de firma de trabajador público, etc.).

2. Validación y completado de firmas digitales: el servicio permite realizar la comprobación de la validez de una firma digital. El servicio inspecciona la firma y verifica por una parte que, matemáticamente, la firma esté bien formada. Por otro lado, comprueba el estado del certificado en el momento en que se ha producido la firma. En función de los resultados anteriores responde si la firma es válida o no es válida.

El servicio permite la validación de firmas digitales simples (CMS y el XMLDsig) y firmas avanzadas (CAdES y XAdES y PAdES). Estas últimas, además de permitir identificar al firmante y detectar cualquier cambio posterior de los datos firmados (al igual que las firmas simples), permiten que la firma digital sea perdurable en el tiempo más allá de la vida del propio certificado del firmante. Esto lo permite hacer la aplicación por medio del completado de la firma: añadiendo a la propia firma un sello de tiempo que permita ubicarla en el tiempo de manera fiable, e información sobre el estado de revocación del certificado del firmante y de la cadena de certificados.

3. Creación de firmas digitales: La aplicación permite generar firmas en uso de claves privadas cargadas previamente en PSIS mediante la consola de carga de claves y políticas de firma. Adicionalmente, la propia PSIS hace uso del módulo de creación de firmas cuando se solicita el retorno de la respuesta firmada.

4. Emisión de sellos de tiempo: La aplicación ofrece la posibilidad de imprimir un sello de tiempo a un documento, proporcionando de este modo evidencias (técnicas y jurídicas) de que el acto en cuestión se ha producido en un determinado momento del tiempo. El servicio dispone xx xxxxxxx de tiempo fiable para proveer la fecha y hora.

Descripción de la arquitectura

La aplicación PSIS está compuesta principalmente por dos módulos. A continuación se enumeran y más adelante se hace una explicación detallada:

• Autoridad de validación semántica (AVS)

• Autoridad de firma centralizada (ASC)

Estos módulos forman parte de un entorno de servicios web común que ofrece las funcionalidades recogidas en la fig. 1.

Este entorno de servicios web común está construido sobre una infraestructura de seguridad criptográfica (ISC) formada, entre otros, por los siguientes componentes (agrupaciones funcionales):

- Componente de autenticación de usuarios

- Componente de autorización de usuarios

- Componente de gestión de claves y certificados

- Componente de generación de firmas electrónicas

- Componente de verificación de firmas electrónicas

- Componente de auditoría, registro de operaciones (log) y registro de consumo

- Consola única de configuración de aplicaciones y componentes.

Autoridad de Validación Semántica

La autoridad de validación semántica (AVS) permite validar elementos de confianza, incluyendo firmas electrónicas en diversos formatos y certificados digitales X.509. Estos elementos de confianza son emitidos por diferentes proveedores de servicios de confianza que deben ser clasificados y gestionados en la plataforma de servicios de la autoridad de validación semántica.

Adicionalmente, la AVS ejecuta trabajos semánticos, localizando y extrayendo información contenida en los elementos de confianza que gestiona.

El módulo AVS registra los perfiles de elementos de confianza que emite cada proveedor de servicios de confianza.

La clasificación de cada perfil, además de asignarle un nivel de clasificación vinculado a la seguridad del certificado, permite establecer el método de validación preferido, de todos los controles establecidos por el proveedor al elemento de confianza, indicando el orden prioritario para ser validado (CRL, OCSP, métodos propietarios, @firma).

Autoridad de Firma Centralizada

La Autoridad de firma centralizada (ASC) permite la generación de firma electrónica asistida desde servidor. La interacción entre el usuario y el hardware de servicios criptográficos se hace a través de la aplicación de creación de firma, mediante un canal seguro, de acuerdo con las especificaciones técnicas CEN CWA 14169 y CEN CWA 141701.

Descripción tecnológica

A continuación se hace una descripción de las tecnologías y estándares más relevantes de los que hace uso la aplicación PSIS. El adjudicatario deberá detallar en su propuesta el conocimiento y experiencia que tiene de estas tecnologías en concreto, y otras similares si lo estima oportuno.

Lenguaje de programación

La aplicación PSIS está desarrollada, principalmente, en J2EE (Java 2 Platform Enterprise Edition), en una arquitectura distribuida en niveles y basada en componentes de software.

La aplicación está diseñada para operar en varias capas lógicas. Estas son:

• Capa web: Entorno con funciones de frontal web e interfaz de usuario.

• Capa de aplicación: Entorno con funciones de servidor de aplicaciones donde se ejecuta toda la lógica de negocio. Se hace uso del framework Spring.

• Capa base de datos: las propias bases de datos de la aplicación. El acceso a la base de datos desde la aplicación se hace por medio de Hibernate.

Estos diferentes entornos o niveles tienen la capacidad de poder estar ejecutándose en la misma máquina o en hardware diferente e incluso clusterizado. Este punto depende de la arquitectura que en cada momento pueda proveer el Área de Sistemas del Consorcio AOC.

Adicionalmente, se utilizan una serie de librerías de otros fabricantes. Las más relevantes son:

• Bouncy Castle

• Apache XML Security

• iText

• Rhino

Infraestructura de software

Este apartado describe el software de base sobre el que se ejecuta la aplicación, así como su configuración básica. Se hace una distinción entre el software que corresponde a cada uno de los entornos anteriores.

- Frontal web:

• Sistema operativo: Red Hat Linux Enterprise.

• Software de servidor web: Apache.

- Servidor de aplicaciones:

• Sistema operativo: Red Hat Linux Enterprise.

• Servidor de aplicaciones: WildFly.

- Servidor de bases de datos:

• Sistema operativo: Red Hat Linux Enterprise.

• Software gestor de base de datos: Oracle RAC.

Descripción de la mensajería: Digital Signature Services

En este apartado se hace una descripción de la mensajería que utiliza la aplicación PSIS para las comunicaciones entre servidor y cliente.

Nota: el contenido que se muestra a continuación es un extracto de la documentación (pública) que se facilita a los clientes del Consorcio AOC para hacer la integración con PSIS. El documento se llama "Guía de integradores de PSIS" y está disponible en la web del Consorcio AOC.

Para poder hacer uso de PSIS se requiere del desarrollo de unos clientes que construirán mensajes de petición y extraerán las respuestas de los mensajes provenientes del servidor abstrayendo el cliente del proceso de invocación remota que se lleva a cabo.

Uno de los protocolos con los que trabaja la plataforma es el DSS (Digital Signature Services), del consorcio de estandarización OASIS (Organization for the Advancement of Structured Information Standards) un protocolo para la prestación de servicios de firma digital abierto y extensible (mediante el uso de perfiles).

El protocolo DSS Core contiene una aproximación generalista a los problemas derivados de la provisión de servicios de firma electrónica. Los perfiles de DSS son extensiones del DSS Core que aportan más detalles y funcionalidades para solucionar problemas más concretos.

De perfiles se pueden encontrar diversos, pero PSIS apoya principalmente el perfil XSS (desarrollado por el Consorcio AOC y que amplía DSS permitiendo, entre otras, la validación de certificados X509), el perfil XAdES (que permite la actualización de firmas), el Timestamping Profile, que aporta más control y detalles en el ámbito de los sellos de tiempo sobre DSS, y el DSS_PDF para la validación y completado de firmas electrónicas en documentos PDF.

Profiles
DSS Protocolo básico de creación i validación de firmas .	urn:oasis:names:tc:dss:1.0:core:schema
XADES Ampliación de DSS que permite trabajar con firmas avanzadas XAdES i CAdES.	urn:oasis:names:tc:dss:1.0:profiles:XAdES
XSS Ampliación de DSS que permite, entre otras coses, validar certificados X509 de clave pública, extraer información de los mismos, y utilizar políticas de firma.	urn:oasis:names:tc:dss:1.0:profiles:XSS
TIMESTAMP Define restricciones extraídas sobre la creación y validación de sellos de tiempo vía DSS.	urn:oasis:names:tc:dss:1.0:profiles:timestamping
DSS_PDF Permite validar y completar firmas en documentos PDF.	urn:oasis:names:tc:dss:1.0:profiles:DSS_PDF

La documentación detallada del protocolo y sus perfiles está disponible en el paquete distribuido por el Consorcio AOC. Los esquemas del protocolo DSS y su perfil XSS están incluidos también en el anexo del presente documento como información complementaria.

NOTA: Todas las descripciones de estructuras / elementos que forman parte de la mensajería DSS contienen el nombre del documento donde se puede encontrar el detalle de la descripción, junto con posibles comentarios particulares de la plataforma PSIS.

La mensajería que interviene en la plataforma PSIS viene definida por el estándar DSS y funciona bajo el protocolo SOAP (Simple Object Access Protocol)..

SOAP es un protocolo estándar sobre el que se fundamenta la tecnología de servicios web (Web Services). A diferencia de otros protocolos de tipo binario como pueden ser COM, COM + o DCOM, los cuales son propios de Microsoft, SOAP se basa en documentos de texto plano codificados en formato XML. La ventaja principal de codificar en XML es que los mensajes son legibles por seres humanos; pero, por el contrario, estos documentos resultantes son, en general, de gran tamaño.

SOAP está diseñado para funcionar sobre cualquier protocolo de internet, aunque el uso más habitual es sobre HTTP. El hecho de utilizar HTTP minimiza el impacto de dispositivos como Firewalls y similares, y hace accesible SOAP a prácticamente cualquier tipología de comunicación cliente-servidor.

Los mensajes SOAP están compuestos por dos grandes bloques funcionales: "Cabecera" (envelope) destinado a suministrar datos de enrutamiento y "Cuerpo" (body), el cual contiene los datos del mensaje de usuario. Una explicación más detallada de SOAP no forma parte del alcance de este documento.

En este apartado se tratan los aspectos más importantes involucrados en el uso del protocolo DSS. Sin embargo, se adjunta la referencia donde se puede consultar el documento del estándar correspondiente por si fuera necesaria más información sobre el apartado concreto.

Además, se definen una serie de prefijos para los diferentes espacios de nombres involucrados. Su mapeo contra las URIs de los espacios de nombres es el siguiente:

• xd: xxxx://xxx.x0.xxx/0000/00/XXXXxxx#

• dss : urn:OASIS:names:tc:dss:1.0:core:schema

• xss : urn:OASIS:names:tc:dss:1.0:profiles:XSS

• pdf: urn:OASIS:names:tc:dss:1.0:profiles:DSS_PDF

Aquí mostramos los dos tipos básicos de estructuras que se utilizan en el estándar DSS, junto con los elementos básicos que se utilizarán para componer los mensajes. Los dos tipos principales de mensajes que define DSS son VerifyRequest (para peticiones de validación) y SignRequest (para peticiones de firma o estampación de sello de tiempo).

Documentación

El adjudicatario de este concurso dispondrá de toda la documentación relacionada con la aplicación que sea necesaria para la prestación del servicio objeto de este contrato.

A continuación se enumeran los principales documentos:

• Guía de integradores de PSIS

• Pliego de requerimientos inicial de PSIS

• Documento análisis funcional

• Documento de arquitectura

• Diagramas secuenciales de firma

• Perfiles internacionales y del Consorci AOC (DSS, XSS, XAdES, DSS_PDF, TimeStamping)

• Documentación sobre gestión de los perfiles de los proveedores y archivos de configuración.

• Documentación de usuario

o Guía de integradores

o Guía de Firma

• Documentación de gestión i configuración de PSIS

Anexo 3 - PSA

El Programari de Signatura Avançada (PSA) se ha concebido como una herramienta base que se puede utilizar en todos los proyectos de las Administraciones Públicas donde se requiera de generación de firmas electrónicas, ya sea mediante servicios web o frontal web si debe interactuar algún usuario. El software ofrece herramientas y mecanismos para que cualquier servidor de aplicación pueda realizar firmas desatendidas y firmas múltiples con soporte de políticas de firma conforme al estándar, haciendo uso de certificados disponibles en PSA o en posesión del firmante. Además, también permite realizar operaciones de cifrado y descifrado de documentos.

A continuación se hace una descripción resumida funcional y de arquitectura en la que se basa PSA. El adjudicatario deberá detallar en su propuesta el conocimiento y experiencia que tiene de aplicaciones iguales o similares, que hagan uso de los estándares que se indican a continuación.

Descripción funcional

PSA ofrece las siguientes funcionalidades:

Creación de una firma electrónica utilizando un certificado en posesión de un usuario en la web de PSA

Típicamente se trata de certificados personales - CPISR-1, idCAT, DNI-e o similares.

En este caso es el componente servidor de PSA, con la colaboración del componente de usuario final, quien genera la firma solicitada.

La aplicación de gestión tiene que hacer una llamada a PSA indicando, entre otros:

1. El documento o el contenido del documento1 a firmar.

2. La identificación de la política de firma múltiple aplicable, y el paso del proceso de la sesión que se está ejecutando -en caso de firma múltiple-.

3. (opcional) Se indicará información que sea obligatoria según recoja la política de firma empleada (commitments, role).

4. (opcional) Información relativa al posicionamiento y contenido de la firma visible en el documento en su caso (sólo para firmas en formato PDF).

5. En relación al firmante, no se indica ninguna referencia a los datos de creación de firma (referencia a la clave privada a emplear para generar la firma: KeySelector) de forma que PSA interpreta a emplear uno de los certificados custodiados por el usuario final y que, por tanto, es necesario que éste lo seleccione y la active.

PSA valida que el formato del documento a firmar indicado está soportado. En base a la información que sobre este formato conste el "registro de formatos" configurado el propio PSA (como las normas sintácticas y semánticas para codificar y descodificar Entender, en definitiva- los formatos), se presenta un link del documento al usuario final, de manera pertinente, para que este pueda - opcionalmente- revisar el contenido del documento y confirmar que el vuelo firmar.

Cuando PSA recibe una petición de creación de firma de un documento conforme a una política de firma múltiple 2 apuntada por un OID, recupera el correspondiente documento que la detalla, la interpreta y aplica la correspondiente política de firma para determinar la forma y contenido de la firma a generar.

1 Mediante el resumen criptográfico del documento. La decisión de enviar el hash desde la aplicación de gestión dependerá de la política de seguridad aplicable.

2 La provisión de los documentos XML que especifican las políticas de firma múltiple y de firma formará parte de las tareas de configuración del sistema que hay que llevar a cabo antes de la entrada en producción de cada proyecto.

Conforme a ello PSA genera la estructura de datos que debe formar la firma (construcción semántica de la firma) consumiendo los servicios de PSIS cuando sea necesario obtener información adicional (como sellos de tiempo o información de revocación) que haya de incorporar a la firma.

Calcula el resumen (hash) del contenido a firmar y, en su caso, también de los atributos de la firma que corresponda firmar.

Este resumen se hace llegar al componente de usuario final para que, simplemente, el cifre empleando una de las claves privadas asociadas a los certificados personales que custodia el usuario. Por lo tanto, es necesario que la seleccione y el active, introduciendo el PIN correspondiente. El resultado de esta operación se enviará como respuesta al componente servidor de PSA.

Este, al recibirlo comprueba que el resultado corresponde al resumen enviado al usuario (para verificar que no ha sido suplantado) y, si es correcto, lo incorpora a la estructura de datos que forma la firma.

Posteriormente, el servidor PSA ejecuta todas las condiciones de validación y completado que se especifiquen en la política de firma electrónica aplicable, con el apoyo de la AVS de PSIS, para lo que le solicita la ejecución de los servicios correspondientes.

Creación de una firma electrónica utilizando un certificado en posesión de un usuario en un portal de la aplicación de gestión

Típicamente se tratará de certificados personales - CPISR-1, idCAT, DNI-e o similares.

En este caso es un portal de la aplicación de gestión que lleva la interlocución con el usuario, y por debajo hará uso del servidor de PSA que será quien generará la firma solicitada.

La aplicación de gestión debe hacer inicialmente una llamada a PSA indicando, entre otros:

1. El documento o el contenido del documento3 a firmar.

2. La identificación de la política de firma múltiple aplicable, y el paso del proceso de la sesión que se está ejecutando -en caso de firma múltiple-.

3. (opcional) Se indicará información que sea obligatoria según recoja la política de firma empleada (commitments, role).

4. (opcional) Información relativa al posicionamiento y contenido de la firma visible en el documento en su caso (sólo para firmas en formato PDF).

PSA valida que el formato del documento a firmar indicado está soportado. En base a la información que sobre este formato conste el "registro de formatos" configurado el propio PSA (como las normas sintácticas y semánticas para codificar y descodificar Entender, en definitiva- los formatos), presenta el resumen criptográfico -hash- a la aplicación de gestión para que ésta presente al usuario final, de manera pertinente, el documento y la posibilidad de generación de la firma con un applet.

El resumen (hash) del contenido a firmar también debe recoger los atributos de la firma que corresponda firmar, y si estos son modificados por el usuario, se debe crear un nuevo resumen.

Cuando PSA recibe una petición de creación de firma de un documento conforme a una política de firma múltiple4 apuntada por un OID, recupera el correspondiente documento que la detalla, la

3 Mediante el resumen criptográfico del documento. La decisión de enviar el hash desde la aplicación de gestión dependerá de la política de seguridad aplicable.

4 La provisión de los documentos XML que especifican las políticas de procedimiento y de firma formará parte de las tareas de configuración del sistema que hay que llevar a cabo antes de la entrada en producción de cada proyecto (al igual que la provisión de certificados a la PSIS, etc.).

interpreta y aplica la correspondiente política de firma para determinar la forma y contenido de la firma a generar.

Este resumen se hace llegar al portal de firma de la aplicación de gestión para que lo haga llegar al usuario final para que éste, simplemente, lo firme empleando una de las claves privadas asociadas a los certificados personales que custodia. Por lo tanto, es necesario que el usuario la selecciona y la active, introduciendo el PIN correspondiente. El resultado de esta operación se envía como respuesta al componente servidor de PSA.

Signador versión APSA-Light

Proporciona las siguientes funcionalidades:

1. Cifrar una serie de hash utilizando la clave de uno de los certificados xxx xxxxxxx de certificados personales del navegador.

2. Cifrar una serie de hash utilizando la clave almacenada en una tarjeta criptográfica.

3. Cifrar una serie de hash utilizando el DNI electrónico.

4. Habilitar una solución para la autenticación vía certificado por aplicaciones Web.

5. Presentar una lista de certificados que sean de confianza según un listado de CAs (Certificate Authority).

6. Facilitar la integración con otras tecnologías y frameworks para construir aplicaciones web.

7. Facilitar la personalización de los estilos e imágenes de la interfaz de usuario que presenta la APSA.

El Consorcio AOC ofrece el firmante en versión APSA-Light por la parte de firma en local necesaria para la firma electrónica utilizando un certificado en posesión del usuario. El mantenimiento evolutivo y correctivo del firmante queda fuera del alcance de este pliego.

Creación de una firma electrónica utilizando un certificado accesible por PSA

En este caso, la llamada de la aplicación de gestión hacia PSA debe indicar, entre otros:

1. El documento o el contenido del documento5 a firmar.

2. La identificación de la política de firma múltiple aplicable, y el paso del proceso de la sesión que se está ejecutando -en caso de firma múltiple-.

3. (opcional) Se indicará información que sea obligatoria según recoja la política de firma empleada (commitments, role).

4. (opcional) Información relativa al posicionamiento y contenido de la firma visible en el documento en su caso (sólo para firmas en formato PDF).

5. En relación al firmante, indicar una referencia a la clave privada (KeySelector) que se debe emplear para generar la firma, correspondiente al certificado pertinente. Esta clave debe estar previamente cargada a PSA y con una autorización de uso firmada por un responsable de la administración.

5 Mediante el resumen criptográfico del documento. La decisión de enviar el hash desde la aplicación de gestión dependerá de la política de seguridad aplicable.

PSA comprueba que hay la autorización de uso del certificado. Es PSA quien gestiona las autorizaciones de los certificados que puede emplear.

En caso afirmativo, PSA recupera el documento que detalla la política de firma múltiple que corresponde al OID indicado y la interpreta para determinar la forma y contenido de la firma a generar.

Es el propio componente servidor de PSA que genera la firma solicitada, accediendo a la llave indicada en la petición.

Manipulación de formatos de documentos que envuelven firmas

Hay que tener en cuenta la relación que se establece entre el documento a firmar y la firma que se quiere generar.

A grandes rasgos se puede decir que las firmas pueden:

- Incluir el documento (ej. Caso de una firma XMLDsig o XAdES envolvente; o bien CMS o CAdES Attached).

- Ser totalmente independientes del documento (ej. Caso de una firma CMS o XML detached en que la relación con el documento será gestionará por la aplicación de gestión).

- Mantener un vínculo con el documento (ej. Caso de una firma XML que apunta al documento).

- Estar contenida dentro del documento:

o Firmas envueltas dentro de documentos XML: XMLDsig o XAdES envueltas (p. ej. firmas de facturas según el formato "Factura-e" definido por la AEAT.

o Estar incrustada dentro del mismo formato del documento (pe. caso de documentos en formato PDF, S / MIME, Open Document Format, Office Open XML, etc.).

Merecen especial atención estos últimos casos, en los que el formato del documento a firmar envuelve sus firmas -como ocurre con los formatos S / MIME, PDF, etc.- porque hay que conocer las particularidades de los formatos para poder manipular correctamente las firmas electrónicas que se quieran incrustar o se encuentren incrustadas, por lo que éstas se visualicen e interpreten correctamente para la aplicación correspondiente.

PSA es capaz de manipular correctamente estos formatos: puede calcular correctamente el resumen (hash) del documento a firmar y saber, después, como incrustar la firma generada allí donde corresponda; del mismo modo también sabe extraer la firma de donde quiera que esté incrustada para poder validarla.

Considerando todas las posibles variantes de los formatos (p. Ej. Entre los documentos de formato PDF, el tratamiento a realizar para firmar el contenido completo de un documento puede ser diferente a lo que hay que hacer cuando se quiere firmar un formulario PDF), PSA puede soportar todas. Eso sí, se tienen en cuenta las posibles limitaciones en el formato de las firmas soportadas por cada formato de documento.

Todo ello, tanto para el caso de que sea la propia PSA quien haga todo el proceso de generación de la firma -construcción semántica de la firma y cifrado del resumen con la clave privada- como para el caso de que PSA sólo haga la construcción semántica de la firma y el cálculo del resumen, y sea el componente de usuario final quien cifre este resumen.

Autorización de firmas automáticas desatendidas

Para que una aplicación pueda firmar documentos de forma automática, desatendida, utilizando un certificado digital concreto accesible a PSA, es necesario que un usuario habilitado a tal efecto autorice el uso. Concretamente, deberá firmar electrónicamente una orden de autorización de uso de este certificado.

Previamente habrá que llevar a cabo las siguientes acciones:

- Provisión del certificado que se quiere activar a PSA e indicación de los datos necesarios del usuario que debe habilitar la autorización.

- Provisión de las políticas de procedimiento y políticas de firmas necesarias a PSA.

Para desencadenar la firma de una orden de autorización de uso de un certificado digital, la aplicación de gestión hace un llamamiento a PSA indicando, entre otros:

1. Los datos identificativos del usuario habilidad que debe gestionar las autorizaciones.

2. PSA responde con una URL donde sólo dispondrá de acceso del usuario habilitado mediante un certificado que dé fe de los datos identificativos.

Así el usuario -con la intervención del componente de usuario final- puede acceder a firmar la orden de autorización de uso del certificado empleando en su certificado CPISR-1 almacenado en la tarjeta criptográfica que él mismo custodia.

Una vez firmada la orden de autorización, PSA crea la correspondiente configuración de seguridad en la aplicación de generación de firma. Así, cuando una aplicación de generación de firma recibe una solicitud de generación de firma indicando que debe emplear un certificado que está accesible para PSA, comprueba si tiene grabada la correspondiente orden de autorización de uso del certificado.

PSA también puede registrar, siguiendo un procedimiento similar al descrito anteriormente, una orden de desactivación del uso del certificado por parte del usuario habilitado - por ejemplo, para que se trate de un órgano administrativo que se va de vacaciones y durante ese período no quiere que el sistema firme documentos con certificados digitales en los que consta su nombre, porque delega ciertas funciones en otro empleado público.

Soporte a las necesidades de negocio en relación a la gestión de la firma electrónica

Se entiende por política de firma múltiple el documento que recoge toda la información relativa a las especificaciones del orden y disposición de los firmantes, así como de las políticas de firma a utilizar al realizar un procedimiento administrativo.

PSA apoya la gestión de políticas de firma múltiple, por lo que las aplicaciones cliente le pueden delegar las complejas tareas de gestión involucradas en la generación de diferentes variantes de firmas: solidarias, mancomunadas, etc.

Hay pues, para cada procedimiento, definir la correspondiente política de firma múltiple y cargarla en PSA.

PSA soporta el tratamiento automático de firmas basadas en políticas de firma electrónica: en el momento en que se va a generar una firma, recoge toda la información relativa a los atributos a firmar:

- PSA obtiene los atributos de los certificados mediante llamadas de servicio a PSIS.

En caso de tratarse de atributos que debe especificar el usuario final -como qué rol y / o compromiso quiere que conste en la firma-, en el caso de firma en local en la web de PSA, se muestra una interfície gráfica de usuario adecuada para que pueda seleccionarlo o especificarse.

PSA permite al usuario seleccionar y ver los atributos que, además del documento, debe firmar - según las especificaciones técnicas de los formatos de firmas avanzadas CAdES y XAdES.

Los atributos no firmados los añade PSIS cuando valida y completa la firma generada.

En todo caso, PSA apoya todos los atributos (firmados y no firmados) a los que hacen referencia las especificaciones técnicas de formatos de firma electrónica: CMS (RFC 3852), CAdES (ETSI TS 101 733), XMLDsig (RFC 3275), XAdES (ETSI TS 101 903).

Por tanto, y en apoyo de las funciones descritas anteriormente, para cada una de las firmas involucradas en un procedimiento se puede:

- Especificar cuál es la política de firma que aplica y cuáles son los atributos -firmados y no firmados- que debe incorporar la firma, entre los previstos por las especificaciones técnicas de los formatos de firma.

- Indicar dónde debe obtener o donde debe consultar PSA cada uno de los atributos a firmar. Y PSA:

- Mostrar al signatario cuáles son los atributos que debe firmar, los añade a la estructura de la firma y calcula el resumen (hash) a firmar.

- Una vez generada la firma, solicita a PSIS que la complete con los atributos no firmados que especifique la política de firma aplicable.

Generación de firmas para múltiples documentos

PSA soporta la generación de firmas para múltiples documentos a partir de una única llamada.

PSA procesa cada una de las peticiones recogidas en la llamada y procede a generar la firma correspondiente según los casos de uso descritos anteriormente.

Generación de comprobantes

La aplicación de gestión puede solicitar a PSA la generación de un comprobante asociado a una firma digital realizada. Por ello, la aplicación de gestión debe indicar a PSA el identificador de la transacción que generó la firma sobre la que se desea generar el comprobante, y opcionalmente el hash del documento que se firmó.

PSA interpreta el identificador recibido y comprueba si se corresponde con una firma archivada en la misma PSA6.

PSA comprueba cuál es la información que debe incluir en el comprobante, a partir del diseño en la configuración de la aplicación de gestión, y recuperará la información necesaria a incluir en el comprobante.

Entonces PSA construye el informe PDF con la información obtenida referente a la firma, y con el diseño especificado en la plantilla asociada. PSA firma con su clave privada CDA el informe PDF y lo devuelve a la aplicación de gestión.

Formatos de documentos suportados

PSA permite firmar y verificar los siguientes tipos de contenidos:

- Cualquier archivo binario, especialmente en la modalidad de firma ciega. Específicamente hay que tratar en este caso la firma de ficheros gráficos7 soportando los siguientes formatos:

o Formato JPEG, en sus diferentes versiones.

o Formato GIF, en sus diferentes versiones.

o Formato TIFF, en sus diferentes versiones.

- Cualquier documento XML, con tratamiento de las transformaciones correspondientes a la visualización de los mismos (como XSLT o XHTML) y, específicamente, todas las capacidades de firma electrónica sobre contenidos y metadatos de los siguientes esquemas.

o Open Document.

o Open XML Office.

6 El archivo de las firmas generadas a la PSA estará configurado con un periodo limitado.

7 La firma de ficheros gráficos resulta especialmente necesaria en los casos de digitalización documental, para traspasar de documentos en papel a sus versiones digitales.

- Cualquier versión de documentos Adobe PDF, hasta la especificación PDF Reference versión 1.7, con soporte específico para las firmas llamadas ordinaria y MDP8, con los métodos de resumen criptográfico llamados Byte Range y Object Digest, y con apoyo de los diferentes formatos de diccionarios de firma (Signature Dictionary) y de manifestaciones legales (Legal Attestation Dictionary). Dando Soporte a la llamada signature appearance9 para facilitar la presentación de la firma al usuario.

- Los documentos en formato PDF que hayan sido firmados por PSA son compatibles -y las firmas se pueden validar- con la última versión del Adobe Reader, y también con versiones anteriores (a partir de la versión 6).

- Cualquier versión de mensajes S / MIME, a los efectos de envolver documentos y firmas electrónicas a enviar o recibir en este formato -frecuentemente empleado en correo electrónico seguro, considerando específicamente la envoltura simple y, como mínimo, el envoltorio triple (Triple Wrapping).

Descripción de los servicios Servicios Principales

Una breve descripción de los principales servicios:

• Servicios públicos o accesibles:

o Consola Web – Una interfaz Web para acceder a los servicios de administración y configuración de PSA.

o Servicio de Administración – Servicio que permite configurar los parámetros generales, configurar los certificados de PSA, y los usuarios.

o Servicio de Configuración – Servicio que permite configurar las políticas de firma, el flujo de firma, y las aplicaciones de gestión.

o Servicio Firma – Servicio que firma el documento después de estudiar el flujo de firma y la política de firma. Este servicio utiliza PSIS.

o Servicio Content Repository – Este servicio utiliza la biblioteca Droid para validar el documento. Los diferentes documentos enviados a PSA son almacenados en un JCR, este servicio es responsable de comunicarse con el JCR y almacenar el documento. El documento es recuperable por peticiones posteriores.

o Servicio Presentación Documento – Servicio que trabaja junto con el servicio JCR para enviar el documento al usuario final y permitir su presentación.

• Servicios internos y no públicos:

o Servicio Generación Comprobantes – Genera los comprobantes después del proceso de signatura.

o Servicio Política de Firma – Servicio que ejecuta una política de firma.

o Servicio Flujo de Firma – Servicio que busca el acto de un flujo de firma para comenzar la realización de la firma, ejecutando el workflow definido.

o Servicio Verificar Firma – Servicio para verificar una firma con la colaboración de PSIS.

o Servicio Criptográfico – Servicio para calcular hashes y cifrarlos.

• Servicios clientes a otros servicios:

o Servicio Cliente AVS – Consume el servicio AVS de PSIS.

8 No serà necesario suportar las firmas de derechos de autor.

9 Conforme al documento Digital Signature Appearances - Version: Acrobat 6.0, de maig de 2003.

o Servicio Cliente Content Repository – Consume el servicio de JCR para almacenar y recuperar un documento.

Servicios Transversales

PSA goza de unos servicios transversales a todos los servicios declarados antes:

Fig. 1 Servicios Transversales

La arquitectura proporciona estos servicios y facilita la construcción y el control del funcionamiento de PSA:

• Security – Responsable de gestionar el acceso a los métodos de los componentes de negocio.

• Transaction – Responsable de garantizar operaciones ACID (atomic, consistent, isolated, durable).

• Cache – Servicio que aumentar el rendimiento de PSA, almacenando los objetos necesarios para un rápido acceso de los servicios.

• Mensajes I18N – Los Servicios de PSA informaran del estado de la operación tanto en caso de éxito como de error. Este servicio es responsable de generar los mensajes adecuados para cada operación, además es un servicio de tipo I18N.

• Audit – Servicio interno de la PSA que permite auditar las principales operaciones realizadas.

• Exceptions – La gestión de excepciones es un servicio inherente a la lógica de negocio, pero se ha abordado la gestión de forma común para asociar la gestión de la excepción con un/os mensaje/s.

CWA 14170

PSA está construido de acuerdo a la legislación vigente, y debe garantizar el cumplimiento de los conceptos jurídicos aplicables a los elementos de software de los sistemas de información (SI).

Se aplicarán las buenas prácticas, patrones, y normas nacionales e internacionales e incluso especificaciones técnicas voluntarias como por ejemplo CEN CWA 14170.

A continuación un resumen de los principales términos introducidos por las especificaciones CEN CWA 14170:

• Data To Be Signed (DTBS) – los datos a firmar, que resultan de los siguientes elementos:

o El documento a firmar (signer’s document), dato obviamente obligatorio.

o Data content type, atributo que define el formato del documento a firmar, y, por derivación, las normas para visualizarlo en el firmante y al verificador de la firma electrónica.

o La identificación del certificado de firma electrónica (certificate identifier) con el que se podrá verificar esta firma, que también es un dato que debe constar de forma obligatoria.

o Otros datos de forma opcional, como por ejemplo atribuciones del firmante, u otros documentos o informaciones.

Una de estos datos adicionales opcionales es el identificador de la política de firma electrónica (signature policy identifier), que nos indica el conjunto de normas de seguridad aplicable a la creación y la verificación de esta firma, así como de su significado jurídico , de forma independiente del contexto de la firma.

Otra de estos datos es el identificador del tipo de compromiso de firma (commitment type), que nos indica, de forma expresa, el significado jurídico o de otro tipo, de la firma electrónica. Cuando una política de firma electrónica contiene varios tipos de compromisos, este dato nos permite conocer de acuerdo con qué tipo concreto de compromiso ha sido emitida esta firma.

Finalmente, los datos a firmar pueden referirse a roles, permisos, poderes, sellos de tiempo y otras informaciones.

• Data To Be Signed Formatted (DTBSF) significa los datos a firmar que ya han recibido el formato necesario y previo a la generación del resumen criptográfico, mediante el correspondiente proceso de formato. Este proceso resulta necesario para garantizar que los datos se encuentran en el orden correcto, de acuerdo con una estructura concreta de firma electrónica, como por ejemplo el formato SignedData definido por PKCS # 7, CMS, XMLDsig, o XAdES.

• Data To be Signed Representation (DTBSR) significa la representación matemática de los datos a firmar formateadas, es decir, el resumen criptográfico de los datos a firmar, que se empleará para la creación de la firma electrónica.

• Signed Data Object (SDO) significa el objeto de datos firmados, que es el resultado, ya tratado, del proceso de firma. El objeto de datos firmados se encuentra en el mismo formato que el DTBSF, incorporando en su interior la firma digital producida a partir de la DTBSR, y otros datos e informaciones que no han sido objeto de firma.

Descripción tecnológica

A continuación se hace una descripción de las tecnologías y estándares más relevantes de las que hace uso la aplicación PSA. El adjudicatario deberá detallar en su propuesta el conocimiento y experiencia que tiene de estas tecnologías en concreto, y otros similares si lo estima oportuno.

Las herramientas para desarrollar son:

Producto	Descripción
Eclipse	Integration Development Environment (IDE).
Maven2	Herramienta clave para la construcción y packaging de nuestros proyectos JEE. Junto con el IDE Eclipse facilitará la generación del software así como de la documentación dinámica del código.
Continuum	Herramienta para introducir la buena práctica de desarrollo de Integración Continua.
Artifactory	Repositorio Maven2 de empresa.
GForge	Herramienta para gestionar artifacts del proyecto, como tareas, bugs, etc.

A continuación recogemos una lista de los frameworks aplicados a PSA, de los que el adjudicatario debe detallar en la propuesta su grado de conocimiento:

Producto	Descripción
TestNG	El equipo de desarrollo generará los tests unitarios con TestNG, que serán fácilmente ejecutados por Maven2 y por Eclipse.
JAX-WS JAXB	Para desarrollar los Web Services ha utilizado la suite proporcionada por SUN. Recordemos que SUN ha sustituido jwsdp para JAX-WS.
EJB 3.0	Los componentes de negocio son EJB 3.0 stateless, y los objetos de dominio son EJB 3.0 entity POJOs.
JSF 1.2	La parte vista está construida con JavaServer Faces 1.2., Aplicando el patrón composite view con el framework Facelets.
Seam	Seam es un framework muy interesante que integra JSF y EJB 3.0 además de otros productos Jboss como jBPM.
JMeter 2.3	Herramienta Work-load.
Droid	Framework para validar documentos.
Annotations	Anotaciones java.
Jackrabbit	Implementación del JSR-170 para disponer de un JCR.
Metro	El stack de Servicios Web de SUN.
XML Security	Framework de Apache.
Bouncy Castle	Framework de criptografía Java.

Infraestructura de software

La aplicación PSA está desarrollada, principalmente, en J2EE (Java 2 Platform Enterprise Edition), y por tanto hecha y ejecutada en software escrito en lenguaje Java en una arquitectura distribuida en niveles y basada en componentes de software.

Se ha adoptado la estructura de directorios estándar de Maven 2, Standard Directory Layout para la organización de los directorios y archivos de un proyecto eclipse-maven.

Concretamente se basa en la estructura propuesta por proyectos multimódulo de Maven2. Los módulos son los siguientes:

Módulos
Nombre del módulo	Descripción
applet	Applet de firma.
cacerts	Módulo que contiene los scripts generadores de certificados de test así como un lote ya generado.
clientws	Módulo que parsea el WSDL de PSA para generar las clases de modelo necesarias para consumir los servicios web de PSA.
cms	Contiene las clases correspondientes al servicio que presenta las interfaces para atacar al CMS (Content Management Repositori).
commons	Clases de utilidades no específicas de PSA.
console	Módulo con la lógica de negocio ligada a la consola de administración.
crypto-native	Contiene los archivos en C++ para compilar una dll que tenga un método para firmar únicamente el hash.
ear	Módulo que define el paquete EAR.
faces-components	Contiene diferentes componentes de JSF.
model	Contiene las clases del modelo así como los scripts para la generación de la base de datos.
profiles	Módulo que permite generar las clases Java que definen la interfaz que PSA ofrece a las aplicaciones cliente.
psa	Contiene las clases que componen el núcleo de PSA, cubre las funcionalidades referentes a firma, políticas, servicios de hash y cifrado, etc...
psis	Contiene las clases del cliente que consumen los servicios web de PSIS.
schedulers	Contiene los planificadores de PSA.
signaturepolicy	Contiene el conjunto de clases necesarias para representar las políticas de firma y de firma múltiple, así como el parser para parsear los XMLS de las políticas.
web	Módulo web de PSA. Contiene la parte web de la Consola de administración.

Descripción de la mensajería

Las funcionalidades soportadas por los diferentes servicios web del PSA, se pueden agrupar en tres tipos:

• Operaciones de firma.

• Operaciones de consulta de información.

• Operaciones de utilidades o realización de otras operaciones.

La interacción entre los clientes y PSA a través de los servicios web consiste en el intercambio de mensajería SOAP, el contenido está definido en el siguiente conjunto de esquemas XML (XML Schema) o profiles:

• dss-directsign.xsd: Namespace: urn:catcert:psa:1.0:profiles:dss-directsign

• dss-dooperation.xsd: Namespace: urn:catcert:psa:1.0:profiles:dss-dooperation

• dss-encrypt.xsd: Namespace: urn:catcert:psa:1.0:profiles:dss-encrypt

• dss-getdata.xsd: Namespace: urn:catcert:psa:1.0:profiles:dss-getdata

• dss-getsession.xsd: Namespace: urn:catcert:psa:1.0:profiles:dss-getsession

• dss-signsession.xsd: Namespace: urn:catcert:psa:1.0:profiles:dss-signsession

Estos esquemas hacen uso de los siguientes profiles importados, no propios de PSA:

• xmlns:xmlmime=xxxx://xxx.x0.xxx/0000/00/xxxxxxx

• xmlns:dsp=xxxx://xxx.xxxx.xxx/0000/x0.0.0#

• xmlns:ds=xxxx://xxx.x0.xxx/0000/00/xxxxxxx#

• xmlns:xs=xxxx://xxx.x0.xxx/0000/XXXXxxxxx

• xmlns:saml=xxxx://xxxx.xxxxx-xxxx.xxx/xxxxxxxx/xxxx/x0.0/xxxx-xxxxxx-xxxxxxxxx-0.0.xxx

• xmlns:dss= xxxx://xxxx.xxxxx-xxxx.xxx/xxx/x0.0/xxxxx-xxx-xxxx-xxxxxx-x0.0-xx.xxx

Nota: En el documento que se llama "Guía integración PSA" -que es de distribución pública a integradores- se proporciona información en detalle.

Anexo 4 - iArxiu

Descripción funcionalidades/servicios

Entre sus funcionalidades principales constan:

• Preservación a largo plazo de los documentos asegurando que:

o No se pierde ni corrompe información

o Se hacen revisiones periódicas de la integridad y consistencia del sistema

o Se dispone de sistemas de seguridad que pueden recuperar la información en caso de desastres

o La información siempre será legible e interpretable por los humanos a pesar de la posible obsolescencia de los formatos y soportes al aplicar las políticas de preservación adecuadas en cada caso. Se controla el ciclo de retención y disposición de los documentos

• Preservación de las evidencias legales asegurando que:

o Todas las informaciones y acciones a iArxiu quedan correctamente registradas, indicando quién, cuándo, qué se hizo y sobre qué se hizo

o Se protegen todos los documentos mediante técnicas criptográficas, de manera que sea posible asegurar que un documento no ha sido alterado desde la fecha de entrada al sistema

o Se preserva en el tiempo la validez de las firmas electrónicas soportadas

o Se dota al sistema de una consulta para obtener un informe de evidencia electrónica Como funcionalidades secundarias y necesarias para el correcto funcionamiento del sistema constan:

• Posibilitar la transferencia de los documentos en el sistema de una manera segura por parte de los productores de información, sean aplicaciones o personas. Pudiendo establecer filtros que aseguren que los documentos transferidos son correctos

• Posibilitar la consulta de los paquetes de información archivados en iArxiu atendiendo a la política de acceso establecido para cada caso

• Gestionar el ciclo de vida de los documentos y la definición de políticas o estrategias de preservación para garantizar su preservación a largo plazo

• Gestionar una base de datos de conocimiento que permita el establecimiento de formatos, filtros de entrada, visores, documentación criptográfica, etc.

• Dotar al sistema de un depósito local de usuarios y roles que facilite la gestión del sistema

Transferencia e ingreso de documentos

Este módulo es el encargado de recibir los documentos (paquetes de información de transferencia o PIT) generados por los diferentes sistemas de información de los clientes de iArxiu. Además, también se encarga de validarlos y prepararlos para su almacenamiento y gestión dentro del repositorio. En este contexto entendemos por transferencia todas aquellas actividades implicadas en la transferencia de documentación de un sistema a otro.

A nuestro juicio, la funcionalidad de transferencia y su posterior ingreso son las más críticas de todo el sistema, pues tenemos que garantizar que en el propio proceso no se producen inconsistencias y que la estructura, contenido y forma de los paquetes de información se mantienen estables.

El procedimiento de transferencia incluye las siguientes fases:

• Fase de preingreso: Incluye todas las actividades relacionadas con la gestión y la planificación adecuada de las transferencias. Los objetivos son: identificar qué tipo de

documentación se debe preservar; su adecuación a los estándares y requerimientos de iArxiu; analizar la viabilidad y los costes del proyecto; diseñar los paquetes de información de transferencia; desarrollar la integración con iArxiu y establecer el protocolo de transferencia para regular la relación entre el productor y iArxiu.

• Fase de transferencia. Una vez establecido el protocolo de transferencia hay que planificar el calendario de ejecución y preparar el sistema para enviar la documentación:

o Creación del paquete de información de transferència

o Preparación de la solicitud de transferencia

o Envío de la solicitud de transferencia

Todas estas operaciones se ejecutan en el sistema cliente cuando la forma de transferir es vía WS. Para aquellos casos en que no existe una aplicación responsable de realizar las transferencias, se ha desarrollado una aplicación web para realizar estas operaciones de forma manual.

• Fase de ingreso. Antes de proceder al ingreso de los documentos en el repositorio, iArxiu realiza una serie de tareas para verificar la integridad, la autenticidad y la idoneidad de los documentos con los requerimientos de conservación:

o Recepción de las solicitudes de transferencia, previa autenticación y autorización.

o Almacenamiento temporal de los paquetes de información de transferencia en un área de preingreso, en la que se procede a su validación y completado. Los controles que se realizan son los siguientes:

▪ Control de checksum.

▪ Control de antivirus.

▪ Introspección automática en los archivos con el fin de extraer los metadatos de carácter técnico y así garantizar su preservación.

▪ Validación y completado de las firmas de "negocio".

▪ Validación del contenido, de la estructura y de la forma del paquete de información de transferencia según lo establecido en el protocolo de transferencia.

▪ Generación del histórico de eventos que incluye todas las acciones que se han realizado en el objeto, así como las acciones que están previstas que se ejecuten.

▪ Incorporación de un sello XAdES-A al paquete para garantizar su integridad.

o Generación del paquete de información de archivo, un objeto normalizado y apto para ser preservado en el repositorio digital en formato XML.

o Indexación de la información descriptiva para facilitar la búsqueda y la consulta de la documentación archivada.

o Envío del paquete de información de archivo en el repositorio para ser almacenado y preservado.

o Creación del asiento correspondiente en el registro de transferencias.

o Notificación del éxito de la operación de transferencia al productor de la documentación.

Consulta de documentos

El servicio de consulta y visualización de documentos electrónicos es aquel servicio que permite la consulta, la recuperación y la visualización de los paquetes de información de archivo almacenados

en el sistema iArxiu, garantizando el cumplimiento con la normativa vigente sobre acceso que afecta a dichos documentos por parte de los usuarios del sistema y terceros.

Los usuarios de la plataforma tienen dos formas o vías de acceso para consultar y visualizar los PIA:

• a través de la web de referencia. Este canal lo podrán utilizar aquellos usuarios que quieran utilizar una interfaz web para consultar y visualizar los documentos.

• a través de los servicios web (WS) de consulta a partir de los cuales las aplicaciones de confianza podrán consultar, obtener y descargar los PIC de forma desatendida, sin una interfaz web.

Las operaciones de búsqueda son aquellas que permiten a los consumidores buscar la documentación a la que pueden tener acceso en función de los privilegios que tengan asignados.

Los archiveros o consumidores podrán, de acuerdo con la política de acceso correspondiente, acceder a los contenidos de los PIA buscados y, optar entre los diferentes modos de visualización / recuperación. La consulta se realiza en los siguientes niveles:

• Consulta de los metadatos relacionados con el PIA

• Descarga de metadatos en Dublin Core.

• Consulta de los documentos electrónicos (objetos digitales o archivos)

• Consulta y descarga directo del PIC

• Consulta del historial de acciones

• Descarga de copia auténtica bajo demanda del usuario

• Conversión en línea de documentos

Administración de los documentos

El módulo de administración es aquel módulo donde se engloban las funcionalidades relativas a la administración del ciclo de vida de los documentos y del propio funcionamiento de la aplicación, lo que constituyen las actividades de gestión y que pueden ser, principalmente:

• Gestión de los usuarios y de las aplicaciones de confianza;

• Gestión de la estructura o jerarquía de la plataforma (nos, fondos y series documentales);

• Gestión del registro de acciones;

• Gestión de la política de autorización y autenticación

• Gestión de las políticas de retención y disposición de los documentos

• Gestión de las políticas de preservación digital

• Gestión de las políticas de acceso

• Gestión de los vocabularios y plantillas de metadatos que deben utilizarse para describir los documentos del sistema

• Gestión de las estadísticas de uso del sistema

• Gestión de los formatos de los ficheros aceptados por el sistema

Administration

Dissemination

Ingest

Core Services

Dissemination Services

Ingest Services

Logs Statistics

Tasks

Trusted Application Manager

Policy Manager

Vaocabulary Manager

Template Manager

ContentType Manager

Package Validator

ClamAV

JHove

Indexer

PSIS

DROID

AIP Manager

Package Sealer

Local User Repository

Storage Manager

Generator

OpenOffice

Core Web Service

Authentication

Upload

Authorization

Evidence

Download

Advanced Search

Basic Search

On-Line

Off-Line

Diagrama de bloques funcional del servicio Core iArxiu

Fig. 2 - Diagrama de bloques del Core

La figura anterior muestra el diagrama de bloques del servicio iArxiu. En esta se pueden distinguir los siguientes grupos:

Interfaz de Usuario

Componentes implicados con la interacción con el usuario, entendiendo como tal, a las aplicaciones externas al Core (Clientes WebService y la Web de Referencia). El Core iArxiu acepta únicamente peticiones del servicio web mediante protocolo SOAP sobre HTTPS.

Las peticiones SOAP antes de ser transmitidas en el interior del Core, para ser procesadas, son evaluadas por los módulos de seguridad.

Servicios de Usuario

Los servicios de usuario son aquellos que prestan funcionalidades directamente a los clientes. Existen tres grandes grupos de servicios:

• Administración (Administration)

• Búsqueda y Consulta (Dissemination)

• Ingreso (Ingest)

Servicios de Core

Los servicios de Core son todos aquellos servicios que no están disponibles en la interfaz de usuario. Estos servicios están disponibles única y exclusivamente para consumo interno del Core (incluidos los propios servicios del Core).

Los servicios de Core son prestados por los siguientes módulos:

• Políticas (Policy Manager)

Gestiona las políticas del sistema. Es accedido por el motor de evaluación de reglas (PDP)

• Aplicaciones de confianza (Trusted Application Manager) Administrar aplicaciones de confiança

• Tareas (Tasks)

Gestiona las tareas automáticas del sistema ejecutadas sin intervención humana.

Este servicio se divide en dos componentes. Por un lado se tiene el programador de tareas (Scheduler) el cual ejecuta tareas periódicas; y por la otra las tareas o los componentes del sistema que ejecuta acciones determinadas.

• Logs

Registro de seguimiento del sistema habitual en cualquier plataforma

• Estadísticas (Statistics)

Genera y permite la consulta estadísticas del sistema

• Gestores especializados

Dentro de los servicios de Core hay un conjunto avanzado formado por los servicios que administran los vocabularios (Vocabulary Manager), las plantillas (Template Manager) y los ContentTypes (ContentType Manager).

Estos módulos gestionan la información correspondiente mediante paquetes especializados y por este motivo acceden directamente al gestor de paquetes (AIP Manager).

Al mismo tiempo para localizar sus paquetes acceden al servicio de indexación de metadatos (Indexer).

No acceden a servicios externos a excepción del administrador de ContentTypes (ContentType Manager), el cual actualiza la información accediendo al servicios DROID y JHOVE.

Componentes Core

Los componentes Core lo forman los componentes centrales del núcleo iArxiu y son los que realizan las tareas principales del iArxiu.

El principal componente del Core es el administrador de paquetes (AIP Manager), el cual requiere de otras según se detalla a continuación.

• Administrador de paquetes (AIP Manager)

Este componente se constituye en el componente principal del sistema dado que ingresa y extrae los paquetes almacenados en iArxiu.

Las actividades principales ejecutadas por este componente son:

• Validación de paquete

• Validación de binarios (Antivirus)

• Validación de firmas

• Indexación de metadatos

• Sellado del paquete

• Almacenaje del paquete

Las funcionalidades comentadas las ejecuta directamente o bien apoyándose en otros componentes del Core.

• Validador de paquetes (Package Validator)

Validar un paquete según los siguientes parámetros:

• Adecuación a los esquemas iArxiu

• Tipos de binarios (Content Type)

• Integridad de binarios (Checksum)

• Validación de binarios contra virus (usando el servicio ClamAV)

• Adecuación a la plantilla

• Vocabularios suportados

• Firmas (usando los servicios de PSIS)

• Indexador de metadatos (Indexer)

Este módulo indexa a base de datos los metadatos para acelerar las tareas de búsqueda.

• Sellador de paquetes (Package Sealer)

Sella o resellado los paquetes. Accede a PSIS para realizar las tareas relacionadas con la firma digital.

• Generador de identificadores únicos (ID Generator)

Este módulo o servicio es utilizado por el gestor de paquetes para obtener identificadores globalmente únicos.

• Gestor de almacenamiento (Storage Manager)

Actúa como un disco duro virtual. Almacena los contenidos de iArxiu, es decir, almacena los paquetes y binarios sin tener en cuenta ninguna consideración especial iArxiu.

Componentes o servicios externos

Estos servicios o componentes no forman parte directamente del Core iArxiu, sino que interactúan con servicios externos a modo de conectores.

Estos servicios son:

• PSIS

Plataforma del Consorci AOC relacionado con validación y creación de firmas digitales y certificados digitales.

• Servicio antivirus

El Core iArxiu interactúa con servicios antivirus. Concretamente interactúa con un servidor antivirus llamado ClamAV.

• Registro de ContentTypes (DROID)

DROID es un servicio público de registro de ContentTypes o formatos tecnológicos.

• Extracción de metadatos (JHOVE)

JHOVE es un componente que analiza binarios y detecta en algunos tipos el formato, permitiendo extraer en estos casos información relativa al binario (metadatos)

• Repositorio Local de Usuarios

Sistema donde se almacena la lista de usuarios (aplicaciones) reconocidos por el sistema y sus atribuciones. Una parte de este repositorio lo forma el repositorio de confianza mediante el que determinadas aplicaciones se consideran de confianza y sus certificados no se validan contra PSIS a fin de mejorar el rendimiento.

• OpenOffice

Se utilizará un conector con un servicio OpenOffice para gestionar las migraciones de formatos de los binarios.

Web de referencia

Authentication

Authorization

RefWeb Administration

Query

Core Administration

La Web de Referencia es un cliente del Core. Su diagrama de bloques es el siguiente:

Organization

Fonds

eaCAT

Local User Repository

WebAreas

PSIS

Organization Fonds Series

Folders

Preingest Area

Ingest

Dissemination

Administration

ClamAV

Web

Core

Preingest

La figura anterior muestra el diagrama de bloques de la Web de Referencia. En él se pueden distinguir los siguientes grupos:

Interfaz de usuario

La Web de Referencia interacciona directamente con los usuarios finales a través de navegadores web.

Los módulos que integran esta capa son:

1. Interfície Web únicamente mediante protocolo HTTPS.

a. Módulo de integración con el portal eaCAT.

2. Capa de Seguridad:

• Autenticación (Authentication)

• Autorización (Authorization)

Áreas de navegación

Funcionalmente la Web de Referencia está dividida en tres grandes áreas de actuación:

1. Preingreso (Preingest)

En esta área el usuario accede a la zona de preingreso y puede consultar la lista de paquetes y su estado de envío al Core.

2. Consulta (Query)

En esta área el usuario accede a las búsquedas y descargas de paquetes.

3. Administración (Administration)

En esta área se puede administrar el sistema. Está dividida en dos subáreas:

a. Administración de la Web de Referencia (RefWeb Administration) Administra los aspectos propios de la Web de Referencia:

I. Usuarios (Users)

II. Grupos (Rols)

III. Entes (Organizations)

IV. Fuentes (Fonds)

V. Series (Series)

VI. Gestión carpetas del área de preingreso

b. Administración del Core (Core Administration)

Componentes

Los componentes de la web de referencia:

1. Evaluador de reglas (PDP)

Concede derechos de acceso a un recurso. Es accedido únicamente por el módulo de autorización.

2. Gestores de entidades

Estos módulos gestionan las siguientes entidades:

x. Xxxx (Organization)

x. Xxxxxxx (Fonds)

c. Series (Series)

d. Carpetas (Folders)

3. Área de preingreso

Constituye el gran bloque de la Web de Referencia dado que no tiene una relación directa con el Core. Se constituye como un espacio de almacenamiento donde los usuarios (según los Entes y Fondo) depositan los paquetes antes de ser ingresados en el Core. Desde esta lista se puede consultar también el estado del envió.

Componentes o servicios externos

Los componentes accedidos desde la Web de Referencia son:

1. PSIS

Plataforma del Consorci AOC para la validación de certificados digitales y para la validación y creación de firmas digitales.

2. Repositorio Local de Usuarios

Sistema donde se almacenan los usuarios y grupos de la aplicación.

3. Servicio Antivirus

La Web de Referencia aplica validación de antivirus los binarios. Existirá un servicio externo destinado a la validación antivirus. Este servicio es el mismo que usa el Core y se llama ClamAV.

4. Core

El Core iArxiu.

Arquitectura lógica

Internet

PSIS

Actualitzacions

DROID Definició Content Types

iArxiu

HTTPS

Actualització Definició Virus

Aplicació Client

WS - SOAP / HTTP

TCP / Socket

Antivirus ClamAV

SQLNET

HTTP

Usuari

WS – SOAP / HTTP

BBDD CORE

File System

Usuari Traspàs Identitat

SQLNET

HTTPS

EACAT

BBDD

Web File System Referencia

TCP / Socket

PSIS

Servlet Web Referència

(JBOSS)

Web Server Apache

Servlet CORE (JBOSS)

Web Server Apache

Este apartado describe los componentes principales de iArxiu y sus interacciones a nivel de flujo de comunicaciones e interfaces.

La figura anterior indica los componentes de la arquitectura lógica:

1- Web Servers Apache: Se encargarán de establecer el canal seguro HTTPS con las aplicaciones cliente que accederán a iArxiu vía web Services (Core), y con los navegadores web de los usuarios que acceden a la interfaz web de iArxiu (Web de Referencia). La autenticación y autorización se hará a los servidores de aplicaciones.

2- Servlet Core y servlet Web de Referencia: Se ejecutarán sobre servidores de aplicaciones JBOSS. La división entre uno y otro se ha hecho de forma que 'Web de Referencia' es un cliente más de los que se pueden integrar para acceder a los servicios que ofrece el 'Core'. 'Web de Referencia' está pensado para ser usado por los clientes del Consorcio AOC que no

necesiten desarrollar un cliente propio. El 'Core' dará servicio a cualquier cliente, tanto el desarrollado dentro de este proyecto como cualquier otro en forma de aplicación cliente WS que un cliente final del Consorcio AOC quiera integrar.

3- Almacenamiento en File System y Base de Datos:

a. La ‘Web de Referencia’ guardará la información siguiente:

i. Base de Datos: Paquetes del área de preingreso e información para la administración de los usuarios.

ii. File System: Logs.

b. El ‘Core’ guardará la información siguiente:

i. File System: Paquetes PIA. Estructurados como una carpeta por paquete que contendrá:

1. Un archivo XML de descripción del paquete en formato METS (estructura, metadatos, etc.)

2. Los binarios que contiene también como archivos individuales.

ii. Base de Datos: Se guardarán el listado de paquetes y sus metadatos, replicando el contenido de los paquetes que ya están en FS. La funcionalidad que proporciona es un acceso eficiente a los metadatos para hacer consultas desde un usuario final (como humano o aplicación cliente) o aplicar las operaciones de gestión de los PIA.

iii. Como se describe en apartados posteriores, esta arquitectura permite la gestión y acceso eficiente a los paquetes (Oracle) y soportar un crecimiento considerable manteniendo la facilidad de manipulación de paquetes individuales (File System).

4- Antivirus: Durante el proceso de validación de los paquetes PIC se llamará a un antivirus. Será ClamAV. Habrá una instancia instalada localmente en cada servidor con JBOSS por rendimiento y simplicidad de administración.

5- DROID: Permite identificar tipos de archivos conocidos según la especificación de PRONOMBRE. Se ejecutará localmente en cada servidor JBOSS como librería.

6- Interfícies externas:

a. PSIS: Será llamado para validar firmas, extraer información, sellar paquetes, etc. El mecanismo será mediante llamadas WS.

b. EACAT: iArxiu estará integrado con un link invocable con un botón en la web de EACAT.

c. DROID: Se conectará a Internet para bajar la actualización de los archivos de firmas de tipos de archivos registrados en PRONOMBRE vía web Services.

d. ClamAV: Conexión a Internet para poder actualizar la base de datos de virus soportados.

7- Flujo de comunicaciones entre componentes:

a. Aplicaciones Cliente 🡪 Web Servers Apache : HTTPS, para enviar mensajes sobre SOAP.

b. Web Servers Apache con peticiones Aplicacions Client 🡪 JBOSS Core: HTTP, para pasar los mensajes sobre SOAP.

c. Usuarios Clientes desde sus navegadores web 🡪 Web Servers Apache: HTTPS.

d. Web Servers Apache con peticiones Usuarios Cliente 🡪 JBOSS Web Referencia: HTTP.

e. JBOSS Web. Ref 🡪 JBOSS Core: HTTP para enviar mensajes WS sobre SOAP.

f. JBOSS Web Ref / Core 🡪 PSIS: HTTPS para enviar mensajes WS sobre SOAP.

g. JBOSS Web Ref. / Core 🡪 ClamAV: Socket TCP con Puerto configurable.

h. DROID 🡪 Internet: WS sobre HTTP.

i. ClamAV 🡪 Internet: HTTP.

Lenguaje de programación

La aplicación iArxiu está desarrollada, principalmente, en J2EE (Java 2 Platform Enterprise Edition), y por tanto hecha y ejecutada en software escrito en lenguaje Java en una arquitectura distribuida en niveles y basada en componentes de software.

La aplicación está diseñada para operar en varias capas lógicas. Estas son:

• Capa web: entorno con funciones de frontal web e interfaz de usuario.

• Capa de aplicación: entorno con funciones de servidor de aplicaciones donde se ejecuta toda la lógica de negocio.

• Capa datos: las propias bases de datos de la aplicación y File System.

Documentación del servicio

El adjudicatario de este contrato dispondrá de toda la documentación relacionada con la aplicación que sea necesaria para la prestación del servicio objeto de este contrato.

A continuación se enumeran los principales documentos:

• Documentos de análisis funcional

• Diagrama de bloques

• Especificaciones técnicas servicios web

• Guía integración de clientes

• Documento de arquitectura del software

• Código fuente de la aplicación

• Manuales de usuario

• Documentación de instalación

• Documentación de monitorización interna / externa

Document Metadata

Table of Contents

Contract

Document Metadata