@Firma

@firma é a solución tecnolóxica na que se basea a Plataforma de validación e firma electrónica do Ministerio. A versión actual de @firma é a 6.4 e constitúe unha evolución da versión 6.2 a partir da achega de múltiples Organismos Públicos cooperantes. 

@firma é un produto robusto e integral, desenvolvida inicialmente pola Xunta de Andalucía, cedida ao resto das Administracións Públicas co obxecto de fomentar e estender o desenvolvemento da Administración Electrónica e a Sociedade da Información.

É unha solución baseada en software libre, estándares abertos e en java: servidor de aplicacións Wildfly, Sistema Operativo Linux, AXIS, etc.

Os servizos proporcionados por Plataforma de validación de certificados e firma electrónica do Ministerio (@firma) proporciónanse ás Administracións Públicas sen custo económico.

A forma máis común de uso de @firma é modo servizo. Este modo consiste en que a plataforma @sinatura do Ministerio proporciona servizos de validación de certificados e firmas electrónicas a través de servizos web. As aplicacións que desexan utilizar os servizos de @firma, conéctanse mediante a rede SARA aos servizos web de @sinatura do Ministerio. É o modo recomendado para aqueles organismos cun volume mensual de validacións medio/baixo. O Ministerio proporciona unha plataforma igual ao a de produción para que os organismos que desexen usar os servizos de @firma realicen probas, e un servizo de soporte para xestionar as altas e integracións.

Existe outro modo de uso de @firma, o modelo federado. Esta unicamente recomendado para aqueles organismos cun volume de transaccións moi elevado. O Ministerio proporciona o software de @firma, para que o organismo instáleo e administre nas súas dependencias. Neste caso o despregamento, instalación e administración é responsabilidade do organismo. O Ministerio proporcionará actualizacións e parches do software segundo xérense.

Pode consultar os servizos dispoñibles ou o modelo federado a través do FAQ correspondentes.

Pode atopar toda a información sobre @firma na a iniciativa do PAE creada para ese efecto. Na área de descargas da este iniciativa poden atopar a documentación dos servizos así como os exemplos de integración.

Para ter acceso á documentación completa debe ser un usuario rexistrado no portal PAE, así como acceder ao portal mediante a Intranet Administrativa (Rede SARA).

Disponse dun equipo de soporte dispoñible para cooperar cos diferentes Organismos Públicos fornecendo toda a información necesaria sobre o uso dos servizos así como para cooperar nas actividades de proba e integración dos sistemas aos servizos da Plataforma.

Este Centro de Atención é accesible SÓ PARA DESENVOLVEDORES DE APLICACIÓNS DAS ADMINISTRACIÓNS PUBLICAS. Para comunicar unha incidencia ou solicitude de soporte ao Centro de Atención a Integradores e Desenvolvedores (CAID) encha o formulario Web de apertura de solicitudes de soporte técnico:
- Acceso ao formulario

Horario de soporte: de Luns a Xoves de 08:30 a 18:30 e venres 08:30 a 15:00.

Mediante a suite de servizos de @firma, ofrécese tamén:

• Un Cliente de Firma para a creación de firmas en local.
• Un servizo de Selaxe de Tempo ( TS@ ).
• Un compoñente para a integración da firma nos fluxos de traballo organizativos ( Port@firmas ).
• Un demostrador dos servizos de @firma: Validación de firmas e certificados dixitais, creación de firmas dixitais, etc.

Os servizos de @firma están dispoñibles de forma gratuíta para aquelas Administracións Públicas que o soliciten. O servizo proporciónase a través da rede SARA (Intranet Administrativa), polo que para poder utilizalo é necesario estar conectado á este rede.

Asináronse convenios con todas as Comunidades Autónomas para permitir a utilización dos servizos de @firma ás aplicacións de administracións electrónicas destas que o desexen. No caso das Entidades locais, algunhas Comunidades Autónomas inclúen no convenio a posibilidade de acceder aos servizos de @firma a través de adhesións.

Así mesmo poden utilizar o servizo as Universidades, a través da CRUE e RedIRIS.

O Ministerio proporciona un servizo de soporte como apoio á integración das aplicacións informáticas que vaian facer uso dos servizos de validación de @firma nos distintos Organismos Públicos. Dentro deste soporte, o Ministerio proporciona unha plataforma de probas que poden utilizar os Organismos Públicos durante a integración das súas aplicacións.

