You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## What?
If the new config setting `authorization_failure_disclosure`
for an authz backend is set to `true`, (`false` by default), RabbitMQ
will return the reason why access was denied to the client.
For now, only the HTTP and OAuth 2.0 auth backends support this new
config setting.
## Why?
This helps debugging and troubleshooting directly in the client.
Some users might not have access to the RabbitMQ logs, for other
users it's cumbersome to correlate authz denial in the client with
logs on the broker.
For example, in dev environments, it may be useful for users to learn
why vhost/resource/topic access was denied for a given OAuth 2.0 token.
Another example is that some customers would like to pass the reason why
authorization was denied from their custom HTTP auth backend via
RabbitMQ back to the client.
## How?
Authz backends can now return `{false, Reason}` as an alternative to
just `false` if access is denied.
For security reasons, the additional denial reason by the authz backend
will be returned to the client only if the operator opted in by setting
`authorization_failure_disclosure` to `true`.
Note that `authorization_failure_disclosure` applies only to
already authenticated clients when they try to access resources (e.g. vhosts,
exchanges, queues, topics). For security reasons, no detailed denial reason is
returned to the client if **authentication** fails.
Also note that `authorization_failure_disclosure` is set separately per
auth backend instead of being set globally for all auth backends. This
more fine granular configurability helps for use cases where the broker
should reveal the authz denial reason for only a specific auth backend,
e.g. only for HTTP backend, but not for OAuth 2.0 backend.
0 commit comments