HTTP security solutions

When using HTTP-based message protocols – AS2, ebXML– security considerations are similar to hosting a web server. There are industry-standard solutions to make this type of communication secure. Solutions recommended for Activator are described in the following topics.

HTTP (embedded) server

You can configure Activator to accept incoming HTTP connections directly from trading partners by adding an inbound delivery exchange that uses the embedded HTTP server. The following is a list of safety options to use in conjunction with the embedded server. The options are numbered from lowest to highest security.

Option 1: HTTP basic authentication

Basic access authentication is a method in which an HTTP client must provide a user name and password when making a request to a server.

You can only enable HTTP basic authentication on pickups that are configured to consume messages through a Activator embedded HTTP server. You can configure HTTP basic access authentication on the following exchanges:

  • HTTP (embedded) no packaging application pickup
  • HTTP (embedded) no packaging trading pickup
  • AS2 (HTTP-embedded) trading pickup

Enable basic authentication

You must manually activate HTTP basic authentication on each pickup where you want to use it. To enable HTTP basic authentication:

To enable HTTP basic authentication:

  1. Add an HTTP embedded application or trading pickup to a community.
  2. Open the maintenance page for the pickup.
  3. On the maintenance page, select the Accounts tab.
  4. Select the option This server requires a username and password to enable basic authentication.
  5. When you select this option, you can then create accounts for partner users who are authorized to connect to this pickup. You can create as many accounts as you require, however one account must be designated as the default account.
  6. To create a user:
    1. Click Add.
    2. Enter a user name and password. The user name must be unique within the community. The password must conform to the requirements of the password policy.
    3. If you already have one or more HTTP users defined for the community, you can click the name of a user from the list of available users and then click Save to use that user for the current pickup.
    4. Select a password policy. See Manage password policies of transport users.
    5. Click Save.
    6. If there is more than one user in the list of users for this pickup, specify which user is the default user by clicking next to the user in the Default column.
    7. Click Save changes.

Related topics

Option 2: Message-level security

It is safe to allow inbound connections directly to the embedded HTTP server if your message validation rules require messages (payloads) to be signed and encrypted (the default). This is true even if Activator is running on a machine within your protected network, because the embedded server rejects any message that was not signed with the partner’s private key.

This level of security is sufficient for most applications.

Advantage: High level of security with minimal per-partner maintenance overhead.

Disadvantage: Does not protect against denial-of-service attacks.

Option 3: Firewall filtering

An additional level of security can be achieved by configuring rules on your firewall to allow only inbound connections from known-partner IP addresses. You also can allow connections only to designated ports (for example, 4080 and 1443).

This level of security, in combination with requiring signed and encrypted payloads, is very high and should be sufficient for virtually all applications.

Advantage: Protects against denial-of-service attacks.

Disadvantage: IP address filtering requires updating firewall rules when a partner is added or removed.

Option 4: SSL

If receiving any unencrypted messages, you should require your partners to connect using HTTPS (SSL) so no one on the Internet can eavesdrop on the contents.

Advantage: Eavesdroppers are thwarted even if messages are not encrypted.

Disadvantage: Extra CPU load introduced by SSL (but see option 5). The user cannot configure the encryption algorithm for HTTPS. It is better to require message-level security because the encryption algorithms are stronger.

Option 5: Client-authenticated SSL

With SSL, an additional level of security called client authentication can be configured. This option is selected by default when you define an SSL embedded server in Activator. Client authentication requires your partner to present a certificate before the inbound connection can be accepted. This is similar to the concept of requiring payloads to be signed.

If you choose to allow unsigned payloads, it is highly recommended that you require client-authenticated SSL to prevent connections from being accepted from unknown parties.

Advantage: Unwanted connections are refused as early as possible, before any part of the payload is received.

Disadvantage: Within Activator you must maintain a list of trusted SSL client-authentication certificates for each partner. This is in addition to the list of partner certificates you must maintain for encrypting messages and verifying signatures.

Summary of options

In summary, most users choose one of the following levels of security when employing the embedded HTTP server.

  • High security – The default behavior of Activator in requiring payloads to be signed and encrypted affords a very high level of security right out of the box, even if connections are terminated within your private network by the embedded HTTP server. This level employs the security described in option 1.
  • High security and denial-of-service resistance – Adding IP and port filtering rules to your firewall prevents connections from being accepted even before the payload has been examined. This level combines the security described in options 1 and 2.

Related Links