What is AS2

AS2 is messaging standard which defines a secure and reliable way of sending business to business messages across the internet. It was created in 2002 by the IETF (Internet Engineering Task Force), and is now ubiquitous with EDI solutions, being used by used in large scales within eCommerce (Amazon, Target, Walmart), aerospace, and even within healthcare (AS2 meets legal HIPAA requirements)

Why use AS2 over SFTP or SOAP

SFTP is very widely used in many of the same EDI scenarios as AS2, however it has a number of disadvanatges, these include:

  • SFTP only provides a one way “fire and forget” interface. The client sending the message does not receive a positive acknowledgement from the server to say the message was successfully accepted by the client.
  • SFTP will usually rely on a username and password setup, which is prone to brute force attacks.
  • SFTP systems can include encryption, but they do not easily provide message signing. Message signing provides a mechanism where every message sent, and acknowledgement received, is verified to ensure the message really has come from who they say they are.
  • While SFTP system may have logs, that are not user friendly, and do not always provide a definite record of all messages sent and received. Using an AS2 platform like the EIS cloud relay provides this auditing out of the box.

SOAP (Simple Object Access Protocol) is a messaging standard in a similar way to AS2, however it encompasses a much large variety of configuration options. It is this variety which is the biggest downfall of SOAP, as many different vendors will implement a SOAP interface in different ways, making setup slower and more costly. In addition, the SOAP standard does not explicitly define a mechanism for async message acknowledgements. As such, while SOAP is often widely used within a single organisation, it is much less commonly used in business to business EDI solution.

How does AS2 work?

Ignoring encryption for a moment, AS2 can operate in 3 different modes. These are:

  • One way, no Message Disposition Notification (MDN)
    In this scenario, a client sends an AS2 message to a server using HTTP POST. The client waits for a HTTP 200 acknowledgment from the server, but does not wait for any other positive acknowledgement. This process can be thought of as fire and forget.
  • Two way, with synchronous Message Disposition Notification (MDN)
    In this scenario, a client sends an AS2 message to a server using HTTP POST, but then wait for an MDN message to be sent from the server back to the client. The response message can indicate either a success or failure to process the message, and can also include security features, such as a message signature so that the caller can verify the identity of who sent the MDN.
  • Two way, with a-synchronous Message Disposition Notification (MDN)
    In this scenario, a client sends an AS2 message to a server using HTTP POST, waits for a HTTP 200 acknowledgement, and the closes the connection. The server will then call back top the client in a new connection, and send an MDN message. As before, the response message can indicate either a success or failure to process the message, and can also include security features, such as a message signature so that the caller can verify the identity of who sent the MDN.
This shows a two way exchange pattern. By default messages will always be sent over HTTPS for security.

Security in AS2

One of biggest advantages in moving to AS2, is the security it can provide for business to business communications over the internet. While this topic can be complicated, it can be easier to thing of AS2 as having 3 different layers of security. These are:

  • Transport encryption using HTTPS
    The HTTPS protocol is ubiquitous in today’s internet. It provides a means of securely transferring data over the internet, and is used by millions of websites and services every day. AS2 uses HTTPS (sometimes called TLS) in the same way as any secure website.
  • Message signing
    Before an AS2 interface is setup, the sender and receiver will exchange certificates such that each party has a private key that only they have access to, and a public key provided by the other party.
    When each AS2 message is sent over a HTTPS channel, a signature is created using the private key. The system which receives the AS2 message, can then check the signature against the public key (which was provided previously) and verify that the caller is who they say they are, and the message has not been tampered with in any way.
    The process works for both the EDI message being sent, and the MDN response.
  • Message encryption
    In addition to sending the message over an encrypted channel, the message can also be encrypted as well, creating 2 levels of encryption. The encryption is implemented using pre-shared certificates in the same way as the message signing. This extra layer of security is not commonly used, but is available.
This shows a two way exchange pattern (as before). But know also with message signing using certificates. Certificate 1 will have been generated (or purchased) by the CLIENT, and Certificate 2 will have been generated (or purchased) by the SERVER.