Open Stack

Need access to the project_id outside of the nova source and available via REST somehow. I also need a way of accessing the data from other OpenStack APIs for resources outside of nova.

Here's the reason why:  Keystone v3 has the concept of polices in arbitrary languages such as XACML. XACML implementations are essentially attribute based access control systems. Usually there is a Policy Enforcement Point (PEP) which is a separate application that intercepts requests to a service and together with a Policy Decision Point (PDP) grants access to a request by taking a look at attributes of the user, the request itself, the resource, or the environment (current-time etc.).

Currently the project_id of the resource is an attribute of the request, because it is in the URI.  If you remove it from the URI I lose access to it  all together and that means I can't write polices which refer to the project_id of the resource.  I think that's a big deal.

The default built in policy that says that the project_id that the token is scoped must match the project_id of the resource works fine for most deployments, but operators should be able to define their own polices.

-jOrGe W.



On May 13, 2013, at 12:00 PM, Jason Kölker wrote:

> On Mon, May 13, 2013 at 11:19 AM, Jorge Williams
> <jorge.williams at rackspace.com> wrote:
>> Here's what I'm asking for though:  At the API level, I'd like to tell that that a server belongs to Tenant Y.  How do I do that?  The X-Tenant-Id simply tells me that the token is scoped to Tenant X, it tells me nothing about the server.
> 
> The api looks up the server via conductor or direct db, the query is
> scoped to the access permissions of the token. The api then has access
> to the project_id field on the server object and can enforce further
> restrictions should any extensions need to. Doing scoping via the URl
> string is insecure. As an API consumer, you have the result of the
> operation so you have the project_id in the return results to compare
> at your leisure (except for delete, but I'm not sure what a use case
> would be to add in the tenant_id in the url just for that, you already
> have the server_id which was more than likely the result of a get
> anyway).
> 
> Happy Hacking!
> 
> 7-11
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev