D andoni...

II ENCUENTRO NACIONAL SOBRE FIRMA Y

ADMINISTRACION ELECTRONICA

OPTIMIZACION DE LA CALIDAD DE SERVICIO Y LA EXPERIENCIA DE USUARIO

EN LOS SERVICIOS DE FIRMA Y AUTENTICACION EN LA IGAE

- José Ignacio Gómez Raya

- Andoni Pérez de Lema Sáenz de Viguera

IGAE

INDICE

1. ¿QUE ES SGIFE?

2. PROCESO DE FIRMA Y ALMACENAMIENTO

3. PROBLEMAS DETECTADOS EN LA PLATAFORMA DE FIRMA

4. SOLUCION 1 : ALMACENAMIENTO CON EXPANSION ASINCRONA DE FIRMAS

5. SOLUCION 2 : CACHEO DE RESPUESTAS DE VERIFICACION DE CERTIFICADOS

6. SOLUCION 3: SERVIDOR DE VALIDACION

7. SOLUCION 4 : OPTIMIZACION DE LOS PROCESOS DE BACKUP Y

ALMACENAMIENTO

8. SOLUCION 5 : OPTIMIZACION DEL ACTO DE LA FIRMA DEL USUARIO

(DOCELWEB)

¿QUE ES SGIFE?

Sistema común de funcionalidades de firma electrónica y de almacenamiento de la

información documental empleado en la Administración Presupuestaria.

Proporciona los servicios corporativos para los sistemas que requieran firma electrónica y

almacenamiento y custodia de documentos firmados (y no firmados), en colaboración con otras

plataformas generales de servicios de firma electrónica, como @FIRMA de la Secretaría de

Estado de Administraciones Públicas y la plataforma de la FNMT-RCM.

El sistema SGIFE proporciona las siguientes funcionalidades :

- Repositorio documental o sistema de gestión documental, en el que los documentos

electrónicos se almacenan como ficheros XML con firma electrónica, con capacidades de

generación de copias auténticas.

- Conjunto de servicios corporativos asociados a la firma electrónica : obtención de la

información vinculada a las firmas de un documento, generación de firma, validación,

resellado, firma longeva.

- Visor de documentos electrónicos para las sedes electrónicas.

¿QUE ES SGIFE?

Arquitectura distribuida multicapa sobre Servicios Web : la lógica de firma y almacenamiento está

fundamentalmente implementada en una plataforma central, que actúa de proveedor para todas las

aplicaciones cliente. Además, se distribuyen, mediante un applet, algunas operaciones al cliente web del

usuario (como las que requieren acceso a claves privadas de certificado).

¿QUE ES SGIFE?

1. La plataforma SGIFE consta de :

1. Núcleo SGIFE instalado en servidores dedicados y accesible mediante WS.

2. Módulo cliente JAVA o .NET, que presenta una API para su utilización con los servidores de

aplicaciones que se integran con SGIFE.

3. Servidores dedicados a lanzar el proceso asíncrono de expansión desatendida de firmas a formato

longevo.

4. Base de Datos ORACLE para almacenamiento de documentos firmados.

5. Applet descargable desde el navegador de un usuario que desea firmar con SGIFE. Dos

posibilidades :

1. Applet ligero : permite seleccionar un certificado y hacer firmas XADES en local

2. Applet extraligero : sólo permite seleccionar un certificado y cifrar el hash en local (firma en 3

fases).

6. Servidor de validación de certificados, con balanceo de carga entre PSC (@Firma y FNMT).

7. Servidores dedicados a la generación de copias auténticas.

8. Servidores dedicados a la validación y cacheo de certificados

2. Actualmente permite realizar firmas XADES Enveloped e Internally Detached.

3. Se están realizando los desarrollos necesarios para poder generar documentos y expedientes electrónicos

de acuerdo al Esquema Nacional de Interoperabilidad.

INDICE

1. ¿QUE ES SGIFE?







ALMACENAMIENTO


(DOCELWEB)

PROCESO DE FIRMA Y ALMACENAMIENTO

