In the context of authenticating within Keystone, there are 3 different scopes: project, domain, or system. User is not part of the scope.
I do not believe what you're trying to achieve is possible with that API call and policy changes. The target in the context is only constructed with scope.project.id as can be seen in the code [0].
In the meanwhile, it is possible with multiple API calls.
1) User can query the projects that the user has permission for. [1]
2) User can authenticate to the projects. The authentication call will return you the roles that you have available in that project.
Hi Sam,
In the context of authenticating within Keystone, there are 3 different scopes: project, domain, or system. User is not part of the scope.
I do not believe what you're trying to achieve is possible with that API call and policy changes. The target in the context is only constructed with scope.project.id as can be seen in the code [0].
In the meanwhile, it is possible with multiple API calls.
1) User can query the projects that the user has permission for. [1]
2) User can authenticate to the projects. The authentication call will return you the roles that you have available in that project.
[0]. https:/ /github. com/openstack/ keystone/ blob/0003168912 6b2a40461921ac4 715ff595fde51ae /keystone/ api/role_ assignments. py#L85 /docs.openstack .org/api- ref/identity/ v3/?expanded= get-available- project- scopes- detail# get-available- project- scopes
[1]. https:/