yahoo-eng-team team mailing list archive

[OpenStack Infra <1843609@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/681833
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=8f43b9cab00c86a455b2a9700b434e98b2e9c2d8
Submitter: Zuul
Branch:    master

commit 8f43b9cab00c86a455b2a9700b434e98b2e9c2d8
Author: Lance Bragstad <lbragstad@xxxxxxxxx>
Date:   Thu Sep 12 16:46:26 2019 +0000

    Make system tokens work with domain-specific drivers
    
    When calling certain group or user APIs, keystone logic would attempt
    to figure out the domain to scope responses to. This was specific to
    enabling domain-specific driver support, where each domain is backed
    by a different identity store. This functionality is turned off by
    default. Since system-scoped tokens are not associated to a domain
    (unlike project-scoped tokens or domain-scoped tokens), the logic to
    determine a domain from a system-scoped token was breaking and
    returning an erroneous HTTP 401 Unauthorized when system users
    attempted to list users or groups.
    
    This commit adds support for domain detection with system-scoped
    tokens.
    
    Change-Id: I8f0f7a623a1741f461493d872849fae7ef3e8077
    Closes-Bug: 1843609


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
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/1843609

Title:
  Domain-specific domain ID resolution breaks with system-scoped tokens

Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Identity (keystone) queens series:
  In Progress
Status in OpenStack Identity (keystone) rocky series:
  In Progress
Status in OpenStack Identity (keystone) stein series:
  In Progress
Status in OpenStack Identity (keystone) train series:
  Fix Released

Bug description:
  System-scope was introduced in Queens [0] but recently we discovered a
  weird case where system users aren't able to do things they should be
  able to with system-scoped tokens when domain-specific drivers are
  enabled.

  For example, they are unable to list groups or users because the API
  logic for GET /v3/groups and GET /v3/users tries to resolve a domain
  ID from the request [1]. If domain-specific drivers are enabled and
  there isn't a domain ID associated to the request (either with a
  domain-scoped token or a project-scoped token) the API returns a 401,
  which makes no sense from the context of a system user [2].

  You can recreate this locally by enabling domain-specific drivers in
  keystone.conf [3] and running the test_groups or test_users v3
  protection tests using:

    $ tox -e py37 -- keystone.tests.unit.protection.v3.test_groups

  Observed failures:
  https://pasted.tech/pastes/b45c6b015b97c865018c4b3290f60e0456fe304a.raw

  This isn't blocking the gate because domain-specific drivers are off
  by default and the logic short-circuits [4].

  [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
  [1] https://opendev.org/openstack/keystone/src/branch/master/keystone/api/groups.py#L84
  [2] https://opendev.org/openstack/keystone/src/branch/master/keystone/server/flask/common.py#L917-L943
  [3] https://pasted.tech/pastes/e8ffce7a3377b960dd88de8c88e2ccfd173ec726.raw
  [4] https://opendev.org/openstack/keystone/src/branch/master/keystone/server/flask/common.py#L924-L926

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