wiki

Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Friday, February 5, 2016 12:50 PM

Toon Vanhoutte by Toon Vanhoutte

This blog post series aims to provide an introduction to AS4, a recent B2B messaging standard. It provides the basic insights on how AS4 establishes a reliable and secure message exchange between trading partners. This is a jump start to get to know the ins and outs of the standard, as the specifications are quite complex to understand without any prior introduction.

If you are active in B2B/B2C messaging, then AS4 is definitely coming your way! Make sure you are prepared.

AS2 Comparison

As AS4 is inspired by AS2, both are often considered in message exchange over the internet. On a high level, they are very similar, however there are some key differences that you should be aware of in order to make a profound decision on this matter. Let’s have a look!

Common Characteristics

These are the most important common characteristics of AS2 and AS4:

  • Payload agnostic: both messaging protocols are payload agnostic, so they support any kind of payload to be exchanged: XML, flat file, EDI, HL7, PDF, binary…
  • Payload compression: AS2 and AS4 support both compression of the exchanged messages, in order to reduce bandwidth. It’s however done via totally different algorithms.
  • Signing and encryption: the two protocols support both signing and encryption of the exchanged payloads. It’s a trading partner agreement whether to apply it or not.
  • Non-repudiation: the biggest similarity is the way non-repudiation of origin and receipt are achieved. This is done by applying signing and using acknowledgement mechanisms.

Technology Differences

The common characteristics are established by using totally different technologies:

  • Message packaging: within AS2, the message packaging is purely MIME based. In AS4, this is governed by SOAP with Attachments, a combination of MIME and SOAP.
  • Security: AS2 applies security via the S/MIME specifications, whereas AS4’s security model is based on the well-known WS-Security standard.
  • Acknowledgements: in AS2 and AS4, acknowledgements are introduced to support reliable messaging and non-repudiation of receipt. In AS2 this is done by so-called Message Disposition Notifications (MDN), AS4 uses signed Receipts.

AS4 Differentiators

These are the main reasons why AS4 could be chosen, instead of AS2. If none of these features are applicable to your scenario, AS2 might be the best option as it is currently more known and widely adopted.

  • Support for multiple payloads: AS4 has full support for exchanging more than one business payload. Custom key/value properties for each payload are available.
  • Support for native web services: being built on top of SOAP with Attachments, AS4 offers native web service support. It’s a drawback that SwA is not supported out-of-the-box by .NET.
  • Support for pulling: this feature is very important if message exchange is required with a trading partner that cannot offer high availability or static addressing.
  • Support for lightweight client implementations: three conformance clauses are defined within AS4, so client applications must not support immediately the full AS4 feature stack.
  • Support for modern crypto algorithms: in case data protection is an important aspect, AS4 can offer more modern and less vulnerable crypto algorithms.
  • Support for more authentication types: AS4 supports username-password and X.509 authentication. There is also a conformance clause on SAML authentication within AS4.

Getting Started

Are you interested to learn more on AS4?

From an architecture / specifications perspective it’s good to have a look at the related OASIS standards. This includes the ebMS 3.0 Core Specifications and the AS4 profile of ebMS 3.0. In case you are more interested on how an AS4 usage profile could be described between trading partners, this ENTSOG AS4 Usage Profile is a great example.

If you’re more developer oriented, it’s good to have a look at Holodeck B2B. It is a java-based open-source software that fully supports the AS4 profile. Some sample files provide you a head start in creating your first AS4 messages. Unfortunately SOAP with Attachments or AS4 is not supported out-of-the-box within Microsoft .NET.

Can we help you?

Codit is closely involved with AS4. It is represented in the OASIS ebXML Messaging Services TC by Toon Vanhoutte, as a contributing member. In this way, Codit keeps a close eye on the evolution of the AS4 messaging standard. Throughout several projects, Codit has gained an extended expertise in AS4. Do not hesitate to contact us if you need any assistance on architecture, analysis or development of your AS4 implementation.

Within our R&D department, we have developed a base .NET library with support for the main AS4 features. In the demo for Integration Monday, this library was plugged into the BizTalk Server engine in order to create AS4 compatible messages. At the time of writing, Codit is defining its AS4 offering. If you would like to be informed about the strategy of Codit when it comes to AS4, please reach out to us. We will be more than happy to exchange ideas.

Categories: Community
written by: Toon Vanhoutte

Posted on Thursday, February 4, 2016 4:39 PM

