You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@sling.apache.org by Eric Norman <er...@gmail.com> on 2010/03/23 16:54:16 UTC

Re: How to implement 'everyone-except' access control in Jackrabbit 2.0

Hi Ray,

Thanks for providing this good information.  I'm replying to the sling users
mailing list to continue discussion about how this information affects
sling.

Since the order of the ACEs is important in resolving the access control in
jackrabbit, we need to make sure that the sling jackrabbit.accessmanager
bundle does the following:

1. Preserves the order of the ACEs when merging changes (during import and
via the ModifyAceServlet). see
SLING-1457<https://issues.apache.org/jira/browse/SLING-1457>
2. Contains a mechanism to re-order the ACEs in the access control list
(during import and via a new RESTful servlet). see
SLING-1458<https://issues.apache.org/jira/browse/SLING-1458>

I have filed issues in jira to address those two items (see
SLING-1457<https://issues.apache.org/jira/browse/SLING-1457>
 and SLING-1458 <https://issues.apache.org/jira/browse/SLING-1458>).

Regards,
-Eric

On Mon, Mar 22, 2010 at 9:52 AM, Ray Davis <ra...@media.berkeley.edu> wrote:

> (This isn't a question -- just wanted to document it in case it helps
> anyone else or in case I got something badly wrong.)
>
> It's not uncommon to want to restrict a resource's access to only a
> specific set of groups or users. For example, we might want the resource
> tree rooted at "/marketing_dept" to be mostly traversable by the general
> public but "/marketing_dept/budget.pdf" to only be readable by members of
> the "marketing.department" Principal.
>
> The default resource AccessControlList provider in Jackrabbit 2 enables
> this, but you have to be aware that its AccessControlEntry resolves
> potential conflicts in an ordered fashion:
>
> - More recent User ACEs override earlier User ACEs.
> - Any User ACEs override any Group ACEs.
> - More recent Group ACEs override earlier Group ACEs.
>
> Thus, to get the desired access control for "/marketing_dept/budget.pdf",
> its ACL could be created as follows:
>
> Privilege[] readPrivs =
> {accessControlManager.privilegeFromName(Privilege.JCR_READ)};
> jackrabbitAccessControlList.addEntry(principalManager.getPrincipal(SecurityConstants.ANONYMOUS_ID),
> readPrivs, false);
> jackrabbitAccessControlList.addEntry(principalManager.getEveryone(),
> readPrivs, false);
> jackrabbitAccessControlList.addEntry(principalManager.getPrincipal("marketing.department"),
> readPrivs, true);
>
> If instead the "everyone" ACE appeared last in the ACL, it would block read
> access by members of the "marketing.department" (since they are also members
> of "everyone").
>
> Best,
> Ray
>

Re: How to implement 'everyone-except' access control in Jackrabbit 2.0

Posted by Eric Norman <er...@gmail.com>.

Thanks Ray,

I've committed the fix in r927532.

I updated the AccessControlUtil.replaceAccessControlEntry(..) API to take an
additional 'order' parameter which is used to ensure the added/updated ACE
is placed at the specified position in the ACL.  Also, the ModifyAceServlet
also looks for the 'order' request parameter when modifying an ACE via
http.  I've outlined the possible values of the 'order' parameter on the
wiki for the jackrabbit.accessmanager bundle at [1].

Please review the changes when you have time to verify it works as expected.

[1]
http://cwiki.apache.org/SLINGxSITE/managing-permissions-jackrabbitaccessmanager.html

Regards,
Eric

On Tue, Mar 23, 2010 at 11:30 AM, Ray Davis <ra...@media.berkeley.edu> wrote:

> Thanks, Eric. I'm going to be unavailable for the rest of this week, but I
> would love to contribute to the effort next week if possible.
>
> Best,
> Ray
>
>
> On 3/23/10 8:54 AM, Eric Norman wrote:
>
>> Hi Ray,
>>
>> Thanks for providing this good information.  I'm replying to the sling
>> users
>> mailing list to continue discussion about how this information affects
>> sling.
>>
>> Since the order of the ACEs is important in resolving the access control
>> in
>> jackrabbit, we need to make sure that the sling jackrabbit.accessmanager
>> bundle does the following:
>>
>> 1. Preserves the order of the ACEs when merging changes (during import and
>> via the ModifyAceServlet). see
>> SLING-1457<https://issues.apache.org/jira/browse/SLING-1457>
>>
>> 2. Contains a mechanism to re-order the ACEs in the access control list
>> (during import and via a new RESTful servlet). see
>> SLING-1458<https://issues.apache.org/jira/browse/SLING-1458>
>>
>>
>> I have filed issues in jira to address those two items (see
>> SLING-1457<https://issues.apache.org/jira/browse/SLING-1457>
>>  and SLING-1458<https://issues.apache.org/jira/browse/SLING-1458>).
>>
>>
>> Regards,
>> -Eric
>>
>> On Mon, Mar 22, 2010 at 9:52 AM, Ray Davis<ra...@media.berkeley.edu>
>>  wrote:
>>
>>  (This isn't a question -- just wanted to document it in case it helps
>>> anyone else or in case I got something badly wrong.)
>>>
>>> It's not uncommon to want to restrict a resource's access to only a
>>> specific set of groups or users. For example, we might want the resource
>>> tree rooted at "/marketing_dept" to be mostly traversable by the general
>>> public but "/marketing_dept/budget.pdf" to only be readable by members of
>>> the "marketing.department" Principal.
>>>
>>> The default resource AccessControlList provider in Jackrabbit 2 enables
>>> this, but you have to be aware that its AccessControlEntry resolves
>>> potential conflicts in an ordered fashion:
>>>
>>> - More recent User ACEs override earlier User ACEs.
>>> - Any User ACEs override any Group ACEs.
>>> - More recent Group ACEs override earlier Group ACEs.
>>>
>>> Thus, to get the desired access control for "/marketing_dept/budget.pdf",
>>> its ACL could be created as follows:
>>>
>>> Privilege[] readPrivs =
>>> {accessControlManager.privilegeFromName(Privilege.JCR_READ)};
>>>
>>> jackrabbitAccessControlList.addEntry(principalManager.getPrincipal(SecurityConstants.ANONYMOUS_ID),
>>> readPrivs, false);
>>> jackrabbitAccessControlList.addEntry(principalManager.getEveryone(),
>>> readPrivs, false);
>>>
>>> jackrabbitAccessControlList.addEntry(principalManager.getPrincipal("marketing.department"),
>>> readPrivs, true);
>>>
>>> If instead the "everyone" ACE appeared last in the ACL, it would block
>>> read
>>> access by members of the "marketing.department" (since they are also
>>> members
>>> of "everyone").
>>>
>>> Best,
>>> Ray
>>>
>>>
>>
>

Re: How to implement 'everyone-except' access control in Jackrabbit 2.0

Posted by Ray Davis <ra...@media.berkeley.edu>.

Thanks, Eric. I'm going to be unavailable for the rest of this week, but 
I would love to contribute to the effort next week if possible.

Best,
Ray

On 3/23/10 8:54 AM, Eric Norman wrote:
> Hi Ray,
>
> Thanks for providing this good information.  I'm replying to the sling users
> mailing list to continue discussion about how this information affects
> sling.
>
> Since the order of the ACEs is important in resolving the access control in
> jackrabbit, we need to make sure that the sling jackrabbit.accessmanager
> bundle does the following:
>
> 1. Preserves the order of the ACEs when merging changes (during import and
> via the ModifyAceServlet). see
> SLING-1457<https://issues.apache.org/jira/browse/SLING-1457>
> 2. Contains a mechanism to re-order the ACEs in the access control list
> (during import and via a new RESTful servlet). see
> SLING-1458<https://issues.apache.org/jira/browse/SLING-1458>
>
> I have filed issues in jira to address those two items (see
> SLING-1457<https://issues.apache.org/jira/browse/SLING-1457>
>   and SLING-1458<https://issues.apache.org/jira/browse/SLING-1458>).
>
> Regards,
> -Eric
>
> On Mon, Mar 22, 2010 at 9:52 AM, Ray Davis<ra...@media.berkeley.edu>  wrote:
>
>> (This isn't a question -- just wanted to document it in case it helps
>> anyone else or in case I got something badly wrong.)
>>
>> It's not uncommon to want to restrict a resource's access to only a
>> specific set of groups or users. For example, we might want the resource
>> tree rooted at "/marketing_dept" to be mostly traversable by the general
>> public but "/marketing_dept/budget.pdf" to only be readable by members of
>> the "marketing.department" Principal.
>>
>> The default resource AccessControlList provider in Jackrabbit 2 enables
>> this, but you have to be aware that its AccessControlEntry resolves
>> potential conflicts in an ordered fashion:
>>
>> - More recent User ACEs override earlier User ACEs.
>> - Any User ACEs override any Group ACEs.
>> - More recent Group ACEs override earlier Group ACEs.
>>
>> Thus, to get the desired access control for "/marketing_dept/budget.pdf",
>> its ACL could be created as follows:
>>
>> Privilege[] readPrivs =
>> {accessControlManager.privilegeFromName(Privilege.JCR_READ)};
>> jackrabbitAccessControlList.addEntry(principalManager.getPrincipal(SecurityConstants.ANONYMOUS_ID),
>> readPrivs, false);
>> jackrabbitAccessControlList.addEntry(principalManager.getEveryone(),
>> readPrivs, false);
>> jackrabbitAccessControlList.addEntry(principalManager.getPrincipal("marketing.department"),
>> readPrivs, true);
>>
>> If instead the "everyone" ACE appeared last in the ACL, it would block read
>> access by members of the "marketing.department" (since they are also members
>> of "everyone").
>>
>> Best,
>> Ray
>>
>