Groups Deny, DefaultAccessManager

[Ian Boston <ie...@tfd.co.uk>]

Hi,
This is a question initiated by looking at Sling, but relates to the  
Jackrabbit DefaultAccessControlManager.

I notice the Access Control Elements with a deny statement don't get  
added to a ACE relating to a Group Principal.

Does any one know the reason for this ? Is it part of the Spec ?

We have use cases where we want to grant part of a tree to a group and  
then deny a subtree to the main group and grant to a smaller group. At  
the moment, it looks like DACM wont do this for us, we could write our  
own (in fact we did for JR 14), but I dont really want to drift too  
far from anything in the spec.

Thanks
Ian

Re: Groups Deny, DefaultAccessManager

[Ian Boston <ie...@tfd.co.uk>]

On 24 Jul 2009, at 11:36, Angela Schreiber wrote:

> ian, please see
>
> http://www.nabble.com/Group-denies-td24335844.html
>
> if i'm not totally mistaken it was you starting that
> thread, wasn't it?
>

Angela,
Yes, guilty.
I am not certain what the conclusion of that thread was.

In this thread, Lars suggested how to make a subtree private, but IIUC  
the solution depends on denying all on the "everyone" group, which is  
not possible in the DefaultAccessControlManager for JR1.5. Did I  
understand correctly ?

Thanks
Ian

Re: Groups Deny, DefaultAccessManager

[Angela Schreiber <an...@day.com>]

ian, please see

http://www.nabble.com/Group-denies-td24335844.html

if i'm not totally mistaken it was you starting that
thread, wasn't it?

Re: Groups Deny, DefaultAccessManager

[Ian Boston <ie...@tfd.co.uk>]

I have had a look at this now, and unfortunately the ACLTemplate  
(either for principals or normal nodes) is not suitable for extension.

Creating a different version of ACLTemplate will allow a change in the  
storage format and the processing of the ACL, but the critical step is  
compilation of the set of ACE's into a set, filtered for the users set  
of Principals and then compiled into a single bitmap. AFAICT the  
static acl.ACLProvider.collectEntries(node,map) does this for normal  
nodes and pricipalbased.ACLProvider.collectEntries(node,map) for the  
principal based step.

At the moment I think I need to change this behavior so its looking  
more like a replacement ACLProvider to generate a different set of  
compiledPermissions, however it looks like I can combine this in the  
combined.ACLProvider since this also operates on a user principal  
filtered and compiled bitmap (combined from acl.ACLProvider and  
principal.ACLProvider)

There is a hand built UML diagram of the space that I have been  
creating for this at
http://groups.google.com/group/sakai-kernel/web/JackrabbitAuthZ.pdf
(CCS&A Licensed as its the rest of the doc there)


If I could modify the CombinedProvider to work of a list of  
compilePermissions rather than merge all the permissions then I think  
I might be able to add another ACLProvider to the list just for my  
special use cases.

Does that sound like a possible approach to extension ?

Ian


On 26 Apr 2009, at 13:56, Lars Michele wrote:

> The AccessControlProviderInterface seems to be a good starting point  
> for
> implementing your own ACLs. But perhaps it would be sufficient for you
> to change the methods in ACLTemplate to evaluate the permission the  
> way
> you want.

Re: Groups Deny, DefaultAccessManager

[Ian Boston <ie...@tfd.co.uk>]

This looks possible, less code == good :) , I will investigate (and  
try and document as I go)
Thanks,
Ian
On 26 Apr 2009, at 13:56, Lars Michele wrote:

>  But perhaps it would be sufficient for you
> to change the methods in ACLTemplate to evaluate the permission the  
> way
> you want.

Re: Groups Deny, DefaultAccessManager

[Lars Michele <la...@tu-dortmund.de>]

Hi Ian,

just for clarification, I think the implementation is doing something
like this:
1. Try to get an ACL based on the user principal. If an ACL for the
principal is defined at the node (or one of its parents) use it. So
giving a user explicit access rights on the root node, you have to deny
them explicit for that user on subnodes, the user is not allowed to access.
2. If no ACL was found, try to find an ACL based on the group principals
the user is in and use it.
3. If no ACL was found that allows the desired action --> no access.

The AccessControlProviderInterface seems to be a good starting point for
implementing your own ACLs. But perhaps it would be sufficient for you
to change the methods in ACLTemplate to evaluate the permission the way
you want.

Regards,
Lars

Ian Boston schrieb:
> Lars,
> Thank you, the explanation makes sense. Its the order independence of
> the ACL and the fact that everything is or'd together that makes a
> deny in group pointless, rather than an explicit design decision. The
> approach you suggest to achieving the private subfolder is perfectly
> workable.
>
> Presumably this policy is expressed inside the implementation of the
> AccessControlProvider where the ACL is compiled.
> Since this class is defined in the repository.xml would it be the
> right place extend or change the behavior *if* I wanted to ? ( I have
> some other use cases that may need to address if the standard impl
> doesnt cover them)
>
> Thanks
> Ian

Re: Groups Deny, DefaultAccessManager

[Ian Boston <ie...@tfd.co.uk>]