El objetivo de este de documento es ofrecer una visión de cómo ha ido evolucionando el proceso de firma y almacenamiento en SGIFE. Ha habido tres avances fundamentalmente :

1.- La firma (generación del XAdES) se realiza, mediante el applet, íntegramente en el PC del cliente, y a continuación se llama al servicio “almacenar” de SGIFE.

2.- En el PC del cliente tan sólo se realiza el cifrado del hash del <SignedInfo> con la clave privada del certificado. La aplicación cliente de SGIFE se encarga de generar el esqueleto de firma (XAdES) y de componerlo con el hash firmado. A continuación se llama al servicio “almacenar” de SGIFE.

3.- El documento a firmar está previamente almacenado en SGIFE. La aplicación cliente proporciona a SGIFE el id del documento a firmar y el certificado. SGIFE genera el esqueleto, lo guarda y devuelve tan solo la cadena a firmar. En el PC cliente se cifra el hash, y la aplicación se lo devuelve a SGIFE para que componga la firma y la almacene.


FIRMA Y ALMACENAMIENTO

CON EL APPLET LIGERO :


FIRMA Y ALMACENAMIENTO CON EL APPLET EXTRALIGERO (TRES FASES CLÁSICA)


FIRMA Y ALMACENAMIENTO CON EL APPLET EXTRALIGERO (TRES FASES NUEVA)

INDICE

1. ¿QUE ES SGIFE?







ALMACENAMIENTO


(DOCELWEB)

PROBLEMAS DETECTADOS EN LA PLATAFORMA DE FIRMA

SITUACION INICIAL : expansión síncrona de firmas.

Debido a la necesidad de interactuar con PSC (@Firma y FNMT) para obtener servicios externos (como respuestas OCSP o servicios web que proporcionan la estructura de los certificados), las siguientes operaciones implicaban en algunos casos unos tiempos de respuesta inaceptables :

– Expandir firmas a formatos longevos.

– Validar certificados.

Ejemplo : cuando se recibía un documento firmado con 3 firmas en XADES-BES, y se realizaba una llamada por servicio Web a SGIFE para solicitar el almacenamiento del documento firmado (que requiere la verificación de la firma y su expansión) había que realizar:

– 3 llamadas a @Firma para validar los certificados, y tres operaciones en local para validar la integridad de las firmas.

– Inserción de sello o marca de tiempo para ampliar a XADES-T

– 12 llamadas OCSP (caso mejor, cadena de validación con sólo 2 certificados) :

1. OCSP Certificado firmante

2. OCSP Certificado raíz de la cadena del certificado firmante

3. OCSP Certificado de marca de tiempo de SGIFE

4. OCSP Certificado raíz de la cadena del certificado firmante

Las 6 llamadas correspondientes a OCSP Certificado Raíz (casos 2 y 4) podrían reducirse a 1.

En aras de minimizar el tiempo de respuesta al máximo, se puede ampliar el documento de manera asíncrona a la petición del cliente, y validar en local los certificados.

X 3

PROBLEMAS DETECTADOS EN LA PLATAFORMA DE FIRMA

DESCOMPOSICION DEL PROCESO DE ALMACENAMIENTO Y AMPLIACION DE FIRMA :

1. Validación integridad y estructura del documento.

2. Llamadas externas a @Firma para verificar cada certificado correspondiente a una firma

3. Fin validación del documento -> respuesta on-line al usuario.

4. Inicio de la ampliación a firma longeva en modo off-line.

5. Inserción de sello de tiempo para ampliar a XADES-T.

6. Obtención de respuestas OCSP

7. Ampliación sucesiva a XADES-C, XADES-X, XADES-XL y XADES-A.

CONCLUSIONES DEL ESTUDIO DE TIEMPOS POR ETAPAS DEL PROCESO :

A. Las acciones que consumen más tiempo son las llamadas externas que hay que realizar para validar y ampliar el documento.

B. La validación se puede optimizar con descargas de CRL’s en local y cacheo de respuestas OCSP.

C. El problema fundamental está en la ampliación de las firmas, que requiere un número elevado de llamadas OCSP.

