I am in the process of setting up the infrastructure for microservices using RabbitMQ as our message broker for our company. I am trying to figure out the best way to handle security for the system. This system will only be used (for now) on our internal network. We use Active Directory to maintain users in the domain.

I have configured RabbitMQ to use LDAP over TLS to authenticate users using our Active Directory servers. At some point I will have to send a user's credentials to RabbitMQ. I plan on using .NET NetworkCredential to store the credentials. RabbitMQ can't use the WindowsIdentity token, so we will need to send actual credentials (username and password instead of a token) to the RabbitMQ server.

First, I understand that NetworkCredential is not bullet proof but is better than nothing.

Some co-workers have expressed concern that we will be storing personal user credentials in the memory of applications. When not using RabbitMQ, there was no need to explicitly store credentials long term. We could simply authenticate the user and move on, (letting the garbage collector eventually clean up the users entered password).

They argue that they would rather have a power user identity that has the permissions needed to connect to RabbitMQ. Then we would not be storing personal credentials, and instead using transitive security via the "Application User" identity.

My question is what is standard practice for this situation? My thought is that storing a power user identity in an application is problematic. If the power user credentials, which will necessarily be distributed to every user in some way (even if obfuscated in the code), were compromised the consequences would be worse than if an individual user's credentials were compromised.

As far as controlling permissions in the system it seems to me that using a person's actual credentials is preferable to some power user identity. I have no way of locking out individuals if an individual has access to the power user credentials.

Am I missing some tool or resource that manages this situation?

  • Consider using the kerberos client, then you'll only get a tgs for your specific service. May 28, 2017 at 13:01
  • @Jonathan Allon Thanks for the suggestion. Do you have any experience setting up Kerberos authentication with RabbitMQ? Are there any good resources to learn how to do this? I ask because I haven't been able to find lot of information on this. There seems to be a Kerberos plugin available for RabbitMQ, but it doesn't look super well supported, and I'm not sure how robust it is. May 30, 2017 at 15:54
  • Sorry, just did a quick search to see if there is any support, didn't notice it was a plugin. Ldap based authentication is broken and that's why I recommended kerberos which generically solves this. If it isn't supported for rabbitmq you might want to either have a proxy software (ngnix, squid) handle the authentication or switch your queue software. Jun 1, 2017 at 5:38

1 Answer 1


The Kerberos authentication plugin we found for RabbitMQ is immature and isn't being maintained as far as we can tell. The only real option was for us to send the user's credentials to RabbitMQ over a TLS connection. We store the credentials in the app in a NetworkCredential object as needed which encrypts the password in memory making it significantly harder to gain access to.

Application users and power user credentials are only viable when you can control access to those credentials. That is, they should only be used in limited contexts, like within a secure web application or service that itself controls access to specific functions users can perform. The app, living on a server, can use the elevated account, without exposing the credentials to a user.

If you share power user credentials with common users, through a desktop app for example, so that the user can take actions that the power user can, then you have to assume that the user has those credentials now, no matter how well you obscure those credentials inside the app. It's a better idea to use the user's own identity for security whenever possible. This allows you to revoke permissions from a user if needed. It also allows you to track and log who is doing what in the system.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .