It landed in Queens. This patch basically enabled the /v3/OS-FEDERATION/projects API to NOT failed with an HTTP 500 Internal Server Error with the presence of the 'group_ids' key in auth_context.
2. This could be a another bug. When listing assignments for groups, we should be using the groups filter, not 'source_from_group_ids'.
So it appears that if 'source_from_group_ids' is empty, it will return the kitchen-and-sink, so to speak. In other words, this API was secured purely by dumb luck. :-)
The original problem may've caused by a couple of things.
1. This patch basically automatically added the 'group_ids' attribute in the auth_context regardless whether there are any groups or not.
https:/ /review. openstack. org/#/c/ 523650/
It landed in Queens. This patch basically enabled the /v3/OS- FEDERATION/ projects API to NOT failed with an HTTP 500 Internal Server Error with the presence of the 'group_ids' key in auth_context.
2. This could be a another bug. When listing assignments for groups, we should be using the groups filter, not 'source_ from_group_ ids'.
https:/ /github. com/openstack/ keystone/ blob/master/ keystone/ assignment/ core.py# L242
'source_ from_group_ ids' work differently. See
https:/ /github. com/openstack/ keystone/ blob/master/ keystone/ assignment/ core.py# L961
So it appears that if 'source_ from_group_ ids' is empty, it will return the kitchen-and-sink, so to speak. In other words, this API was secured purely by dumb luck. :-)