Toon Vanhoutte by Toon Vanhoutte

This blog post series aims to provide an introduction to AS4, a recent B2B messaging standard. It provides the basic insights on how AS4 establishes a reliable and secure message exchange between trading partners. This is a jump start to get to know the ins and outs of the standard, as the specifications are quite complex to understand without any prior introduction.

Security is a crucial aspect of every messaging standard, so it is for AS4! This section describes the most common mechanisms to establish a secure AS4 communication.

Non-repudiation of origin

In order to guarantee message integrity, it’s important to have non-repudiation of origin. This means that the receiver is a 100% sure that the message originates from the sending party and that the message was unmodified during the exchange.

AS4 provides this evidence by applying the WS-Security signing feature on User Messages. This message signing is performed via asymmetric keys: the sender of the message signs with its own private key and the receiver authenticates the sender via the public key, which could be included in the message as a BinarySecurityToken.

According to the AS4 usage profile, the following parts of the ebMS message must be signed:

  • The ebMS Messaging Header
  • The SOAP Body
  • All SOAP Attachments

The receiving MSH checks if the hash values within the signature correspond to the actual received payloads. If not, an ebMS Error is generated and sent to the sending MSH, according to the agreed P-Mode configuration.

Non-repudiation of receipt

Another important aspect is non-repudiation of receipt. This means that the sender is a 100% sure that receiver has received the message, without being modified during the message exchange.

AS4 provides legal proof for this non-repudiation of receipt, by applying the WS-Security signing feature on Receipts. The exchanged Receipts are signed by the receiving MSH, which authenticates the originator of the receipt. The signature of Receipts must be applied on the ebMS Messaging Header.

In addition to this signature, the ebMS Messaging Header must include Non Repudiation Information within the Receipt element. This Non Repudiation Information contains the hashes of the signed payloads of the referenced User Message. This information is verified again at the sending MSH, in order to establish evidence for non-repudiation of receipt.

Data confidentiality

Data confidentiality can be ensured on both the communication and message level.

Encryption, which ensures data confidentiality, on the communication channel could be applied by using Transport Layer Security (SSL). Due to known vulnerabilities in this HTTPS protocol, it is recommended to use TLS 1.1 or higher. TLS may be offloaded to specific infrastructure components (e.g. proxy), so an AS4 MSH does not need to explicitly offer this functionality.

Data confidentiality on the message level could be achieved by leveraging the WS-Security encryption feature on User Messages. This message encryption is performed via asymmetric keys: the sender of the message encrypts with the public key of the receiver, so the message can only be decrypted by the receiver, who owns the private key. Encryption must be applied on:

  • The SOAP Body
  • All SOAP Attachments

In case the receiving MSH is unable to decrypt the message, an ebMS Error is generated and sent to the sending MSH, according to the agreed P-Mode configuration.

 

written by: Toon Vanhoutte

Posted on Wednesday, February 3, 2016 4:17 PM

Toon Vanhoutte by Toon Vanhoutte

This blog post series aims to provide an introduction to AS4, a recent B2B messaging standard. It provides the basic insights on how AS4 establishes a reliable and secure message exchange between trading partners. This is a jump start to get to know the ins and outs of the standard, as the specifications are quite complex to understand without any prior introduction.

Reliable Messaging

Reliable messaging is established by exchanging positive (Receipts) and negative (Errors) acknowledgements on the processing of User Messages. For completeness, their descriptions are repeated here:

  • The Receipt is a positive acknowledgement. It indicates that the receiving MSH was able to parse the incoming message without an exception. This ensures the Receive operations was successful. It’s an implementation choice whether to send the Receipt before or after the Deliver operation towards the message consumer.

  • The Error is a negative acknowledgement. It indicates that the receiving MSH encountered an issue during the parsing of the incoming message. The ebMS 3.0 specifications define a list of standard error codes and their meaning.

AS4 establishes once-and-only-once delivery, if both the sending and the receiving MSH conform to the required AS4 reliability capabilities.

Reception Awareness

The sending MSH must support reception awareness. This feature requires the ability to detect the fact that no corresponding Receipt was received for a specific User Message, within a configurable time interval. In case this happens, the sending MSH must be able to report this issue to the business application (message producer).

As a sending MSH, it is recommended to also support message retry. This means resending the same message (with identical ebMS MessageId) when reception awareness triggers a missing Receipt. This message retry can be configured with a specific retry policy, which includes a retry count and a time interval between retries. In case a User Message is resent, the sending MSH must ensure that the hash values, included in the signature, are identical to the ones within the original User Message.

These requirements ensure that the sending party is aware whether the User Message was received correctly by the receiving party or not.

Duplicate Detection

The receiving MSH must support duplicate detection. If the sending MSH triggers a message retry, then it could be that the message is received multiple times. In order to assure only-once delivery, the receiving MSH must perform duplicate detection, based on the ebMS MessageId.

Duplicate detection preferably leads to the elimination of duplicate messages in the receiving MSH. If this duplicate elimination is not performed by the receiving MSH, it must at least notify the receiving business application (message consumer) of this event.

It’s an implementation choice how this duplicated detection is parameterized. It could be that there’s a configurable time window for duplicate detection or a maximum log size for the history of received MessageId’s.

Categories: Community
written by: Toon Vanhoutte

Posted on Wednesday, February 3, 2016 10:09 AM

This blog post series aims to provide an introduction to AS4, a recent B2B messaging standard. It provides the basic insights on how AS4 establishes a reliable and secure message exchange between trading partners. This is a jump start to get to know the ins and outs of the standard, as the specifications are quite complex to understand without any prior introduction.

Messaging Model

The messaging model defines the following components in a message exchange between two parties. A clear separation between business and AS4 components is considered.

  • The Messaging Services Handler (MSH) is responsible to establish the AS4 message exchange with the other party on both sending and receiving side. Communication with the other party must be in conformance with the AS4 specifications. The MSH must also be able to communicate with the internal business application. This can be done in an implementation specific way, which is out of scope for the AS4 usage profile. An AS4 MSH typically resides in your integration/middleware layer.

  • The Business Application interacts in a loosely coupled manner with the MSH. The message producer initiates the message exchange at sender side, whereas the message consumer processes the message at receiver side. ERP and CRM systems are good examples of business applications within this context.

The interaction between these components is defined in abstract operations, such as Submit, Send, Receive, Deliver and Notify. The Send and Receive operations are governed by a P-Mode configuration, which is an agreement between the parties on how the AS4 message exchange will be applied. The P-Mode configures all areas of the message exchange: the protocol, business info, error handling, reliability and security.

Message Types

The ebMS 3.0 specifications define 4 different message types, which have been given a more specific definition within the AS4 usage profile.

  • The User Message contains the actual business payload that is exchanged amongst the business applications of two parties.

  • Signal Messages have a supporting role in order to establish message exchange patterns, non-repudiation and reliability. They are restricted to the sending and receiving MSH. There are 3 types of Signal Messages:

    • The Receipt is a positive acknowledgement. It indicates that the receiving MSH was able to parse the incoming message without an exception. This ensures the Receive operations was successful. It’s an implementation choice whether to send the Receipt before or after the Deliver operation towards the message consumer.
    • The Error is a negative acknowledgement. It indicates that the receiving MSH encountered an issue during the parsing of the incoming message. The ebMS 3.0 specifications define a list of standard error codes and their meaning.
    • The Pull Request is in support of the pull message exchange pattern, described in the next topic. It allows the receiving MSH to interrogate the sending MSH for the next available message on a specific queue (MPC).

Message Exchange Patterns

Whereas the ebMS 3.0 specification defines several message exchange patterns, the AS4 usage profile only demands support for two of them. The agreed message exchange pattern is configured within the P-Mode configuration.

  • Within the one-way/push pattern, the sending MSH initiates the communication and sends the message to the receiving MSH. This exchange may occur on both one-way and two-way underlying transport channels.

  • When applying the one-way/pull pattern, the receiving MSH initiates the communication and sends a request for a new message to the sending MSH. The sending MSH returns the message as the response of the two-way transport channel. In case there’s no message available, an ebMS Error (with warning severity) is returned by the sending MSH. This pulling mechanism is ideal for receiving parties that are not high available and do not have a static address.

Message Packaging

AS4 uses SOAP with Attachments as a message format. This is a MIME payload (multi-part), which contains a SOAP envelope as the first MIME part. This SOAP envelope holds the UserMessage, Receipt, Error or PullRequest. In case of the UserMessage, the business payloads that are exchanged are located in the SOAP Body (only allowed for XML data) or in other SOAP Attachments (read MIME parts). Within AS4, there is support for gzip compression of the payloads in the SOAP Attachments.

