[
https://issues.apache.org/jira/browse/SLING-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Henzler updated SLING-5768:
---------------------------------
Description:
Oak allows to extend its permissions management by using custom restrictions
\[1], also the standard oak restrictions are based on this and are implemented
in a fairly straight-forward way \[2] (example is for rep:ntNames).
It would be nice to have sling level restrictions using sling properties in
general. This issue is about introducing a restriction on resource types - the
following should be possible:
{code}
- /content/mynode
- rep:policy (rep:ACL)
- allow (rep:GrantACE)
+ principalName (String) = "myAuthorizable"
+ rep:privileges (Name[]) = "rep:write"
- rep:restrictions (rep:Restrictions)
+ sling:resourceTypes (String[]) =
[myproj/resourcetype1,myproj/resourcetype2]
{code}
The example would only grant "rep:write" for the resource types
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other
resources under path /content/mynode would not have "rep:write" permissions.
Additionally to strict resource type matching it shall be possible to
automatically match a resource with a given resource type including all
children. Also, not all content nodes have a resource type, therefore it should
be possible to match against a child node by appending \@path to the resource
type:
{code}
- /content/myprj
- rep:policy (rep:ACL)
- allow (rep:GrantACE)
+ principalName (String) = "myAuthorizable"
+ rep:privileges (Name[]) = "rep:write"
- rep:restrictions (rep:Restrictions)
+ sling:resourceTypesWithChildren (String[]) =
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a
match (but only up to the base path, /content/myprj in this example). For AEM
use cases, this can match a whole page structure (e.g. something like
/content/myprj/path/to/newsoverview, the whole news section can be easily
matched by having a distinct news overview template).
\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java
was:
Oak allows to extend its permissions management by using custom restrictions
\[1], also the standard oak restrictions are based on this and are implemented
in a fairly straight-forward way \[2] (example is for rep:ntNames).
It would be nice to have sling level restrictions using sling properties in
general. This issue is about introducing a restriction on resource types - the
following should be possible:
{code}
- /content/mynode
- rep:policy (rep:ACL)
- allow (rep:GrantACE)
+ principalName (String) = "myAuthorizable"
+ rep:privileges (Name[]) = "rep:write"
- rep:restrictions (rep:Restrictions)
+ rep:resourceTypes (String[]) =
[myproj/resourcetype1,myproj/resourcetype2]
{code}
The example would only grant "rep:write" for the resource types
myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other
resources under path /content/mynode would not have "rep:write" permissions.
Additionally to strict resource type matching it shall be possible to
automatically match a resource with a given resource type including all
children. Also, not all content nodes have a resource type, therefore it should
be possible to match against a child node by appending \@path to the resource
type:
{code}
- /content/myprj
- rep:policy (rep:ACL)
- allow (rep:GrantACE)
+ principalName (String) = "myAuthorizable"
+ rep:privileges (Name[]) = "rep:write"
- rep:restrictions (rep:Restrictions)
+ rep:resourceTypesWithChildren (String[]) =
[myproj/resourcetype1@jcr:content]
{code}
To achieve this any path match attempt traverses the parents and checks for a
match (but only up to the base path, /content/myprj in this example). For AEM
use cases, this can match a whole page structure (e.g. something like
/content/myprj/path/to/newsoverview, the whole news section can be easily
matched by having a distinct news overview template).
\[1]
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
\[2]
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java
> Introduce sling:resourceTypes as extension to Oak permission system
> -------------------------------------------------------------------
>
> Key: SLING-5768
> URL: https://issues.apache.org/jira/browse/SLING-5768
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Georg Henzler
>
> Oak allows to extend its permissions management by using custom restrictions
> \[1], also the standard oak restrictions are based on this and are
> implemented in a fairly straight-forward way \[2] (example is for
> rep:ntNames).
> It would be nice to have sling level restrictions using sling properties in
> general. This issue is about introducing a restriction on resource types -
> the following should be possible:
> {code}
> - /content/mynode
> - rep:policy (rep:ACL)
> - allow (rep:GrantACE)
> + principalName (String) = "myAuthorizable"
> + rep:privileges (Name[]) = "rep:write"
> - rep:restrictions (rep:Restrictions)
> + sling:resourceTypes (String[]) =
> [myproj/resourcetype1,myproj/resourcetype2]
> {code}
> The example would only grant "rep:write" for the resource types
> myproj/resourcetype1 and myproj/resourcetype2 in path /content/mynode, other
> resources under path /content/mynode would not have "rep:write" permissions.
> Additionally to strict resource type matching it shall be possible to
> automatically match a resource with a given resource type including all
> children. Also, not all content nodes have a resource type, therefore it
> should be possible to match against a child node by appending \@path to the
> resource type:
> {code}
> - /content/myprj
> - rep:policy (rep:ACL)
> - allow (rep:GrantACE)
> + principalName (String) = "myAuthorizable"
> + rep:privileges (Name[]) = "rep:write"
> - rep:restrictions (rep:Restrictions)
> + sling:resourceTypesWithChildren (String[]) =
> [myproj/resourcetype1@jcr:content]
> {code}
> To achieve this any path match attempt traverses the parents and checks for a
> match (but only up to the base path, /content/myprj in this example). For AEM
> use cases, this can match a whole page structure (e.g. something like
> /content/myprj/path/to/newsoverview, the whole news section can be easily
> matched by having a distinct news overview template).
> \[1]
> https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability
> \[2]
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/NodeTypePattern.java#L50)
> https://github.com/apache/jackrabbit-oak/blob/cea167f5bf70d818d58b1ffcc6bc65b3c0f9a5a4/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authorization/restriction/RestrictionProviderImpl.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
