Return-Path: X-Original-To: apmail-jackrabbit-users-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E2DCB9D56 for ; Wed, 23 May 2012 06:55:01 +0000 (UTC) Received: (qmail 68376 invoked by uid 500); 23 May 2012 06:55:01 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 68102 invoked by uid 500); 23 May 2012 06:54:56 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 68057 invoked by uid 99); 23 May 2012 06:54:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2012 06:54:55 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Ferdinand.Malzer@s-itsolutions.at designates 213.150.10.1 as permitted sender) Received: from [213.150.10.1] (HELO smxsat1.smxs.net) (213.150.10.1) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2012 06:54:48 +0000 Received: from m01x1.s-mxs.net ([10.3.55.201]) by smxsat1.smxs.net over TLS secured channel (TLSv1/SSLv3:AES256-SHA:256) with XWall v3.47i. ; Wed, 23 May 2012 08:54:26 +0200 Received: from m0106.s-mxs.net ([10.3.55.6]) by m01x1.s-mxs.net over TLS secured channel (TLSv1/SSLv3:AES128-SHA:128) with XWall v3.47i. ; Wed, 23 May 2012 08:54:25 +0200 Received: from M0182.s-mxs.net ([fe80::75f4:618d:f52c:d9af]) by m0106.s-mxs.net ([fe80::19fd:3ed:7b2f:a92a%11]) with mapi id 14.02.0298.004; Wed, 23 May 2012 08:54:24 +0200 From: Malzer Ferdinand OSP sIT To: "users@jackrabbit.apache.org" Subject: AW: AW: AW: AW: AW: remove read-access for everyone from a principal ACL based workspace Thread-Topic: AW: AW: AW: AW: remove read-access for everyone from a principal ACL based workspace Thread-Index: Ac0sH+xgPl4zZjVLT7GumhfcE653IgAtEUwAADHt7/AAA8wjAAAL1xLg///54YD//TGoQIAFphmA//UCmvCAHDTcAP/+Y7nw Date: Wed, 23 May 2012 06:54:24 +0000 Message-ID: References: <4FA8BF06.8080603@adobe.com> <4FAA2794.1030001@adobe.com> <4FAA71E7.6010408@adobe.com> <4FACD463.1080503@adobe.com> <4FBB45A2.10702@adobe.com> In-Reply-To: <4FBB45A2.10702@adobe.com> Accept-Language: en-US, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-XWALL-BCKS: auto X-Virus-Checked: Checked by ClamAV on apache.org 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 sec= urity workspace which comes with the DefaultSecurityManager. Furthermore a = user should only access workspaces where he has a defined ACL in that works= pace. to avoid that every user could read every workspace, we create a new worksp= ace with ACLProvider as Workspace-AccessControlProvider with option omit-de= fault-permission=3Dtrue. unfortunately this leads to LoginException: Workspace access denied when t= rying to login with a user with access-rights jcr:read/jcr:write on the cor= responding workspace. perhaps it is possible to override methods in DefaultSecurityManager to mak= e our constellation work? best regards ferry -----Urspr=FCngliche Nachricht----- Von: Angela Schreiber [mailto:anchela@adobe.com]=20 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 princip= al 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 solut= ion 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 mana= ged in the particular workspace (users could have different access-rights f= or different workspaces). > > is there a possibilty to implement the behaviour needed by overriding som= e methods of the DefaultSecurityManager or is there now way for such a solu= tion? > > best regards > ferry > > -----Urspr=FCngliche 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 > > > > > > 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 th= e workspace by using the JackrabbitAccessControlManager. >> this results in the following entry in the workspace: >> >> /rep:accesscontrol >> /rep:accesscontrol/jcr:primaryType =3D rep:AccessControl >> /rep:accesscontrol/rep:security >> /rep:accesscontrol/rep:security/jcr:primaryType =3D rep:AccessControl >> /rep:accesscontrol/rep:security/rep:authorizables >> /rep:accesscontrol/rep:security/rep:authorizables/jcr:primaryType =3D re= p:AccessControl >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/jcr:primaryT= ype =3D rep:AccessControl >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/jcr:primar= yType =3D rep:AccessControl >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/jcr:pri= maryType =3D rep:AccessControl >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/j= cr:primaryType =3D rep:PrincipalAccessControl >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/jcr:primaryType =3D rep:ACL >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry/rep:privileges =3D jcr:write >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry/rep:privileges =3D jcr:read >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry/rep:glob =3D * >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry/rep:nodePath =3D / >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry/rep:principalName =3D ferry >> /rep:accesscontrol/rep:security/rep:authorizables/rep:users/f/fe/ferry/r= ep:policy/entry/jcr:primaryType =3D rep:GrantACE >> >> after that we tried to get e session to the new workspace with user 'fer= ry' but we get the following exception: >> >> Exception in thread "main" javax.jcr.LoginException: Workspace access de= nied >> 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 s= et in the acl for user 'ferry'? >> >> best regards >> ferry >> >> -----Urspr=FCngliche 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 AC= L 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 =3D principalMgr.getEveryone(); >> AccessControlPolicy[] plcs =3D jackrabbitAcMgr.getPolicies(everyone) >> AccessControlPolicy everyonePolicy =3D [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 >> > >