– Para evitar estas múltiples llamadas se pueden cachear las respuestas OCSP. Comprobamos si la verificación de un certificado está cacheada, y si la fecha de la respuesta OCSP es superior a la de la firma, usamos la respuesta cacheada.

INDICE

1. ¿QUE ES SGIFE?






ALMACENAMIENTO


(DOCELWEB)

SOLUCION 1 : ALMACENAMIENTO CON EXPANSION ASINCRONA DE FIRMAS

En el modo de almacenamiento síncrono, después de firmar un documento, SGIFE lo almacena validándolo, es decir comprobando la validez de los certificados y la integridad de la firma. A continuación se produce la ampliación del de la firma a formato XAdES-A. Una vez concluida la ampliación de la firma, SGIFE devuelve la respuesta a la aplicación.

– Esta operativa daba lugar a tiempos de respuesta inaceptables, y ello exigía mejorar la experiencia de usuario.

ALMACENAMIENTO CON EXPANSION ASINCRONA :

Con el fin de mejorar el tiempo de respuesta a los usuarios, se implantó en SGIFE una nueva funcionalidad, que permite configurar por sistema de información si la expansión de las firmas a formato longevo se realizará en background (almacenamiento asíncrono) o bien en foreground.

El almacenamiento asíncrono consiste en que a la hora de almacenar un documento firmado en SGIFE, éste se guarda en un formato básico de firma (XAdES BES), consiguiendo de esta manera que la respuesta al cliente sea rápida, ya que se ahorran todas las llamadas al OCSP Responder del Prestador de Servicios de Certificación. Una vez almacenado en BES, hay un proceso asíncrono que se ejecuta cada dos minutos y que completa el documento ampliándolo hasta XAdES-A.

– La frecuencia de este proceso se configura mediante un parámetro en el fichero de configuración CA_new.ini:

[FRECUENCIA_BATCH_COMPLETO]

Valor=120 (en segundos)

Si algún documento no pudiera ser completado, el proceso asíncrono envía un email de notificación a las direcciones de correo asociadas al sistema de información al que pertenezca el documento.


ESQUEMA DEL PROCESO DE ALMACENAMIENTO CON EXPANSION ASINCRONA DE FIRMAS :


VENTAJAS :

Se obtiene un tiempo de respuesta reducido y prácticamente constante, con independencia del número de firmas del documento, lo que asegura una experiencia de usuario satisfactoria en cualquier circunstancia.

El funcionamiento del modo de almacenamiento asíncrono es completamente transparente para la aplicación, que no tendrá que cambiar en nada su interacción con SGIFE si decide pasar a este modo de funcionamiento

Potencial desventaja : si se produce un error que haga que la operación de expansión no termine correctamente (por ejemplo, a causa de la revocación de un certificado), la aplicación usuaria de SGIFE habría dado por correcta una operación que no lo ha sido finalmente.

Para atenuar el impacto, si en el caso de algún documento no pudiera ser completada su expansión a formato longevo, el proceso asíncrono enviará un email de notificación a las direcciones configuradas en la tabla “contactos” de la base de datos de SGIFE que estén asociadas al sistema de información al que pertenezca tal documento.

– Esas personas tomarán la iniciativa que corresponda para subsanar el problema.


FUNCIONAMIENTO COMPARADO :

Proceso Modelo normal Modelo

asíncrono

Online Batch

Guardar documento

firmado (XL):

1.- Comprueba el token contra tokenser x

2.- Se valida que el documento cumpla el esquema XAdES y la integridad de la firma. x

3.- Se comprueba contra @firma la fecha y la validez del certificado de firma. x

4.- Se obtienen los CN de los firmantes del documento para almacenarlo en BBDD. x

5.- Almacena el documento en la tabla AlmacenDocs x

6.- Obtenemos el documento original de la firma para su conversión a PDF. x

7.- Guarda el documento en la tabla FaroConversionPdf para su conversión a PDF. x

8.- Se amplia el documento a XAdES T usando el "timestamp" de sgife o externo. x

9.- Obtenemos la dirección OCSP del CA_new.ini y comprobamos que el certificado no aparece como revocado en la respuesta. x

10.- Hacemos lo mismo con el certificado de timestamp. Llamamos al OCSP Responder y comprobamos que no está revocado. x

