hi ferry
ok... i assume everything is fine when it comes to access control
enforced on items but your user isn't allowed to access the workspace.
since the workspace isn't an item in the repo it needs some special
handling.
in the current jackrabbit-core this is controlled by a separate
WorkspaceAccessManager. there are a few implementations in jackrabbit
core (see below) and again it's configurable. if i remember correctly
it's part of the SecurityManager configuration of the repository.
something like
<Repository>
<SecurityManager class=...>
<WorkspaceAccessManager class="..." />
the following implementations are part of jackrabbit core:
a SimpleWorkspaceAccessManager: dummy implementation that always
returns true
b default implementation in DefaultSecurityManager: allows true if
the root node is accessible. that was the first try but it turned
out that this wasn't really meeting our own requirements.
c default implementation in UserPerWorkspaceSecurityManager: it is
granting access to a given user if the latter is present in the
workspace.... that one doesn't work with the default setup on b
unless the users are stored in the same workspace (instead of that
extra workspace for users that we had at that initial stage when
b) was built.
you may check which version you are having in your setup and possible
reconfigure it to something that meets your needs.
hope that helps
angela
On 5/11/12 8:39 AM, Malzer Ferdinand OSP sIT wrote:
hello angela,
we have done one more test.
we created a new workspace with the ' omit-default-permission '.
we checked the acl's of the workspace with the admin user and everything was
fine (no everyone acl contained).
after that we wanted to grant the user ferry read and write access to the
workspace by using the JackrabbitAccessControlManager.
this results in the following entry in the workspace:
/rep:accesscontrol
/rep:accesscontrol/jcr:primaryType = rep:AccessControl
/rep:accesscontrol/rep:security
/rep:accesscontrol/rep:security/jcr:primaryType = rep:AccessControl
/rep:accesscontrol/rep:security/rep:authorizables
/rep:accesscontrol/rep:security/rep:authorizables/jcr:primaryType =
rep:AccessControl
/rep:accesscontrol/rep:security/rep:authorizables/rep:users
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/jcr:primaryType =
rep:AccessControl
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/jcr:primaryType =
rep:AccessControl
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/jcr:primaryType
= rep:AccessControl
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/jcr:primaryType
= rep:PrincipalAccessControl
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/jcr:primaryType
= rep:ACL
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry/rep:privileges
= jcr:write
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry/rep:privileges
= jcr:read
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry/rep:glob
= *
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry/rep:nodePath
= /
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry/rep:principalName
= ferry
/rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/rep:policy/entry/jcr:primaryType
= rep:GrantACE
after that we tried to get e session to the new workspace with user 'ferry' but
we get the following exception:
Exception in thread "main" javax.jcr.LoginException: Workspace access denied
at
org.apache.jackrabbit.core.RepositoryImpl.login(RepositoryImpl.java:1496)
is there any further policy we besid jcr:read and jcr:write we have to set in
the acl for user 'ferry'?
best regards
ferry
-----Ursprüngliche Nachricht-----
Von: Angela Schreiber [mailto:anch...@adobe.com]
Gesendet: Mittwoch, 09. Mai 2012 15:32
An: users@jackrabbit.apache.org
Betreff: Re: AW: AW: remove read-access for everyone from a principal ACL based
workspace
hi ferry
well... that config just defines what to do on the initialization
of the provider. if the corresponding access control entry exists
in a subsequent start it will not be removed.
in order to get rid of the existing entry you have to remove it
using the API. something like
Principal everyone = principalMgr.getEveryone();
AccessControlPolicy[] plcs = jackrabbitAcMgr.getPolicies(everyone)
AccessControlPolicy everyonePolicy = [select the desired policy]
jackrabbitAcMgr.removePolicy(everyonePolicy);
session.save();
perhabs principalbased.ACLProvider does not support the '
omit-default-permission' parameter?
yes, i am pretty sure that the principalbased ac provider supports
that option :)
anyway, i think the removal of the existing policy was the missing
piece. still leave the config option as otherwise the ace will
be recreated upon startup.
kind regards
angela
