Comment 8 for bug 1843609

Reviewed: https://review.opendev.org/681849
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=417d2c0e6e6bef39f447681325ae5b0ba46b2e2c
Submitter: Zuul
Branch: stable/rocky

commit 417d2c0e6e6bef39f447681325ae5b0ba46b2e2c
Author: Lance Bragstad <email address hidden>
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.

    Conflicts:
          keystone/server/flask/common.py

    This backport has conflicts with keystone/server/flask/common.py due to
    a massive refactor to get keystone off python-paste that started in
    Rocky and spilled over into Stein. The change is functionally equivalent
    to the patch merged to Train but done in keystone/common/controller.py
    instead of keystone/server/flask/common.py. There was also some changes
    to the test since it didn't have a utility method to obtain a
    system-scoped token.

    Change-Id: I8f0f7a623a1741f461493d872849fae7ef3e8077
    Closes-Bug: 1843609
    (cherry picked from commit 8f43b9cab00c86a455b2a9700b434e98b2e9c2d8)