Open Stack

(Inline)

On May 14, 2013, at 11:01 AM, Jason Kölker wrote:

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

Yes,  it calls Keystone to verify that the token has access to the project_id, when it does token validation.
If the server is not owned by the project_id, it should return a 404, because the project ID is a container for all resources that belong to it.  So you can craft URIs all you want, you're just going to get 404s.



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

To use an attribute based access control system, all that is needed is for you to expose the range as an attribute of the resource.  It need not be in the URI, but it needs to be accessible via the REST API.

Sure the service itself can be the PDP and PEP -- in some cases that makes sense.  But in the worst case it involves putting business specific logic in your code (stuff that's applicable to say Rackspace, but no one else).  It also makes it difficult to write polices that need to refer to different services.

-jOrGe W.