Keystone mapping always creates federated/ephemeral users in the default domain only

[reqa]

As a SCS operator, I want to separate the customers identities and projects as good as possible so that different customers cannot see other customers resources. Additionally as an SCS operator, I want to grant my customers the possibility of self servicing their resources (see also #184). To make that work, using separated domains in OpenStack/Keystone is assumed to be good.

When using the approach of #314 for connecting Keystone to Keycloak via a proxy realm (to avoid Keystone restarts when adding/removing customer realms), it becomes apparent that the Keystone mapping engine always creates the users in the same default domain. From research on #358, #359 and #360 it looks like the Keystone mapping engine needs to be improved/extended to allow selecting the target realm via a value determined by an OIDC token claim and mapped by the Keystone mapping.

Definition of Ready:

• [ ] User Story is small enough to be finished within one sprint
• [ ] User Story is clear and understood by the whole team
• [ ] Acceptance criteria are defined
• [ ] Acceptance criteria are clear and understood by the whole team

Definition of Done:

• [ ] All acceptance criteria are met
• [ ] Changes have been reviewed
• [ ] CI tests have run successfully
• [ ] Documentation has been updated
• [ ] Release Notes have been updated

[reqa]

Information from @knikolla regarding the question where the shadow accounts are created (if mapping type is ephemeral) or expected to exist, pre-created by external tooling (if mapping type is local):

The proxy approach however, will be putting all users in the same domain, which may not work for your use case.

There are two specs that were proposed a while ago to allow specifying the domain for the user in the mapping https://review.opendev.org/c/openstack/keystone-specs/+/748042, and allowing for project definitions as JSON https://review.opendev.org/c/openstack/keystone-specs/+/748748. It looks like these 2 specs would go a long way towards helping your use case UX. However, these specifications were implemented by introducing schema versioning for mappings and as I don't think that's the direction the keystone team wants to go, I'll try to reestablish a channel of communication with the proposer to remove that requirement.

• The first part (allow specifying the domain for the user in the mapping) is connected to this Bug: https://bugs.launchpad.net/keystone/+bug/1887515
• and to this "blueprint" https://blueprints.launchpad.net/keystone/+spec/versioning-for-attribute-mapping-schema
• and is backed by this proposed code changes: https://review.opendev.org/c/openstack/keystone/+/739966

From https://docs.opendev.org/opendev/infra-manual/latest/developers.html#rebasing-a-commit I learned that I could checkout that feature branch locally by running:

reqa:~/repos/openstack/keystone# git review -d 739966

which then left me in a local branch called review/rafael_weingartner/bug/1887515.

Originally posted by @reqa in https://github.com/SovereignCloudStack/issues/issues/314#issuecomment-1707992955

[JuanPTM]

Following the information from @knikolla and the code proposed in https://review.opendev.org/c/openstack/keystone/+/739966 I've been manually patching the testbed with the code related to the users domain.

After implementing the changes the test works, but not with the desire results. The ephemeral users are still assigned to the IdP domain (called keycloak in the testbed).

After a few hours of debugging I tracked down the origin of the issue and its related to the keystone/identity/core.py file in keystone where the shadow federated user are handle.

• During the handle_unscoped_token there is a call to the identity api to handle the user creation/load []()
• That idenity_api is just a class on the core.py, calling shadow_federate_user(idp,....) []()
• That calls for _shadow_federated_user where the id of the idp is obtain and used to place the user in that domain. []()

So, I'm thinking on how to modify all of this to use the domain id of the specific domain in the assertion, at the moment are the ideas are a bit too hacky to upstream them. We will think something.

Relevant links: _shadow_federated_user shadow_federated_use handle_unscoped_token

[JuanPTM]

An upstream merge request has been created with the current patch from the testbed.

https://review.opendev.org/c/openstack/keystone/+/896072/1

[JuanPTM]

I've contacted Kristi Nikolla due to the failing test that i can't fix. Waiting for his answer.

[JuanPTM]

Keystone patch CLI patch

After apply both upstream patches, the I was able to map the user into a domain specify on the claim. Still we have the problem that only works with non specific roles. This would require a future patch to keystone to make it fully functional.

dragon@testbed-manager:/opt/configuration/environments/openstack$ OS_CLOUD=admin openstack user list --domain d00001
+------------------------------------------------------------------+-------+
| ID                                                               | Name  |
+------------------------------------------------------------------+-------+
| 282fb55f5cb385a00c41eff538b075cbf03217f25ef1b8ebded4309c950a2018 | test4 |
+------------------------------------------------------------------+-------+

[JuanPTM]

After researching and testing on the testbed some changes, I've been able to map non domain specific roles into federated users mapped to domains.

dragon@testbed-manager:/opt/configuration/environments/openstack$ OS_CLOUD=admin openstack role assignment list --user test11
+----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+
| Role                             | User                                                             | Group | Project                          | Domain | System | Inherited |
+----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+
| c455008d365f44ab8df16f289178f425 | b94edcb60872d4c944a99996e338c9abae84c28414da112742f2b580fdcc4388 |       | 12fb9731a9f140b09e5da75bae595847 |        |        | False     |
| fac2e9f6092444e7bb5fa58db8779658 | b94edcb60872d4c944a99996e338c9abae84c28414da112742f2b580fdcc4388 |       | 12fb9731a9f140b09e5da75bae595847 |        |        | False     |
+----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+
dragon@testbed-manager:/opt/configuration/environments/openstack$ OS_CLOUD=admin openstack role list --domain d00001
+----------------------------------+----------------------+--------+
| ID                               | Name                 | Domain |
+----------------------------------+----------------------+--------+
| 690f7df3e4364aaabb39a0b6ad50d22d | member               | d00001 |
| c455008d365f44ab8df16f289178f425 | load-balancer_member | d00001 |
| fac2e9f6092444e7bb5fa58db8779658 | test_role            | d00001 |
+----------------------------------+----------------------+--------+
dragon@testbed-manager:/opt/configuration/environments/openstack$ OS_CLOUD=admin openstack role list
+----------------------------------+----------------------+
| ID                               | Name                 |
+----------------------------------+----------------------+
| 37dd45e68fe949128d01ffcf1dd07a6f | load-balancer_member |
| 67c6423e009546508b038b1a71cb6165 | reader               |
| 8992dbacd7d44a689774e10f0a6a50d2 | _member_             |
| 9f454e5558c745b3924e2c5f074e7782 | admin                |
| d2cbe08571a34b7eb2e2c5e793f7467e | member               |
+----------------------------------+----------------------+

I still have some bad news:

• With the current config I cannot access horizon (Login failed: You are not authorized for any projects or domains.). I think it's due to lack of permissions/policies, but i'm not completely sure.
• IF you had a role in a domain with the same name as the non specific one, we have a problem as only 1 will stay. So we have to think about what behavior we want in that case. (This probably can happen in the current version of openstack, before any patch)

[JuanPTM]

Finally, the upstream patch has been merged: Upstream patch It still needs the merge of this MR for the CLI integration.

I guess the next step is to create a gerrit review with the changes to use domain specific roles.

[reqa]

@berendt Since the patches are merged upstream they will be part of 2024.1 Carcal. Can we backport them to SCS?

[berendt]

No big deal when we already have it on master.

A backport of https://review.opendev.org/c/openstack/keystone/+/739966 only or do we need some dependencies?

[JuanPTM]

We will also need this one https://review.opendev.org/c/openstack/python-openstackclient/+/749572 Also merged already.

[berendt]

With the in python-openstackclient it will be difficult because we can install it in our opnenstackclient image, but nobody else has anything of it...

[berendt]

But the openstackclient releases are independent of the OpenStack major release. Maybe there will be the next minor openstackclient release before the next SCS release in March. Maybe you can ask them for it?

[JuanPTM]

Both merge request are merged.

Plan is to contact upstream asking for expected release time on openstackclient. For Keystone the plan is to try and backport it to OSISM. (Looks already done)

Probably this issue can be close.

[fkr]

I will ping gtema for openstack client.

[JuanPTM]

But the openstackclient releases are independent of the OpenStack major release. Maybe there will be the next minor openstackclient release before the next SCS release in March. Maybe you can ask them for it?

Accordingly to gtema's mail, They are on the release week so the openstackclient should be released soon.