Resource ACL Examples.mdown

Resources

Resource Security

Assumptions

Based on the yaml format

Resources are stored within a project and can be organized within subdirectories. I.e.

<PROJECT_HOME>/file1.resources
<PROJECT_HOME>/file2.resources
<PROJECT_HOME>/database/file1.resources

Each directory within project home for resources constitutes a URL that can be guarded against.

Security Model

Within a aclpolicy, restricting access to a set of resource can be accomplished two ways. One is structural, the other is label driven (more on this later on).

It's expect that a majority of the configuration will be structural. Perhaps the 80/20 rule applies here, but I'd be speculating.

Structural ACLs

With structural acls, the following is possible (a hypothetical language):

policy: 
   id: D6C73EA1-F0E3-4481-A6B6-86DCBF6443DC
   description: Resource ACL Policy Example
  
   # Example of restricting a set of resources.
   # All resources live at a URL, <project>/resources
   /project1/resources:
      action: "GET"
      
  by:
    user: auditor

This would provide the user auditor access to all project1's resources. The project contains an entry point called resources, but this could be any url that contains resources.

Assuming that there is a one to one mapping of directories that contain the resources files, then the following can be modified to restrict to those resources

policy: 
   ...
   /project1/resources/subdir:
      action: "GET"
   ...

This would effectively block the users ability to see any nodes in the resources/ directory or any siblings to sub directories.

Label Based ACLs

Label Based ACLs are used in conjunction with structural based ACLs. They're intended to provide an orthogonal means to govern resources when a hierarchy is not flexible enough.

For example, the intent is to grant a specific user access to all unix or linux machines

policy: 
   id: D6C73EA1-F0E3-4481-A6B6-86DCBF6443DC
   description: Tag

   /project1/resources:
      osFamily:(linux|unix)
      action: "GET"
  
   by:
     user: auditor

Any linux or unix boxes (case sensitive) will be available to the auditor user. This can be further constrained by adding additional tags, i.e.

policy: 
  ...
  /project1/resources:
    osFamily:(linux|unix)
    tags:database
    action: "GET"
  ...

or structure restrictions

policy: 
  ...
  /project1/resources/customer:
    osFamily:(linux|unix)
    tags:database
    action: "GET"
  ...

In this case, the user would have access to all unix or linux database nodes within the customer container.

Processing a Policy

This section focuses on how a resource clause is parsed. This is not normative.

The resource label, the ^/project/resources/customer in:

policy: 
  ...
  ^/project1/resources/customer:
    osFamily:(linux|unix)
    tags:database
    action: "GET"
  ...

Is a string that is parsed during access to the particular resource (the policy enforcement point). This string is matched, using extended regular expression on the URL's path spec (query options are ignored) for the underly resource. The action tag is matched against the action requested for the resource, in this context, a resource in the ^/project1/resources/customer directory.

Once a document is retrieved, an additional step to process any matching labels is performed. In this case, the osFamily and tags properties are retrieved from the underlying document and matched using extended regular expressions. Since the tag is typically thought of a set, each element in the set is evaluated for a match.

All the tags must match to GRANTED access to the underlying resource, otherwise it's DENIED.