Para a realización de probas cos servizos de validación de firma que prové o Ministerio, non é necesaria a realización de ningún acto de compromiso por parte de ningunha das partes, e sen ningún custo.

Para poder realizar pedimentos aos servizos proporcionados pola plataforma de validación, hanse de cumprir os seguintes puntos:

1. Uso da Intranet Administrativa: Os pedimentos só poderán realizarse desde máquinas conectadas á Intranet Administrativa (Rede SARA) e con permisos de acceso sobre a plataforma. Por iso deberán identificarse aquelas máquinas desde as que se vaian a realizar as probas e solicitar a soporte de @firma ( Acceso ao formulario ) permiso de acceso ás IPs internas das este máquinas.
   Para iso deberase cubrir o ficheiro correspondente coa información das mesmas e envialo a soporte de @firma para a súa alta efectiva. Pode descargar o formulario de alta da área de descargas da páxina web de @firma, no portal de administración electrónica ( http://administracionelectronica.gob.es/ctt/afirma ). Para acceder á documentación necesítase estar rexistrado no portal e acceder ao mesmo desde a Intranet Administrativa (rede SARA).
2. Identificación das aplicacións: Co fin de poder realizar un seguimento da actividade das aplicacións e a plataforma (tanto en probas como en produción), os pedimentos deberán ser realizadas por aplicacións identificadas na plataforma mediante certificado ou usuario e contrasinal na Plataforma.
3. Crear un cliente de Web Service: Unha vez que se dispoñan de permisos é necesario desenvolver un Cliente de Web Service para que realice o pedimento aos servizos publicados na plataforma.
   Para desenvolver o Cliente Web Service, proporciónase aos integradores a descrición do servizo web de destino. Para iso, a plataforma especifica para cada Servizo Web (WS en diante) o ficheiro WSDL que inclúe o URL do WS, a mensaxe de pedimento co XML schema de entrada e a mensaxe de resposta devolto polo servizo. Así mesmo, tamén se proporciona información na área de descargas da páxina web de @firma, no portal de administración electrónica ( http://administracionelectronica.gob.es/ctt/afirma ), na zona restrinxida para usuarios rexistrados. Ademais do WSDL E XML proporciónase un kit de exemplo de integración, tanto para plataformas Java como .NET.

Actualmente puxéronse a disposición dos usuarios de @firma varias listas de distribución ás que se poden subscribir. A través destas listas recibirán notificacións referentes a cambios relevantes relacionados co proxecto ao que estean vinculadas (actualizacións, intervencións, etc.).
Para máis información, rógase que se consulte a sección de Contacto dos diferentes proxectos (plataforma de firma @asina, Cliente de Firma, TS@…).

Para integrarse en @firma, é necesario seguir os pasos que se definen a seguir:

1. Estar conectado á rede SARA.
2. Porse en contacto co servizo de soporte e facilitar os seus datos de contacto.
3. O equipo de soporte informar os prerrequisitos e facilitaralle o formulario para o control de acceso que o organismo debe cubrir. Xunto coa documentación de benvida, facilitarase o Manual de Programación de WS de @firma xunto coas instrucións técnicas necesarias para conectar as aplicacións dos servizos de administración electrónica á Plataforma @asina.
4. O organismo debe conectar as aplicacións de servizos de administración electrónica para acceder  á Plataforma a través de servizos web implementados en tecnoloxía Microsoft® ou Java.
5. Por último, para acceder á totalidade da documentación é necesario ser un usuario rexistrado, para iso, acceder á páxina do PAE e darse de alta como usuario no menú da dereita: "Acceso a Usuarios" -> "Rexistrarse".

O modelo de solicitude de datos de acceso e utilización dos servizos de @firma (formulario en formato PDF) contén unha serie de datos necesarios para realizar a integración do Organismo na plataforma. A seguir, explícanse os distintos campos do formulario:

• Conxunto de datos "Datos xerais”: 
• “Nome da aplicación” que vai facer uso dos servizos WS e/ou OCSP da plataforma @asina. O identificador da aplicación no sistema, que deberá incluírse no campo idAplicación dentro do pedimento, proporcionarase polo equipo de soporte de @firma cando se procese o alta. Recoméndase non utilizar o mesmo identificador para múltiples aplicacións, xa en caso de problemas cunha aplicación, dificulta a rastrexabilidade dos mesmos para a súa pronta solución.
• "Contorna": Sinalar a contorna ao que se desexa acceder (Desenvolvo / Servizos Estables, Produción ou ambos os).
• "Volume de transaccións mensuais": Indicar o número aproximado de transaccións que se realizarán por contorna nun mes.
• "Volume de transaccións por minuto": Indicar o número aproximado de transaccións que se realizarán por contorna nun minuto.
• Conxunto de datos "Órgano solicitante”: 
• Deberá indicar o código DIR3 (Directorio Común de Unidades Orgánicas e Oficinas). Pode obter máis información do mesmo en http://administracionelectronica.gob.es/ctt/dir3. 
• O nome e os apelidos do titular do órgano solicitante deben coincidir cos que aparecen no DNI/NIE.
• • Conxunto de datos “Persoas de contacto”:
• É importante manter estes datos actualizados, porque se utilizarán para notificar de posibles problemas na plataforma ou coa aplicación. Adicionalmente, é recomendable subscribirse ás listas de correo, e ás noticias e novos documentos da solución no PAE.
• • Conxuntos de datos "Certificado utilizado para a autenticación da entidade na contorna" (servizos estables e produción)
• Ademais deberá achegar ao pedimento a parte pública do certificado que utilizará para identificarse para a comprobación dos datos, en formato codificado (ficheiro con extensión.cer).
• Se se usa un certificado distinto para os pedimentos a @firma polo protocolo OCSP, achegar ambos.
• • Conxunto de datos "Encamiñamento utilizado"
• En caso de rango, indicar a máscara. O acceso debe realizarse desde a rede SARA, debéndose indicar un máximo de 32 IP's agrupadas nun máximo de 4 rangos.
• • Conxunto de datos “Datos dos servizos web”:
• "Formato da sinatura de resposta": escoller entre Sen firma, XMLDSignature (Asina XML Básica), XAdESBES (Asina XML Avanzada), XAdEST (Asina XML avanzada con selaxe temporal).
• "Política de validación": escoller entre Política lixeiro, Política avanzada, Política crítica.

Existen dúas contornas de explotación da plataforma @asina: un chamado de desenvolvemento, para a realización de probas por parte dos organismos, e un de produción, que se corresponde coa contorna real da plataforma. Ambas as contornas son de similares características, coa excepción que o de desenvolvemento ponse a disposición dos organismos para realizar as probas de integración de aplicacións, non estando permitidas as probas na contorna de produción.
O url de acceso aos servizos da plataforma de desenvolvemento, desde dentro da rede interadministrativa (SARA) é:
http://des-afirma.redsara.es/afirmaws/services/ (WS)
https://deas-afirma.redsara.es/afirmaws/services/ (WS modo Seguro)
O url de acceso aos servizos da plataforma de produción, desde dentro da rede interadministrativa (SARA) é:
http://afirma.redsara.es/afirmaws/services/ (WS)
https://afirma.redsara.es/afirmaws/services/ (WS modo Seguro)
O URL do servizo OCSP son:
http://des-afirma.redsara.es/servidorocsp/servidorocsp
http://afirma.redsara.es/servidorocsp/servidorocsp

As solicitudes de servizo realizadas mediante servizos web (Web Services - WS) deben realizarse polos portos 8080 ou 443. Os pedimentos ao servizo ValidarCertificado mediante OCSP débense dirixir ao porto 80. Con todo, debe ter en conta que o servizo ValidarCertificado considérase “legacy” (obsoleto), e non será evolucionado. En xeral recoméndase a aquelas aplicacións que integren este servizo, ou outros “legacy”, substituílos polo seu equivalente DSS (estándar Dixital Signature Services de OASIS, como DSSAfirmaVerifyCertificate no caso de ValidarCertificado).

Pode obter este documento (Persoal-de-alta-en-Afirma-rev3.pdf) na "Área de descargas" da iniciativa “ Plataforma de validación de firma electrónica @firma ” no apartado "Persoal de alta de IPs e Aplicacións en @firma".

O Modelo Federado da plataforma @asina consiste nunha copia do software desta Plataforma, lista para ser instalada na contorna do Organismo solicitante.

Para obter este Modelo Federado, ha de ser remitida unha solicitude ao Soporte da Plataforma ( Acceso ao formulario ), desde onde se lle indicarán os pasos a seguir.

É posible validar mediante a plataforma @asina todos os certificados incluídos no documento que poden consultar nesta ligazón .

Adicionalmente, a Plataforma permite a validación dos certificados europeos que son recoñecidos pola TSL correspondente a cada país, dita información pode consultarse no URL https://webgate.ec.europa.eu/tl-browser/#

Como primeiro paso, comprobar que o certificado se atopa recollido na web de Ministerio de Asuntos Económicos e Transformación Dixital (https://sedeaplicaciones.minetur.gob.es/Fornecedores/) de Prestadores de servizos Electrónicos de Confianza Cualificados.

Adicionalmente, comprobar se se trata dun certificado europeo recoñecidos pola TSL correspondente a cada país, consultando o URL https://webgate.ec.europa.eu/tl-browser/#

Se algún dos casos é afirmativo, ha de ser solicitado ao soporte da plataforma @asina ( Acceso ao formulario ).

Poden atopar o kit de certificados de proba na área de Descargas do portal do PAE da presente iniciativa. Para ter acceso á este descarga debe ser un usuario rexistrado no portal PAE e estar autenticado.

Todos os certificados do kit xeráronse por Autoridades de Certificación reais, aínda que este certificados sexan de proba. Non corresponden en ningún caso a contornas de proba do PSCs.

• Pedimentos WS: É necesario a sinatura do pedimento mediante un certificado dixital configurado para esta aplicación.
• Pedimentos OCSP: Os pedimentos han de remitirse asinadas mediante un certificado dixital configurado para a aplicación, así como incluír o requestor name.

Efectivamente existe na plataforma o servizo de verificación de certificado DSSAfirmaVerifyCertificate. Mediante esta interface Web Service pódese solicitar a verificación de certificados X509 así como extraer a información do certificado mediante a aplicación do mapeo definido para o seu tipo.

Tamén existen os servizos ObtenerInfoCertificado e ValidarCertificado. Con todo, debe ter en conta que os servizos ObtenerInfoCertificado e ValidarCertificado considéranse “legacy” (obsoletos), e non serán evolucionados. En xeral recoméndase a aquelas aplicacións que integren este servizo, ou outros “legacy”, substituílos polo seu equivalente DSS (estándar Dixital Signature Services de OASIS, como DSSAfirmaVerifyCertificate no caso de ValidarCertificado).

O servizo “legacy” ObtenerInfoCertificado permítelle obter a información dos campos ou atributos dun certificado dado. Á hora de invocar a este webservice, no pedimento, debemos indicar o certificado codificado en base64 para realizar a extracción da información.

No caso de o  servizo “legacy” ValidarCertificado ademais de validalo, permítenos extraer información dos atributos do certificado da mesma maneira que se obtén desde o servizo ObtenerInfoCertificado, a condición de que se especifique esta opción no pedimento.

Os formatos lonxevos de firma son os que permiten a unha firma electrónica poder validarse unha vez que caducou o certificado electrónico con que se asinaron.

Nestes momentos a plataforma @asina permite validar todos os formatos lonxevos, a través do servizo web de validación de firmas DSS. Tamén proporciona un servizo de upgrade de firmas (mediante uso do servizo DSSAfirmaVerify), que, a partir dunha firma simple (BES/EPES) sen evidencias de validación, devolve a mesma firma en formato lonxevo.

Os formatos lonxevos son: T, C, X, X-1, X-2, X-L. X-L-1, X-L-2 e A.

Para máis información sobre a firma lonxeva, pode consultar o documento de estándares soportados por @firma, dispoñible na páxina web da plataforma no PAE: http://administracionelectronica.gob.es/ctt/afirma

A plataforma @asina soporta os algoritmos de hash XA1 e a familia de algoritmos XA2 (XA256, XA384 e XA512), e os algoritmos de firma RSA e curvas elípticas.

A plataforma @asina soporta os seguintes algoritmos de canonizació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

Na actualidade existen varios servizos obsoletos (sinalados como deprecated na área de Descargas). Nestes servizos xa non é posible dar máis altas, pois non se van a evolucionar se hai cambios tecnolóxicos que os fagan inservibles, polo que non se recomenda iniciar unha integración con eles; no caso de que se estean utilizando xa, recoméndase migrar ás solucións alternativas.

Entre as solucións anteriormente mencionadas, constan:

• Para os servizos de xeración de firma/cofirma en servidor: Un API para que os integradores inclúano nos seus desenvolvementos e realicen as firmas en local.
• Para o servizo de firma en dúas fases, proporcionarase un servizo de xustificante de firma configurable.

A Suite Cliente de Firma é unha ferramenta de firma electrónica en contornas de escritorio e dispositivos móbiles, que funciona integrado nunha páxina Web mediante Javascript, como applet, como aplicación de escritorio, ou como aplicación móbil, dependendo da contorna do usuario.

Pode atopar toda a información sobre o mesmo na iniciativa do CLIENTE de @firma .

Aínda que a resposta (a mensaxe de saída, non así o envelope SOAP) efectivamente non leva indicado o encoding, este é Utf-8. É dicir, todo o que retorna a plataforma está codificado en Utf-8.

A estrutura dunha asina CMS vén definida no RFC 3852 e mantén a compatibilidade con PKCS#7 tanto no caso do Cliente de Firma como na plataforma @asina, de maneira que calquera plataforma allea poderá validar ditas firmas sen problemas.

O servizo de selaxe de tempo permite emitir selos de tempo dos documentos electrónicos que os Organismos fornecer ao servizo. Un selo de tempo é unha firma electrónica realizada por unha Autoridade de Selaxe de Tempo (TSA) que nos permite demostrar que os datos fornecidos han existido e non foron alterados desde un instante específico no tempo (proveniente dunha fonte fiable de tempo).

Para incluír selos de tempo ás firmas electronicas, pode utilizar o servizo de upgrade de @firma (mediante uso do servizo DSSAfirmaVerify).

O Ministerio tamén pon a disposición das Administracións Públicas unha Autoridade de Selo de Tempo ( TS@ ). A través deste servizo o usuario, ademais, poderá validar un selo de tempo emitido desde a plataforma @asina.

Se necesita máis información achega do mesmo, pode porse en contacto co noso servizo de CAID (soporte) ou ben consultar no PAE a iniciativa de Autoridade Autoridade de Selaxe de Tempo Ts@

A resposta que proporciona @firma ás consultas de firmas e certificados dos organismos van asinadas e seladas pola plataforma.

O selo de tempo do pedimento SOAP atoparao no elemento "EncapsulatedTimeStamp" dentro das "UnsignedProperties" do sinatura do SOAP, que se atopa no Header do este pedimento, a condición de que teña como formato de resposta XAdES-T.

A validación da cadea consiste en validar o certificado enviado á plataforma e os certificados intermedios, correspondentes ao certificado a validar da CA que emitiu o certificado.

Dado que o parser XML interpreta os tabuladores e os espazos como elementos, non se permitirán nas integracións a inclusión de espazos entre as etiquetas de peche e as de apertura.

Toda resposta OCSP, á parte da información do estado do certificado, pode conter tres campos informativos que son os seguintes: -producedAt: indica o instante no que se asina a mensaxe de resposta. -thisUpdate: indica o instante no que se coñece que a información sobre o estado do certificado é correcta. -nextUpdate: indica cal é o instante da próxima actualización da información do estado do certificado.
En definitiva, os campos thisUpdate e nextUpdate definen un intervalo de tempo no cal podemos dar por válida a resposta OCSP, isto é, unha resposta será válida ou fiable se o instante no que se recibe está dentro do intervalo mencionado, en caso contrario, a información proporcionada sobre o estado do certificado non é "fiable".

Trátase dun atributo dun pedimento OCSP que, no caso de ser remitida á plataforma @asina, ha de indicarse no este atributo o identificador da aplicación peticionaria.

Se, a plataforma acepta Standard Dixital Signature.

O que se inclúe en Utf-8 é o contido do XML, a plataforma utiliza o Iso-8859-1 para codificar e decodificar en base 64.