<div dir="ltr">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?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 6:41 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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).</div>
<div><div class="h5">

<div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 16, 2014 at 8:52 AM, Dong Liu <span dir="ltr"><<a href="mailto:willowd878@gmail.com" target="_blank">willowd878@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi stackers:<br>
<br>
I found that when creating network subnet and other resources, the attribute tenant_id<br>
can be set by admin tenant. But we did not verify that if the tanent_id is real in keystone.<br>
<br>
I know that we could use neutron without keystone, but do you think tenant_id should<br>
be verified when we using neutron with keystone.<br>
<br>
thanks<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>