A User Message consists of the following segments:

  • MessageInfo contains the unique MessageId and the timestamp of the message.
  • PartyInfo identifies the sender and receiver of the message.
  • CollaborationInfo describes the business context through a service and action parameter
  • MessageProperties offer an extension point to add additional business information
  • PayloadInfo makes a reference to the payloads in the SOAP Body or Attachments

A Signal Message consists of the following segments:

  • MessageInfo contains the unique MessageId, the MessageId of the referenced User Message and the timestamp of the message.
  • One of these segments:
    • Receipt which contains the proof of non-repudiation of receipt. This is further explained in the next parts of this blog post series.
    • Error which contains a particular error code and description.
    • Pull Request which contains the queue (MPC) it requests a message from.
Categories: Community

Posted on Monday, February 1, 2016 5:00 PM

Toon Vanhoutte by Toon Vanhoutte

This blog post series aims to provide an introduction to AS4, a recent B2B messaging standard. It provides the basic insights on how AS4 establishes a reliable and secure message exchange between trading partners. This is a jump start to get to know the ins and outs of the standard, as the specifications are quite complex to understand without any prior introduction.

The content of this blog post series has also been presented during an Integration Monday  session of the Integration User Group, within the Microsoft community. Check out the video, which includes some nice demos of the interoperability of Microsoft .NET with AS4.

What is AS4?

AS4 defines a standardized, secure and reliable exchange of messages, containing one or multiple payloads. These are the key features of the messaging standard:

  • Interoperable: AS4 is defined as an OASIS standard. It is built on top of existing standards, which have proven interoperability in the past: MIME, SOAP and WS-Security.
  • Secure: AS4 uses a subset of the WS-Security features in order to assure message non repudiation and data confidentiality.
  • Reliable: AS4 guarantees once-and-only-once delivery, via the exchange of acknowledgements and additional requirements on both send and receive side.
  • Payload   agnostic: AS4 can exchange any kind of payloads (XML, JSON, HL7, EDI, binary …) and it supports also multiple payloads being sent in one AS4 message.

A Short History

AS4 originates from ebXML (Electronic Business XML), which enables enterprises to conduct business over the internet. Here’s a short overview of how AS4 was originated:

  • 2002 – ebMS 2.0 : ebXML Messaging Services version 2.0 defines a communications-protocol neutral method for exchanging electronic business messages, using a flexible enveloping technique.

  • 2007 – ebMS 3.0 Core Features : ebXML Messaging Services version 3.0 core specification defines message packaging and provides several options to deal with message exchange patterns, error handling, security and reliability.

  • 2010 – ebMS 3.0 Advanced Features : ebXML Messaging Services version 3.0 advanced features adds some extra features and scenarios to ebMS 3.0. The most important are: multi-hop messaging, message bundling and a split/join mechanism for large messages.

  • 2013 – AS4 Profile of ebMS 3.0 : this AS4 profile has the success of AS2 in mind and applies the same “just enough” design principles in order to narrow down the options of ebMS 3.0, which results in a simplified usage profile of ebMS 3.0. AS4 defines 3 possible conformances clauses: minimal client (minimal feature set), light client and the eb handler (richest feature set).

This history makes AS4 a rather difficult standard to read, as it is spread across multiple specifications.

Where is AS4 applied?

Even though it is a rather recent standard, AS4 gains more and more interest from organizations that want to expand their B2B/B2C capabilities. In Europe, eSENS e-delivery promotes and funds the usage of AS4 for all cross-border communication between member states. This results in many large-scale projects that are looking into AS4. Also outside the European borders, AS4 is adopted. Here’s a non-exhaustive list of known projects / organizations that are applying AS4, spread over different sectors, with implementation levels going from design phase, over piloting, until production ready.

  • Australia:  Superstream  Pensions
  • Europe:  PEPPOL  (Pan-European Public Procurement Online)
  • Europe:  ENTSOG  (European Network of Transmission System Operators for Gas)
  • Europe:  EESSI  (Electronic Exchange of Social Security Information)
  • Europe:  e-CODEX  (e-Justice Communication via Online Data Exchange)
  • Japan:  JEITA  (Japan Electronics and Information Technology Industries Association)
  • World Wide:  IATA  (International Air Transport Association)

Read more on AS4 in the coming days as this blog series will progress...

Categories: Community
written by: Toon Vanhoutte