Trigger a 4.3.x alpha release build / trigger_alpha_build (push) Waiting to runDetails
Test Authentication/Authorization backends via mutiple messaging protocols / selenium (chrome, 1.17.3, 27.3) (push) Waiting to runDetails
Test Authentication/Authorization backends via mutiple messaging protocols / summary-selenium (push) Blocked by required conditionsDetails
Test (make) / Build and Xref (1.18, 26) (push) Waiting to runDetails
Test (make) / Build and Xref (1.18, 27) (push) Waiting to runDetails
Test (make) / Build and Xref (1.18, 28) (push) Waiting to runDetails
Test (make) / Test (1.18, 28, khepri) (push) Waiting to runDetails
Test (make) / Test (1.18, 28, mnesia) (push) Waiting to runDetails
Test (make) / Test mixed clusters (1.18, 28, khepri) (push) Waiting to runDetails
Test (make) / Test mixed clusters (1.18, 28, mnesia) (push) Waiting to runDetails
Test (make) / Type check (1.18, 28) (push) Waiting to runDetails
## 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.
As mentioned in discussion #14426, the way that `cacerts` is handled by
cuttlefish schemas simply will not work if set.
If `cacerts` were set to a string value containing one X509 certificate,
it would eventually result in a crash because the `cacerts` ssl option
must be of [this type](https://www.erlang.org/doc/apps/ssl/ssl.html#t:client_option_cert/0):
```
{cacerts, CACerts :: [public_key:der_encoded()] | [public_key:combined_cert()]}
```
Neither of those are strings, of course.
This PR removes all use of `cacerts` in cuttlefish schemas. In addition,
it filters out `cacerts` and `certs_keys` from being JSON-encoded by an
HTTP API call to `/api/overview`. It _is_ technically possible to set
`cacerts` via `advanced.config`, so, if set, it would crash this API
call, as would `certs_keys`.
David Ansari
Luke Bakken
Michael Klishin
Luke Bakken
Marcial Rosales
Michael Klishin
SzumiecM
Michael Klishin
Daniil Fedotov
Arnaud Cogoluègnes