Effect of revoked permissions on existing AMQP connections

[gomoripeti]

I was looking for answers for the following questions

• in case of OAuth2 authorization what happens with existing AMQP connections if the token meanwhile expires.
• in case of internal authorization what happens with existing AMQP connections if some permissions are revoked.

I think I now know the answers from code, but I couldn't find it in the documentation in:

• https://www.rabbitmq.com/access-control.html
• https://github.com/rabbitmq/internals/blob/master/authorization_and_authentication.md
• https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbitmq_auth_backend_oauth2/README.md

Is this documented somewhere that I missed? If not I am willing to contribute, but would need some guidance on where and how deep as the permission cache makes it a bit tricky.

If the rabbit_auth_backend_oauth2 is enabled and Oauth2 is used the behaviour is quite satisfactory: it is guaranteed that a limited time (channel_tick_interval) after the token expires, all requests will be rejected. However the connection is not disconnected (is this true?)

If internal authorization is used (and rabbit_auth_backend_oauth2 is not enabled) then operations which were already executed on the channel before revoking a permission will be still allowed (because permissions are cached, but only the last 12) but others will be rejected. And because the cache is not cleared until a connection is closed this situation can go on for a long time seemingly inconsistently. I wonder how can this be hinted at in the Access Control chapter without overwhelming the users with too much technical details? Did you receive questions about this apparent inconsistency?

The last scenario I might even consider as a bug: when rabbit_auth_backend_oauth2 is enabled, even internal authorization will change its behaviour and a limited time (channel_tick_interval) after a permission is revoked, all affected requests will be rejected. Maybe for some authorization backends where permissions can be revoked (like internal or ldap), state_can_expire should return true? (I understand this can have performance implications, so might not be desirable) Either way it's hard to document the current behaviour without raising some eyebrows. Maybe the easiest (but not most satisfactory) to say that the effect of revoking permissions for existing AMQP connections is undefined.

appreciate your insights and comments

[michaelklishin]

Modern RabbitMQ versions will close all existing connections when a user or virtual host is deleted.

Permissions are cached for N latest operations by channels, and there is a caching authN/authZ backend, but any reasonably realistic client would run into a permission violation exception soon enough.

If you really want an app to not be able to access something, delete the credentials it uses.

[michaelklishin]

Different backends can work very differently from each other, in particular when they rely on external services. Like I said earlier, if you want to revoke a user's permissions effective immediately, delete the user and all of its connections should be closed with a reasonable log message.

[gomoripeti]

thank you for your very quick response

so what you say is

• even if there is no theoretic guarantee, in realistic scenarios a revoked permission will rotate out of the channel cache eventually
• but if someone wants guarantees, then deleting the user is the way forward (good info that it will close all connections). Fiddling with permissions of existing users is not tuned toward this use case

[michaelklishin]

Your understanding is correct.

[michaelklishin]

There is also a caching authN/authZ backend that allows you to control cache expiration time. This is mostly useful to cut down on traffic to external services and not to quickly revoke permissions of a user but it still feels relevant to this discussion.