You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@jackrabbit.apache.org by Andreas Hartmann <an...@apache.org> on 2008/06/27 16:54:08 UTC

Managing access policies across workspaces

Hi Jackrabbit community,

considering a setup with multiple workspaces for separated authoring and 
live content, what would be the most promising approach to model access 
control policies?

Given that a future Jackrabbit release will support JSR-283-like access 
control entries, I'd assign an entry to a node in the authoring 
workspace (simplifying the Java syntax and JCR API):

   accessControlMgr.addAccessControlEntry(
       "/site/anniversary", anniversaryAuthors, { "jcr:write" });

BTW, is the scope of an access control entry the item it is assigned to, 
or the whole subtree?

Now comes the tricky part. What if I have a structure like this:

   /site
     /anniversary
       /…
     /permanent
       /…

Let's assume that the /site/anniversary subtree is not live yet - it 
will be published on the day of the anniversary. I want to allow the 
anniversaryReviewers to publish anniversary content, but no permanent 
content. That means I'd have to assign the jcr:write privilege to a 
not-yet-existing node in the live workspace. Unfortunately, 
addAccessControlEntry() throws a PathNotFoundException if the node 
doesn't exist …

Tobias Bocanegra told me on dev@sling that (IIUC) the access control 
entries are not copied to the staging workspace if the staging node is 
updated, which makes perfect sense. I hope it will conform to the 
upcoming JSR-283 - I didn't find anything in the spec about this.

Thanks a lot in advance for any hints!

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01

Re: Managing access policies across workspaces

Posted by Angela Schreiber <an...@day.com>.

hi andreas

> BTW - Tobias, you were referring to "hierarchical user-based ACLs". Are 
> these the access control entries mentioned in JSR-283 section 6.11.3?

no. an ACL is an example of an access control policy.

> I didn't find anything about inheritance to child nodes there, but maybe 
> the public review version is out of date in comparison to the Jackrabbit 
> implementation.

the current jackrabbit impl is not based on the public review version
of the spec but on a more recent version.

however: inheritance to child nodes will most probably not be defined
by the specification. the acl tobi was referring to is an specific 
implementation of the 283 access control policy... and as i said 
before... still work in progress

angela

Re: Managing access policies across workspaces

Posted by Andreas Hartmann <an...@apache.org>.

Andreas Hartmann schrieb:

[…]

> Tobias Bocanegra told me on dev@sling that (IIUC) the access control 
> entries are not copied to the staging workspace if the staging node is 
> updated, which makes perfect sense. I hope it will conform to the 
> upcoming JSR-283 - I didn't find anything in the spec about this.

BTW - Tobias, you were referring to "hierarchical user-based ACLs". Are 
these the access control entries mentioned in JSR-283 section 6.11.3?

I didn't find anything about inheritance to child nodes there, but maybe 
the public review version is out of date in comparison to the Jackrabbit 
implementation.

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01

Re: Managing access policies across workspaces

Posted by Andreas Hartmann <an...@apache.org>.

Hi Angela,

Angela Schreiber schrieb:

[…]

>> Currently we're in the process of considering which features can be 
>> delegated to the JCR repository, and in which way - regarding access 
>> control, we're still a bit uncertain.
> 
> yes... i can't take that decision for you.
> in any case: i will sent a mail to the list, once the refactoring
> is done.

that would be great, TIA!

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01

Re: Managing access policies across workspaces

Posted by Angela Schreiber <an...@day.com>.

hi andreas

> OK, it appears to be worth waiting a while. The proposed final draft is 
> scheduled for July 2008. Is it possible to anticipate if there will be 
> changes to the scope of the spec after the final draft?

this i don't know. but i hope that the access control feature will
not be reworked again :)

> Currently we're in the process of considering which features can be 
> delegated to the JCR repository, and in which way - regarding access 
> control, we're still a bit uncertain.

yes... i can't take that decision for you.
in any case: i will sent a mail to the list, once the refactoring
is done.

angela

> Thanks for your reply!
> 
> -- Andreas
> 
>

Re: Managing access policies across workspaces

Posted by Andreas Hartmann <an...@apache.org>.

Hi Angela,

Angela Schreiber schrieb:
>> BTW, is the scope of an access control entry the item it is assigned 
>> to, or the whole subtree?
> 
> this is not specified. the spec states, that a policy or an ace
> may affect other nodes that the one the policy/ace is assigned to.

thanks - this is good to know.

>> [...] Unfortunately, addAccessControlEntry() throws a 
>> PathNotFoundException if the node doesn't exist …
> 
> correct. that's the expected behaviour.
> 
>> Tobias Bocanegra told me on dev@sling that (IIUC) the access control 
>> entries are not copied to the staging workspace if the staging node is 
>> updated, which makes perfect sense. I hope it will conform to the 
>> upcoming JSR-283 - I didn't find anything in the spec about this.
> 
> because this is not specified. the specification does not require
> the access control information to be stored in the jcr content.
 >
> please be also aware that the ac section in jsr 283 was refactored
> and the code present with jackrabbit-core will be completely
> reworked.

OK, it appears to be worth waiting a while. The proposed final draft is 
scheduled for July 2008. Is it possible to anticipate if there will be 
changes to the scope of the spec after the final draft?

Currently we're in the process of considering which features can be 
delegated to the JCR repository, and in which way - regarding access 
control, we're still a bit uncertain.

Thanks for your reply!

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01

Re: Managing access policies across workspaces

Posted by Angela Schreiber <an...@day.com>.

hi andreas

> BTW, is the scope of an access control entry the item it is assigned to, 
> or the whole subtree?

this is not specified. the spec states, that a policy or an ace
may affect other nodes that the one the policy/ace is assigned to.

> [...] Unfortunately, 
> addAccessControlEntry() throws a PathNotFoundException if the node 
> doesn't exist …

correct. that's the expected behaviour.

> Tobias Bocanegra told me on dev@sling that (IIUC) the access control 
> entries are not copied to the staging workspace if the staging node is 
> updated, which makes perfect sense. I hope it will conform to the 
> upcoming JSR-283 - I didn't find anything in the spec about this.

because this is not specified. the specification does not require
the access control information to be stored in the jcr content.

please be also aware that the ac section in jsr 283 was refactored
and the code present with jackrabbit-core will be completely
reworked.

angela