For information about Globalscape, visit www.globalscape.com. |
|
|
For information about Globalscape, visit www.globalscape.com. |
|
EFT Enterprise edition incorporates a Drummond-certified AS2 adapter to support inbound and outbound AS2 transfers. Drummond certified means that EFT's AS2 module has achieved interoperability with other Drummond-certified AS2 servers and clients.
AS2 Optional Profile Supported
EFT supports inbound AS2 Multiple Attachments (MA) for processing a single message with multiple payloads. MA messages are treated the same as normal messages with the exception that multiple files are processed.
EFT also supports the Reliability Profile, which consist of various internal methods for avoiding duplicate file processing standardizes mechanisms for retrying and resending AS2 Messages and MDNs.
What EFT's AS2 module does not support
EFT does not support non-encrypted payloads over plaintext HTTP, asynchronous MDN deliveries via SMTP for outbound transactions (but does support inbound ones), EDI file content manipulation (translation, extraction, transformation, loading), or outbound Multiple Attachments (MA). EFT does not determine if the data sent or received is usable; it only transfers the data. The AS2 module is "push only"; that is, EFT does not request files.
For security reasons, if you are transferring files using HTTP, the payload must be encrypted; if the payload is not encrypted, HTTPS must be used. This Rule applies to both inbound and outbound transactions. Encrypting the payload and sending it over HTTPS provides additional protection from "man-in-the-middle" attacks.
How EFT manages AS2 transmissions
In receiver mode (inbound), EFT examines the HTTP header, then determines whether to process it as a normal file transfer, as an AS2 receipt (MDN), or as an AS2 transmission. If the file is an AS2 transmission, EFT will process the file, and if a receipt was requested, send a receipt back to the originator. Once the file is received, the following Event triggers will apply:
An On File Upload Event occurs for each file uploaded in an MA transaction.
An AS2 Inbound Transaction Succeeded Event occurs just once per single file or MA transaction after all files are received and the MDN (if requested) is successfully sent.
An AS2 Inbound Transaction Failed Event occurs if an AS2 file upload failed for any reason, such as bad Message Integrity Check (MIC), no permissions/access, duplicate message ID, or other AS2 transfer-related error.
In sender mode (outbound), EFT provides granular control over AS2 configuration, such as whether to compress or encrypt the message contents, whether to request a synchronous or asynchronous receipt, and whether to launch one or more post transaction Events:
An AS2 Outbound Transaction Succeeded Event occurs after EFT has successfully offloaded a file to a remote partner and, if a receipt was requested, a valid receipt was received that indicates the transfer was successfully completed.
An AS2 Outbound Transaction Failed Event occurs if EFT has failed to offload a file to a remote partner, an MDN receipt sent by EFT was not received in the specified duration, or the receipt signature or MIC failed.
EFT sends e-mails and executes commands only after the final transaction status (Failure or Success) is known. The success or failure to receive the MDN is stored in the database and can be viewed in reports and in the AS2 Status Viewer.
How EFT determines failed AS2 transmissions
AS2 transfers may have more than a simple success or failure outcome. For example, an outbound AS2 file transfer may succeed, but no MDN received from the remote host. This could be considered an outright failure in some cases. Another example of a failure is when a file is successfully sent, but the received MDN’s signature cannot be verified. Not all AS2 systems consider these partial failures an overall failure. For example, a remote host may accept an inbound file even though its signature was bad or had other issues, yet still accept the file.
EFT accepts most AS2 transmissions, even if there is a MIC mismatch or the signature used to sign the payload was not found. However, the overall transaction is not considered a success unless every part of the transmission succeeds. That is, EFT's acceptance of the transmission does not mean that the transmission was successful.
EFT's implementation of AS2 considers the following transmissions permanent failures:
An inbound unencrypted transmission over plaintext HTTP protocol
An upload attempt to a folder to which the user does not have write permission
In each of these situations, the transmission is rejected automatically. An error is returned to the client, audited to the database, and can trigger an AS2 transaction failure Event, if configured.
Redirecting AS2 transfers from HTTP to HTTPS
You can configure EFT to redirect HTTP connections to HTTPS. The redirect HTTP to HTTPS option affects all incoming HTTP transmission including AS2 requests over HTTP. When you have configured redirection, EFT simply tells the connecting client that the resource was moved to the new HTTPS URL. The connecting client decides whether it will allow the redirect, because the new URL could be on different server. If the connecting AS2 client does not allow redirection to a different port, the connection will fail.
You can also configure EFT to accept AS2 transactions over HTTP/S, but not allow general HTTP and/or HTTPS transactions. To do this, simply turn off HTTP and/or HTTPS and turn on AS2. The HTTP engine will stay active and only process HTTPS requests that include the AS2 headers.
Are AS2 transfers FIPS compliant?
If FIPS is enabled for SSL in EFT, then AS2 transfers over HTTPS use FIPS-certified encryption for the SSL/TLS connection through the Internet. Internal processing of the AS2 MIME payload, may use non-FIPS algorithms or hashes, such as MD5, depending on the content of the AS2 payload or MDN that is received.
