Prev Next

Integration / ActiveMQ Interview Questions Advanced

How do you secure ActiveMQ using SSL/TLS and authentication plugins?

Encrypt the wire with an ssl:// transport connector backed by a broker keystore and truststore, optionally setting needClientAuth for mutual TLS so clients must also present a certificate:

<transportConnectors>
  <transportConnector name="ssl" uri="ssl://0.0.0.0:61617?needClientAuth=true"/>
</transportConnectors>

<plugins>
  <simpleAuthenticationPlugin>
    <users>
      <authenticationUser username="app" password="changeit" groups="consumers,producers"/>
    </users>
  </simpleAuthenticationPlugin>
  <authorizationPlugin>
    <map>
      <authorizationMap>
        <authorizationEntries>
          <authorizationEntry queue=">" write="producers" read="consumers" admin="producers,consumers"/>
        </authorizationEntries>
      </authorizationMap>
    </map>
  </authorizationPlugin>
</plugins>

Layer in authentication next: simpleAuthenticationPlugin for a small static user list, or a JAAS/LDAP plugin for a real directory, so connections must supply valid credentials. Then add authorization so authenticated users are restricted to only the queues and topics their group is allowed to read, write, or administer. In production, credentials are usually externalized to a JAAS realm backed by LDAP or a database rather than hardcoded in activemq.xml, and keystores are rotated on a schedule.

Beyond the basics shown above, it's common to layer in a JAAS login module backed by LDAP or Active Directory instead of the static simpleAuthenticationPlugin user list, so that user accounts and group membership stay centrally managed rather than duplicated inside activemq.xml. It's also worth restricting the admin permission tightly, since a user with admin rights on a destination can purge it or change its configuration, which is a much bigger blast radius than simply being able to read or write messages. For defense in depth, many production deployments also disable the plain, unencrypted tcp:// connector entirely once the ssl:// connector is confirmed working, so a misconfigured client can't silently fall back to sending credentials or message payloads unencrypted over the network.

What does needClientAuth=true on the SSL connector enable?
What does the authorizationPlugin control?

More Related questions...

Show more question and Answers...


Comments & Discussions