Hello, Thanks for the replies; Please note the user I am using does not exist in keystone, as I wished to test the shadow/ephemeral user via federation.

...

One thing I don't see in your output is role assignment. Do you have role mapping as part of mappings?

I have the mapping set to use the 'member' role, which does exist: # openstack mapping show attribute_mapping_keycloak_cloud_ld +----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | id | attribute_mapping_keycloak_cloud_ld | | rules | [{'local': [{'user': {'name': '{0}', 'email': '{1}', 'domain': {'name': '{2}'}}, 'domain': {'name': '{2}'}, 'projects': [{'name': '{3}', 'roles': [{'name': 'member'}]}]}], 'remote': [{'type': | | | 'OIDC-preferred_username'}, {'type': 'OIDC-email'}, {'type': 'OIDC-openstack-user-domain'}, {'type': 'OIDC-openstack-default-project'}]}] | | schema_version | 1.0 | +----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ # openstack role show member +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | id | ff15fcf085014471b166140c2bc4ee78 | | name | member | | domain_id | None | | description | None |

...

Have you also tried to create non-scoped token, to check if you are not granted permissions to the specific project, or in general?

I've tried to do a 'token issue' in the CLI, if that is what you mean? Anyway it's the same error as before. Maybe there is a POST I can send to keystone that I could do for an unscoped in particular?

...

Another guess, is that iirc, keystone is not really managing role assignments after shadow user (it could have changed in later releases). Then if you adjusted configuration after the first login, it may still acting with prior permissions. So potentially cleaning up the user from shadow users in DB might be worth trying as well

I didn't see any users in the nonlocal and federated user tables, is there another table I need to check? MariaDB [keystone]> select * from federated_user; Empty set (0.001 sec) MariaDB [keystone]> select * from nonlocal_user; Empty set (0.001 sec) I also checked the federation_protocol table, and found that the remote_id_attribute is null; would this need to be changed to match what kolla is deploying? MariaDB [keystone]> select * from federation_protocol; +--------+----------+-------------------------------------+---------------------+ | id | idp_id | mapping_id | remote_id_attribute | +--------+----------+-------------------------------------+---------------------+ | openid | cloud.ld | attribute_mapping_keycloak_cloud_ld | NULL | +--------+----------+-------------------------------------+---------------------+ The idp is also enabled MariaDB [keystone]> select * from identity_provider; +----------+---------+---------------------------+----------------------------------+-------------------+ | id | enabled | description | domain_id | authorization_ttl | +----------+---------+---------------------------+----------------------------------+-------------------+ | cloud.ld | 1 | Authenticate via keycloak | 707860e8ad4e4040b9668882e47db610 | NULL | +----------+---------+---------------------------+----------------------------------+-------------------+

...

try this, remove (unset all exports) except

...

export OS_AUTH_URL=http://$KEYSTONE_IP:5000/v3 export OS_AUTH_TYPE=v3oidcpassword export OS_IDENTITY_PROVIDER=cloud.ld export OS_PROTOCOL=openid

...

And set this one export OS_ACCESS_TOKEN=<See if you can get an access token from keycloak from you user profile>

...

not sure if you need to configure/create an application in kc to give access tokens

...

and openstack token issue

I tried this, however v3oidcpassword requires a user/pass/client_id/client secret, so it ends up being the same exports as I had before. Thanks for any further info! On Thu, Oct 23, 2025 at 1:07 AM Mario David <mariojmdavid@gmail.com> wrote:

hi Tyler

try this, remove (unset all exports) except

export OS_AUTH_URL=http://$KEYSTONE_IP:5000/v3 export OS_AUTH_TYPE=v3oidcpassword export OS_IDENTITY_PROVIDER=cloud.ld export OS_PROTOCOL=openid

And set this one export OS_ACCESS_TOKEN=<See if you can get an access token from keycloak from you user profile>

not sure if you need to configure/create an application in kc to give access tokens

and openstack token issue

best Mario

On 23/10/25 05:35, Tyler Wilson wrote:

...

Hello All,

I'm trying to get a test idp setup going via this document: https://docs.openstack.org/kolla-ansible/latest/contributor/setup-identity-p... and everything seems to be configured correctly however I am getting a 403 when I try to use the openstack CLI to test.

# openstack token issue You are not authorized to perform the requested action. (HTTP 403) (Request-ID: req-be79246b-ccc1-4fbd-ba3f-fa98b9cae7ba) # openstack user show customer01 You are not authorized to perform the requested action. (HTTP 403) (Request-ID: req-4e385968-796e-44a0-8003-351188c202ba)

In the keystone log I see a traceback with handle_unscoped_token and apply_mapping_filter (full output here: https://pastebin.com/xZ2qeCPW ) so maybe I'm missing something with permissions?

I have the attribute mapping exactly as it is in the documentation, and im getting this when replicate the POST to userinfo with the bearer token;

{"sub":"$UUID","email_verified":true,"name":"CustomerFirst CustomerLast","preferred_username":"customer01","given_name":"CustomerFirst","openstack-default-project":"customers","openstack-user-domain":"cloud.ld","family_name":"CustomerLast","email":"customer01@example.com"}

I also checked keycloak and the user event log shows green authentications. Both domain and project exist in identity as well

# openstack domain list | grep cloud.ld | $UUID | cloud.ld | True | | # openstack project list | grep customers | $UUID | customers |

I'm using these exports for the client

export OS_AUTH_URL=http://$KEYSTONE_IP:5000/v3 export OS_PROJECT_NAME="customers" export OS_PROJECT_DOMAIN_NAME="cloud.ld" export OS_USERNAME="customer01" export OS_PASSWORD="$USER_PASSWORD" export OS_INTERFACE=public export OS_IDENTITY_API_VERSION=3 export OS_CACERT=/etc/ssl/certs/ca-certificates.crt export OS_AUTH_TYPE=v3oidcpassword export OS_CLIENT_ID=Keystone export OS_CLIENT_SECRET=$SECRET_ALTHOUGH_DOESNT_MATTER export OS_IDENTITY_PROVIDER=cloud.ld export OS_PROTOCOL=openid export OS_ACCESS_TOKEN_ENDPOINT=https://$KEYCLOAK_IP:8443/realms/cloud.ld/protocol/openid-connect/token

Is there anything I might be missing here? Thanks for any help!