Lars,
Thank you, the explanation makes sense. Its the order independence of  
the ACL and the fact that everything is or'd together that makes a  
deny in group pointless, rather than an explicit design decision. The  
approach you suggest to achieving the private subfolder is perfectly  
workable.

Presumably this policy is expressed inside the implementation of the  
AccessControlProvider where the ACL is compiled.
Since this class is defined in the repository.xml would it be the  
right place extend or change the behavior *if* I wanted to ? ( I have  
some other use cases that may need to address if the standard impl  
doesnt cover them)

Thanks
Ian
On 25 Apr 2009, at 15:40, Lars Michele wrote:

> Just a correction...
> Lars Michele schrieb:
>> Hi,
>>
>>> I notice the Access Control Elements with a deny statement don't get
>>> added to a ACE relating to a Group Principal.
>>>
>>> Does any one know the reason for this ? Is it part of the Spec ?
>>>
>> I do not know if it is part of the spec, but when you comment it  
>> out, it
>> works and I have not found a drawback yet.
>>
>>> We have use cases where we want to grant part of a tree to a group  
>>> and
>>> then deny a subtree to the main group and grant to a smaller  
>>> group. At
>>> the moment, it looks like DACM wont do this for us, we could write  
>>> our
>>> own (in fact we did for JR 14), but I dont really want to drift too
>>> far from anything in the spec.
>>>
>> If the check is removed, following rules work.
>>
>> The principal "everybody" has read rights on the node, which is
>> important, so that every (authenticated) user can access the  
>> repository.
>> If you want to make a subdirectory protected, you just set a "deny  
>> all"
>> rule for "everybody" on this directory and add the appropriate rights
>> for the desired groups with access rights. So it does, what it  
>> should do.
>>
>> What rules count:
>> Because the rules get computed by "OR", an "allow" counts more than a
>> "deny". That means if you set a "deny all" on group1 and "allow  
>> all" on
>> group2 and a user is in both groups (I know, you never should do
>> something like this)
>
> In fact, you do something like this. I am a little bit gaga. My  
> example
> with the group "everybody" shows, that you have to do something like
> this ;-)
>
>> , the "allow all" wins.
>> A user rule always wins against a group rule.
>> The order of the rules in the ACLs is *NOT* important!
>>
>> I hope, that helps.
>>
>> Lars
>>
>

Re: Groups Deny, DefaultAccessManager

[Lars Michele <la...@tu-dortmund.de>]

Just a correction...
Lars Michele schrieb:
> Hi,
>   
>> I notice the Access Control Elements with a deny statement don't get
>> added to a ACE relating to a Group Principal.
>>
>> Does any one know the reason for this ? Is it part of the Spec ?
>>     
> I do not know if it is part of the spec, but when you comment it out, it
> works and I have not found a drawback yet.
>   
>> We have use cases where we want to grant part of a tree to a group and
>> then deny a subtree to the main group and grant to a smaller group. At
>> the moment, it looks like DACM wont do this for us, we could write our
>> own (in fact we did for JR 14), but I dont really want to drift too
>> far from anything in the spec.
>>     
> If the check is removed, following rules work.
>
> The principal "everybody" has read rights on the node, which is
> important, so that every (authenticated) user can access the repository.
> If you want to make a subdirectory protected, you just set a "deny all"
> rule for "everybody" on this directory and add the appropriate rights
> for the desired groups with access rights. So it does, what it should do.
>
> What rules count:
> Because the rules get computed by "OR", an "allow" counts more than a
> "deny". That means if you set a "deny all" on group1 and "allow all" on
> group2 and a user is in both groups (I know, you never should do
> something like this)

In fact, you do something like this. I am a little bit gaga. My example
with the group "everybody" shows, that you have to do something like
this ;-)

> , the "allow all" wins.
> A user rule always wins against a group rule.
> The order of the rules in the ACLs is *NOT* important!
>
> I hope, that helps.
>
> Lars
>   

Re: Groups Deny, DefaultAccessManager

[Lars Michele <la...@tu-dortmund.de>]

Hi,
> I notice the Access Control Elements with a deny statement don't get
> added to a ACE relating to a Group Principal.
>
> Does any one know the reason for this ? Is it part of the Spec ?
I do not know if it is part of the spec, but when you comment it out, it
works and I have not found a drawback yet.
> We have use cases where we want to grant part of a tree to a group and
> then deny a subtree to the main group and grant to a smaller group. At
> the moment, it looks like DACM wont do this for us, we could write our
> own (in fact we did for JR 14), but I dont really want to drift too
> far from anything in the spec.
If the check is removed, following rules work.

The principal "everybody" has read rights on the node, which is
important, so that every (authenticated) user can access the repository.
If you want to make a subdirectory protected, you just set a "deny all"
rule for "everybody" on this directory and add the appropriate rights
for the desired groups with access rights. So it does, what it should do.

What rules count:
Because the rules get computed by "OR", an "allow" counts more than a
"deny". That means if you set a "deny all" on group1 and "allow all" on
group2 and a user is in both groups (I know, you never should do
something like this), the "allow all" wins.
A user rule always wins against a group rule.
The order of the rules in the ACLs is *NOT* important!

I hope, that helps.

Lars