Optionally return HTTP auth backend denial reason to client #14641
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ansd
force-pushed
the
auth-backend-http-log-deny-reason
branch
3 times, most recently
from
16af50f to
5e08d74
Compare
ansd
force-pushed
the
auth-backend-http-log-deny-reason
branch
5 times, most recently
from
f9b9fa0 to
36f885c
Compare
ansd
changed the title
## What? Support logging (at INFO level) the reason provided by the HTTP auth backend why authentication or autorisation was denied. ## Why? * Security and compliance often require detailed logs of why access was denied * Operational debugging: Operators see immediately in RabbitMQ logs why authentication/authorization failed without checking the HTTP backend logs ## How? The HTTP body returned by the HTTP auth server is allowed to be `deny <Reason>` where `<Reason>` is any text that will be logged by RabbitMQ at INFO level.
## 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 auth backend supports 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, 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.
ansd
force-pushed
the
auth-backend-http-log-deny-reason
branch
from
36f885c to
9c075ad
Compare
dumbbell
reviewed
Oct 9, 2025
dumbbell
approved these changes
Oct 9, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains two commits.
Commit 1:
What?
Support logging (at INFO level) the reason provided by the HTTP auth backend why authentication or autorisation was denied.
Why?
How?
The HTTP body returned by the HTTP auth server is allowed to be
deny <Reason>where<Reason>is any text that will be logged by RabbitMQ at INFO level.Commit 2:
What?
If the new config setting
authorization_failure_disclosurefor an authz backend is set to
true, (falseby default), RabbitMQwill return the reason why access was denied to the client.
For now, only the HTTP auth backend supports 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, 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 tojust
falseif 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_disclosuretotrue.Note that
authorization_failure_disclosureapplies only toalready 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_disclosureis set separately perauth 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.