Fix 403 issue when policy not found to return 404

Question

Fix 403 issue when policy not found to return 404

RoValentim opened this issue 5 years ago · comments

When a policy is not found the return error is 403, but should be 404.

That's happening because on DoPoliciesAllow function, the first validation is to check if exist a policy, when that's always false, the loop exit without any error and the variable allowed stay false, so the return is always ErrRequestDenied, which is the 403.

In this case should return ErrNotFound which is 404, for that only need to check if the policy was found.

I made a fix to that on:
https://github.com/RoValentim/ladon/blob/bf9a39ca71cd959a9e9b2228f88fc54f698f49ed/ladon.go#L63

Since CONTRIBUTING.md ask for first discuss it here, I would like to know if it's possible to create a PR for that, or should I make something more to solve this issue?

hackerman · Answer 1 · Thu Nov 14 2019 17:30:46 GMT+0800 (China Standard Time)

The behavior is correct. „not found“ is not valid response for: „Is the request authorized“? Only „not authorized“ and „forbidden“ and „ok“ are correct answers.

…

On 13. Nov 2019, at 12:10, Rodrigo Valentim ***@***.***> wrote: When a policy is not found the return error is 403, but should be 404. That's happening because on DoPoliciesAllow function, the first validation is to check if exist a policy, when that's always false, the loop exit without any error and the variable allowed stay false, so the return is always ErrRequestDenied, which is the 403. In this case should return ErrNotFound which is 404, for that only need to check if the policy was found. I made a fix to that on: https://github.com/RoValentim/ladon/blob/bf9a39ca71cd959a9e9b2228f88fc54f698f49ed/ladon.go#L63 Since CONTRIBUTING.md ask for first discuss it here, I would like to know if it's possible to create a PR for that, or should I make something more to solve this issue? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Rodrigo Valentim · Answer 2 · Thu Nov 14 2019 17:58:51 GMT+0800 (China Standard Time)

Well, I just want to be more consistent with RFC 7235:
https://tools.ietf.org/html/rfc7235

Ladon don't need to be RFC 7235 compliance, but even so the concept should be the same for that approach:

For Unauthorized, you can say that you aren’t authenticated, either not authenticated at all, or authenticated incorrectly, but please re-authenticate and try again.

Forbidden it’s permanent, basically means that Ladon know who you are, believe who you say you are, but you just don’t have permission to access.

So, if the policy doesn't exists, is wrong to use:

Unauthorized, since there's no policy to authenticate, doesn't matter the action, subject or resource, you'll never find it.
Forbidden, because for that should match a policy which action is not allowed for that resource/subject.

Maybe Not Found is the wrong approach too, but for sure if there is no policy at all to match the request, both Unauthorized and Forbidden are wrong.

If the return will be Not Found and for some reason the application wants to return Forbidden, it's easy to deal with it, but if it's always return Forbidden, it's impossible to the application know if the reason is because was found and it's forbidden, or not found at all, so any application that use Ladon cannot be RFC compliance, which is a big restriction for serious applications.

hackerman · Answer 3 · Mon Nov 18 2019 18:40:04 GMT+0800 (China Standard Time)

but for sure if there is no policy at all to match the request, both Unauthorized and Forbidden are wrong.

That is an incorrect assumption. The chain goes like this: deny > allow > default (deny). The default is applied when no resource is found. Therefore, 403 is the correct answer. We know who you are, but you do not have permission to see that resource.

This logic applies to all and every authorization mechanism. If you have RBAC, and your user does not have a permission (which basically means the user does not have (404) the permission) you get a 403. In ACL the same. Why should it be different here?

it's impossible to the application know if the reason is because was found and it's forbidden, or not found at all, so any application that use Ladon cannot be RFC compliance, which is a big restriction for serious applications.

The downstream (serious) application does not care if a policy store was able to find a policy or not. It only cares if the request is allowed or not. If you wish to debug why the request failed, you check your policy store (e.g. logs), you do not handle this in the downstream application.