11.- Ampliamos el documento a XL, añadiendo los certificados y las respuestas OCSP. x

12.- Almacena el documento en XL en la tabla AlmacenDocs x


FUNCIONAMIENTO COMPARADO (2) :

Proceso Modelo normal Modelo

asíncrono

Online Batch

Archivar

documento (A) :

1.- Comprueba el token contra tokenser x

2.- Se valida que el documento cumpla el esquema XAdES y la integridad de la firma. x

3.- Se comprueba contra @firma la fecha y la validez del certificado de firma. x

4.- Se obtienen los CN de los firmantes del documento para almacenarlo en BBDD. x

5.- Almacena el documento en la tabla AlmacenDocs x

6.- Obtenemos el documento original de la firma para su conversión a PDF. x

7.- Guarda el documento en la tabla FaroConversionPdf para su conversión a PDF. x

8.- Se amplía el documento a XAdES T usando el "timestamp" de sgife o externo. x

9.- Obtenemos la dirección OCSP del CA_new.ini y comprobamos que el certificado no aparece como revocado en la respuesta. x

10.- Hacemos lo mismo con el certificado de timestamp. Llamamos al OCSP Responder y comprobamos que no está revocado. x

11.- Ampliamos el documento a XL, añadiendo los certificados y las respuestas OCSP. x

12.- Ampliamos el documento a XAdES A, añadiendo el elemento ArchiveTimeStamp y usando de nuevo del certificado de sellado de

tiempo de SGIFE.

x

13.- Almacena el documento en A en la tabla AlmacenDocs x

INDICE

1. ¿QUE ES SGIFE?






ALMACENAMIENTO


(DOCELWEB)

SOLUCION 2 : CACHEO DE RESPUESTAS DE VERIFICACION DE CERTIFICADOS

Con vistas a la mejora de los tiempos de respuesta en procesos de firma electrónica, SGIFE ha implementado como opción una funcionalidad de cacheo de certificados electrónicos. Esta funcionalidad es complementaria a la de “almacenamiento asíncrono”, ya que ambas persiguen obtener una mejor sensación por parte de los usuarios en el momento de la firma en las aplicaciones.

FUNCIONAMIENTO DEL CACHEO DE RESPUESTAS DE VERIFICACION DE CERTIFICADOS :

1. El uso de CRL’s - en lugar de respuestas OCSP- permite realizar una validación local, reduciendo así drásticamente el tiempo de repuesta.

2. Con este fin, la FNMT nos transmite 4 veces al día por FTP-s las CRL’s que contienen sus certificados que hayan sido revocados, en formato LDIF (formato de texto ASCII para entradas LDAP).

3. Para conseguir tolerancia a fallos, las CRL’s se envían simultáneamente a 4 servidores dedicados a almacenar CRL’s, integrados con SGIFE :

o 2 servidores redundantes conectados a la red SARA

o 2 servidores redundantes conectados a Internet

4. SGIFE realiza la extracción de la información contenida en los ficheros LDIF a tablas de ORACLE y SQL Server (tablas de certificados revocados).


5. Cada vez que se solicita la validación de un certificado electrónico al Servidor de Validación de SGIFE, éste almacena en una caché las respuestas de validación obtenidas de los Prestadores de Servicios de Certificación.

6. A las 0:00 horas de cada día, un proceso borra automáticamente de la caché aquellos certificados que no están cubiertos por las CRL’s de la FNMT (es decir, los certificados que no sean de estos tipos : clase 2CA, APE 1 o APE 2).

7. Cuando el Servidor de validación reciba una petición de validación de un certificado por parte de un sistema de información que tenga activado el cacheo de certificados, hará estas acciones :

A. Extraer los campos “Entidad Emisora” y “Número de Serie” del certificado.

B. Ejecutar el flujo de acciones que se representa a continuación, dependiendo del tipo de certificado.


Certificados Clase 2CA, * Resto de certificados reconocidos

APE1 y APE2


En la siguiente gráfica se muestra la arquitectura del sistema de cacheo de certificados :

INDICE

