SWIM-TI Yellow Profile Implementation Guidance: AMQP Messaging Service Binding

Last updated:   JULY 2nd, 2019

Introduction

This document provides implementation guidance for the AMQP Messaging Service Binding of the SWIM-TI Yellow Profile using a variety of Free and Open Source Software (FOSS) solutions. For each of the solutions analysed the satisfaction of the requirements that define the Service Binding is provided as well as the necessary configuration elements used to verify its satisfaction.

The proposed configuration options are aimed for minimum satisfaction of the requirements and should be understood as guidance of implementation, implementers should tailor their configuration to their needs.

In section 2 we cover a number of messaging brokers that support AMQP 1.0 messages and in section 3 we cover clients and libraries that can be used in producer or consumer side for sending and receiving AMQP 1.0 messages.

Brokers

RabbitMQ

RabbitMQ is a multi-protocol message broker that supports AMQP 0.9.1, AMQP 1.0, MQTT 3.1.1 and STOMP. In this section, we will analyse its capabilities as an AMQP 1.0 broker and the satisfaction of the AMQP Messaging Service Binding requirements of the Eurocontrol Specification for SWIM TI Yellow Profile.

Additional details on RabbitMQ and its configuration are available in its extensive documentation: https://www.rabbitmq.com/documentation.html

Service Interface Binding Requirements

The following table summarizes the Service Binding requirements of the AMQP Messaging Service Binding.

Requirement Title

Requirement ID

Conformance Level

Data Compression

SWIM-TIYP-0041

Optional

AMQP Content Encoding Header 

SWIM-TIYP-0049

Optional

AMQP Content Type Header 

SWIM-TIYP-0048

Mandatory Conditional

AMQP Transport Security Authentication 

SWIM-TIYP-0037

Mandatory

SASL

SWIM-TIYP-0051

Mandatory

AMQP over TLS

SWIM-TIYP-0052

Mandatory

AMQP

SWIM-TIYP-0036

Mandatory

TLS

SWIM-TIYP-0008

Mandatory

Data Compression

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ acts as a pass-through for messages between producers and consumers, it respects the message body set by the producer, in particular for the case where the message body consists of binary string of the compressed message data.

No specific configuration is needed on the part of the broker.

Comment:

See section 2.1.1.1 for more details on how this compressed data can be set up on the producer side.

AMQP Content Encoding Header

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ acts as a pass-through for messages between producers and consumers, it respects the Content-Encoding property set by the producer of the message. No specific configuration is needed.

Comment:

See section 2.1.1.2 for more details on how this property can be set up on the producer side.

AMQP Content Type Header

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ acts as a pass-through for messages between producers and consumers, it respects the Content-Type property set by the producer of the message. No specific configuration is needed.
Comment:

See section 2.1.1.3 for more details on how this property can be set up on the producer side.

AMQP Transport Security Authentication

Satisfaction:

Complete

Verification:

Test

Configuration:

  • TLS Server Authentication: To enable TLS server authentication the server must be configured with a X.509 certificate and private key and the certificate of the Root CA. This is done in the configuration file rabbitmq.conf , as shown in the following figure:

  • TLS Mutual Authentication: To use TLS mutual authentication we have to allow the clients to authenticate themselves by means of a X.509 certificate. The following snippet from the rabbitmq.conf explains how this is achieved:

The auth-mechanism-ssl plugin is activated with the rabbitmq-plugins on the command line:

  • SASL Anonymous: The broker accepts connections using SASL Anonymous mode (no SASL authentication). The broker assigns these anonymous users a default user which can be defined in the configuration file rabbitmq.conf . As shown in the following figure:

  • SASL Plain: The broker accepts connections using SASL Plain mode (User/password authentication). The user will be authenticated against the database of users. The user can be created in design time using the JSON definitions file to load the users, or dynamically through the Management REST API. Below is a sample from the JSON definitions file that is loaded onto RabbitMQ.

