| 2013-07-04 15:52:24 |
Henry Nash |
bug |
|
|
added bug |
| 2013-07-04 15:53:05 |
Henry Nash |
description |
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/authenticate-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. |
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 v2 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/authenticate-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. |
|
| 2013-07-04 18:55:34 |
Henry Nash |
keystone: importance |
High |
Critical |
|
| 2013-07-05 05:08:32 |
OpenStack Infra |
keystone: status |
New |
In Progress |
|
| 2013-07-05 16:54:44 |
Henry Nash |
bug |
|
|
added subscriber Guang Yee |
| 2013-07-05 16:55:26 |
Henry Nash |
description |
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 v2 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/authenticate-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. |
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 and 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 v2 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/authenticate-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. |
|
| 2013-07-05 18:09:53 |
Dolph Mathews |
tags |
|
grizzly-backport-potential |
|
| 2013-07-08 20:58:01 |
OpenStack Infra |
keystone: status |
In Progress |
Fix Committed |
|
| 2013-07-17 12:02:06 |
Thierry Carrez |
keystone: status |
Fix Committed |
Fix Released |
|
| 2013-07-24 20:10:55 |
Dolph Mathews |
nominated for series |
|
keystone/grizzly |
|
| 2013-07-24 20:10:55 |
Dolph Mathews |
bug task added |
|
keystone/grizzly |
|
| 2013-07-24 20:11:05 |
Dolph Mathews |
keystone/grizzly: importance |
Undecided |
Critical |
|
| 2013-07-24 21:17:07 |
Henry Nash |
keystone/grizzly: status |
New |
In Progress |
|
| 2013-07-24 21:17:11 |
Henry Nash |
keystone/grizzly: assignee |
|
Henry Nash (henry-nash) |
|
| 2013-07-26 21:11:35 |
Matt Riedemann |
bug |
|
|
added subscriber Matt Riedemann |
| 2013-07-27 03:24:55 |
OpenStack Infra |
keystone/grizzly: status |
In Progress |
Fix Committed |
|
| 2013-08-05 19:44:33 |
Alan Pevec |
keystone/grizzly: milestone |
|
2013.1.3 |
|
| 2013-08-05 19:46:51 |
Alan Pevec |
tags |
grizzly-backport-potential |
|
|
| 2013-08-08 19:59:14 |
Alan Pevec |
keystone/grizzly: status |
Fix Committed |
Fix Released |
|
| 2013-10-17 12:36:19 |
Thierry Carrez |
keystone: milestone |
havana-2 |
2013.2 |
|
