Open Stack

On Tue, May 14, 2013 at 3: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.


Based on the URI only, how does one verify that the project_id and the
server match up? This PDP is going to have to call out to something to
verify that the request is correct, or else I can just craft URIs in
such a way to bypass it and get at the service its trying to enforce
the policies for.


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


Totes, so to throw out a straw man argument, how would a policy be
crafted to enforce a policy of a cidr range, would we then have to put
the cidr in the URI? Its going to have to call out to something to get
the resource to make the policy decision it might as well be the
service that owns the resource its making the policy decision for.

Happy Hacking!

7-11