Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Peppol online ws. 3 start and agreements

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

  • Login to see the comments

  • Be the first to like this

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 />