Open Stack

Can't we solve this by putting a attribute on the resource itself ("owner")? After all the project_id is really just an attribute on the resource. The policy could then be crafted via attribute matching instead of uri matching.

I don't see any reason to make the "owner" attribute special vs other attributes like state (policy could allow showing of "soft-deleted" vms) or flavor (policy could allow hiding some flavors). Including it in the uri or as a header seems like we are arbitrarily choosing one attribute of the resource and making it extra important. I don't really think that is justified.

Vish

On May 14, 2013, at 1:33 AM, Jorge Williams <jorge.williams at rackspace.com> wrote:

> 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.