www.nordicmessaging.se

EMG 6.0.6 - User's Guide

Table of ContentsPreviousNext

12. Security

Security in the EMG environment is enforced in a number of ways. However, the mechanisms are available at an application level and the system as a whole including hardware, operating system etc should be secured by other means of protection.

EMG can use SSL for encryption for all protocols. However, it requires the remote entity to also support SSL for the connection in question. If SSL support is not available it is recommended to use VPN or similar for protecting data transmitted over the Internet.

For HTTP and SMTP EMG also supports the authentication mechanisms available in the protocol such as HTTP basic authentication and SMTP login/plain/cram-md5 authentication.

When creating incoming connectors make sure that the correct IP address is specified by the ADDRESS keyword. Multi-homed machines with more than one network interface may give several possibilities for the IP address specified, make sure to pick the correct one. Connectors that will only be accessed locally on the machine should use IP address 127.0.0.1 (localhost). The localhost interface can only be accessed internally on the machine.

12.1 Access control

Incoming connectors can be restricted to only accept connections from specific client IP addresses or subnets.

See ACCESS connector keyword.

12.2 Authentication

Incoming connectors usually require authentication in the form of a username and password being supplied after the connection has been established and before any messages can be sent or received. If no encryption is used this information is sent in clear text.

See USERS and USERDB connector keywords for incoming connectors and USERNAME and PASSWORD keywords for outgoing connectors.

12.3 Blacklists and whitelists

Certain source or destination addresses may need to be logged separately or even blocked (rejected). To enable this blacklists and whitelists can be used per connector or server-wide.

A blacklist can be used to specifically reject or log an address, while a whitelist, if present, will reject all addresses not in the whitelist.

If an address is rejected by any blacklist the address will be rejected since whitelists cannot be used to override the behavior from a blacklist.

Processing of blacklists and whitelists is illustrated by the pseudo code below.

DoLog = false
DoReject = false

If connector blacklist exists
  If entry matches
    If action LOG -> DoLog = true
    If action REJECT -> DoReject = true
If general blacklist exists
  If entry matches
    If action LOG -> DoLog = true
    If action REJECT -> DoReject = true
If connector whitelist exists
  If entry matches
    If action LOG -> DoLog = true
  else
    DoReject = true
If general whitelist exists
  If entry matches
    If action LOG -> DoLog = true
  else
    DoReject = true
If DoReject = true
  Reject message
Else If DoLog = true
  Log message and allow
Else
  Allow message

See BLACKLIST, WHITELIST general and connector keywords.

12.4 Using SSL

EMG supports SSL for all protocols although it is most commonly for HTTP connections. SSL provides means for authentication using certificates and encryption (with or without a certificate).

12.4.1 Outgoing SSL without a certificate

An outgoing connector, for example HTTP, can use SSL without a certificate by just adding the connector keyword SSL to the connector configuration. This will encrypt all data sent over the connection protecting it from eavesdropping. The type of encryption used will depend on what is negotiated between the client and the server.

12.4.2 Incoming SSL

Using SSL for an incoming connection requires a certificate which can be defined server-wide or per-connector. The certificate is stored in the form of a so called PEM file.

12.4.3 Certificate-based authentication

It is possible to enable certificate-based authentication by using the keyword SSL_CAFILE on connector.

When used, the following criteria must be met for a client to be accepted by system.

Client must present a certificate issued by a CA certificate present in the SSL_CAFILE
The client perform a normal log in using a valid username and password
If a certificate fingerprint is specified on the user profile (CERT_FINGERPRINT in "users" file or value of "cert_fingerprint" in emguser table if USERDB is used) for the authenticated user it must match the fingerprint of the certificated presented by client.

Table of ContentsPreviousNext