[openstack-dev] Specifying Tenant-ID in Openstack REST API URLs and Quatum 2.0 APIs

heckj heckj at mac.com
Thu Nov 1 19:29:11 UTC 2012


Hey Peter,

I'm not sure that's an entirely safe assumption. Although that's totally what we're doing today, and in most implementations the authorization is scoped to a single tenant, there's a request outstanding to allow a token to be applicable to more than one tenant, which would leave this kind of request in a very indeterminate status if you're relying on Keystone.

I'm not terribly in favor of having a token scoped so widely - but it's technically possible to have a token that's scoped more broadly with the V2 API. V3 was attempting to lock that down to mandate a bit of interoperability, but so far there's a far bit of push back on wanting that open.

Needless to say, your feedback on that topic would be nice as it related to the Quantum 2.0 API.

For this specific purpose, I would encourage the API to require a specific tenant_id - either in the URL, or as part of the posted query parameter elements if it's tied to the resource in question (i.e CRUD operations that are specific to a tenant)


-joe

On Nov 1, 2012, at 12:15 PM, "Mellquist, Peter" <peter.mellquist at hp.com> wrote:
> The majority of the existing Openstack APIs allow specifying the tenant_id as part of the REST resource URL where resources are structured around tenants.  For example within nova APIs, these API calls are prefixed with /v2/{tenant_id} / ...  www.api.openstack.org
>  
> Quantum API 2.0 specifies a new way for APIs to reference tenant based resources. As part of the transition from the Quantum API 1.0 to 2.0 , the tenant_id as part of the resource URL has been dropped and instead the requested resource is assumed to be the Keystone derived tenant_id.  This shortens the Quantum API 2.0 calls to exclude {tenant_id} as part of the URL. For example, for LBaaS with Quantum 2.0 we would just have
> /v1.0/…
> For cross tenant access, when roles allow so, Quantum 2.0 allows specifying tenant_id as a query parameter, ‘? tenant_id=XXX.’
>  
> Does the Quantum 2.0 API work in terms of handling multi-tenant resource access? YES
> Is the Quantum 2.0 API consistent with existing Openstack APIs in regard to tenant resource access? NO
>  
> Openstack API Community Questions:
> Does consistency across Openstack APIs in regard to tenant based resource access matter?
> Does this impact developers, direct REST usage or those using language bindings / libraries?
>  
> Thank You,
> Peter Mellquist
> Hewlett Packard Company
>  
> _______________________________________________
> 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/20121101/b035c9ab/attachment.html>


More information about the OpenStack-dev mailing list