Open Stack

On 12/19/2012 09:56 AM, David Chadwick wrote:
> Hi Adam
>
> I believe our attribute mapping work is orthogonal to and independent of
> revocation of roles or tokens, since attribute mapping takes place 
> before the token is created. if a role is revoked subsequently to it 
> being assigned by the attribute mapping service, then it will remain 
> revoked.
>
> What could potentially effect the mapping, is if the user's 
> organisational attributes (or group memberships, if groups were to use 
> mappings) are revoked whilst he is accessing the cloud. Currently this 
> would not cause his current session to be terminated or his mapped 
> roles to be revoked since there is no mechanism for the IDP to inform 
> OpenStack about this. But when the user tries to activate a new 
> session he would not be able to since he would no longer have the 
> correct organisational attributes (or groups) and could therefore no 
> longer be assigned a role.
>
> However, I need you to answer one question
>
> You said " When a users roles change,..." How do they change? Who 
> changes them and how
It would need to happen when either the user attribute changes, or the 
mapping changes.  Whenever a user would no longer have a role that they 
used to have, all tokens that would have had that role need to be revoked.

Say a user is a member of group admins.  Then they get promoted. They 
are removed from admins, and added to supervisors.

both admins and supervisors  have the role "VMManagers"  that allows 
them to do things like create new vms and so forth, as enforced by 
RBAC.  But we realize that we should not  trust managers to do this. So 
we unmap the role "VMManagers" from the group "supervisors."  All tokens 
for supervisors must now be revoked.


Now when a user is promoted from admin to supervisor, we change their 
group membership, and their tokens must be revoked at that point.


Both are "role changes" and both are revokable events.

>
> regards
>
> David
>
> On 19/12/2012 14:30, Henry Nash wrote:
>> Hi Adam,
>>
>> Quite right.  The api blueprint for user groups specifies that this
>> should happen (Dolph had been reviewing this) and the server code is
>> using the same revoke mechanism that happens when a user role
>> changes. I'll see if I can refactor this so it is more general and
>> will then be obvious how we could plug in the mapping triggers.
>>
>> Henry On 19 Dec 2012, at 14:25, Adam Young wrote:
>>
>>> Since both of you are working on stuff invloving how Roles are
>>> assigned to users, I want you to both be aware of an important
>>> issue.  When a users roles change, their tokens get invalidated.
>>> Since both the group and mapping blueprints will affect Role
>>> assignments, both can have significant effects on the number of
>>> users whose tokens get revoked.
>>>
>>>
>>> Please update both of your blueprints to reflect this.    We will
>>> need a common mechanism for determining which tokens to revoke.
>>>
>>> This must happen before anything that changes  role assignments can
>>> be merged.
>>>
>>
>>
>> _______________________________________________ OpenStack-dev mailing
>> list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>