Aquí explicaré aspectes tècnics referents a enviar i rebre documents mitjançant PEPPOL, que son les inicials de “Pan-European Public Procurement OnLine”.  Un projecte pilot que va sobre la contractació pública en línia a Europa que quan estigui en marxa servirà per intercanviar documents electrònics amb l’administració pública europea. Aquesta informació tècnica és pública, però està escampada en forums i documents de tot tipus.

Arquitectura

Els tres elements de l’arquitectura son els AP, els SMP i un únic SML.

  • AP = Access Point. És el servei que permet rebre documents de Peppol. Per exemple ap.b2brouter.com
  • SMP = Service Metadata Publisher. És el servei que permet publicar les dades del participants. Per exemple dir a quin AP s’ha d’enviar un cert tipus de documents. Un exemple de SMP seria smp.b2brouter.com
  • SML = Service Metadata Locator. És un servidor DNS que donat un destinatari et dóna el SMP on hi ha publicades les seves dades. El domini de la zona DNS és peppolcentral.org.

Certificats

Els participants s’identifiquen i s’autoritzen mitjançant una PKI X.509. Al projecte pilot hi ha una root CA i tres CA intermèdies on la “PEPPOL Root Test CA” signa les tres CA intermèdies.

Es necessiten dos certificats, el de l’AP i el del SMP. Existeix un tercer certificat, que es diu STS, que no es fa servir.  Per obtenir aquests certificats s’ha de demanar participar en el pilot PEPPOL.

  1. El certificat de l’AP està signat per la “PEPPOL Access Point Test CA”. Serveix per poder enviar a altres AP i rebre d’altres AP.
  2. El certificat del SMP està signat per la “PEPPOL Service Metadata Publisher Test CA”. Serveix per poder publicar entrades DNS al SML.
  3. El STS està signat per la “PEPPOL Security Token Service Test CA” i de moment no serveix per a res.

Enviar documents

És evident que per poder enviar s’ha de saber l’adreça del destinatari, i en el cas de Peppol l’adreça del destinatari és un Participant ID, un Process ID i un Document ID.

Per enviar un document el primer pas és esbrinar quin és l’AP del destinatari.  Per fer això s’agafa l’adreça del destinatari (el participant, el procés i el document) i s’utilitza el SML i un SMP:

  1. El Participant ID es converteix a una zona DNS mitjançant un hash MD5, un prefixe “B-” i un sufixe. Per exemple el Participant ID “9912:esb63276174” es converteix en “B-ae2866398fd1d4c0d35343e8464a5258.iso6523-actorid-upis.sml.peppolcentral.org”
  2. La zona DNS es resol i s’obté una IP. Aquesta IP és la del SMP, que és el lloc on hi ha la informació referent al Participant ID que busquem. En l’exemple, la zona resol al CNAME smp.b2brouter.com i finalment a la IP del SMP.
  3. Finalment s’accedeix per HTTP a les dades del Participant ID que el SMP té publicades mitjançant la URL http://B-ae2866398fd1d4c0d35343e8464a5258.iso6523-actorid-upis.sml.peppolcentral.org/complete/iso6523-actorid-upis::9912:esb63276174
El document XML que retorna el SMP conté la referència al AP que busquem. A dins del XML hi ha la llista de documents que accepta el participant, i per cada document la llista de processos. Per exemple, per enviar una factura “urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice(…)” al procés “urn:www.cenbii.eu:profile:bii04:ver1.0” en aquest cas l’AP seria ap.b2brouter.com.

Un cop es coneix la URL del AP destí només cal enviar-li el document mitjançant el que anomenen “Secure Trusted Asynchronous Reliable Transport” o START per als amics, que defineix com els AP han d’utilitzar aquestes 5 tecnologies per comunicar-se:

  • SOAP 1.1 – Simple Object Access Protocol.
  • WS-Security 1.1 – a flexible and feature-rich extension to SOAP to apply security to web service.
  • WS-Transfer – a specification defining the transfer of an XML-representation of an WS-addressable resource – as a standard approach to accessing the message channels.
  • WS-ReliableMessaging 1.1 – a protocol that allows SOAP messages to be reliably delivered between distributed applications.
  • SAML 2.0 – Security Assertion Markup Language – an XML-based open standard for exchanging authentication and authorization data between security domains.

Per sort la implementació de referència és en Java i Java ja té totes les llibreries ws-* necessàries.

Keystores Java

És molt important tenir clar quins certificats van a cada element de l’arquitectura:

  • Tant el client com el servidor AP necessiten el certificat signat per la “PEPPOL Access Point Test CA” per poder enviar i rebre. Crearem una keystore i li direm ap.jks
  • El SMP necessita el certificat signat per la “PEPPOL Service Metadata Publisher Test CA” per poder actualitzar les entrades DNS en el SML. Crearem una alta keystore i li direm smp.jks
  • Necessitem també una keystore addicional per posar-hi els certificats en els que confiem. N’hi direm peppol-cacerts.jks

Per crear les keystores podem utilitzar el Portecle perquè el keytool és força críptic. Coses a tenir en compte:

  1. Posar l’alias “1” a la clau privada.
  2. Posar “peppol” de password, tant a la keystore com a la clau privada.
  3. Utilitzar l’opció “Import CA Reply” amb botó dret sobre la clau privada “1”, per afegir el nostre certificat signat per la CA.
  4. La keystore del servidor AP només pot tenir un certificat, perquè agafa el primer que troba i si en tingués més es podria confondre pobrissó.

Implementacions

Les implementacions que hem fet servir son Open Source:

També hem desenvolupat algunes eines auxiliars que podeu trobar a github.