How does AS2 works in IBM Sterling Integrator (EDI)

 

What is AS2?

AS2 (Applicability Standard 2) is an EDI specification intended to ensure the proper level of security for data transmitted over the Internet.

The AS2 protocol is based on HTTP. It was the second ASx protocol developed and uses the same signing, encryption and MDN conventions used in the original AS1 protocol.

AS2 is the most popular of the ASx protocols but usually requires more work to set up than AS1 or AS3.

 

2. How AS2 Works

AS2 addresses security for data transmitted via the HTTP (Hypertext Transfer Protocol) transport protocol (or its more secure version, HTTPS) over the Internet or over any TCP/IP network. It does this through the use of encryption and digital signatures, using a format called S/MIME (Secure Multi-Purpose Internet Mail Extension), and the use of receipts called MDNs (Message Disposition Notifications).

MDNs contain information about the delivery status of the message. In this way, MDNs allow for a particular benefit called “nonrepudiation,” which means the recipient of a message cannot deny having received it.

 

3. Comparing AS2 vs. AS1 and AS3

AS1, AS2 and AS3 are all standards from EDIINT (EDI over the INTernet) for the secure transfer of data over the Internet. All include the same conventions for encryption and digital signatures. Where they differ is in the communications protocol they each address. While AS2 is specific to HTTP (or HTTPs), AS1 refers to data transmitted via email, using SMTP (Simple Mail Transfer Protocol). AS3 applies to files exchanged via FTP (including sFTP or FTPs).

 

4. Communicating via AS2

Although exchanging data via AS2 is typically handled automatically by AS2 software (Sterling B2B Integrator), it is important to understand the process and what you need to get going. Here are the key elements:

 

• Secure Certificates and Keys - AS2 utilizes a very common method called public-key cryptography for securing AS2 messages. Certificates are created that contain keys for encrypting and decrypting your data. One key, called the “Private” key, is used for both decryption and signing messages and should always be protected. A “Public” key, which is used for encryption and verifying the sender's signature, is intended to be shared with your trading partners so they can “encode” messages for you.
• AS2 ID – essentially the name that identifies you as the source of your messages, an AS2 ID is for verification through the use of digital signatures.
• AS2 URL – to send and receive information over the Internet, you need a unique AS2 web address. This is typically set up as as2.yourdomain.com.
• Communications Port – in order to connect with your trading partners, you need to open a communications port in your system. Port 4080 is a commonly utilized port.

Note: System Certificates contains Private keys and corresponding Certificates. Trusted Certificates contains Public Keys that can be used for cryptographic operations like encryption and signature verification.

To begin exchanging data via AS2 with a trading partner, you will need to exchange public keys, AS2 IDs, AS2 URLs and port information. If you are running AS2 software, you will need to enter this information, and then specify what the software should do with new inbound messages and where to find new outbound messages. The software will “listen” for new inbound messages, and send new outbound messages automatically.

4.1. AS2 with Synchronous MDN

1.       You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message. (Both the encryption and signing steps are optional, but should be used when possible.)

2.       You send the AS2 message to your partner's AS2 server AND WAIT UNTIL YOUR PARTNER RETURNS AN "MDN" RESPONSE. (Credentials and cleartext message headers may be protected with SSL transport in this step.)

3.       Your partner will retrieve your AS2 message off his/her AS2 server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)

4.       If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS2 message to verify that the data file they now have is identical to the data file you sent them.

5.       If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message. (The signing step is optional and controlled by the original message sender.)

6.       Your partner will send his/her MDN delivery receipt message back as a response to your still-waiting AS2 "send message and get MDN" request. Once you receive this response (or time out while waiting) you will close your connection. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)

7.       You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.

4.1. AS2 with Asynchronous MDN

1. You encrypt a data file with the public key on your partner's SSL certificate and sign it with the private key of your organization's SSL certificate as you bundle everything into an AS2 message. (Both the encryption and signing steps are optional, but should be used when possible.)
2. You send the AS2 message to your partner's AS2 server and close the connection. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
3. Your partner will retrieve your AS2 message off his/her AS2 server. (Credentials and cleartext message headers may be protected with SSL transport in this step.)
4. If the message is encrypted, your partner will decrypt it using the private key on his/her SSL certificate. If the message is signed, your partner will validate your signature using the public key on your SSL certificate. Your partner will also use the contents of the AS2 message to verify that the data file they now have is identical to the data file you sent them.
5. If you requested an MDN delivery receipt for your data file, your partner will calculate a cryptographic hash from the data file they received, sign the hash (and some other information) with the private key on their SSL certificate and create an MDN delivery receipt message. (The signing step is optional and controlled by the original message sender.)
6. Your partner will send his/her MDN delivery receipt message back by posting it to your AS2 server. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
7. You will retrieve your partner's MDN delivery receipt message off your AS2 server. (Credentials and the cleartext MDN delivery receipt message may be protected with SSL transport in this step.)
8. You will inspect your partner's MDN delivery receipt message, making sure that you can verify his/her signature using the public key on your partner's SSL certificate and that the cryptographic hash calculated from your partner's copy of your data file matches the same hash calculation from your original data file.