hi marian
the 401 is most probably rather a result on how access to workspaces
is evaluated that a permission evaluation problem on the content itself.
in other words:
i was testing with our default setup that keeps users in each workspace
(workspace access is granted if the user exists), while i would assume
you are having the default jackrabbit setup with the
DefaultSecurityManager.
unless you change the workspaceaccessmgr configuration you will get
a default that makes workspace access depending on accessibility of
the root node (see DefaultSecurityManager line 659).
if that's the case you can adjust the default configuration by
something that better fits your needs regarding accessibility
of workspaces...
something like:
<SecurityManager
class="org.apache.jackrabbit.core.DefaultSecurityManager"
workspaceName="security">
<WorkspaceAccessManager class="..."/>
</SecurityManager>
the most trivial implementation of the workspace-access-mgr just
allows access to all workspace (there is such an implementation
somewhere in jackrabbit core).
alternatively you may want to create one that specifically fits
your needs.
in general i find the UserPerWorkspaceSecurityManager more intuitive
than what is the default in jackrabbit core... despite the terrible
name :-)
kind regards
angela
On 2/13/13 3:51 PM, SCHEDENIG Marian wrote:
Hi Angela,
thanks for the quick reply. I had a bug in my test code and could indeed get it
working now with multiple grant/denies on the same node, as long as I make sure
to put the grants before the denies.
I still can't reproduce your suggested example though (Miroslav's fix taken into
account). By default I do indeed provide ALL permissions to "everyone" on root,
as otherwise (i.e. if I remove that ACE at the beginning of my test case), non-admins
cannot access the repository content at all. In fact (I'm doing all my access through
WebDAV), I get a 401 (authentication required) from the repository if I don't explicitly
grant permissions on the root folder. And that goes for a subfolder with granted ALL as
well: No root permissions, no permissions anywhere.
Not sure if perhaps I'm doing something wrong there. But solution 2 (deny
rights to everyone and grant them to a certain group per relevant folder)
should be good enough for us.
Cheers,
Marian.
-----Original Message-----
From: Angela Schreiber [mailto:anch...@adobe.com]
Sent: Mittwoch, 13. Februar 2013 13:30
To: users@jackrabbit.apache.org
Subject: Re: How does Jackrabbit resolve ACL permissions?
hi marian
imo there shouldn't be any major obstacles in setting up the ACL to reflect the
permissions as you describe below.
in quickly tried it out on the crx-explorer using the following
setup:
groups
---------------------------------------------------------------
- groupA
- groupB
users
---------------------------------------------------------------
- userA: member of groupA (and everyone)
- userB: member of groupB (and everyone)
- userC: member of groupA and groupB (and everyone)
acl setup
---------------------------------------------------------------
+ root
+ a
+ rep:policy
+ allow
- jcr:primaryType = rep:GrantACE
- rep:principalName = groupA
- rep:privileges = [jcr:read]
+ b
+ rep:policy
+ allow
- jcr:primaryType = rep:DenyACE
- rep:principalName = groupB
- rep:privileges = [jcr:read]
result
---------------------------------------------------------------
- userA can read /a but not /b
- userB can read /b but not /a
- userC can read /a and /b
additional adding an DENY ace for everyone on the root is redundant and doesn't
not have an effect on the result.
general notes
---------------------------------------------------------------
- ACEs are inherited through the node hierarchy. ACEs defined on
a particular node take precedence over inherited onces.
defining addition restrictions may be used to limit the effect to
certain parts of the subtree defined by the access controlled node
- as long as ACEs are defined from group principals the evaluation
is strictly hierarchical. on a single ACL the order of ACEs matters.
- if you define ACEs for non-group principal they will take predecence
in any case: over the group principals and over the inheritance rule
defined above.
regarding your comments below:
---------------------------------------------------------------
1) that works for me... see above. in don't think you analysis
matches the way the permissions are evaluated.
2) that would work as well but the ACE for everyone is redundant.
it would not work if you would allow group A first and deny everyone
group after that... as the ACE for A would become redundant.
hope that helps
angela
On 2/13/13 11:34 AM, SCHEDENIG Marian wrote:
Hi,
we're using the standard ACLProvider for permission handling. We're
now running into problems when trying to set up slightly more complex
ACLs than we've used so far:
Say we have three groups, "everyone" (which is Jackrabbit's
EveryonePrincipal) and "A" and "B". We want to allow only users in the
A group to be able to access the folder /a_folder and only members of
B to access /b_folder. A user may be a member of A, B, A and B or of
neither group. If user X is a member of A and not a member of B, X
should still have access to /a_folder.
We've tried two approaches:
1. Deny full permissions to "everyone" on the root folder and then
grant full permissions to A on /a_folder and to B on /b_folder. This
fails, apparently because permissions are resolved in a "top down"
manner, and as soon as it has been established that a user doesn't
have access to a parent folder, its subfolders are no longer
evaluated. That's fine, if we can find a different way to do it.
2. Deny full permissions to "everyone" on /a_folder and grant full
permissions to A on the same folder (and the same with "everyone" and
B on /b_folder). This also fails, although apparently it works for
user X if we deny "everyone" and grant X (specifically the user) on the folder.
I'm now wondering: How exactly does Jackrabbit resolve permissions?
Case
1 seems to be clear, but what are the exact rules for overlapping
grants and denies on the same resource? And what is the correct way to
solve our requirement?
Thanks,
Marian.
--
*DI Marian Schedenig*
Senior Developer
Description: Description: Description: Description: Description:
Description: cid:image001.png@01CCBE64.F3314040
INFINICA - Member of Qualysoft Group**
Leonard-Bernstein-Straße 10
A-1220 Wien
Österreich
Tel +43 1 4095987-26
Fax +43 1 4095987-11
www.infinica.at<http://www.infinica.at/>
www.qualysoft.at<http://www.qualysoft.at/>
marian.schede...@infinica.at<mailto:marian.schede...@infinica.at>
*P**Please consider the environment before printing this email*
