Application credentials doesn't work when using access_rules

[eshulman2]

What happened?

Application credentials doesn't work when using access_rules. This is due to a (poorly documented) missing header called OpenStack-Identity-Access-Rules which enables access_rules when using application credentials. To allow using access_rules + application credentials the keystone token get and validate functions need to send this header in their request.

python implementation reference: https://opendev.org/openstack/python-keystoneclient/src/branch/master/keystoneclient/v3/tokens.py#L60

Version

v2 (current)

[kayrus]

when application credentials are created with access rules, these rules must be honored by the end service, e.g. neutron, nova or cinder. and these services must be configured accordingly, e.g. include service catalog on token response. are you sure that the corresponding services work fine without gophercloud? have you tried to issue a token using application credentials and use this token with a curl -H "X-Auth-Token: my-issued-token" http://my-service/etc/api/resource?

[winiciusallan]

I've tried to reproduce the same error as reported in ORC, and I was able to make the request using the generated token.

> curl -s -H "Content-Type: application/json" -H "X-Auth-Token: $TOKEN" http://devstack:9696/v2.0/networks | jq .
{
  "networks": [
    {
....

I configured my clouds.yaml with the application_credentials and created a token with it. I used that same token on the request.

[kayrus]

@eshulman2 could you please provide more debug details on with and wo the OpenStack-Identity-Access-Rules header?

[eshulman2]

Hi @kayrus sure,

This is related to this ORC bug in the feature spec it is mentioned that:

1. When requesting token validation, keystonemiddleware (or any 3rd party application that supports access rule enforcement) sets an Openstack-Identity-Access-Rules header with a version string as its value. Token validation for an application credential with a access rule list will only succeed if this header is present. The version string will allow us to safely extend this feature by invalidating tokens using the extended version in situations where keystonemiddleware only supports an older version of this feature.

2. If there is no Openstack-Identity-Access-Rules header in the token validation request, token validation fails.

here is an example usage with and without this flag: without:

$ TOKEN=$(openstack token issue -c id -f value)
$ curl -g -i -X GET -H "Accept: application/json" -H "X-Auth-Token: ${TOKEN}" -H "X-Subject-Token: ${TOKEN}" "https://mycloud.com:13000/v3/auth/tokens"
HTTP/1.1 404 NOT FOUND
date: Wed, 10 Dec 2025 16:49:55 GMT
server: Apache
content-length: 80
vary: X-Auth-Token
x-openstack-request-id: req-77b5fd64-8267-4038-88b7-23c77ea92c44
content-type: application/json

{"error":{"code":404,"message":"Failed to validate token","title":"Not Found"}}

with:

$ TOKEN=$(openstack token issue -c id -f value)
$ curl -H "OpenStack-Identity-Access-Rules: 1" -H "Accept: application/json" -H "X-Auth-Token: ${TOKEN}" -H "X-Subject-Token: ${TOKEN}" "https://mycloud.com:13000/v3/auth/tokens" 2>/dev/null | jq .token.expires_at
"2025-12-11T10:35:25.000000Z"

When identifying to other services that are not keystone and are using keystone middleware you won't hit this issue as it is strictly set for all requests: https://opendev.org/openstack/keystonemiddleware/src/branch/master/keystonemiddleware/auth_token/_identity.py#L24 https://opendev.org/openstack/keystonemiddleware/src/branch/master/keystonemiddleware/auth_token/_identity.py#L51

This means that only for direct keystone request you would need to set it as it is already set for all middleware using services.

[eshulman2]

I don't like this draft but I didn't have any better idea on implementing it without breaking the API https://github.com/gophercloud/gophercloud/pull/3576