Description of problem:
In RHOSP 17.1, we introduced Federation. A Govt. CU with Federation via RH-SSO is having issues with Application Credentials, and by default they do not work at all. However, if the customer sets `default_authorization_ttl`, then Application Credentials will work for that lifetime, before needing to be recreated again.

```

1. keystone.conf
   ...
   [federation]
2. Default time in minutes for the validity of group memberships carried over
3. from a mapping. Default is 0, which means disabled. (integer value)
   #default_authorization_ttl = 0
   ```

Version-Release number of selected component (if applicable):
python3-keystoneauth1-4.4.0-17.1.20230620202404.112bcae.el9ost.noarch
python3-keystoneclient-4.3.0-17.1.20230621025111.d5cb761.el9ost.noarch
python3-keystonemiddleware-9.2.0-17.1.20230620211753.3659bda.el9ost.noarch

How reproducible:
Always

Steps to Reproduce:
1. Have a federated SSO setup.
2. Attempt to authentication with Application Credentials.
3. Fail.
4. Attempt again with `default_authorization_ttl` set to a positive non-zero value.
5. Application Credentials are valid for the `default_authorization_ttl` in minutes from the time of creation, then are invalid. Setting this to an absurdly high value is also not sustainable, because this could have security implications.

Actual results:

• Application Credentials with Federation do not work as documented.

Expected results:

• Application Credentials with Federation should work for the period of time specified upon creation of the token.

Additional info:
It seems potentially this issue may be addressed by [1][2].

[1] https://review.opendev.org/c/openstack/keystone/+/713976
[2] https://bugs.launchpad.net/keystone/+bug/1809116

The CU is reporting that this is impacting their go-live in migrating from RHOSP13 to RHOSP17.1, since they have Consulting involvement and plan to use os-migrate to migrate VMs across from the previous cloud to the new cloud.