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 <willowd...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
