jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: AW: AW: AW: AW: remove read-access for everyone from a principal ACL based workspace
Date Tue, 22 May 2012 07:52:02 GMT
hi ferry

what exactly is your problem?
iho that everything you describe should be feasible with
minimal effort.

kind regards
angela

On 5/18/12 8:57 AM, Malzer Ferdinand OSP sIT wrote:
> hello angela,
> I tried different variations of security configurations but find no solution that works
for us.
> we would need a configration, where users are defined outside a workspace (e.g. as it
works with the DefaultSecurityManager) but where ACLs are managed in the particular workspace
(users could have different access-rights for different workspaces).
>
> is there a possibilty to implement the behaviour needed by overriding some methods of
the DefaultSecurityManager or is there now way for such a solution?
>
> best regards
> ferry
>
> -----Urspr√ľngliche Nachricht-----
> Von: Angela Schreiber [mailto:anchela@adobe.com]
> Gesendet: Freitag, 11. Mai 2012 10:57
> An: users@jackrabbit.apache.org
> Betreff: Re: AW: AW: AW: remove read-access for everyone from a principal ACL based workspace
>
> 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:anchela@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
>>
>
>

Mime
View raw message