Open Stack

On Fri, Jun 21, 2013 at 5:25 AM, Chmouel Boudjnah <chmouel at enovance.com>wrote:

> Hello,
>
> [moving on the public mailing list since this bug is anyway public]
>
> On 3 Jun 2013, at 17:25, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>
> Apologies for the delayed response on this. We have several related open
> bugs and I wanted to investigate them all at once, and perhaps fix them all
> in one pass.
> Disabling a tenant/project should result in existing tokens scoped to that
> tenant/project being immediately invalidated, so I think Chmouel's analysis
> is absolutely valid.
> Regarding "list_users_in_project" -- as Guang suggested, the semantics of
> that call are inherently complicated,
>
>
>
> looking into this it seems that we have already such function :
>
>
> https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql.py#L608
>
> Should it get fixed?
>
> so ideally we can just ask the token driver to revoke tokens with some
> context (a user OR a tenant OR a user+tenant combination). We've been going
> down that direction, but have been incredibly inconsistent in how it's
> utilized. I'd like to have a framework to consistently apply the
> consequences of disabling/deleting any entity in the system.
>
>
> agreed, I think this should be doable if we can modify :
>
>
> https://github.com/openstack/keystone/blob/master/keystone/token/core.py#L169
>
> changing the default user_id to None
>
> as for the getting the tokens for a specify project/tenant if we are not
> using a list_users_in_project would that mean we need to parse all the
> tokens to get the metadatas/extras tenant_id or there is some more
> efficient ways?
>

Currently the memcache token backend and SQL token backend each have their
own advantages, and I'd like to get the best of both worlds and use each as
intended. So, store tokens with these fields indexed appropriately in SQL
and cache them in memcache (and if memcache/etc isn't available, in-memory
in python).


>
> Chmouel.
>
>
> -Dolph
>
>
> On Wed, May 29, 2013 at 9:59 AM, Yee, Guang <guang.yee at hp.com> wrote:
>
>> Users does not really belong to a project. They have access to, or
>> associated with, a project via role grant(s). Therefore, when disabling a
>> project, we should only invalidate the tokens scoped to that project. But
>> yes, you should be able to use the same code to invalidate the tokens when
>> disabling a project.****
>>
>> ** **
>>
>>
>> https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L164
>> ****
>>
>> ** **
>>
>> We have to be careful with list_users_in_project as user can associate
>> with project with either direct role grant, or indirectly via group
>> membership and group grant.  This is going to get complicated with the
>> addition of inherited role grants.****
>>
>> ** **
>>
>> ** **
>>
>> Guang****
>>
>> ** **
>>
>> ** **
>>
>> *From:* Chmouel Boudjnah [mailto:chmouel at enovance.com]
>> *Sent:* Wednesday, May 29, 2013 2:23 AM
>> *To:* Adam Young; Dolph Mathews; Henry Nash; Joseph Heck; Yee, Guang;
>> dev at enovance.com
>> *Subject:* disabling a tenant still allow user token****
>>
>> ** **
>>
>> Hi,
>>
>> Apologies for the direct email but I will be happy to move this on
>> openstack-dev@ before to make sure it's not security involved.
>>
>> I'd like to bring you this bug :
>>
>> https://bugs.launchpad.net/keystone/+bug/1179955
>>
>> to your attention.
>>
>> Basically for the TL;DR when disabling a tenant don't disable the tokens
>> of the user attached to it.
>>
>> We could probably do that :
>>
>>
>> https://github.com/openstack/keystone/blob/master/keystone/common/controller.py#L164
>>
>> when updating a tenant. but I need to find a way to list users attached
>> to a tenant (without having to list all the users).
>>
>> not being able to list_users_in_project() is it something intended by
>> keystone?
>>
>> Do you see a workaround for how to delete tokens of all users belonging
>> to a tenants?
>>
>> Let me know what do you think.
>>
>> Cheers,
>> Chmouel.****
>>
>
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130621/109892ad/attachment.html>