[openstack-dev] [Neutron]Do you think tanent_id should be verified

Yongsheng Gong gongysh at unitedstack.com
Mon Feb 17 12:35:45 UTC 2014


It is not easy to enhance it. If we check the tenant_id on creation, if
should we  also to do some job when keystone delete tenant?


On Mon, Feb 17, 2014 at 6:41 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

> keystoneclient.middlware.auth_token passes a project ID (and name, for
> convenience) to the underlying application through the WSGI environment,
> and already ensures that this value can not be manipulated by the end user.
>
> Project ID's (redundantly) passed through other means, such as URLs, are
> up to the service to independently verify against keystone (or
> equivalently, against the WSGI environment), but can be directly
> manipulated by the end user if no checks are in place.
>
> Without auth_token in place to manage multitenant authorization, I'd still
> expect services to blindly trust the values provided in the environment
> (useful for both debugging the service and alternative deployment
> architectures).
>
> On Sun, Feb 16, 2014 at 8:52 AM, Dong Liu <willowd878 at gmail.com> wrote:
>
>> Hi stackers:
>>
>> I found that when creating network subnet and other resources, the
>> attribute tenant_id
>> can be set by admin tenant. But we did not verify that if the tanent_id
>> is real in keystone.
>>
>> I know that we could use neutron without keystone, but do you think
>> tenant_id should
>> be verified when we using neutron with keystone.
>>
>> thanks
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140217/a939e6a8/attachment.html>


More information about the OpenStack-dev mailing list