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