Comment:

This covers the necessary configuration aspects from the broker point of view to satisfy the requirement. The configuration aspects from the point of view of the client are covered in section 2.

SASL

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ accepts SASL client authentication as depicted in section 1.1.1.4.

Comment:

N/A.

AMQP over TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ accepts AMQP over TLS (AMQPS) connections over the standard port assigned by IANA (5671).

This port can be nonetheless configured in the configuration file rabbitmq.conf with the following line.

2116

Comment:

N/A.

AMQP

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ supports AMQP 1.0 protocol through a plugin. The plugin must be enabled as otherwise RabbitMQ defaults to AMQP 0.9.1. Enabling this plugging can be done with the following command on the command line before running the broker:

Comment:

N/A.

TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

RabbitMQ supports TLS and allows to specify and restrict the version of TLS to be used through the configuration file rabbitmq.conf . The following line specifies the allowed versions of TLS:

Comment:

N/A.

ActiveMQ Artemis

Service Interface Binding Requirements

The following table summarizes the Service Binding requirements of the AMQP Messaging Service Binding.

Requirement Title

Requirement ID

Conformance Level

Data Compression

SWIM-TIYP-0041

Optional

AMQP Content Encoding Header 

SWIM-TIYP-0049

Optional

AMQP Content Type Header 

SWIM-TIYP-0048

Mandatory Conditional

AMQP Transport Security Authentication 

SWIM-TIYP-0037

Mandatory

SASL

SWIM-TIYP-0051

Mandatory

AMQP over TLS

SWIM-TIYP-0052

Mandatory

AMQP

SWIM-TIYP-0036

Mandatory

TLS

SWIM-TIYP-0008

Mandatory

Data Compression

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis acts as a pass-through for messages between producers and consumers, it respects the message body set by the producer, in particular for the case where the message body consists of binary string of the compressed message data.

No specific configuration is needed on the part of the broker.

Comment:

See section 2.1.1.1 for more details on how this compressed data can be set up on the producer side.

AMQP Content Encoding Header

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis acts as a pass-through for messages between producers and consumers, it respects the Content-Encoding property set by the producer of the message. No specific configuration is needed.

Comment:

See section 2.1.1.2 for more details on how this property can be set up on the producer side.

AMQP Content Type Header

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis acts as a pass-through for messages between producers and consumers, it respects the Content-Type property set by the producer of the message. No specific configuration is needed.

Comment:

See section 2.1.1.3 for more details on how this property can be set up on the producer side.

AMQP Transport Security Authentication

Satisfaction:

Complete

Verification:

Test

Configuration:

  • TLS Server Authentication: To enable TLS server authentication the broker has to be configured with the private key and a trust store. This is done in the acceptors section of the broker.xml configuration file, the relevant parameters to pass in the definition of the acceptor URL are:
    • sslEnabled=true
    • keyStorePath=/path/to/broker_keystore.jks
    • keyStorePassword=securepassword
    • trustStorePath=/path/to/broker_trust_store.jks
    • trustStorePassword=securepassword

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\acceptor.png

  • TLS Mutual Authentication: To use TLS mutual authentication we have to allow the clients to authenticate themselves by means of a X.509 certificate, on top of setting the TLS Server Authentication as in the previous bullet point. This requires multiple configuration files to be properly set up and aligned:
    • login.config: Defines the JAAS plugins used by the broker to perform client authentication. In particular, we need to define the use of TextFileCertificateLoginModule as shown in the following configuration snippet:

This configuration file refers to two other files “cert-users.properties” and “cert-roles.properties”.

  • cert-users.properties: Defines the users that are recognized by the broker and must contain an entry for the client’s X.509 Distinguished Name, as shown in the following image:

