You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Justin Edelson (JIRA)" <ji...@apache.org> on 2016/06/14 15:43:01 UTC
[jira] [Commented] (SLING-5768) Introduce rep:resourceTypes as
extension to Oak permission system
[ https://issues.apache.org/jira/browse/SLING-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329685#comment-15329685 ]
Justin Edelson commented on SLING-5768:
---------------------------------------
I'm 99% sure we should not be using rep as a namespace here because that namespace is "owned" by the repository implementation. Is there a reason we can't use sling as the namespace?
> Introduce rep: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)
> + 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)