Comment 5 for bug 1626046

this is great news! - thanks Nikolay. - there is one thing I have noticed in the shadow users blue print and that is the change to keystone policy file, I don't know if this will have any affect on ...

"Another issue is with the group-based access model that is currently used with federated authentication. After some testing I have found that user with group-derived roles is not able to grant trusts, as Keystone does not take it into account when validating if the user is eligible to create trust with given permissions."

...but the change by keystone policy.json

this was added:

"identity:list_projects_for_user": "",
"identity:list_domains_for_user": "",

and this was removed:

"identity:list_projects_for_groups": "",
"identity:list_domains_for_groups": "",

it's not obvious to me why this is a requirement for federated access - the upgrade note only states:

upgrade:
  - In the policy.json file, we changed `identity:list_projects_for_groups`
    to `identity:list_projects_for_user`. Likewise, we changed
    `identity:list_domains_for_groups` to `identity:list_domains_for_user`. If
    you have customized the policy.json file, you will need to make these
    changes. This was done to better support new features around federation.

this sort of goes against operator intuition as one would expect federated 'users' to be ephemeral and consume their groups role - now it seems that federated users will also be keystone users which is not usual. (e.g. AWS federated users are not IAM users - simple RBAC - also the mapping is not nearly as awful especially for a single user with multiple roles)