Open Stack

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

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
>