Integrating ActiveMQ brokers with LDAP

You can access your ActiveMQ brokers using the following protocols with TLS enabled:

Amazon MQ offers a choice between native ActiveMQ authentication and LDAP authentication and authorization to manage user permissions. For information about restrictions related to ActiveMQ usernames and passwords, see Users.

To authorize ActiveMQ users and groups to works with queues and topics, you must edit your broker's configuration. Amazon MQ uses ActiveMQ's Simple Authentication Plugin to restrict reading and writing to destinations. For more information and examples, see Always configure an authorization map and authorizationEntry.

Integrate LDAP with ActiveMQ

You can authenticate Amazon MQ users through the credentials stored in your lightweight directory access protocol (LDAP) server. You can also add, delete, and modify Amazon MQ users and assign permissions to topics and queues through it. Management operations like creating, updating and deleting brokers still require IAM credentials and are not integrated with LDAP.

Customers who want to simplify and centralize their Amazon MQ broker authentication and authorization using an LDAP server can use this feature. Keeping all user credentials in the LDAP server saves time and effort by providing a central location for storing and managing these credentials.

Amazon MQ provides LDAP support using the Apache ActiveMQ JAAS plugin. Any LDAP server, such as Microsoft Active Directory or OpenLDAP that is supported by the plugin is also supported by Amazon MQ. For more information about the plugin, see the Security section of the Active MQ documentation.

In addition to users, you can specify access to topics and queues for a specific group or a user through your LDAP server. You do this by creating entries that represent topics and queues in your LDAP server and then assigning permissions to a specific LDAP user or a group. You can then configure broker to retrieve authorization data from the LDAP server.

Prerequisites

Before you add LDAP support to a new or existing Amazon MQ broker, you must set up a service account. This service account is required to initiate a connection to an LDAP server and must have the correct permissions to make this connection. This service account will set up LDAP authentication for your broker. Any successive client connections will be authenticated through the same connection.

The service account is an account in your LDAP server, which has access to initiate a connection. It is a standard LDAP requirement and you have to provide the service account credentials only once. After the connection is setup, all the future client connections are authenticated through your LDAP server. Your service account credentials are stored securely in an encrypted form, which is accessible only to Amazon MQ.

To integrate with ActiveMQ, a specific Directory Information Tree (DIT) is required on the LDAP server. For an example ldif file that clearly shows this structure, see Import the following LDIF file into the LDAP server in the Security section of the ActiveMQ documentation.

Getting Started with LDAP

To get started, navigate to the Amazon MQ console and choose LDAP authentication and authorization when you create a new Amazon MQ or edit an existing broker instance.

Provide the following information about the service account:

The following image highlights where to supply these details.

In the LDAP login configuration section, provide the following required information:

The following image highlights where to specify these details.

In the Optional settings section, you can provide the following optional information:

The following image highlights where to specify these optional settings.

How LDAP integration works

You can think of integration in two main categories: the structure for authentication, and the structure for authorization.

Authentication

For authentication, client credentials must be valid. These credentials are validated against users in the user base in the LDAP server.

The user base supplied to the ActiveMQ broker must point to the node in the DIT where users are stored in the LDAP server. For example, if you are using AWS Managed Microsoft AD, and you have the domain components corp, example, and com, and within those you have organizational units corp and Users, you would use the following as your user base:

OU=Users,OU=corp,DC=corp,DC=example,DC=com
                

The ActiveMQ broker would search at this location in the DIT for users in order to authenticate client connection requests to the broker.

Because the ActiveMQ source code hardcodes the attribute name for users to uid, you must make sure that each user has this attribute set. For simplicity, you can use the user’s connection username. For more information, see the activemq source code and Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions.

To enable ActiveMQ console access for specific users, make sure they belong to the amazonmq-console-admins group.

Authorization

For authorization, permissions search bases are specified in the broker configuration. Authorization is done on a per-destination basis (or wildcard, destination set) via the cachedLdapAuthorizationMap element, found in the broker’s activemq.xml configuration file. For more information, see Cached LDAP Authorization Module.

You must provide the following three attributes as part of the cachedLDAPAuthorizationMap element:

The following demonstrates a working example of the cachedLdapAuthorizationMap.

<authorizationPlugin>
    <map>
        <cachedLDAPAuthorizationMap
            queueSearchBase="ou=Queue,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            topicSearchBase="ou=Topic,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            tempSearchBase="ou=Temp,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            refreshInterval="300000"
            legacyGroupMapping="false"
        />
    </map>
</authorizationPlugin> 

These values identify the locations within the DIT where permissions for each type of destination are specified. So for the above example with AWS Managed Microsoft AD, using the same domain components of corp, example, and com, you would specify an organizational unit named destination to contain all your destination types. Within that OU, you would create one for queues, one for topics, and one for temp destinations.

This would mean that your queue search base, which provides authorization information for destinations of type queue, would have the following location in your DIT:

OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
                

Similarly, permissions rules for topics and temp destinations would be located at the same level in the DIT:

OU=Topic,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
OU=Temp,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
            

Within the OU for each type of destination (queue, topic, temp), either a wildcard or specific destination name can be provided. For example, to provide an authorization rule for all queues that start with the prefix DEMO.EVENTS.$., you could create the following OU:

OU=DEMO.EVENTS.$,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com

For more info on wildcards in ActiveMQ, see Wildcards

To provide authorization rules for specific queues, such as DEMO.MYQUEUE, specify something like the following:

OU=DEMO.MYQUEUE,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com

Security Groups

Within each OU that represents a destination or a wildcard, you must create three security groups. As with all permissions in ActiveMQ, these are read/write/admin permissions. For more information on what each of these permissions allows a user to do, see Security in the ActiveMQ documentation.

You must name these security groups read, write, and admin. Within each of these security groups, you can add users or groups, who will then have permission to perform the associated actions. You’ll need these security groups for each wildcard destination set or individual destination.

Adding a user to the admin security group for a particular destination will enable the user to create and delete that topic. Adding them to the read security group will enable them to read from the destination, and adding them to the write group will enable them to write to the destination.

In addition to adding individual users to security group permissions, you can also add entire groups. However, because ActiveMQ again hardcodes attribute names for groups, you must ensure the group you want to add has the object class groupOfNames, as shown in the activemq source code.

To do this, follow the same process as with the uid for users. See Configuring ID mappings in Active Directory Users and Computers for Windows Server 2016 (and subsequent) versions.