1. ¿QUE ES SGIFE?






ALMACENAMIENTO


(DOCELWEB)

SOLUCION 3 : SERVIDOR DE VALIDACION

Para minimizar los tiempos de indisponibilidad de servicio en las aplicaciones corporativas que requieran firma electrónica o autenticación, es preciso maximizar la resiliencia en el manejo de certificados.

Esto se consigue mediante el aprovechamiento de las posibilidades de backup que ofrece la FNMT como proveedor de servicios alternativo a @Firma, ya que proporciona un web service análogo en su comportamiento.

Los objetivos de esta solución son :

Incluir el servicio de la FNMT como respaldo de @Firma, en un paradigma de interoperabilidad “activo a activo” con el servicio de @firma, haciendo partícipes a los sistemas de información corporativos de las optimizaciones que se derivan de dicha implementación.

Introducir políticas de uso de firma en función del sistema de información que demande tales servicios.

Habilitar una consola para manejar con mayor comodidad los parámetros, y propiciar una mayor rapidez de reacción ante una situación adversa (por ejemplo, problemas en un nodo de interoperabilidad).

Mejorar el tiempo de respuesta de SGIFE, proporcionando unos métodos de servicios web que permitan parametrizar la activación del cacheo de certificados a nivel de un sistema de información concreto.


IMPLEMENTACION TECNICA :

1. Se opta por la decisión de duplicar los end-points de acceso a @Firma (diferenciando autenticación por usuario y contraseña y autenticación con certificado), para poder tener más flexibilidad en el servicio, por los siguientes motivos :

– Restricciones de la plataforma @firma, que sólo permite una modalidad de acceso por servicio cliente : WS-Security con usuario y contraseña, o bien WS-Security con certificado.

– Disponer de la posibilidad de un protocolo menos pesado : WS-SECURITY con usuario y contraseña es más rápido que WS-SECURITY basado en autenticación con certificado

– Posibilidad de acceso por un medio alternativo al caducar un certificado.

2. Con el fin de mejorar respaldo e incrementar el rendimiento de los accesos, se implementó un nuevo servicio web, apoyado en los servicios de autenticación y firma de la FNMT, que requieren acceso por protocolo SOAP con autenticación basada en usuario y contraseña

3. Se implementan nuevos servicios de acceso a @Firma o bien a la FNMT, que incorporan la posibilidad de cacheo referente a la validación, ya sea mediante usuario-contraseña o con certificado.

4. Se crean parámetros alojados en las bases de datos de SGIFE, que permiten configurar el reparto de peticiones entre los servicios comunes de acceso a @Firma y el nuevo servicio de la FNMT


IMPLEMENTACION TECNICA :

5. Se desarrolló una consola que permite modificar manualmente todos los parámetros, sin necesidad de recurrir a los servicios técnicos de soporte de BB.DD., servidores de aplicación, etc.

6. Para cubrir la eventualidad de un fallo en el servicio coordinador, se implementa un script de monitorización en NAGIOS, que modifica los parámetros alojados en base de datos en caso de caída del servicio.

7. Se dispone de máquinas HSM (principal y respaldo) para la custodia de los certificados que usan los servicios para establecer la conexión a los WSS de @firma.


RELACION DE NUEVOS SERVICIOS WEB :

WSValidaCert es un servicio coordinador que implementa la orquestación necesaria para facilitar el balanceo de carga entre @Firma y la FMNT, e incrementar la disponibilidad.


BENEFICIOS DE LA SOLUCION :

Disponer de la posibilidad de cacheo en la validación de certificados, permite reducir el tiempo de respuesta de las aplicaciones y los costes de comunicaciones.

Esta solución incrementa la escalabilidad de las aplicaciones de la Administración Presupuestaria, al mejorar su capacidad para soportar picos de demanda.

Se obtienen las mejores posibilidades de respaldo, al contar con el servicio de la FNMT. Esta estrategia se enmarca en el concepto de Gestión de la demanda, que persigue optimizar y racionalizar el uso de los recursos TI, subsanando las degradaciones del servicio por aumentos no previstos de la demanda, o las interrupciones parciales del servicio por errores de hardware o software.

