accesskey_mod_content

@Firma

@firma es la solución tecnológica en la que se basa la Plataforma de validación y firma electrónica del Ministerio. La versión actual de @firma es la 6.1 y constituye una evolución de la versión 4.0 a partir de la aportación de múltiples Organismos Públicos cooperantes.

@firma es un producto robusto e integral, desarrollada inicialmente por la Junta de Andalucía, cedida al resto de las Administraciones Públicas con el objeto de fomentar y extender el desarrollo de la Administración Electrónica y la Sociedad de la Información.

Es una solución basada en software libre, estándares abiertos y en java: servidores web Apache, JBOSS, Sistema Operativo Solaris/Linux, AXIS, etc.

Los servicios proporcionados por Plataforma de validación de certificados y firma electrónica del Ministerio (@firma) se proporcionan a las Administraciones Públicas sin coste económico.

La forma más común de uso de @firma es modo servicio. Este modo consiste en que la plataforma @firma del Ministerio proporciona servicios de validación de certificados y firmas electrónicas a través de servicios web. Las aplicaciones que desean utilizar los servicios de @firma, se conectan mediante la red SARA a los servicios web de @firma del Ministerio. Es el modo recomendado para aquellos organismos con un volumen mensual de validaciones medio/bajo. El Ministerio proporciona una plataforma igual al a de producción para que los organismos que deseen usar los servicios de @firma realicen pruebas, y un servicio de soporte para gestionar las altas e integraciones.

Existe otro modo de uso de @firma, el modelo federado. Esta únicamente recomendado para aquellos organismos con un volumen de transacciones muy elevado. El Ministerio proporciona el software de @firma, para que el organismo lo instale y administre en sus dependencias. En este caso el despliegue, instalación y administración es responsabilidad del organismo. El Ministerio proporcionará actualizaciones y parches del software según se generen.

Puede consultar los servicios disponibles o el modelo federado a través de las FAQ correspondientes.

Puede encontrar toda la información sobre @firma en la iniciativa del PAE creada a tal efecto. En el área de descargas de dicha iniciativa pueden encontrar la documentación de los servicios así como los ejemplos de integración.

Para tener acceso a la documentación completa debe ser un usuario registrado en el portal PAE, así como acceder al portal mediante la Intranet Administrativa (Red SARA).

Se dispone de un equipo de soporte disponible para cooperar con los diferentes Organismos Públicos suministrando toda la información necesaria sobre el uso de los servicios así como para cooperar en las actividades de prueba e integración de los sistemas a los servicios de la Plataforma.

Este Centro de Atención es accesible SOLO PARA DESARROLLADORES DE APLICACIONES DE LAS ADMINISTRACIONES PUBLICAS. Para comunicar una incidencia o solicitud de soporte al Centro de Atención a Integradores y Desarrolladores (CAID) rellene el formulario Web de apertura de solicitudes de soporte técnico:
- Acceso al formulario

Horario de soporte: de Lunes a Jueves de 08:30 a 18:30 y viernes 08:30 a 15:00.

Mediante la suite de servicios de @firma, se ofrece también:

  • Un Cliente de Firma para la creación de firmas en local.
  • Un servicio de Sellado de Tiempo ( TS@ ).
  • Un componente para la integración de la firma en los flujos de trabajo organizativos ( Port@firmas ).
  • Un demostrador de los servicios de @firma: Validación de firmas y certificados digitales, creación de firmas digitales, etc.

Los servicios de @firma están disponibles de forma gratuita para aquellas Administraciones Públicas que lo soliciten. El servicio se proporciona a través de la red SARA (Intranet Administrativa), por lo que para poder utilizarlo es necesario estar conectado a dicha red.

Se han firmado convenios con todas las Comunidades Autónomas para permitir la utilización de los servicios de @firma a las aplicaciones de administraciones electrónicas de éstas que lo deseen. En el caso de las Entidades Locales, algunas Comunidades Autónomas incluyen en el convenio la posibilidad de acceder a los servicios de @firma a través de adhesiones.

Asimismo pueden utilizar el servicio las Universidades, a través de la CRUE y Red Iris.

