Applicability statement 2 – more commonly referred to as AS2 – is a protocol which is used to exchange business data in a safe and secure way via HTTP. Today the AS2 EDI protocol is one of the most popular ways that businesses exchange EDI messages with their partners.
In this article we’ll explore how the AS2 protocol works and why it is so popular in the EDI sphere.
AS2’s growing usage
On the face of it, AS2 is simply one of a number of different protocols that are available to businesses when it comes to exchanging EDI data with one another. However, AS2 is increasingly being recognised as the most reliable and attractive EDI protocol for businesses across all industries.
The reason for AS2’s impressive reputation can be boiled down to three key benefits that it offers users:
- Security
When messages are sent via AS2 they are encrypted by the sender and have to be decrypted by the receiver. This provides a layer of security that is crucial given the business-critical nature of the information being exchanged.
- Transparency
When using AS2, the sender will always get an acknowledgement notifying them if their partner has successfully received the message or not. Plus every message has a unique identifier, which makes tracing very easy.
- Convenience
AS2 is extremely popular with large supply chain organisations. In the retail sphere, for example, Walmart, Amazon and Migros all require suppliers to use AS2 – with Walmart having done so since 2002. This has had a knock-on effect on supply chains across the world, meaning AS2 is now the logical choice for customers and suppliers alike. Moreover, the fact that AS2 uses HTTP to exchange messages is also beneficial, as HTTP’s own popularity and high level of standardisation makes debugging simple.
What are the key attributes of the AS2 protocol?
Keys and certificates
One central feature of the AS2 protocol is the use of keys. In AS2 exchanges, sender and receiver have both a public and private key. These public and private keys are mathematically related, with the public key being calculated using the private key.
Public keys are meant to be shared with partners, and allow recipients to verify message authenticity without requiring the sender’s private key. If the system just required each party to have a public key, there would be no way to verify that a message wasn’t sent by a fraudulent party.
In AS2 exchanges, a certificate contains the public key of a party, together with a signature, which can be made using the private key of a trusted certificate authority (CA).
Key stores
Key stores are containers that hold several private keys and certificates. Two common use cases of containers are identity stores and trust stores. The first holds a private key with the corresponding public certificate. The latter holds a set of certificates, e.g. from CAs.
Key stores are usually single files with different extensions. Common extensions are .jks (Java Key Store) and .p12 (present industry standard).
Encryption
Data encryption is a key aspect of the AS2 protocol as it ensures the security of the data being transmitted. In exchanges sent via AS2 the sender encrypts the payload with the public key of the receiver. This ensures that only the receiver (who has the relevant private key) can decrypt the message.
Most commonly used AS2 encryption algorithms = Triple DES (3DES) and AES-256 (both state-of-the art encryption algorithms)
Digital Signatures
In addition to encryption, AS2 also uses digital signatures, which allow the user to guarantee the authenticity of the sender/receiver. First, the sender signs the payload with a private key. The receiver then verifies the origin and authenticity of the message using the sender’s public key.
Most commonly used AS2 signature algorithms = SHA1, SHA256 and SHA512
Acknowledgements
In AS2 EDI exchanges, a Message Disposition Notification (MDN) serves as an acknowledgement of the message transfer to ensure non-repudiation. It is a digitally signed receipt of a file which is received by the recipient and sent back to the message sender.
Hash Function / MIC
The message integrity check (MIC) is connected to the MDN, and ensures the integrity of the message content. It is calculated with a secure hash function over the payload. The receiver calculates the MIC over the received payload and sends the MDN, including the MIC value, back to the sender. If the returned MIC value equals the original calculated MIC value, the payload is an integer.
How AS2’s secure transmission loop works
The diagram below shows how a message is transmitted from sender to receiver, and how the receipt of the message is communicated back to the sender.
[click to enlarge]
On the sender’s side…
1) The message integrity check (MIC) is completed using a secure hash function.
2) The sender then digitally signs the message content with their private key and the file content (including the signature) is placed in a MIME message.
3) The MIME message, which includes the file content and the digital signature, is encrypted using the receiver’s public key (certificate).
4) Before the data is transmitted via HTTP, specific AS2 EDI headers are added, e.g. AS2-FROM and AS2-TO. Additionally, a request for the return of a signed receipt is requested.
On the receiver’s side…
5) The message AS2 headers are checked to verify if sender and receiver are correct.
6) The receiver then decrypts the message with their private key.
7) To verify the sending partner (and that the payload wasn’t changed), the signature is verified with the sender’s public key (certificate). If both steps are successful, the integrity of the data and authenticity of the sender can be guaranteed.
8) The receiver returns the signed receipt as confirmation (MDN). This receipt contains the hash value of the message (MIC). Therefore, the sender has confirmation of the proper authentication and decryption of the receiver. The MDN is also transmitted via HTTP, either synchronously during the same session or asynchronously within a different session than the sender’s original session.
Back on the sender’s side…
9) The signature of the MDN is verified with the receiving partners certificate, confirming that the MDN was digitally signed.
10) The MDN is stored for non-repudiation or troubleshooting purposes.
Setting up an AS2 EDI connection
Before you can start exchanging messages via AS2 with partners, it is necessary to complete several steps. The first and most important of these is setting up the relevant AS2 software.
Software setup
For businesses in this position there are three distinct approaches to choose between: installing the software on-premise, installing via the cloud, or opting for a Software as a Service (SaaS) solution.
1) Installing on-premise
Traditionally, on-premise installation has been the most popular approach for achieving AS2 compatibility (be it on company servers or virtual machines).
Pros
- Simple to meet data localisation requirements
- Tight integration with internal systems possible
Cons
- Expensive, especially when operational and maintenance costs are accounted for
- Integration with cloud-based systems (e.g. Google storage) can be difficult
2) Installing via the cloud
A cloud-based approach offers a simple way to satisfy regulatory requirements while leveraging the flexibility and availability of the cloud.
Pros
- Excellent scalability and availability
- Greater capacity for integration with cloud services
- Lower cost than in-house installation thanks to much simpler operation and maintenance
Cons
- Integrating with legacy in-house technology can be difficult
3) Utilising an SaaS provider
Using a SaaS provider offers a quick way to achieve AS2 EDI connectivity, with users able to sign up and configure AS2 settings themselves via a web interface.
Pros
- High potential for cost savings, particularly for businesses sending a low volume of messages via AS2, as payment is typically managed on a per use basis
- AS2 connectivity can be achieved extremely fast
- No maintenance or operational costs
Cons
- Can be difficult to meet specific data localisation or network requirements.
- As with cloud-based installations, integration with in-house legacy technology may be tricky
Creating a partner profile
Once access to AS2 EDI software has been achieved (either via on-premise installation, the cloud or an SaaS solution) both you and your partner must provide the other with your AS2 identifier, URL and certificate.
Both parties must then create a ‘Partner’ entity within the AS2 software using this information.
Testing
After partner profiles have been created, the next step is to test connectivity. This is done by exchanging basic text files, which can then be verified for integrity by the receiver. During this stage it is also advisable to test the sending and receiving of MDNs.
The AS2 connection is deemed complete and validated only when both partners can exchange files successfully.
Final setup and go-live
Once testing has been successfully completed, the AS2 connection can be made live.
Looking to experience the benefits of EDI with minimal internal effort?
Whether it’s setting up an AS2 EDI connection, handling complicated EDI mappings, or simply liaising with partners during onboardings, EDI processes can be technical and time consuming.
Thankfully, however, effective EDI doesn’t have to be difficult!
At ecosio we understand the importance of successful, reliable EDI connections, and are passionate about helping our clients to experience EDI’s full potential. As we know that supply chain organisations don’t always have the time or expertise to integrate, run and maintain an EDI solution, we offer a fully managed service, allowing businesses to experience all the benefits of efficient EDI with none of the hassle.
With a single connection to ecosio’s powerful Integration Hub, you can achieve hassle-free connections to all your partners, no matter how complicated your routing or mapping requirements.
In short, we take care of all your EDI needs, from liaising with partners and setting up connections to message monitoring and error resolution, leaving you to concentrate on what you do best.
For more information, contact us today!
