GET /v3/domains returns all domains even in domain scope

[Markus Hentsch]

## Summary

The `GET /v3/domains` endpoint's returned domain list is not filtered if a domain-scoped authentication is used to access it. Instead it returns all domains.
In case domain names have relations to tenants/customers, any policy model that allows tenants to list domains will expose other tenants' identities.

In contrast, endpoints like `GET /v3/projects` and `GET /v3/groups` implement proper domain scoping. For further technical analysis how those endpoints achieve this, see here: https://github.com/SovereignCloudStack/issues/issues/446#issuecomment-1775095749

## Steps to reproduce

The following steps have been recorded using an unmodified DevStack environment.

First consider the following adjustment to `/etc/keystone/policy.yaml`:

```
identity:list_domains: role:member or rule:admin_required
```

... so that users with the `member` role may access `GET /v3/domains` for illustration purposes.

Next, create additional domains and a domain member:

```
openstack domain create domain2
openstack domain create domain3
openstack user create --domain domain2 --password "foobar123%" domain2-user
openstack role add --user domain2-user --domain domain2 member
```

Finally, create an openrc file for the domain member to have it issue a domain-scoped token:

```
source stackrc
export OS_REGION_NAME=RegionOne
export OS_AUTH_URL=http://$HOST_IP/identity
export OS_IDENTITY_API_VERSION=3
export OS_USERNAME=domain2-user
export OS_AUTH_TYPE=password
export OS_USER_DOMAIN_NAME=domain2
export OS_DOMAIN_NAME=domain2
export OS_PASSWORD=foobar123%
unset OS_PROJECT_NAME
unset OS_TENANT_NAME
unset OS_PROJECT_DOMAIN_NAME
unset OS_PROJECT_DOMAIN_ID
unset OS_USER_DOMAIN_ID
```

(this example is based on a DevStack environment)

Now the following happens when the domain member user is accessing the domain list:

```
$ source domain-member.openrc

$ openstack domain list
+----------------------------------+---------+---------+--------------------+
| ID | Name | Enabled | Description |
+----------------------------------+---------+---------+--------------------+
| 1a1a793377464131a2744e27fec9bcdf | domain2 | True | |
| 449167ed506c43cea43b997a1f345606 | domain3 | True | |
| default | Default | True | The default domain |
+----------------------------------+---------+---------+--------------------+
```

Although the token of the domain member user making the API request is strictly domain-scoped, all domains are returned.
In case domain names would somehow be related to other tenants' identities, these would get exposed this way.

## Notes

This is not an issue with Keystone's default policy configuration since only admins may access the `GET /v3/domains` endpoint at all and those have access to all domains anyway.

Only unlocking `GET /v3/domains` for other roles will make this undesired behavior possible.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit dd785ee692118a56ea0e3aaaf7f5bd6c73ea9c91
Author: Markus Hentsch <email address hidden>
Date: Fri Nov 3 10:43:34 2023 +0100

    Add domain scoping to list_domains

    Introduces domain-scoped filtering of the response list of the
    list_domains endpoint when the user is authenticated in domain scope
    instead of returning all domains. This aligns the implementation with
    other endpoints like list_projects or list_groups and allows for a
    domain-scoped reader role.
    Changes the default policy rule for identity:list_domains to
    incorporate this new behavior for the reader role.

    Closes-Bug: 2041611
    Change-Id: I8ee50efc3b4850060cce840fc904bae17f1503a9

[OpenStack Infra (hudson-openstack)]

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