Support path based authorization constraints on any jcr node and support it in the authorization query

There are currently two ways to add an authorization constraint to a node based on its location:

1) On a very specific location, without having effect on hierarchy. For example the hipposys:facetrule as follows does this:

hipposys:equals true
hipposys:facet jcr:uuid
hipposys:filter false
hipposys:type Reference
hipposys:value /content/documents/myhippoproject/news

2) On a very specific location, with having implicit effect on hierarchy because the used property (hippo:paths) can be present on descendants containing a value that is equal. For example the hipposys:facetrule as follows does this:

hipposys:equals true
hipposys:facet hippo:paths
hipposys:filter false
hipposys:type Reference
hipposys:value /content/documents/myhippoproject/news

The problem is now, that you cannot give easily read access to a subtree of nodes that do not have the hippo:paths property. For example assume I have a user that I want to give read access to the subtree below /webresources/intranet and a piece of the tree is:

+ webresources

• site
  • js
    • foo.js
  • css
    • bar.js
• intranet
  • js
    • foo.js
  • css
    • bar.js

I need a user that has

1) read access to the node 'webresources'
2) read access to everything below /webresources/intranet

Since the node webresources/intranet does not have the hippo:paths property, I can now only use hipposys:facet 'jcr:uuid' but then I need to add read access for every folder below webresources/intranet separately as well! This is not desirable.

Suggested solution:

Support the following facetrule:

hipposys:equals true
hipposys:facet jcr:path
hipposys:filter false
hipposys:type Reference
hipposys:value /content/documents/myhippoproject/news

Implementation details:
1) Since above the only thing that changes is a new possibly value for the hipposys:facet, the CNS is unchanged
2) In the HippoAccessManager add a bit different check if the rule.getFacetName() is the Name jcr:path : Then check whether the path of the nodeState to authorize is a descendant or equal to the hipposys:value
3) Also account for the hasPrivileges(Path absPath, Privilege[] privileges)
4) In the servicing node indexer, index in a separate lucene field the uuid of the node itself + all its ancestors (note to use UUIDs since the hipposys:type Reference gets translated in QFacetRule to a UUID and since paths like /hst:hst/hst:configurations or paths with SNS are much easier to index with their UUIDS)
5) Account in the translation of QFacetRule to the AuthorizationQuery for the jcr:path hipposys:facet

This is from a first investigation. Perhaps some details must be different but I think it is most of what needs to be done