El Ministerio proporciona un servicio de soporte como apoyo a la integración de las aplicaciones informáticas que vayan a hacer uso de los servicios de validación de @firma en los distintos Organismos Públicos. Dentro de este soporte, el Ministerio proporciona una plataforma de pruebas que pueden utilizar los Organismos Públicos durante la integración de sus aplicaciones.

Para la realización de pruebas con los servicios de validación de firma que provee el Ministerio, no es necesaria la realización de ningún acto de compromiso por parte de ninguna de las partes, y sin ningún coste.

Para poder realizar peticiones a los servicios proporcionados por la plataforma de validación, se han de cumplir los siguientes puntos:

  1. Uso de la Intranet Administrativa: Las peticiones sólo podrán realizarse desde máquinas conectadas a la Intranet Administrativa (Red SARA) y con permisos de acceso sobre la plataforma. Por ello deberán identificarse aquellas máquinas desde las que se vayan a realizar las pruebas y solicitar a soporte de @firma ( Acceso al formulario ) permiso de acceso a las IPs internas de dichas máquinas.
    Para ello se deberá cumplimentar el fichero correspondiente con la información de las mismas y enviarlo a soporte de @firma para su alta efectiva. Puede descargar el formulario de alta del área de descargas de la página web de @firma, en el portal de administración electrónica ( http://administracionelectronica.gob.es/ctt/afirma ). Para acceder a la documentación se necesita estar registrado en el portal y acceder al mismo desde la Intranet Administrativa (red SARA).
  2. Identificación de las aplicaciones: A fin de poder realizar un seguimiento de la actividad de las aplicaciones y la plataforma (tanto en pruebas como en producción), las peticiones deberán ser realizadas por aplicaciones identificadas en la plataforma mediante certificado o usuario y password en la Plataforma.
  3. Crear un cliente de Web Service: Una vez que se dispongan de permisos es necesario desarrollar un Cliente de Web Service para que realice la petición a los servicios publicados en la plataforma.
    Para desarrollar el Cliente Web Service, se proporciona a los integradores la descripción del servicio web de destino. Para ello, la plataforma especifica para cada Servicio Web (WS en adelante) el fichero WSDL que incluye la URL del WS, el mensaje de petición con el XML schema de entrada y el mensaje de respuesta devuelto por el servicio. Asimismo, también se proporciona información en el área de descargas de la página web de @firma, en el portal de administración electrónica ( http://administracionelectronica.gob.es/ctt/afirma ), en la zona restringida para usuarios registrados. Además de los WSDL Y XML se proporciona un kit de ejemplo de integración, tanto para plataformas Java como .NET.

Actualmente se han puesto a disposición de los usuarios de @firma varias listas de distribución a las que se pueden suscribir. A través de estas listas recibirán notificaciones referentes a cambios relevantes relacionados con el proyecto al que estén vinculadas (actualizaciones, intervenciones, etc).
Para más información, se ruega que se consulte la sección de Contacto de los diferentes proyectos (plataforma de firma @firma, Cliente de Firma, TS@…).

Para integrarse en @firma, es necesario seguir los pasos que se definen a continuación:

  1. Estar conectado a la red SARA.
  2. Ponerse en contacto con el servicio de soporte y facilitar sus datos de contacto.
  3. El equipo de soporte le informará de los prerrequisitos y le facilitará el formulario para el control de acceso que el organismo debe cumplimentar. Junto con la documentación de bienvenida, se facilitará el Manual de Programación de WS de @firma junto con las instrucciones técnicas necesarias para conectar las aplicaciones de los servicios de administración electrónica a la Plataforma @firma.
  4. El organismo debe conectar las aplicaciones de servicios de administración electrónica para acceder  a la Plataforma a través de servicios web implementados en tecnología Microsoft® o Java.
  5. Por último, para acceder a la totalidad de la documentación es necesario ser un usuario registrado, para ello, acceder a la página del PAE y darse de alta cómo usuario en el menú de la derecha: "Acceso a Usuarios" -> "Registrarse".

 

El ACL (Lista de Control de Acceso) es un modelo de solicitud de datos de acceso y utilización de los servicios de @firma (formulario en formato EXCEL). Contiene una serie de datos necesarios para realizar la integración del Organismo en la plataforma. A continuación, se explican los distintos campos del formulario:

• Instrucciones (Pestaña): Instrucciones para el rellenado del ACL.
• Aplicación (Pestaña): Los datos solicitados en esta pestaña se rellenarán si se utilizarán los servicios WS y/u OCSP de la plataforma @firma.
o Conjunto de datos "Datos a rellenar por sistemas" : Se debe indicar la IP desde la que se accederá a los servicios de @Firma y los datos de una persona de sistemas/comunicaciones con la que podamos contactar en caso de que se produjese algún problema de conexión.
o Conjunto de datos "Datos a rellenar por el Organismo" :
o Conjunto de datos "Entorno" : Señalar el entorno al que se desea acceder (Desarrollo, Producción o ambos).
o Conjunto de datos "Volumen de transacciones mensuales" : Indicar el número aproximado de transacciones que se realizarán por entorno en un mes.
o Conjunto de datos "Volumen de transacciones por minuto" : Indicar el número aproximado de transacciones que se realizarán por entorno en un minuto.
o Conjunto de datos "Aplicación" : Hay que indicar el nombre de la aplicación a dar de alta, una breve descripción de la aplicación y Organismo (Ministerio y Dirección General, Comunidad Autónoma o Entidad Local) para el que se está desarrollando la aplicación.Los datos de la persona responsable de la aplicación, con quien nos pondremos en contacto en caso notificaciones al respecto de la misma.Breve descripción de los servicios telemáticos que soportará la aplicación y URL donde se ubicará la misma.

o En caso de solicitar acceso a través de WS :
- Formato de la Firma de Respuesta.- Formato de firma con el que desea que la plataforma firme los mensajes de respuesta a sus peticiones de servicio.
- Método de autorización.- Método con el que autenticarán sus mensajes de petición de servicio a la plataforma @Firma. Se recomienda con certificado.

o En caso de solicitar acceso a través de OCSP :
- Parte pública del certificado firmante en formato Base64 (PEM). Las peticiones OCSP deben ir firmadas por lo que se deberá adjuntar la parte pública del certificado.

Existen dos entornos de explotación de la plataforma @firma: uno llamado de desarrollo, para la realización de pruebas por parte de los organismos, y uno de producción, que se corresponde con el entorno real de la plataforma. Ambos entornos son de similares características, con la salvedad que el de desarrollo se pone a disposición de los organismos para realizar las pruebas de integración de aplicaciones, no estando permitidas las pruebas en el entorno de producción.
La url de acceso a los servicios de la plataforma de desarrollo, desde dentro de la red interadministrativa (SARA) es:
http://des-afirma.redsara.es/afirmaws/services/ (WS)
https://des-afirma.redsara.es/afirmaws/services/ (WS modo Seguro)
La url de acceso a los servicios de la plataforma de producción, desde dentro de la red interadministrativa (SARA) es:
http://afirma.redsara.es/afirmaws/services/ (WS)
https://afirma.redsara.es/afirmaws/services/ (WS modo Seguro)
Las URL del servicio OCSP son:
http://des-afirma.redsara.es/servidorOcsp/servidorOCSP
http://afirma.redsara.es/servidorOcsp/servidorOCSP

Las solicitudes de servicio realizadas mediante servicios web (Web Services - WS) deben realizarse por los puertos 8080 ó 443. Las peticiones al servicio ValidarCertificado mediante OCSP se deben dirigir al puerto 80.

Puede obtener dicho documento (ACL_Nuevo.xls) en el "Área de descargas" de la iniciativa “ Plataforma de validación de firma electrónica @firma ” en el apartado "Plantilla alta IP y Aplicación".

El Modelo Federado de la plataforma @firma consiste en una copia del software de esta Plataforma, lista para ser instalada en el entorno del Organismo solicitante.

Para obtener este Modelo Federado, ha de ser remitida una solicitud al Soporte de la Plataforma ( Acceso al formulario ), desde donde se le indicarán los pasos a seguir.

Es posible validar mediante la plataforma @firma todos los certificados incluidos en el documento que pueden consultar en este link .

Como primer paso, se ha de comprobar que es un certificado soportado por el Ministerio de Industria, Tecnología y Comercio

https://sedeaplicaciones2.minetur.gob.es/prestadores/(Abre en nueva ventana)

y, en caso afirmativo, ha de ser solicitado al soporte de la plataforma @firma ( Acceso al formulario ).

Pueden encontrar el kit de certificados de prueba en el Área de Descargas del portal del PAE de la presente iniciativa.

Todos los certificados del kit se han generado por Autoridades de Certificación reales, aunque dichos certificados sean de prueba. No corresponden en ningún caso a entornos de prueba de los PSCs.

  • Servicios de validación de certificados:
    o Validación de certificados mediante WS: estándar DSS.
    o Validación de certificados WS básica.
    o Validación de certificados OCSP.
    o Obtención de información de un certificado
  • Servicios de validación de firmas:
    o Validación de firmas mediante WS: estándar DSS: incluye validación de firmas longevas.
    o Validación de firmas WS básica.
  • Servicio de Upgrade de firmas (mediante uso del servicio DSSAfirmaVerify).
  • Otros servicios deprecados. La plataforma ofrece otros servicios, cuyo uso y evolución estaestá siendo descontinuado, sustituyéndose por otros componentes de la Suite de productos de @firma. (Consulte la FAQ correspondiente a los servicios deprecados)

En estos momentos se dispone de varias alternativas a la hora de enviar peticiones autenticadas a la plataforma @firma, de acuerdo a este esquema:

  • Peticiones WS: Es necesario añadir una cabecera (
    ) al SOAP de la petición. En dicha cabecera ha de remitirse bien el usuario y el password configurados para la aplicación peticionaria, o la firma de la petición mediante un certificado digital configurado para esta aplicación.
  • Peticiones OCSP: Las peticiones han de remitirse firmadas mediante un certificado digital configurado para la aplicación, así como incluir el requestor name.

Tanto el usuario y password como el certificado firmante son indicados en el fichero ACL mediante el que se solicita el alta o la modificación de la aplicación.

Es necesario recordar que a partir del día 31 de enero de 2012 será obligatorio remitir las peticiones autenticadas.

Efectivamente existe en la plataforma de @firma un servicio web que le permite obtener la información de los campos o atributos de un certificado dado. Este servicio se denomina ObtenerInfoCertificado. A la hora de invocar a dicho webservice, en la petición, debemos indicar el certificado codificado en base64 para realizar la extracción de la información.
Existe además otro servicio, ValidarCertificado, que además de validarlo, nos permite extraer información de los atributos del certificado de la misma manera que se obtiene desde el servicio ObtenerInfoCertificado, siempre y cuando se especifique esta opción en la petición.

Los formatos longevos de firma son los que permiten a una firma electrónica poder validarse una vez que ha caducado el certificado electrónico con que se firmaron.

En estos momentos la plataforma @firma permite validar todos los formatos longevos, a través del servicio web de validación de firmas DSS. También proporciona un servicio de upgrade de firmas (mediante uso del servicio DSSAfirmaVerify), que, a partir de una firma simple (BES/EPES) sin evidencias de validación, devuelve la misma firma en formato longevo.

Los formatos longevos son: T, C, X, X-1, X-2, X-L. X-L-1, X-L-2 y A.

Para más información sobre la firma longeva, puede consultar el documento de estándares soportados por @firma, disponible en la página web de la plataforma en el PAE: http://administracionelectronica.gob.es/ctt/afirma

La plataforma @firma soporta los algoritmos de hash SHA1 y SHA2 y los algoritmos de firma RSA y curvas elípticas.

La plataforma @firma soporta los siguientes algoritmos de canonicalización:

 

En la actualidad existen varios servicios obsoletos (señalados como deprecated en el Área de Descargas). En estos servicios ya no es posible dar más altas, pues no se van a evolucionar si hay cambios tecnológicos que los hagan inservibles, por lo que no se recomienda iniciar una integración con ellos; en el caso de que se estén utilizando ya, se recomienda migrar a las soluciones alternativas.

Entre las soluciones anteriormente mencionadas, constan:

  • Para los servicios de generación de firma/cofirma en servidor: Un API para que los integradores lo incluyan en sus desarrollos y realicen las firmas en local.
  • Para el servicio de firma en dos fases, se proporcionará un servicio de justificante de firma configurable.

El cliente de firma es una aplicación cliente de Firma Electrónica que se ejecuta en el PC del usuario. Está basado en Applets Java, por lo que es necesario tener instalada la máquina virtual de Java, que será el entorno donde se ejecutará dicha aplicación.

Puede encontrar toda la información sobre el mismo en la iniciativa del ClientE de @firma .

Aunque la respuesta (el mensaje de salida, no así el envelope SOAP) efectivamente no lleva indicado el encoding, éste es UTF-8. Es decir, todo lo que retorna la plataforma está codificado en UTF-8.

La estructura de una firma CMS viene definida en la RFC 3852 y mantiene la compatibilidad con PKCS#7 tanto en el caso del Cliente de Firma como en la plataforma @firma, de manera que cualquier plataforma ajena podrá validar dichas firmas sin problemas.

El servicio de sellado de tiempo permite emitir sellos de tiempo de los documentos electrónicos que los Organismos suministren al servicio. Un sello de tiempo es una firma electrónica realizada por una Autoridad de Sellado de Tiempo (TSA) que nos permite demostrar que los datos suministrados han existido y no han sido alterados desde un instante específico en el tiempo (proveniente de una fuente fiable de tiempo).

Para incluir sellos de tiempo a las firmas electronicas, puede utilizar el servicio de upgrade de @firma (mediante uso del servicio DSSAfirmaVerify).

El Ministerio también pone a disposición de las Administraciones Públicas una Autoridad de Sello de Tiempo ( TS@ ). A través de este servicio el usuario, además, podrá validar un sello de tiempo emitido desde la plataforma @firma.

Si necesita más información acerca del mismo, puede ponerse en contacto con nuestro servicio de CAID (soporte) o bien consultar en el PAE la iniciativa de Autoridad de Sellado de Tiempo TS@

La respuesta que proporciona @firma a las consultas de firmas y certificados de los organismos van firmadas y selladas por la plataforma.

El sello de tiempo de la petición SOAP lo encontrará en el elemento "EncapsulatedTimeStamp" dentro de las "UnsignedProperties" de la firma del SOAP, que se encuentra en el Header de dicha petición, siempre y cuando tenga como formato de respuesta XAdES-T.

La validación de la cadena consiste en validar el certificado enviado a la plataforma y los certificados intermedios, correspondientes al certificado a validar de la CA que emitió el certificado.

Dado que el parser XML interpreta los tabuladores y los espacios como elementos, no se permitirán en las integraciones la inclusión de espacios entre las etiquetas de cierre y las de apertura.

Toda respuesta OCSP, aparte de la información del estado del certificado, puede contener tres campos informativos que son los siguientes: -producedAt: indica el instante en el que se firma el mensaje de respuesta. -thisUpdate: indica el instante en el que se conoce que la información sobre el estado del certificado es correcta. -nextUpdate: indica cual es el instante de la próxima actualización de la información del estado del certificado.
En definitiva, los campos thisUpdate y nextUpdate definen un intervalo de tiempo en el cual podemos dar por válida la respuesta OCSP, esto es, una respuesta será válida o fiable si el instante en el que se recibe está dentro del intervalo mencionado, en caso contrario, la información proporcionada sobre el estado del certificado no es "fiable".

Se trata de un atributo de una petición OCSP que, en el caso de ser remitida a la plataforma @firma, ha de indicarse en dicho atributo el identificador de la aplicación peticionaria.

Si, la plataforma acepta Standard Digital Signature.

Lo que se incluye en UTF-8 es el contenido del XML, la plataforma utiliza el ISO-8859-1 para codificar y decodificar en base 64.

Enlaces relacionados