The AS2 connector in Anypoint B2B adds the pervasive EDIINT integration standard over HTTP(s) to MuleSoft ESB. EDIINT AS2 satisfies the following key business requirements
AS2 is a protocol for exchanging any structured data in a reliable manner using MDNs (Message Disposition Notification’s) as a form of acknowledgement, which includes a MIC (Message Integrity Check). Consider AS2 when an acknowledgement pattern is needed and the trading partner already supports EDI over the Internet (EDIINT).
AS2 supports 12 different security and authentication permutations for validating authenticity of sending or receiving parties as well as validation of the exchanged data. These permutations start at
1. Sender sends un-encrypted data and does NOT request a receipt.
For non-sensitive business data, consider signed but un-encypted data over SSL
9. Sender sends signed data and requests a signed receipt.
Receiver sends back the signed receipt.
Reaching encrypted, signed
12. Sender sends encrypted and signed data and requests a signed receipt.
Receiver sends back the signed receipt.
When testing signed or encrypted interchanges, a bit more thought is involved than simply sending messages. With AS2, that means anything other than option 1. (But option 1 should not be used as a workaround because S/MIME isn’t used which means the MIME payload properties will not exist – see AS2 release notes for more information).
Keystore
Options 2-12, above, require a keystore. The keystore requires the organisation's PKI key pair such that signed or encrypted data can be generated using the private key which a 3rd party trading partner can validate or decrypt with the shared certificate (which contains the organisation's public key).
The keystore also requires the trading partners’ certificate to enable decryption and digital signature verification of the AS2 messages received from the trading partner.
When adding the keys or certificates to the keystore, we need to remember that the AS2 connector uses the alias to locate the appropriate key or certificate. These aliases must match the parties’ AS2 naming as used in the AS2-To and AS2-From message properties.
It is also recommended to create a key pair with an alias of signed-test to reduce the dependency on the trading partner for testing support.
Trading partners are never going to be as supportive during system testing as expected and a common requirement for independent testing emerges, ideally without changing the standard AS2 connector settings in SIT (System Integration Testing). The trading partner cannot be impersonated, because, with only a public key, AS2 requests and the MDN's cannot be signed or encrypted. Having the signed-test profile allows a bit of flexibility in working with a test harness such that messages can be sent from a tertiary trading entity.
As Receive and Send differ, they will be considered in order, below.
3.
<as2:receive config-ref="AS2-receive-connector" doc:name="AS2 (Streaming)" preferredMicAlgorithm="sha1" requireSenderSigns="true" keyStorePassword="as2-keystore" keyStorePath="as2-keystore.p12" requireSenderAs2To="my-enterprise"/>
AS2-To restriction validates that the intended recipient is my-enterprise. Leaving the AS2-To field empty allows multiple senders to send the AS2 messages. The AS2 receive connector will look in the keystore for the alias matching the received message AS2-From property. This will allow both the intended trading-partner and signed-test profiles to send messages to my-enterprise.
4.
<as2:send config-ref="fileAS2-TH-send-connector" doc:name="AS2" as2From="signed-test" as2To="my-enterprise" keyStorePassword="as2-keystore" keyStorePath="as2-keystore.p12" sign="true" requestReceipt="signed" requireSignedReceipt="true" contentType="text/plain"/>
Another flow can be made as a test harness to send to the Receive flow in SIT, as above. This profile will send to my-enterprise from signed-test, with signed-test being the recipient of the returned MDN.
Now that the Standard Receive is working, consider the inverse, Send.
5.
<as2:send config-ref="AS2-send-connector" doc:name="AS2" as2From="my-enterprise" as2To="trading-partner" keyStorePassword="as2-keystore" keyStorePath="as2-keystore.p12" sign="true" requestReceipt="signed" requireSignedReceipt="true" contentType="text/plain"/>
The trading-partner likely permits my-enterprise to send as and when required, automatically returning valid MDN’s, but if the received HTTP request properties or MIME message properties need to be reviewed or MDN scenarios need to be generated, a test harness may be necessary. If so, a test flow has to be created which accepts messages from my-enterprise. This flow requires a unique HTTP listener endpoint.
6.
<as2:receive config-ref="AS2-TH-receive-connector" doc:name="AS2 (Streaming)" preferredMicAlgorithm="sha1" requireSenderSigns="true" keyStorePassword="as2-keystore" keyStorePath="as2-keystore.p12" requireSenderAs2To="signed-test" requireSenderAs2From="my-enterprise"/>
A complication is that the Send AS2-To value must be set, so it is likely the send flow will need to be duplicated such that test harness’ HTTP and AS2 values can be set. If using files to test, a separate polling folder needs to be used.
7.
<as2:send config-ref="copyAS2-send-connector" doc:name="AS2" as2From="my-enterprise" as2To="signed-test" keyStorePassword="as2-keystore" keyStorePath="as2-keystore.p12" sign="true" requestReceipt="signed" requireSignedReceipt="true" contentType="text/plain"/>
Sending through this flow will allow the inspection of what is sent via the test harness. It will also allow the test harness to be forced to return negative MDNs by, say, changing the key alias or throwing an exception.
If you would like to find out more about how Systems Integration could help you make the most out of your current infrastructure while enabling you to open your digital horizons, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com
Other useful links:
API Recipes with MuleSoft Anypoint Platform