Alternatively, the broker can be integrated with an existing LDAP infrastructure using JAAS LDAPLoginModule (see, https://activemq.apache.org/components/artemis/documentation/1.2.0/security.html ).

  • cert-roles.properties: Assigns each user to one or more roles with their associated permissions. The following example assigns the “ certconsumer” user defined previously with a “cert” role.
    • bootstrap.xml: Defines various configuration aspects of the broker, including the JAAS security configuration to be used (defined in the previous bullet point). We must point to the security configuration defined in login.config , the following snippet illustrates this by pointing to the “activemq” domain defined previously.

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\bootstrap.xml.png

  • SASL Anonymous: The broker accepts connections using SASL Anonymous mode. We have to enable the GuestLoginModule in the login.config configuration file, assigning a default user and role to unauthenticated users. As shown in the following snippet.

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\login.config.png

  • SASL Plain: The broker accepts connections using SASL Plain mode (User/password authentication). To do so we have to enable the PropertiesLoginModule in the login.config configuration file.

In the example above the user will be authenticated against the database of users defined by org.apache.activemq.jaas.properties.user (i.e. “artemis-users.properties”). Which contains the credentials in the following format:

Username = password

The password itself can be stored in an unrecoverable manner using hashes.

Below is a sample from the “artemis-users.properties” file.

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\artemis-useres.properties.png

Comment:

Additional documentation on the configuration of the JAAS plugins can be found in Apache ActiveMQ Artemis documentation: https://activemq.apache.org/components/artemis/documentation/1.2.0/security.html

SASL

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis accepts SASL client authentication as depicted in section 1.2.1.4.

Comment:

N/A.

AMQP over TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis accepts AMQP over TLS (AMQPS) connections.

The use of AMQPS is configured in the acceptors section of the broker.xml configuration file. As shown in the following configuration snippet:

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\acceptor.png

The relevant parameters of the configuration are:

  • sslEnabled=true
  • protocols=AMQP

Which establish the use of TLS and AMQP 1.0 for said acceptor. And:

  • keyStorePath=/path/to/broker_private_key.jks
  • keyStorePassword=securepassword
  • trustStorePath=/path/to/broker_trust_store.jks
  • trustStorePassword=securepassword

Which establish the private key, trust store of the broker and its passwords.

Comment:

N/A.

AMQP

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis natively supports AMQP 1.0 protocol. The use of the protocol is enabled in the acceptors section of the broker.xml configuration file, as shown in section 1.2.1.6.

The relevant parameter of the configuration is:

  • protocols=AMQP

Comment:

N/A.

TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

ActiveMQ Artemis supports TLS and allows to specify and restrict the version of TLS to be used. This is done with the enabledProtocol parameter in the acceptors section of the broker.xml configuration file. As shown in the following configuration snippet:

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\acceptor.png

The relevant parameters of the configuration are:

  • sslEnabled=true
  • enabledProtocol=TLS1.2

Comment:

N/A.

Clients

Apache Qpid Proton

Apache Qpid Proton provides a low-level implementation of AMQP 1.0 in the C programming language and multiple higher-level reactive APIs on various mainstream programming languages (Java, C++ and Python). The following demonstrates the configuration of Qpid Proton using its Python API [1] but Qpid Proton’s API is quite consistent across the different languages.

Service Binding Requirements

Requirement Title

Requirement ID

Conformance Level

Data Compression

SWIM-TIYP-0041

Optional

AMQP Content Encoding Header 

SWIM-TIYP-0049

Optional

AMQP Content Type Header 

SWIM-TIYP-0048

Mandatory Conditional

AMQP Transport Security Authentication 

SWIM-TIYP-0037

Mandatory

SASL

SWIM-TIYP-0051

Mandatory

AMQP over TLS

SWIM-TIYP-0052

Mandatory

AMQP

SWIM-TIYP-0036

Mandatory

TLS

SWIM-TIYP-0008

Mandatory

Data Compression

Satisfaction:

Complete

Verification:

Test

Configuration:

AMQP 1.0 and Qpid Proton are agnostic of the payload and do not require any special configuration to work with data compression. A compressed payload is treated as a binary string. The following example illustrates how a string of text is compressed into binary using Gzip, sent using Qpid Proton to the RabbitMQ broker which in turn delivers it to the subscribed consumers.

  • Producer: On the producer side we build a small sample message whose body is a Gzip compressed string:

2111-producer

  • Consumer: On the consumer side the message arrives compressed and can be decompressed using Gzip. The following snippet will leave a log trace of the arrival of the message and the message elements.

2111-consumer

Which produces the following log trace on the consumer side:

2111-consumer log

Comment:

The documentation of the Message class can be found here: https://qpid.apache.org/releases/qpid-proton-0.27.1/proton/python/api/proton._message.Message-class.html

AMQP Content Encoding Header

Satisfaction:

Complete

Verification:

Test

Configuration:

Qpid Proton allows to set the AMQP 1.0 properties of a message in a straightforward manner, the following example shows how to do so for the Content-Encoding and Content-type properties.

2112-2113

Comment:

See further details of the Message class API.

https://qpid.apache.org/releases/qpid-proton-0.27.1/proton/python/api/proton._message.Message-class.html

AMQP Content Type Header

Satisfaction:

Complete

Verification:

Test

Configuration:

Qpid Proton allows to set the AMQP 1.0 properties of a message in a straightforward manner, the following example shows how to do so for the Content-Encoding and Content-type properties.

2112-2113

Comment:

See further details of the Message class API.

https://qpid.apache.org/releases/qpid-proton-0.27.1/proton/python/api/proton._message.Message-class.html

AMQP Transport Security Authentication

Satisfaction:

Complete

Verification:

Test

Configuration:

  • TLS Server Authentication: To enable TLS server authentication on Qpid Proton the client must configure the root CA certificate in order to verify the public certificate presented by the server. This can be done in the following manner:

2114-TLS server

  • TLS Mutual Authentication: To use TLS mutual authentication we have to configure not only the root CA certificate to authenticate the server (see point above) but also configure the client’s certificate and private key that he will use to authenticate himself. The following snippet shows how this can be done in Qpid Proton.

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\2114-TLS client.png

  • SASL Anonymous: From the point of view of the client configuring a SASL Anonymous authentication amounts to not using SASL. The following snippet shows a connection configured without SASL.

2114-SASL Anonymous

  • SASL Plain: Qpid Proton allows the use of SASL PLAIN authentication mechanism. Upon opening the connection the client simply has to provide its credentials in the following way:

2114-SASL-plain

Comment:

The documentation of the SSLDomain class is available at: https://qpid.apache.org/releases/qpid-proton-0.27.1/proton/python/api/proton._transport.SSLDomain-class.html

The documentation of the Container.connect method is available at: https://qpid.apache.org/releases/qpid-proton-0.27.1/proton/python/api/proton._reactor.Container-class.html#connect

SASL

Satisfaction:

Complete

Verification:

Test

Configuration:

Qpid Proton supports SASL authentication but a few dependencies are required, as explained in its documentation:

https://github.com/apache/qpid-proton/blob/master/INSTALL.md

Section 2.1.1.4 provides further details on the configuration of SASL credentials.

Comment:

N/A.

AMQP over TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

Qpid Proton allows to establish AMQP over TLS connections, section 2.1.1.4 provides the configuration details from the point of view of the client.

Comment:

N/A.

AMQP

Satisfaction:

Complete

Verification:

Test

Configuration:

Qpid Proton is a library of AMQP 1.0. No specific configuration is needed.

Comment:

N/A.

TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

Qpid Proton supports establishing TLS connections but a few dependencies are required, as explained in its documentation:

https://github.com/apache/qpid-proton/blob/master/INSTALL.md

Comment:

N/A.

Rhea

Rhea provides a reactive AMQP 1.0 library for Javascript (Node.js). The following section matches its capabilities against the requirements of the AMQP Messaging Service Binding.

Additional documentation and working examples can be found on Rhea’s GitHub repository: https://github.com/amqp/rhea

Service Binding Requirements

Data Compression

Satisfaction:

Complete

Verification:

Test

Configuration:

AMQP 1.0 and Rhea are agnostic of the payload and do not require any special configuration to work with data compression. A compressed payload is treated as a binary string. The following example illustrates how a string of text is compressed into binary using Gzip, sent using Rhea to the RabbitMQ broker which in turn delivers it to the subscribed consumers.

  • Producer: On the producer side we build a small sample message whose body is a deflate compressed string:

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\3211-producer.png

  • Consumer: On the consumer side the message arrives compressed and can be decompressed using the reverse operation of deflate ( inflate ). The following snippet will leave a log trace of the arrival of the message and the message elements.

Which produces the following log trace on the consumer side when a message arrives:

Comment:

AMQP Content Encoding Header

Satisfaction:

Complete

Verification:

Test

Configuration:

Rhea allows to define an AMQP 1.0 message using JavaScript Object Notation (JSON), the following example shows how to do so for a small sample message containing Content-Encoding and Content-type properties and some payload in the body.

Comment:

N/A.

AMQP Content Type Header

Satisfaction:

Complete

Verification:

Test

Configuration:

Rhea allows to define an AMQP 1.0 message using JavaScript Object Notation (JSON), the following example shows how to do so for a small sample message containing Content-Encoding and Content-type properties and some payload in the body.

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\3212-message.png

Comment:

N/A.

AMQP Transport Security Authentication

Satisfaction:

Complete

Verification:

Test

Configuration:

  • TLS Server Authentication: To enable TLS server authentication using Rhea the client must configure the root CA certificate in order to verify the public certificate presented by the server. This can be done in the following manner:
  • TLS Mutual Authentication: To use TLS mutual authentication we have to configure not only the root CA certificate to authenticate the server (see point above) but also configure the client’s certificate and private key that he will use to authenticate himself. The following snippet illustrates this configuration.
  • SASL Anonymous: To configure a SASL Anonymous authentication with Rhea it suffices to not specify a password, the username can be any string as it will be mapped by the broker to its default anonymous user. The following snippet shows a connection configured with SASL Anonymous.

C:\Users\fjcrabif\AppData\Local\Microsoft\Windows\INetCache\Content.Word\3214-sasl-anonymous.png

  • SASL Plain: To configure a SASL Plain authentication with Rhea we simply provide the username and password of the client to authenticate. The following snippet shows a connection configured with SASL Plain.

Comment:

N/A.

SASL

Satisfaction:

Complete

Verification:

Test

Configuration:

Rhea allows to perform SASL Anonymous and SASL PLAIN authentication, section 3.2.1.4 provides detailed configuration snippets for both cases.

Comment:

N/A.

AMQP over TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

Rhea allows to establish AMQP over TLS connections, section 3.2.1.4 provides the configuration details from the point of view of the client.

Comment:

N/A.

AMQP

Satisfaction:

Complete

Verification:

Test

Configuration:

Rhea is a library of AMQP 1.0. No specific configuration is needed.

Comment:

N/A.

TLS

Satisfaction:

Complete

Verification:

Test

Configuration:

Rhea supports establishing TLS sessions, section 3.2.1.4 provides the configuration details from the point of view of the client.

Comment:

N/A.

References

  1. Eurocontrol Specification for SWIM Technical Infrastructure Yellow Profile , EUROCONTROL
  2. RabbitMQ Documentation , Pivotal
  3. ActiveMQ Artemis Documentation , Apache
  4. Qpid Proton Documentation , Apache
  5. Rhea Documentation

Notes

  1. https://qpid.apache.org/releases/qpid-proton-0.27.1/proton/python/api/index.html