Registro o log detallado de la actividad de los usuarios.

INDICE

1. ¿QUE ES SGIFE?






ALMACENAMIENTO


(DOCELWEB)

SOLUCION 4 : OPTIMIZACION DE LOS PROCESOS DE BACKUP Y ALMACENAMIENTO

- En el período 2007-2013 se ha experimentado un crecimiento exponencial del espacio de almacenamiento dedicado a documentos electrónicos.

- Ante este estado, es necesario definir un plan de acción que permita optimizar el espacio consumido y hacer que las tablas sean inmodificables (sólo de lectura), lo que tendría además como beneficios añadidos:

1. la reducción de la duración de los backups a valores moderados y controlables.

2. la disminución del tiempo de restauración de la Base de Datos en caso de emergencia.

3. la mejora del acceso a los documentos, para mayor rapidez y seguridad.

SITUACION INICIAL :

- El servicio SGIFE consta de dos tablas principales :

- ALMACENDOCS, en la que las aplicaciones gestoras guardan los documentos originales, que pueden estar firmados por los usuarios o no.

- FAROCONVERSION, en la que se almacenan: los documentos originales sin firmar, y las copias electrónicas PDF con firma longeva XADES-A.

• En SGIFE, cuando un documento es modificado por una aplicación, se debe anular la versión anterior y crear otro nuevo documento. Los documentos anulados nunca se eliminan físicamente del repositorio documental.


• DESCRIPCION SOLUCION TECNICA PARA LA OPTIMIZACION :

1. Mediante un rediseño de la base de datos basado en el particionamiento se obtiene de manera automática una división de las tablas de la base de datos en distintas tablas físicas independientes, atendiendo al año en el que hayan entrado los documentos.

• Las tablas particionadas son una buena opción para las tablas que contengan un elevado volumen de registros, y permiten mejorar el rendimiento en los accesos mediante una reducción de la cantidad de lecturas físicas.

• Asimismo, las tablas particionadas permiten establecer un mantenimiento diferenciado con configuraciones específicas, como señalar que una partición es de “sólo lectura”.

• El particionamiento constituye la base de una estrategia de alta disponibilidad, ya que si una partición no está disponible, todas las demás particiones de la tabla permanecen en línea.

• Permite establecer una arquitectura de data protection (protección de datos), o backup-almacenamiento, acorde con la utilidad de los datos/documentos.



2. Tabla ALMACENDOCS :

• Se estableció esta tabla como de “Solo Lectura”, lo que permite realizar únicamente backups de la partición correspondiente al período en curso. Para que esta tabla pueda configurarse como de sólo lectura, es necesario extraer parte de los datos relacionados con la anulación a una tabla aparte.

• Denominamos a dicha tabla DOCSELIMINADOS, que contendrá como campos: el identificador del documento, el motivo de anulación, y un campo nuevo fechaactualizacion. Sólo se insertará un registro en la tabla DOCSELIMINADOS cuando se elimine un documento, minimizando así el espacio de almacenamiento requerido.

• ALMACENDOCS contenía inicialmente un Blob con los esqueletos de firma que se pregeneran y conservan temporalmente, con la finalidad de hacer más rápida la firma de los usuarios.

• Se creó una tabla separada denonimada “ESQUELETOS”, con tres campos: el Identificador del documento, un campo con el contenido del elemento esqueletosfirma, y otro campo con la fecha de actualización. En la tabla ESQUELETOS se borrarán automáticamente los registros que tengan más de una semana de antigüedad.

• Cuando sea necesario resellar los documentos de ALMACENDOCS correspondientes a un año específico, se declarará transitoriamente como de “Lectura y Escritura” la partición correspondiente, hasta que se complete el resellado, y después se volverá a configurar la partición en “Sólo Lectura”.


2. Tabla ALMACENDOCS :



3. Tabla FAROCONVERSION :

• Se decidió la eliminación de los documentos originales sin firmar de la tabla FAROCONVERSION, que almacenará exclusivamente los documentos copia PDF-A con firma longeva XADES-A. De esta manera, se consigue el correspondiente ahorro en espacio de almacenamiento.

