AS2 Authentication

In "normal" authentication, EFT supports client-authenticated transactions, meaning EFT’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 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.

If you are using To specify SSL certificate-based logins for the Settings Template or a User for accounts that need to send AS2 transfers, leave it at the default password authentication, not certificate authentication.

Message Level Security (MLS) authentication is a sort of sub-set of normal authentication. MLS requires only two criteria to authenticate on EFT (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 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 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 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, as specified in the inbound settings for that particular partner’s account.

Process flow:

If authentication credentials are missing, EFT 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 rejects the transaction

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

• If MLS is not allowed, EFT rejects the transaction

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

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

• If invalid, EFT rejects the transaction

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

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

• EFT rejects the transaction if they do not match

• EFT accepts the transaction if they do match

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

• If set to reject, EFT sets RequireSign to true

• If set to accept, EFT 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’s Controlling Access to the Site by IP Address, Setting Maximum Transfer Size to a reasonable level, or select the Enabling SSL on the Site 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).

HTTP Header Information sent from inbound AS2 client to EFT "Auth" = username/password|"Sign" = certificate signature	MLS Auth Allowed	Accept mismatch AS2-From id + Do require sign	Reject mismatch AS2-From id + Do require sign	Accept mismatch AS2-From id + Do require sign	Reject mismatch AS2-From id + Do require sign
No Auth, No Sign, AS2ID invalid	fail	fail	fail	fail	fail
No Auth, No Sign, AS2ID valid	fail	fail	fail	fail	fail
No Auth, Sign invalid, As2ID invalid	fail	fail	fail	fail	fail
No Auth, Sign invalid, As2ID valid	fail	fail	fail	fail	fail
No Auth, Sign valid, As2ID invalid	fail	fail	fail	fail	fail
No Auth, Sign valid, As2ID valid	pass	fail	fail	fail	fail
Valid Auth, No Sign, AS2ID invalid	fail	pass	fail	fail	fail
Valid Auth, No Sign, AS2ID valid	fail	pass	pass	fail	fail
Valid Auth, Sign invalid, As2ID invalid	fail	fail	fail	fail	fail
Valid Auth, Sign invalid, As2ID valid	fail	fail	fail	fail	fail
Valid Auth, Sign valid, As2ID invalid	fail	pass	fail	pass	fail
Valid Auth, Sign valid, As2ID valid	pass	pass	pass	pass	pass
Invalid Auth, No Sign, AS2ID invalid	fail	fail	fail	fail	fail
Invalid Auth, No Sign, AS2ID valid	fail	fail	fail	fail	fail
Invalid Auth, Sign invalid, As2ID invalid	fail	fail	fail	fail	fail
Invalid Auth, Sign invalid, As2ID valid	fail	fail	fail	fail	fail
Invalid Auth, Sign valid, As2ID invalid	fail	fail	fail	fail	fail
Invalid Auth, Sign valid, As2ID valid	fail	fail	fail	fail	fail

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 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.