Peppol online ws. 3 start and agreements


Published on

Presentation from the third online PEPPOL workshop now available. Topics: START protocol and provider agreements.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Peppol online ws. 3 start and agreements

  1. 1. PEPPOLWorkshop – START and Agreements<br />Martin Forsberg, Ecru Consulting<br />Mikael Aksamit, Tickstar AB<br />
  2. 2. The PEPPOL project<br />The PEPPOL project is the result of the European Competitiveness and Innovation Programme (CIP) ICT Policy Support Programme (ICTPSP) 2007 and 2009 Call for Proposals<br />Pilot A objective: Enabling EU-wide public eProcurement<br />50% EU contribution for achieving interoperability<br />Coordinated by the Norwegian Agency for Public Management and eGovernment (Difi)<br />Consortium and scope:<br />18 beneficiaries from 12 countries<br />Total budget 30,8 M€ <br />8 work packages, <1.600 person months and 10 M€ on sub-contractors<br />Project start up: 1 May 2008, duration 48 months*<br />*Current project duration is 42 months (+6 months extension subject to European Commission's approval)<br />
  3. 3. Any supplier (incl. SMEs) in the EU can communicateelectronically with any European contracting authority for all procurement processes.<br />The PEPPOL Vision<br />3<br />
  4. 4. eProcurement<br />
  5. 5. Page 5<br />Provider Agreements and Governance<br />
  6. 6. Change of plans<br /><ul><li>Detailed walk through of the providers agreements will be done on the 9:th of May
  7. 7. This presentation will only give a short introduction</li></ul>Page 6<br />
  8. 8. Regional<br />domain<br />Regional<br />domain<br />AP<br />AP<br />Contracting<br />Authority<br />Economic<br />Operator<br />SMP<br />SMP<br />SML<br />Coordinating<br />Authority<br />Regional<br />Authority<br />Two levels of governance<br />Provides European wide governance for:<br />the PEPPOL Technical Standards<br />the PEPPOL Service Specifications <br />the PEPPOL SML<br />the PEPPOL Agreements<br />Provides regional governance for:<br />the implementation and use of the transport infrastructure<br />the legal framework for specific AP and SMP agreements<br />specific requirements applicable within a domain<br />
  9. 9. PEPPOL Transport Infrastructure Agreements<br />The aim of the PEPPOL Transport Infrastructure Agreements is to regulate the roles and responsibilities of the actors involved in the governance and operation of the PEPPOL transport infrastructure.<br />Three separate agreements with a common set of annexes.<br />Contact points<br />Definitions<br />Service and Service Levels<br />Technical Standards<br />Regional domain and its specific services and service levels<br />Change Procedures<br />The PEPPOL Governance Model and model agreements<br />
  10. 10.
  11. 11. Key principles<br />Inspired by other initiatives, but reflects the uniqueness of the PEPPOL initiative:<br />An open community where interoperability is achieved through common specification and not point-to-point agreements.<br />The PEPPOL Transport Infrastructure Agreements provides governance for the PEPPOL Transport Infrastructure based on:<br />a European wide coordination over all common components of the transport infrastructure;<br />a regional coordination and supervision of the implementation and use of the transport infrastructure within a domain; and<br />open and transparent provision of SML, SMP and AP services based on a common set of agreements as well as common definition of services and service levels.<br />
  12. 12. PEPPOL Transport Infrastructure Agreements<br />PEPPOL<br />Community Agreement<br />“… terms and conditions under which the Parties shall provide governance for the PEPPOL Transport Infrastructure.”<br />A model agreement regulating the “… terms and conditions under which: the PEPPOL AP Provider shall provide the required PEPPOL AP Services; the PEPPOL Regional Authority shall ensure  that the services provided by the PEPPOL AP Provider are provided and maintained in a reliable, professional and state of the art manner, in compliance with all applicable laws and all relevant technical specifications, to ensure consistency across the full PEPPOL Transport Infrastructure .”<br />A model agreement regulating the “… terms and conditions under which: the PEPPOL SMP Provider shall provide the required PEPPOL SMP Services; the PEPPOL Regional Authority shall ensure that the services provided by the PEPPOL SMP Provider are provided and maintained in a reliable, professional and state of the art manner, in compliance  with all applicable laws and all relevant technical specifications, to ensure consistency across the full PEPPOL Transport Infrastructure.”<br />PEPPOL<br />AP <br />Provider<br />Agreement<br />Coordinating<br />Authority<br />I.e. PEPPOL GB<br />Regional<br />Authority<br />E.g. VM<br />SMP<br />Provider<br />E.g. ITELLA<br />AP<br />Provider<br />E.g. ITELLA<br />PEPPOL<br />SMP Provider<br />Agreement<br />
  13. 13. Page 12<br />START – Secure Trusted Asynchronous Reliable Transport<br />
  14. 14. Goals<br />START<br />SecureTrusted Asynchronous Reliable Transport<br />A SOAP-based profile that offers secure and reliable delivery of messages between Access Points.<br />START Access Point (START AP)<br />Communicates in a peer-to-peer manner with other START APs<br />Derives endpoints to other START APs through SMP-lookups<br />Can offer other transport profiles, but MUST always offer START<br />Restricted usage of standards to achieve interoperability<br />
  15. 15. Goals of START Profile<br />A single profile that implementers can follow and therefore gain access to the infrastructure<br />Define a simple, interoperable communications pattern<br />Ensure messages reliable delivered between Access Points<br />Ensure confidentiality using transport-level encryption<br />Ensure integrity and authenticity of received messages by signature validation<br />Content of transferred messages is opaque for the Access Points<br />
  16. 16. Technology in profile<br />15<br />START Profile<br /> A set of well-known standard, to be strictly used to ensure interoperability<br />SOAP 1.1<br />WS-Addressing 1.0<br />WS-Security 1.1<br />WS-Transfer<br />WS-ReliableMessaging 1.1<br />SAML 2.0<br />
  17. 17. Typical flow<br />SML<br />SMP<br />Company 2<br />(C2)<br />Company 1<br />(C1)<br />2.<br />START Access Point 2<br />(AP2)<br />4.<br />1.<br />3.<br />3 (5).<br />START Access Point 1<br />(AP1)<br />
  18. 18. Typical flow<br />Message is created by C1 and transferred to AP1, containing necessary identifiers<br />AP1 does a SML/SMP-lookup to find out location of AP2 (where the receiver C2 is located behind)<br />AP1 prepares any tokens it needs to include in transfer and calculates the SAML 2.0 assertions<br />AP1 adds identifiers to SOAP headers and signs message<br />AP1 uses WS-ReliableMessaging and TLS to transfer message to AP2<br />AP2 can deliver message to C2 in a synchronous or asynchronous manner, in either case a proof-of-delivery needs to be returned at some point to AP1<br />AP1 log signed proof of delivery<br />
  19. 19. Sequence of a typical flow<br />
  20. 20. Page 19<br />Security overview<br />Timestamp with 5 minutes expiration<br />Message Authentication and Integrity<br />START AP Certificate must be included<br />SAML 2.0 Assertions<br /> Due to the complexity and size of the SOAP-Envelopes, an in-depth analysis will be held during the Face2Face meeting the 18th of April.<br />
  21. 21. Page 20<br />Types of SAML Assertions<br />Sender-Vouches<br />Used when sender AP itself have authenticated the sender<br />Sender AP both issues and signs the token, authenticating the senders identity<br />Receiving AP must trust the sending AP regarding authentication of sender<br />Holder-of-key<br />Trusted 3rd parties authenticate the sender on behalf of the sending AP<br />SAML assertion issued and signed by a 3rd party<br />
  22. 22. Receiving START AP<br />Page 21<br />Must validate the message signature and security tokens<br />Test of validity of period (timestamp expiration)<br />Trust in certificate issuer<br />Check revocation status of certificates<br /> In return the receiving START AP must sign and include its certificate in any responses.<br /> Sending AP have the possibility to verify that returned certificate is the same that was included in SMP reply.<br />
  23. 23. SOAP Faults<br />Page 22<br />In case of error in the transaction the START AP can return 5 faults<br />Channel Full Fault<br />Unknown Endpoint<br />Security Error<br />Document Type Not Accepted<br />Server Error<br />The detailed information about fault handling in the START specification contains contradictions. A corrigendum will be issued shortly.<br />
  24. 24. Environment<br />Page 23<br />Previous version of Metro WS Framework contained a bug! <br />It is essential to upgrade Metro, to version 2.1<br />Similar bug may exist in .NET WCF (unconfirmed!)<br />Environments proven to work<br />GlassFish 2.1.1 with Metro 2.1, Windows and Linux<br />Tomcat 6 with Metro 2.1, Linux<br />
  25. 25. About the certificates<br />Page 24<br />Three certificates can be issued<br />START AP Certificate<br />SMP Certificate<br />Security Token Service (STS) Certificate<br />START AP Certificate<br />Used to authenticate START AP (both sending and receiving) <br />Can be attached in SMP responses<br />Can be used to authenticate the sender<br />SMP Certificate<br />Used to authenticate response from SMP service<br />Used for client authentication when managing SML<br />Security Token Service Certificate<br />Used in a “holder-of-key”-scenario by a 3rd party<br />
  26. 26. Certificate Hierarchy<br />Page 25<br />Hierarchy of certificates<br />One Root CA<br />Three Intermediate CAs<br />
  27. 27. Certificate Revocation<br />Page 26<br />Certificates are issued by Verisign on behalf of the PEPPOL consortium.<br />Certificates can be revoked by the issuer<br />Certificate still looks valid<br />Needs to be checked against revocation list (usually a mechanism not enabled by default in most application servers)<br />Can be solved by:<br />Certificate Revocation List (CRL)<br />Online Certificate Status Protocol (OCSP)<br />
  28. 28. Page 27<br />Questions…<br />
  29. 29. eProcurementwithout borders in Europe<br /><br />