Learn RabbitMQ - User Management & Authentication

#Introduction

So far we've used the guest and arman users without much thought. In real environments, users are RabbitMQ's first security gate: who is allowed to log in, what they may do, and how much access they have. Manage users poorly and your broker can be infiltrated — whether from inside the team or from the network.

This episode covers user management from two sides. First, user management: creating users, assigning user tags that determine admin/monitoring rights, and applying password policies. Second, authentication: the mechanisms that prove a user's identity, from the default internal backend to integration with LDAP, OAuth 2.0, x509 certificates, and the HTTP backend.

By the end of the episode, you'll be able to decide the right authentication mechanism for your team's needs, and enforce the least privilege principle from the identity side.

#User Management

#Creating Users with rabbitmqctl

Create a user and assign tags:

rabbitmqctl add_user 'svc-order' 'S3kret$2026'
rabbitmqctl set_user_tags 'svc-order' monitoring
rabbitmqctl list_users

The rabbitmqctl add_user command creates a service user, then set_user_tags assigns the monitoring tag — enough to view metrics, without administrative rights.

#Creating Users via the Management UI

The same can be done through the Management UI: open the Admin > Users > Add a user tab, fill in the username and password, select tags, then click Add user. For permissions, you configure them per vhost at the bottom of the user page.

#User Tags

RabbitMQ has several standard tags:

• administrator — full access to all resources and settings.
• monitoring — management access, but no configuration.
• management — UI and API access, only for authorized resources.
• policymaker — manages policies and parameters.
• impersonator — logs in as another user via OAuth 2.0.

An important principle: don't give every user the administrator tag. Grant as little access as needed for the role.

#Password Policies

RabbitMQ 3.10+ supports password policies: minimum length, complexity rules, and expiration. Configure them in rabbitmq.conf:

auth_mechanisms = PLAIN AMQPLAIN EXTERNAL
password_complexity.min_length = 12
password_complexity.guessability = 4
password_complexity.reuse = 3

The password_complexity.min_length rule forces passwords of at least 12 characters. Combine it with a random password generator for service users.

#Authentication Mechanisms

#Internal Authentication

The internal backend is the default: usernames and passwords are stored in RabbitMQ's internal database. It's enough for small teams, with the note that passwords are stored as hashes. This is what all examples in this series use.

#LDAP Authentication

For companies with LDAP/AD, the rabbitmq_auth_backend_ldap plugin verifies users against the directory. Users don't need to be recreated in RabbitMQ — they log in with their LDAP credentials. The drawbacks: RabbitMQ must be able to reach the LDAP server, and there's added latency per login.

#OAuth 2.0 and x509

RabbitMQ 3.11+ supports OAuth 2.0: users use JWT tokens from an Identity Provider like Keycloak. Meanwhile, the rabbitmq_auth_mechanism_ssl plugin enables authentication through x509 certificates — the client sends a certificate during the TLS handshake, and the broker matches it against a trusted CA. TLS details are covered in episode 17.

#Authentication Backends

#HTTP Backend and Multi-Backend

Authentication backends can be combined. You can use internal for some users and the HTTP backend for others, with a fallback order:

auth_backends.1 = internal
auth_backends.2 = http
auth_http.user_path = http://auth.example.com/auth/user
auth_http.vhost_path = http://auth.example.com/auth/vhost
auth_http.resource_path = http://auth.example.com/auth/resource

The configuration above tries internal first, then the HTTP backend. This enables a RabbitMQ without static users — verification is delegated to your team's own authentication service.

#Authentication Caching

To lighten the load on external backends like LDAP or HTTP, enable authentication caching so verified credentials aren't re-checked on every connection:

auth_cache.cache_ttl = 3000
auth_cache.cache_max_entries = 100

The cache_ttl value above holds cached authentication results for 3 seconds, reducing pressure on LDAP when many connections arrive at once.

#Conclusion

In episode 15 you managed users with rabbitmqctl and the Management UI, understood user tags and password policies, compared the internal, LDAP, OAuth 2.0, and x509 authentication backends, and set up the HTTP backend and caching for centralized authentication.

Key takeaways:

• Users are created with rabbitmqctl add_user or the Management UI.
• The administrator tag is the highest privilege — limit its use.
• Password policies enforce length, complexity, and rotation.
• The internal backend is enough for small teams; LDAP for large organizations.
• OAuth 2.0 is available since 3.11 with JWT tokens.
• x509 certificates enable passwordless login.
• Multi-backend and auth caching lighten the verification load.

In the next episode we will set up authorization and access control — the configure, write, and read permission model; regex patterns for permissions; per-vhost RBAC with least privilege; and topic authorization for filtering routing keys on topic-type exchanges. This is the second security layer after authentication!