@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.4 y constituye una evolución de la versión 6.2 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: servidor de aplicaciones Wildfly, Sistema Operativo 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 RedIRIS.

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 modelo de solicitud de datos de acceso y utilización de los servicios de @firma (formulario en formato PDF) 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:

• Conjunto de datos "Datos generales”: 
• “Nombre de la aplicación” que va a hacer uso de los servicios WS y/u OCSP de la plataforma @firma. El identificador de la aplicación en el sistema, que deberá incluirse en el campo idAplicación dentro de la petición, se proporcionará por el equipo de soporte de @firma cuando se procese el alta. Se recomienda no utilizar el mismo identificador para múltiples aplicaciones, ya en caso de problemas con una aplicación, dificulta la trazabilidad de los mismos para su pronta solución.
• "Entorno": Señalar el entorno al que se desea acceder (Desarrollo / Servicios Estables, Producción o ambos).
• "Volumen de transacciones mensuales": Indicar el número aproximado de transacciones que se realizarán por entorno en un mes.
• "Volumen de transacciones por minuto": Indicar el número aproximado de transacciones que se realizarán por entorno en un minuto.
• Conjunto de datos "Órgano solicitante”: 
• Deberá indicar el código DIR3 (Directorio Común de Unidades Orgánicas y Oficinas). Puede obtener más información del mismo en http://administracionelectronica.gob.es/ctt/dir3. 
• El nombre y los apellidos del titular del órgano solicitante deben coincidir con los que aparecen en el DNI/NIE.
• • Conjunto de datos “Personas de contacto”:
• Es importante mantener estos datos actualizados, porque se utilizarán para notificar de posibles problemas en la plataforma o con la aplicación. Adicionalmente, es recomendable suscribirse a las listas de correo, y a las noticias y nuevos documentos de la solución en el PAE.
• • Conjuntos de datos "Certificado utilizado para la autenticación de la entidad en el entorno" (servicios estables y producción)
• Además deberá adjuntar a la petición la parte pública del certificado que utilizará para identificarse para la comprobación de los datos, en formato codificado (fichero con extensión.cer).
• Si se usa un certificado distinto para las peticiones a @firma por el protocolo OCSP, adjuntar ambos.
• • Conjunto de datos "Direccionamiento utilizado"
• En caso de rango, indicar la máscara. El acceso debe realizarse desde la red SARA, debiéndose indicar un máximo de 32 IP's agrupadas en un máximo de 4 rangos.
• • Conjunto de datos “Datos de los servicios web”:
• "Formato de la firma de respuesta": escoger entre Sin firma, XMLDSignature (Firma XML Básica), XAdESBES (Firma XML Avanzada), XAdEST (Firma XML avanzada con sellado temporal).
• "Política de validación": escoger entre Política light, Política avanzada, Política crítica.

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. Sin embargo, debe tener en cuenta que el servicio ValidarCertificado se considera “legacy” (obsoleto), y no será evolucionado. En general Se recomienda a aquellas aplicaciones que integren este servicio, u otros “legacy”, sustituirlos por su equivalente DSS (estándar Digital Signature Services de OASIS, como DSSAfirmaVerifyCertificate en el caso de ValidarCertificado).

Puede obtener dicho documento (Plantilla-de-alta-en-Afirma-rev3.pdf) en el "Área de descargas" de la iniciativa “Plataforma de validación de firma electrónica @firma” en el apartado "Plantilla de alta de IPs y Aplicaciones en @firma".

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.

Adicionalmente, la Plataforma permite la validación de los certificados europeos que son reconocidos por la TSL correspondiente a cada país, dicha información puede consultarse en la URL https://webgate.ec.europa.eu/tl-browser/#

Como primer paso, comprobar que el certificado se encuentra recogido en la web de Ministerio de Asuntos Económicos y Transformación Digital (https://sedeaplicaciones.minetur.gob.es/Prestadores/) de Prestadores de Servicios Electrónicos de Confianza Cualificados.

Adicionalmente, comprobar si se trata de un certificado europeo reconocidos por la TSL correspondiente a cada país, consultando la URL https://webgate.ec.europa.eu/tl-browser/#

Si alguno de los casos es 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. Para tener acceso a dicha descarga debe ser un usuario registrado en el portal PAE y estar autenticado.

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:
• Validación de certificados mediante WS: estándar DSS.
• Validación de certificados WS básica.
• Validación de certificados OCSP.
• Obtención de información de un certificado
• Servicios de validación de firmas:
  Validación de firmas mediante WS: estándar DSS: incluye validación de firmas longevas.
  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 está siendo descontinuado, sustituyéndose por otros componentes de la Suite de productos de @firma. (Consulte la FAQ correspondiente a los servicios deprecados)

• Peticiones WS: Es necesario 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.

Efectivamente existe en la plataforma el servicio de verificación de certificado DSSAfirmaVerifyCertificate. Mediante esta interfaz Web Service se puede solicitar la verificación de certificados X509 así como extraer la información del certificado mediante la aplicación del mapeo definido para su tipo.

También existen los servicios ObtenerInfoCertificado y ValidarCertificado. Sin embargo, debe tener en cuenta que los servicios ObtenerInfoCertificado y ValidarCertificado se consideran “legacy” (obsoletos), y no serán evolucionados. En general Se recomienda a aquellas aplicaciones que integren este servicio, u otros “legacy”, sustituirlos por su equivalente DSS (estándar Digital Signature Services de OASIS, como DSSAfirmaVerifyCertificate en el caso de ValidarCertificado).

El servicio “legacy” ObtenerInfoCertificado le permite obtener la información de los campos o atributos de un certificado dado. 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.

En el caso del  servicio “legacy” ValidarCertificado 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 la familia de algoritmos SHA2 (SHA256, SHA384 y SHA512), y los algoritmos de firma RSA y curvas elípticas.

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

• Canonical XML: http://www.w3.org/TR/2001/REC-xml-c14n-20010315
• Canonical XML with comments: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
• Exclusive Canonical XML: http://www.w3.org/2001/10/xml-exc-c14n#
• Exclusive Canonical XML with comments: http://www.w3.org/2001/10/xml-exc-c14n#WithComments

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.

La Suite Cliente de Firma es una herramienta de firma electrónica en entornos de escritorio y dispositivos móviles, que funciona integrado en una página Web mediante JavaScript, como applet, como aplicación de escritorio, o como aplicación móvil, dependiendo del entorno del usuario.

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.