For v3 tokens, if there are any group roles for the required scope (e.g. domain or project), then ONLY these roles will be returned, at the expense of any non-group (i.e directly assigned) roles.
This is caused by incorrect coding in the driver calls of "get_roles_for_user_and_project()" and "get_roles_for_user_and_domain()" where a dict update method is used to try add group roles into the user ones. Incredibly, despite lots of unit testing around this area, there isn't one that checks that both user and group roles are returned.
The v3 tokens are unaffected, since they don't call these functions, but rather add the group roles in manually.
For v3 tokens, if there are any group roles for the required scope (e.g. domain or project), then ONLY these roles will be returned, at the expense of any non-group (i.e directly assigned) roles.
This is caused by incorrect coding in the driver calls of "get_roles_ for_user_ and_project( )" and "get_roles_ for_user_ and_domain( )" where a dict update method is used to try add group roles into the user ones. Incredibly, despite lots of unit testing around this area, there isn't one that checks that both user and group roles are returned.
The v3 tokens are unaffected, since they don't call these functions, but rather add the group roles in manually.
The problem was discovered when implementing https:/ /blueprints. launchpad. net/keystone/ +spec/authentic ate-role- rationalization which looked to handle all such role combination in one place. Since I suspect we will want to back-port this particular fix to stable/grizzly, I have broken this out as a separate patch.