• Con el objeto de reducir el impacto de las copias de seguridad, se decidió :

• Presentación de un mensaje que indique que un documento ha sido anulado cuando un usuario lo verifique en la sede electrónica, sin realizar ninguna modificación en el PDF que es una copia del original (como una marca de agua “ANULADO”). Así, al hacer que los documentos de SGIFE sean inmodificables, se consigue :

• ahorrar espacio de almacenamiento, así como el proceso necesario para generar otro documento.

• En la tabla central de FAROCONVERSION no se modificarán nunca los blobs, con lo cual podrá declararse como una tabla de “Solo Lectura”, y particionarla por años o meses.

• sólo será necesario efectuar copias de seguridad de la partición correspondiente al último período.

INDICE

1. ¿QUE ES SGIFE?






ALMACENAMIENTO


(DOCELWEB)

SOLUCION 5 : OPTIMIZACION DEL ACTO DE LA FIRMA DEL USUARIO (DOCELWEB)

DocelWeb es un portafirmas electrónico bajo arquitectura web concebido como herramienta

corporativa a disposición de todos los usuarios internos de la Administración

presupuestaria, y también de aquellos otros usuarios externos que lo requieran a efectos de

la documentación tramitada por aplicaciones de la Administración presupuestaria.

Este portafirmas puede recibir solicitudes de firma procedentes de aplicaciones de la

Administración presupuestaria o del propio usuario del portafirmas. Cada solicitud de firma

puede comprender uno o varios documentos, al menos uno de ellos objeto de firma.

DocelWeb dispone de servicios web para la interconexión con :

– otros sistemas de información que requieran funcionalidades de firma electrónica. O

– tros sistemas de portafirmas externos a la administración presupuestaria que requieran

funcionalidades de firma electrónica.

DOCELWEB TIENE ENTIDAD SUFICIENTE PARA CONSTITUIR UNA PONENCIA

COMPLETA PERO AQUÍ SOLO RELATAMOS EL BENEFICIO EN LA EXPERIENCIA DE

USUARIO EN EL ACTO FISICO DE LA FIRMA


Para la solicitud de firma desde una aplicación de la Administración presupuestaria se han

desarrollado servicios web para envío de las solicitudes de firma y descarga de las

respuestas, una vez revisados o firmados los documentos correspondientes a la solicitud, y

han sido puestos a disposición de las aplicaciones..

Cuando es un usuario del portafirmas quien desea efectuar la solicitud de firma, DocelWeb

dispone de una opción para que el usuario prepare la solicitud con los ficheros que

corresponda.

Tienen especial interés dos prestaciones incorporadas a DocelWeb: la posibilidad de

generación del PDF/A de documento firmado, con código electrónico y URL de verificación,

como posible copia auténtica del documento electrónico (si se cumplan las condiciones

establecidas en el Real decreto 1671/2009 y en el ENI); y la posibilidad de que el

portafirmas admita solicitudes de firma con documentos estructurados en varios niveles de

agregación (carpetas).

El portafirmas DocelWeb utiliza los servicios de firma y de almacenamiento y custodia de

documentos, proporcionados por la plataforma corporativa de firma electrónica (SGIFE).


Muchos sistemas de información corporativos han delegado la funcionalidad de la firma en

DOCELWEB, sustituyendo las llamadas a funciones de firma por llamadas a los servicios

web de Docelweb.

Docelweb es una aplicación Web muy intuitiva y facil de usar, disponiendo de una gran

eficiencia en la firma de arrays de documentos, incluso estructurados en carpetas, con

posibilidad de generar en línea PDF-A de documento firmado, con código electrónico y URL

de verificación.

– Estas cualidades han contribuido a que la estrategia de entrar a una única aplicación

para firmar haya sido bien aceptada por los usuarios VIP, que como es obvio son los

que más firman.

Se ha observado un aumento importante del nivel de satisfacción de usuario , después de

todas las optimizaciones conseguidas al unificar el acto de firma en una única aplicación,

para realizar la firma de todas las solicitudes pendientes por parte del usuario en un único

acto.

D andoni...

Technology

Transcript of D andoni...