"user" role, to support self-service usage.

[petersilva]

Request for enhancement ... add a role, slotted less privileged than "monitor", call it "user".
When a user requests a list of queues, exchanges, or bindings, that list is filtered by the permission regexps. The can monitor and manage their own usage, but cannot see anything else.
The user could also change their own password.

more discussion here:
https://groups.google.com/forum/?nomobile=true#!topic/rabbitmq-users/uuv0cPY-kgA

[michaelklishin]

As mentioned in the thread above, this goes against the multitenancy approach in RabbitMQ but the use case for this is clear enough so we can at least investigate it.

[petersilva]

after thinking a while, I don't understand the conflict with multi-tenancy.

1. This is about a single tenant having multiple users. By single tenant, I mean all the users in the vhost will be looking at different subsets of the same data. If we force them into separate vhosts then we end up duplicating messages unnecessarily.

2. The proposal slots in nicely to the exiting hierarchy below monitoring, so it should not conflict that way.

3. It doesn't make much sense that every user on an AMQP broker must have their own vhost, which seems to be the multi-tenancy philosophy. In that case, user is redundant, and one would just use vhosts. If the intent is for every user to have a vhost, I would need to create thousands of vhosts for my application... it seems like user is a better model for my use case than vhost If I have thousands of vhosts, the gui becomes hard to use (vhost dialogs and such.)

4. It is likely that not applying the regexp permission in addition to the labels is a mistake to begin with. But it is there, so need to preserve the behaviour, but there would be a lot more flexibility in all the roles if the regexp's were applied across the board to all roles. Can't do that right now, but for my purposes, just adding the user role with the permissions respected is enough to solve all my issues.

5. It is really weird that monitors can do things in the GUI that they cannot do with the AMQP API (create bindings to queues, delete and purge queues, etc..., because the AMQP layer applies the permissions and the HTTP layer doesn't. The inconsistency isn't conceptually helpful for admins.
   Although it is documented, it violates expectations.

[michaelklishin]

@petersilva you have a couple of points. By "goes against the multitenancy approach" I mean that usually users who are not allowed even see each other's queues or channels use separate vhosts,
or are not granted access to the management UI.

We will see what can be done for your case after 3.7.0 ships.

[petersilva]

ah... that explanation makes sense, but the way it is implemented means users cannot see their own queues and exchanges either! Also, unless there are regexp permissions to prevent it, users can do dictionary-style attacks to delete, change bindings, or read messages from other peoples queues, so not aligning access with permissions to prevent visibility amounts to security by obscurity.