yahoo-eng-team team mailing list archive

[Lance Bragstad <1915540@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1915540

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

Status in OpenStack Identity (keystone):
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1915540/+subscriptions