HTTP 403s are more confusing than HTTP 404s when evaluating authorization of a non-existent resource

[Lance Bragstad]

When keystone implemented support for default personas (system-admin, system-member, system-reader, domain-admin, domain-member, domain-reader, project-admin, project-member, project-reader), we took the stance that HTTP 403s should be returned for non-existent resources outside of someone's authorization.

For example, if the domain administrator for Coke attempts to update a project in Pepsi's domain, keystone will return a 403. If the domain administrator for Coke attempts to update the project for a domain the doesn't exist, keystone will still return a 403.

Even though the return code is consistent in both cases, it's confusing because the client can interpret existence from 403 if they're not familiar with what keystone is doing under the covers (e.g., something exists here, I just don't have access to it).

A different, and contrasting approach would be to always return 404. The domain administrator for Coke would receive a 404 attempting to update a project in Pepsi's domain, or in a domain that doesn't exist.

Even though the domain administrator for Coke is clearly unauthorized to access resources outside their authorization, an HTTP 404 allows keystone to play dumb for both cases and leaves less room for existence interpretation by the client.

Dan, Ghanshyam and I discussed this while working through the approach glance should take implementing the same personas [0].

http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2021-02-12.log.html#t2021-02-12T15:28:21

[Lance Bragstad (lbragstad)]

These tests show case the behavior described in the bug:

https://opendev.org/openstack/keystone/src/commit/d67975e7b9cdbb3654840d7453402438a546c1bf/keystone/tests/protection/v3/test_projects.py