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

Bug #1843609 reported by Lance Bragstad on 2019-09-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Status tracked in Train
Lance Bragstad
Lance Bragstad
Lance Bragstad
Lance Bragstad

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

Observed failures:

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


Changed in keystone:
status: New → Triaged
importance: Undecided → High
tags: added: system
tags: added: system-scope
removed: system

Fix proposed to branch: master

Changed in keystone:
assignee: nobody → Lance Bragstad (lbragstad)
status: Triaged → In Progress
no longer affects: keystone/stein
no longer affects: keystone/trunk
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers