Requesting a scoped token when using x509 authentication is redundant

[Lance Bragstad]

In order to get a project-scoped token with an x509 certificate (not tokenless authentication), I need to specify X-Project-Id in the request header and I need to specify the project in the scope of the request body.

If I leave out the header (e.g., X-Project-Id) but keep the scope in the request body, the request fails with an HTTP 400 validation error [1]. If I leave the request body unscoped and keep the X-Project-Id header in the request, it is ignored an I get back an unscoped token [2].

It seems redundant to have to specify both to get a scoped token.

[0] https://pasted.tech/pastes/44d9393b0b01f40257fc216fec914ebb9bce07a6.raw
[1] https://pasted.tech/pastes/a41b17ec4c51bb57cb7625847544a75b97282585.raw
[2] https://pasted.tech/pastes/746cd35c00a6fd1c0d12a49ec1a705b4d0464b6a.raw

[Guang Yee (guang-yee)]

I think this is an invalid use case. X.509 certificate based authentication is not meant to be used with external auth. It is designed to be a federation protocol and hence using the federation workflow.

[Guang Yee (guang-yee)]

If documentation is unclear about that, we should update the doc instead.

[Colleen Murphy (krinkle)]

I think this is more about tokenless authentication than about external vs mapped X.509 authentication. We allow setting scope with tokenless auth:

https://opendev.org/openstack/keystone/src/commit/71a1fb0437cdb5949d808ba82e36f4586ec7794d/keystone/common/tokenless_auth.py#L48

but I don't see why it should work differently than setting scope for a token request, and if it does need to be different then the requirement to pass the scope in the request body should be relaxed.