jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malzer Ferdinand OSP sIT <Ferdinand.Mal...@s-itsolutions.at>
Subject AW: AW: AW: AW: AW: remove read-access for everyone from a principal ACL based workspace
Date Wed, 23 May 2012 06:54:24 GMT
hello angela,

we don't want to define users per workspace because most of our users will have access to
different workspaces. Therefore we would like to use the security workspace which comes with
the DefaultSecurityManager. Furthermore a user should only access workspaces where he has
a defined ACL in that workspace.

to avoid that every user could read every workspace, we create a new workspace with ACLProvider
as Workspace-AccessControlProvider with option omit-default-permission=true.

unfortunately this leads to  LoginException: Workspace access denied when trying to login
with a user with access-rights jcr:read/jcr:write on the corresponding workspace.

perhaps it is possible to override methods in DefaultSecurityManager to make our constellation
work?

best regards
ferry



-----Ursprüngliche Nachricht-----
Von: Angela Schreiber [mailto:anchela@adobe.com] 
Gesendet: Dienstag, 22. Mai 2012 09:52
An: users@jackrabbit.apache.org
Betreff: Re: AW: AW: AW: AW: remove read-access for everyone from a principal ACL based workspace

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