PKI tokens in Grizzly are enabled by default, so if a grizzly deployment is issuing PKI tokens to an older client, that client will attempt to perform online validation and hit this code path. Correct?
Adam: your patch appears to be completely removing support for belongsTo. Apparently we don't have test coverage on this particular feature, and I'm not aware that this feature is used within OpenStack, but it's definitely part of the v2.0 API that should be tested by suites like tempest. This is used to perform server-side validation that a token has authorization on a specific tenant in one of the following two calls:
GET /v2.0/tokens/{token_id}?belongsTo={tenant_id}
HEAD /v2.0/tokens/{token_id}?belongsTo={tenant_id}
The auth_token middleware does this same validation client-side, rather than asking keystone to do it server-side.
These two lines need to be restored:
- if belongs_to:
- assert data['access']['token']['tenant']['id'] == belongs_to
PKI tokens in Grizzly are enabled by default, so if a grizzly deployment is issuing PKI tokens to an older client, that client will attempt to perform online validation and hit this code path. Correct?
Adam: your patch appears to be completely removing support for belongsTo. Apparently we don't have test coverage on this particular feature, and I'm not aware that this feature is used within OpenStack, but it's definitely part of the v2.0 API that should be tested by suites like tempest. This is used to perform server-side validation that a token has authorization on a specific tenant in one of the following two calls:
GET /v2.0/tokens/ {token_ id}?belongsTo= {tenant_ id} {token_ id}?belongsTo= {tenant_ id}
HEAD /v2.0/tokens/
The auth_token middleware does this same validation client-side, rather than asking keystone to do it server-side.
These two lines need to be restored:
- if belongs_to: ]['token' ]['tenant' ]['id'] == belongs_to
- assert data['access'