Return actual auth error to the client in case of auth callout failure
ryad-eldajani-usv opened this issue · 1 comments
Proposed change
When a client tries to connect to a NATS server using credentials that are authenticated using the auth callout feature, in case of an auth failure, the client connection is forbidden and a generic "Authorization Violation" string is returned from the server.
Instead of a generic "Authorization Violation", the server may return the actual error that the server receives from the auth callout service. As specified in the documentation the auth callout service may return an error that correctly is logged in the server log.
As there may be multiple functional reasons why a client auth can be rejected by the auth callout, we propose that this error message could be returned to the client when the connection attempt is rejected. This way the client has the opportunity to react accordingly.
Use case
We have implemented an auth callout service to have a fine granular role and permission system of our end users that accessing our services (that internally use the NATS ecosystem). There can be multiple functional reasons, why a connection attempt from an end user may be rejected by our auth callout service, including but not limited to
- not existing, deleted, temporary locked user in the auth service
- request capacity exceeded
- specified service type not available for multiple reasons
The API gateway our end users are accessing is only able to see an "Authorization Violation" in any case the auth callout service rejects the connection attempt. This makes it difficult for the API gateway to return a useful error message back to the end user.
Contribution
As of the documentation (i.e. CONTRIBUTING.md) we first propose this change as an issue, before creating an actual PR.
We have crafted a simple patch to return the error to the client.
Please see: main...ryad-eldajani-usv:nats-server:error-messages-for-auth-violations
We would assume, that this patch is lacking of desired quality. We are looking for feedback. Thanks!
@ryad-eldajani-usv telegraphing information about why an user is rejected is not a good practice. The server logs report this information (or should, if you are not seeing them in the logs, this is something we need to address). With that said, there's nothing preventing the callout service from notifying other systems on your side by publishing a message about the error the callout service experienced.