Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
2014-02-25 19:48 GMT+08:00 Salvatore Orlando sorla...@nicira.com: I understand the fact that resources with invalid tenant_ids can be created (only with admin rights at least for Neutron) can be annoying. However, I support Jay's point on cross-project interactions. If tenant_id validation (and orphaned resource management) can't be efficiently handled, then I'd rather let 3rd party scripts dealing with orphaned and invalid resources. I reckon that it might be worth experimenting whether the notifications sent by Keystone (see Dolph's post on this thread) can be used to deal with orphaned resources. For tenant_id validation, anything involving an extra round trip to keystone would not be efficient in my opinion. If there is a way to perform this validation in the same call which validates the tenant auth_token then it's a different story. Notifications from keystone *could* be used to build a local (persistent perhaps) cache of active tenant identifiers. However, this would require reliable notifications, as well as appropriate cache management, which is often less simple than what it looks like. Salvatore Thanks for your explanation and suggestion, Salvatore, I still think it's a problem that we should handle in OpenStack or outside(through what you said, say 3rd party scripts), maybe we could add some contents in wiki or doc? any idea? -- *---* *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: konglingx...@huawei.com; anlin.kong@gmail.c anlin.k...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
I understand the fact that resources with invalid tenant_ids can be created
(only with admin rights at least for Neutron) can be annoying.
However, I support Jay's point on cross-project interactions. If tenant_id
validation (and orphaned resource management) can't be efficiently handled,
then I'd rather let 3rd party scripts dealing with orphaned and invalid
resources.
I reckon that it might be worth experimenting whether the notifications
sent by Keystone (see Dolph's post on this thread) can be used to deal with
orphaned resources.
For tenant_id validation, anything involving an extra round trip to
keystone would not be efficient in my opinion. If there is a way to perform
this validation in the same call which validates the tenant auth_token then
it's a different story.
Notifications from keystone *could* be used to build a local (persistent
perhaps) cache of active tenant identifiers. However, this would require
reliable notifications, as well as appropriate cache management, which is
often less simple than what it looks like.
Salvatore
On 25 February 2014 05:23, Lingxian Kong anlin.k...@gmail.com wrote:
2014-02-25 11:25 GMT+08:00 Dong Liu willowd...@gmail.com:
Thanks Jay, now I know maybe neutron will not handle tenant
creating/deleting notifications which from keystone.
There is another question, such as creating subnet request body:
{
subnet: {
name: test_subnet,
enable_dhcp: true,
network_id: 57596b26-080d-4802-8cce-4318b7e543d5,
ip_version: 4,
cidr: 10.0.0.0/24,
tenant_id: 4209c294d1bb4c36acdfaa885075e0f1
So, this is exactly what I mean for 'temant_id' here that should be
validated.
I insist this could be done via some middleware or else.
}
}
As we know, the tenant_id can only be specified by admin tenant.
In my test, the tenant_id I filled in the body can be any string (e.g., a
name, an uuid, etc.) But I think this tenant existence (I mean if the
tenant exists in keystone) should be verified, if not, the subnet I created
will be an useless resource.
Regards,
Dong Liu
On 2014-02-25 0:22, Jay Pipes Wrote:
On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote:
I think 'tenant_id' should always be validated when creating neutron
resources, whether or not Neutron can handle the notifications from
Keystone when tenant is deleted.
-1
Personally, I think this cross-service request is likely too expensive
to do on every single request to Neutron. It's already expensive enough
to use Keystone when not using PKI tokens, and adding another round trip
to Keystone for this kind of thing is not appealing to me. The tenant is
already validated when it is used to get the authentication token used
in requests to Neutron, so other than the scenarios where a tenant is
deleted in Keystone (which, with notifications in Keystone, there is now
a solution for), I don't see much value in the extra expense this would
cause.
Best,
-jay
___
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
--
*---*
*Lingxian Kong*
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Mobile: +86-18602962792
Email: konglingx...@huawei.com; anlin.k...@gmail.com
___
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
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
Salvatore, thank you very much for your reply.
I know that there was a proposal[1] to handle the message security
stuff. For this proposal implementation, there was a blueprint[2] of
keystone will merge in Icehouse.
I'm looking forward to the notification handling could implemente in
Juno. Although I'm a new bee here, if it is possible, I wish I can take
part in this in the days to come.
[1] https://wiki.openstack.org/wiki/MessageSecurity
[2] https://blueprints.launchpad.net/keystone/+spec/key-distribution-server
Regards,
Dong Liu
On 2014-02-25 19:48, Salvatore Orlando Wrote:
I understand the fact that resources with invalid tenant_ids can be
created (only with admin rights at least for Neutron) can be annoying.
However, I support Jay's point on cross-project interactions. If
tenant_id validation (and orphaned resource management) can't be
efficiently handled, then I'd rather let 3rd party scripts dealing with
orphaned and invalid resources.
I reckon that it might be worth experimenting whether the notifications
sent by Keystone (see Dolph's post on this thread) can be used to deal
with orphaned resources.
For tenant_id validation, anything involving an extra round trip to
keystone would not be efficient in my opinion. If there is a way to
perform this validation in the same call which validates the tenant
auth_token then it's a different story.
Notifications from keystone *could* be used to build a local (persistent
perhaps) cache of active tenant identifiers. However, this would require
reliable notifications, as well as appropriate cache management, which
is often less simple than what it looks like.
Salvatore
On 25 February 2014 05:23, Lingxian Kong anlin.k...@gmail.com
mailto:anlin.k...@gmail.com wrote:
2014-02-25 11:25 GMT+08:00 Dong Liu willowd...@gmail.com
mailto:willowd...@gmail.com:
Thanks Jay, now I know maybe neutron will not handle tenant
creating/deleting notifications which from keystone.
There is another question, such as creating subnet request body:
{
subnet: {
name: test_subnet,
enable_dhcp: true,
network_id: 57596b26-080d-4802-8cce-__4318b7e543d5,
ip_version: 4,
cidr: 10.0.0.0/24 http://10.0.0.0/24,
tenant_id: __4209c294d1bb4c36acdfaa885075e0__f1
So, this is exactly what I mean for 'temant_id' here that should be
validated.
I insist this could be done via some middleware or else.
}
}
As we know, the tenant_id can only be specified by admin tenant.
In my test, the tenant_id I filled in the body can be any string
(e.g., a name, an uuid, etc.) But I think this tenant existence
(I mean if the tenant exists in keystone) should be verified, if
not, the subnet I created will be an useless resource.
Regards,
Dong Liu
On 2014-02-25 0:22, Jay Pipes Wrote:
On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote:
I think 'tenant_id' should always be validated when
creating neutron
resources, whether or not Neutron can handle the
notifications from
Keystone when tenant is deleted.
-1
Personally, I think this cross-service request is likely too
expensive
to do on every single request to Neutron. It's already
expensive enough
to use Keystone when not using PKI tokens, and adding
another round trip
to Keystone for this kind of thing is not appealing to me.
The tenant is
already validated when it is used to get the
authentication token used
in requests to Neutron, so other than the scenarios where a
tenant is
deleted in Keystone (which, with notifications in Keystone,
there is now
a solution for), I don't see much value in the extra expense
this would
cause.
Best,
-jay
_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
*---*
*Lingxian Kong*
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
I think 'tenant_id' should always be validated when creating neutron resources, whether or not Neutron can handle the notifications from Keystone when tenant is deleted. thoughts? 2014-02-20 20:21 GMT+08:00 Dong Liu willowd...@gmail.com: Dolph, thanks for the information you provided. Now I have two question: 1. Will neutron handle this event notification in the future? 2. I also wish neutron could verify that tenant_id is existent. thanks 于 2014-02-20 4:33, Dolph Mathews 写道: There's an open bug [1] against nova neutron to handle notifications [2] from keystone about such events. I'd love to see that happen during Juno! [1] https://bugs.launchpad.net/nova/+bug/967832 [2] http://docs.openstack.org/developer/keystone/event_notifications.html On Mon, Feb 17, 2014 at 6:35 AM, Yongsheng Gong gong...@unitedstack.com mailto:gong...@unitedstack.com wrote: 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 mailto: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 mailto: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 mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/ openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 -- *---* *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: konglingx...@huawei.com; anlin.k...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote: I think 'tenant_id' should always be validated when creating neutron resources, whether or not Neutron can handle the notifications from Keystone when tenant is deleted. -1 Personally, I think this cross-service request is likely too expensive to do on every single request to Neutron. It's already expensive enough to use Keystone when not using PKI tokens, and adding another round trip to Keystone for this kind of thing is not appealing to me. The tenant is already validated when it is used to get the authentication token used in requests to Neutron, so other than the scenarios where a tenant is deleted in Keystone (which, with notifications in Keystone, there is now a solution for), I don't see much value in the extra expense this would cause. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
Thanks Jay, now I know maybe neutron will not handle tenant
creating/deleting notifications which from keystone.
There is another question, such as creating subnet request body:
{
subnet: {
name: test_subnet,
enable_dhcp: true,
network_id: 57596b26-080d-4802-8cce-4318b7e543d5,
ip_version: 4,
cidr: 10.0.0.0/24,
tenant_id: 4209c294d1bb4c36acdfaa885075e0f1
}
}
As we know, the tenant_id can only be specified by admin tenant.
In my test, the tenant_id I filled in the body can be any string (e.g.,
a name, an uuid, etc.) But I think this tenant existence (I mean if the
tenant exists in keystone) should be verified, if not, the subnet I
created will be an useless resource.
Regards,
Dong Liu
On 2014-02-25 0:22, Jay Pipes Wrote:
On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote:
I think 'tenant_id' should always be validated when creating neutron
resources, whether or not Neutron can handle the notifications from
Keystone when tenant is deleted.
-1
Personally, I think this cross-service request is likely too expensive
to do on every single request to Neutron. It's already expensive enough
to use Keystone when not using PKI tokens, and adding another round trip
to Keystone for this kind of thing is not appealing to me. The tenant is
already validated when it is used to get the authentication token used
in requests to Neutron, so other than the scenarios where a tenant is
deleted in Keystone (which, with notifications in Keystone, there is now
a solution for), I don't see much value in the extra expense this would
cause.
Best,
-jay
___
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
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
2014-02-25 11:25 GMT+08:00 Dong Liu willowd...@gmail.com:
Thanks Jay, now I know maybe neutron will not handle tenant
creating/deleting notifications which from keystone.
There is another question, such as creating subnet request body:
{
subnet: {
name: test_subnet,
enable_dhcp: true,
network_id: 57596b26-080d-4802-8cce-4318b7e543d5,
ip_version: 4,
cidr: 10.0.0.0/24,
tenant_id: 4209c294d1bb4c36acdfaa885075e0f1
So, this is exactly what I mean for 'temant_id' here that should be
validated.
I insist this could be done via some middleware or else.
}
}
As we know, the tenant_id can only be specified by admin tenant.
In my test, the tenant_id I filled in the body can be any string (e.g., a
name, an uuid, etc.) But I think this tenant existence (I mean if the
tenant exists in keystone) should be verified, if not, the subnet I created
will be an useless resource.
Regards,
Dong Liu
On 2014-02-25 0:22, Jay Pipes Wrote:
On Mon, 2014-02-24 at 16:23 +0800, Lingxian Kong wrote:
I think 'tenant_id' should always be validated when creating neutron
resources, whether or not Neutron can handle the notifications from
Keystone when tenant is deleted.
-1
Personally, I think this cross-service request is likely too expensive
to do on every single request to Neutron. It's already expensive enough
to use Keystone when not using PKI tokens, and adding another round trip
to Keystone for this kind of thing is not appealing to me. The tenant is
already validated when it is used to get the authentication token used
in requests to Neutron, so other than the scenarios where a tenant is
deleted in Keystone (which, with notifications in Keystone, there is now
a solution for), I don't see much value in the extra expense this would
cause.
Best,
-jay
___
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
--
*---*
*Lingxian Kong*
Huawei Technologies Co.,LTD.
IT Product Line CloudOS PDU
China, Xi'an
Mobile: +86-18602962792
Email: konglingx...@huawei.com; anlin.k...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
Dolph, thanks for the information you provided. Now I have two question: 1. Will neutron handle this event notification in the future? 2. I also wish neutron could verify that tenant_id is existent. thanks 于 2014-02-20 4:33, Dolph Mathews 写道: There's an open bug [1] against nova neutron to handle notifications [2] from keystone about such events. I'd love to see that happen during Juno! [1] https://bugs.launchpad.net/nova/+bug/967832 [2] http://docs.openstack.org/developer/keystone/event_notifications.html On Mon, Feb 17, 2014 at 6:35 AM, Yongsheng Gong gong...@unitedstack.com mailto:gong...@unitedstack.com wrote: 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 mailto: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 mailto: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 mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
There's an open bug [1] against nova neutron to handle notifications [2] from keystone about such events. I'd love to see that happen during Juno! [1] https://bugs.launchpad.net/nova/+bug/967832 [2] http://docs.openstack.org/developer/keystone/event_notifications.html On Mon, Feb 17, 2014 at 6:35 AM, Yongsheng Gong gong...@unitedstack.comwrote: 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.comwrote: 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
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.comwrote: 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
[openstack-dev] [Neutron]Do you think tanent_id should be verified
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
Re: [openstack-dev] [Neutron]Do you think tanent_id should be verified
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
