AS2 Authentication

In "normal" authentication, EFT Server supports client-authenticated transactions, meaning EFT Server’s HTTP/S protocol handler requires a username and password at the outset of the HTTP/S-based AS2 transaction. After it authenticates the partner's login credentials, EFT Server passes the transaction to its AS2 processor, which performs all message validation and handling. This normal authentication method is secure, but requires the administrator to create and manage partner accounts.

Message Level Security (MLS) authentication is a sort of sub-set of normal authentication. MLS requires only two criteria to authenticate on EFT Server (AS2-From + signature), whereas normal authentication can require up to four criteria (Username + Password + AS2-From + Signature).

To accommodate MLS, instead of immediately rejecting messages that don’t contain the Authentication verb (or an empty value next to the Authentication verb) EFT Server manually looks for the AS2-From verb, and if present, looks up the partner account that matches the identifier. If that account is found, and if MLS is allowed for that partner, EFT Server passes the message to its AS2 processor, along with the mandatory “RequireSign” parameter--one of two mandatory factors used for MLS authentication. The AS2 processor checks for mismatched signatures and properly formatted AS2 messages, and if validated, submits the transaction to the AS2 engine for decryption and processing.

Regardless of whether MLS is enabled for a particular partner account, if a username and password are provided (authentication verb and values present), EFT Server validates the user account credentials. If those credentials are invalid, the transaction is denied (regardless of whether the AS2-From and signatures match). If the credentials are valid, then the transaction proceeds and is passed to the AS2 processor; however, if MLS authentication is enabled for that partner, then not only does the AS2-From identifier have to match up with that partner account, but also the RequireSign must be passed to the AS2 processor (and be a valid signature for that account), meaning all four factors must be correct. If, on the other hand, normal authentication mode was specified for the user (rather than MLS), then only the username and password factors are checked, unless AS2-From and signature factors were required by EFT Server, as specified in the inbound settings for that particular partner’s account.

Process flow:

If authentication credentials are missing, EFT Server manually parses the AS2-From ID, and then:

• If not present rejects the transaction

• If present, locates the partner (user) account associated with the AS2-From ID

• • If no partner is found, EFT Server rejects the transaction

  • If a partner is found, EFT Server determines if MLS is allowed for that partner

  • • If MLS is not allowed, EFT Server rejects the transaction

    • If MLS is allowed, EFT Server passes the transaction to the AS2 component for processing, along with the RequireSign parameter set to True

If authentication credentials are present, EFT Server validates the credentials, and then:

• If invalid, EFT Server rejects the transaction

• If valid, EFT Server determines if that account will accept or reject mismatched AS2-From IDs

• • If set to reject, then EFT Server verifies the AS2-From ID provided in the header matches the account profile AS2 From ID

  • • EFT Server rejects the transaction if they do not match

    • EFT Server accepts the transaction if they do match

• If the AS2-From ID is valid, EFT Server determines whether that account accepts or rejects messages that lack signatures

• • If set to reject, EFT Server sets RequireSign to true

  • If set to accept, EFT Server sets RequireSign to false, then submits the transaction to the AS2 component for processing

To mitigate the risk of DoS attacks and prevent unauthorized transactions, the administrator should employ EFT Server’s IP address filters, set a maximum size limit to a reasonable level, or select the Require SSL certificates from connecting clients check box in the SSL Certificate Settings dialog box on the Site's Connections tab.

You can enable Message Level Authentication in the AS2 Partner Inbound Wizard or the AS2 Inbound Settings dialog box.

Permutations of Valid Authentication Factors

Normal Authentication

Any of the four combinations below will allow the inbound AS2 transaction:

• USERNAME + PASSWORD (“Auth” + “Message not signed” = ACCEPT + “as2-from mismatch” = ACCEPT)

• USERNAME + PASSWORD + AS2 FROM ID + SIGNATURE (“Auth” + “Message not signed” = REJECT + “as2-from mismatch” = REJECT)

• USERNAME + PASSWORD + AS2 FROM ID (“Auth” + “Message not signed” = ACCEPT + “as2-from mismatch” = REJECT)

• USERNAME + PASSWORD + SIGNATURE (“Auth” + “Message not signed” = REJECT + “as2-from mismatch” = ACCEPT)

MLS Authentication

Any of the two combinations below will allow the inbound AS2 transaction:

• AS2 FROM ID + SIGNATURE (“MLS” + “Message not signed” = REJECT + “as2-from mismatch” = REJECT)

• USERNAME + PASSWORD + AS2 FROM ID + SIGNATURE (“MLS” + “Message not signed” = REJECT + “as2-from mismatch” = REJECT)

The following table describes possible login scenarios, depending on settings specified in the partner’s AS2 inbound configuration page (top row column headings), and depending on the verbs and factors provided by the incoming partner in the HTTP headers (left column row headings).

From the table above, you can see that:

• If no username/password is provided (No Auth), and the certificate is either not provided (No Sign) or invalid (Sign invalid), the transaction will fail.

• If the username/password is invalid, no matter what the settings are, the transaction will fail. For example, if you have configured Message Level Security, EFT Server does not require a username/password. But if an incorrect username/password is provided in the header information, the transaction will fail (to prevent unauthorized transactions).

• The advantage to using MLS authentication is that partners can connect without providing a username/password pair, as long as the certification and AS2 ID are valid.