Application credential documentation doesn't mention necessary service configuration

[Lance Bragstad]

In order for keystonemiddleware to validate access rules it needs to be configured with the service_type [0].

We should update the application credential documentation [1] to describe this, or potentially add a new section to the admin guide so that operators are aware they need to set this configuration for users to actually use access rules.

[0] https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L180-L183
[1] https://docs.openstack.org/keystone/latest/user/application_credentials.html

[Lance Bragstad (lbragstad)]

I noticed this using a deployment with an application credential and access rules and I kept getting a 401 when I didn't expect it (I added the API to the access rules.)

It wasn't until I dug through the keystonemiddleware code that I realized I needed to set that configuration option in keystonemiddleware. After I updated the configuration for all the services, access rules and keystonemiddleware filtered properly.

I feel like this might be an important part of the feature that should be called out, since it's not straightforward from the error what needs to happen.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/keystone/+/836309

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/keystone/+/836309
Committed: https://opendev.org/openstack/keystone/commit/3856cbf10d4d19b9d7797d600ef096b0c04aaedb
Submitter: "Zuul (22348)"
Branch: master

commit 3856cbf10d4d19b9d7797d600ef096b0c04aaedb
Author: Marcin Wilk <email address hidden>
Date: Mon Apr 4 09:37:33 2022 +0000

    Add service_type config info for access rules

    The service_type config param is crucial to successfully use
    application credentials with access rules.

    Closes-Bug: #1950464
    Change-Id: I98d1cfcbd229f2939d900861f453efa996466c32

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/keystone 22.0.0.0rc1 release candidate.