How AS2 works | Aayu Technologies
EDI and AS2 Gateways by Aayu Technologies
mft gateway logo as2 gateway logo edi generator logo
Link Search Menu Expand Document
logo
Contact

How AS2 Works

This guide provides a comprehensive description of the operation of the AS2 protocol.

The high level layout is broken down as follows:

  • How does AS2 work?
  • Key components of an AS2 system
  • Message flow in AS2

1 How does AS2 work?

Internal applications, first generate files for transmission to partners. Most of such files are Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format, or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format. Enterprise Resource Planning or Line of Business systems are examples of systems generating such files. Such files are submitted to AS2 communications software for transmission to partners. Partner details are defined to the AS2 software, and includes the partner AS2 identifier, URL, and certificates. Upstream applications are integrated with the AS2 software using API’s,
shared directories, SFTP or messaging etc.

An AS2 solution performs the exchange of files as per the protocol defined by the RFC 4130. Its core components and the message flow are defined below.

AS2 Software as a service

2 Key components of an AS2 system

2.1 AS2 Station

An AS2 Station defines an AS2 communications profile for an organization. This includes the AS2 identifier, key-pair and certificate. Most organizations define a single station. Some define separate stations for Testing and Production use. Organizations can also create separate stations for different business units or identities. Each AS2 station should have a descriptive AS2 identifier. e.g.

  • ACME_COMPANY - Single AS2 Station used for both testing and production use. The simplest form for most organizations

  • ACME_TEST, ACME_PROD - Two stations for testing and production use. Used by large organizations. Not required for SMBs

  • ACME_MANUFACTURING, ACME_DISTRIBUTION - Multiple stations used by different business units of the same organization. Only useful for very large organizations

2.2 Partner Directory

A Partner directory holds AS2 identifiers, URLs and certificates of all configured partners. Partner directories allow the easier management of partner details, as some partners use non-human friendly IDs as AS2 identifiers.

2.3 Certificate Store

Certificate store lists all certificates used by the stations and partners. This information is useful to understand upcoming expiry dates for certificates. Certificates rotated upon expiry, and new certificates, are usually provided in advance by partners. Each Station also includes its private key along with its public key / certificate.

2.4 Mailboxes

Mailboxes such as an Inbox and Outbox stores received and sent messages. Mailboxes are like email folders, and helps to organize and view messages. New messages could be composed or sent, and received messages downloaded and viewed. Each message will also show its MDN status as successful or failed.

2.5 Integration

AS2 solutions may expose multiple options for integration with existing systems that generates and processes files. Common options available are the following:

  • API’s - e.g. REST APIs
  • SFTP servers
  • AWS S3 bucket integration
  • Shared file system locations / NFS
  • Messaging systems

Most systems based around files such as SFTP, S3 or local shared folder will have a directory structure as follows. In addition, there maybe directories for failed transfers.

  • Outgoing files to be places: e.g. AS2/send/<station-AS2-id>/<partner-AS2-id>/
  • Incoming files received: e.g. AS2/files/<station-AS2-id>/<partner-AS2-id>/inbox/
  • Outgoing files after send: e.g. AS2/files/<station-AS2-id>/<partner-AS2-id>/outbox/

Most APIs based around REST may expose URIs such as follows.

  • Submit messages: e.g. POST /message/submit
  • List messages received: e.g. GET /message/inbox
  • List messages sent: e.g. GET /message/outbox
  • Download specific message by ID: e.g. GET /message/inbox/<msg-id>

3 Message flow in AS2

Internal steps of AS2 communications

3.1 At the Sender

  1. Use a secure hash function to calculate the Message Integrity Check (MIC) or the Message Digest. The hash algorithms most commonly used are MD5, SHA-1 or SHA-256
  2. Digitally sign the file content using the sender’s private key, and place the file contents and signature into a MIME message.
  3. Encrypt the MIME message with the file contents and signature, using the receiver’s public key or certificate. Overwrite the MIME message with the now encrypted content. (Note when decrypted, this the contents of step #2 above will be available, including the signature, and the file contents)
  4. Add AS2 protocol specific headers such as AS2-From, AS2-To etc, and transmit S/MIME message as a HTTP POST to the partner’s URL

3.2 At the Receiver

  1. Check received message AS2 headers to verify that the received message is intended for the recipient, and the sender is known.
  2. Decrypt the outermost payload using the receiver’s private key
  3. Verify the digital signature placed by the sender, to verify the partner sending the message, and the payload was not altered
  4. Compute Message Integrity Check (MIC), by hashing the original payload received
  5. Create Message Disposition Notification (MDN) by digitally signing the received MIC with the receiver’s private key.
  6. Send the MDN back to the sender using the HTTP response (i.e. synchronous MDN) or a new HTTP message (i.e. asynchronous MDN)

3.3 At the Sender, receiving an MDN

  1. After receiving an MDN, verify its signature with the partner’s certificate to confirm it was digitally signed and sent by the claimed partner which received the original message intact.
  2. Store the successful (or failed) MDN for non-repudiation, investigation or troubleshooting.

3.4 Notes

  • HTTPS can be used instead of HTTP as the transport mechanism, although using HTTP still provides all the guarantees of AS2
  • Signing, Encryption and MDNs are not enforced by the AS2 specification, and are left for the individual partners to decide and use.
  • The certificates of each of the partners contain the public key of its asymmetric key pair. These are exchanged prior to receiving messages from such partners, usually over email.
  • Certificates used in AS2 does not require signing by a third party trusted Certification Authority (CA). However, certain industries (e.g. Energy industry in Europe) may require such signed certificates.