You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Ian Boston <ie...@tfd.co.uk> on 2010/05/13 15:05:50 UTC
AccessControlProvider on security workspace. (JR2)
Hi,
Would it be possible to use the AccessControlProvider from the default "content" workspace on the security workspace, provided the rep:* nodes were suitably protected with ACLs?
I need to delegate group administration and deny read in places.
Ian
Re: AccessControlProvider on security workspace. (JR2)
Posted by Ian Boston <ie...@tfd.co.uk>.
On 14 May 2010, at 19:59, Angela Schreiber wrote:
> Ian Boston wrote:
>
>> Do you think there would be a problem extending the rep:Group node from
>> [rep:Group] > rep:Authorizable
>> - rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
>> to
>> [rep:Group] > rep:Authorizable
>> - rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
>> - rep:managers (STRING) protected multiple
>> - rep:viewers (STRING) protected multiple
>
>> I am not asking that the spec be extended since thats JSR work, just if its going to conflict with things in the future that you know of ?
>
> the user management currently doesn't for part of the JCR spec.
> it's a jackrabbit specific extension due to the fact we at
> Day have the need for user management.
>
> as far as i understood: you want to cover access control functionality
> with those 2 properties. is that correct?
yes
> if this is the case i would
> rather define a mixin. without having thought about it carefully that
> would look more appropriate to me since the 2 properties are not intrinsic characteristics of a Group itself but [in JCR lingo] rather belong to an access control policy that may be applied or even be effective by default on a specific group node.
agreed.
>
> modification of those properties thus is from my point of view rather
> a question of being allowed to manipulate the access control of the group node than of changing the groups properties or adding/removing
> a member from the group...
agreed, I need to think a bit more about this, however I think that the policy is so simple compared to full ACL's that manage effectively gives administrative rights over the group, avoiding the need for a finer grained policy separating properties and access control policy.
>
> but that's just my gut feeling without knowing the details behind your
> questions.
We have a need for a) private groups and b) delegated administration of individual groups
>
> hope it helps anyway
It does, thank you, no more questions :)
Ian
> regards
> angela
Re: AccessControlProvider on security workspace. (JR2)
Posted by Angela Schreiber <an...@day.com>.
Ian Boston wrote:
> Do you think there would be a problem extending the rep:Group node from
>
> [rep:Group] > rep:Authorizable
> - rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
>
> to
>
> [rep:Group] > rep:Authorizable
> - rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
> - rep:managers (STRING) protected multiple
> - rep:viewers (STRING) protected multiple
> I am not asking that the spec be extended since thats JSR work, just if its going to conflict with things in the future that you know of ?
the user management currently doesn't for part of the JCR spec.
it's a jackrabbit specific extension due to the fact we at
Day have the need for user management.
as far as i understood: you want to cover access control functionality
with those 2 properties. is that correct? if this is the case i would
rather define a mixin. without having thought about it carefully that
would look more appropriate to me since the 2 properties are not
intrinsic characteristics of a Group itself but [in JCR lingo] rather
belong to an access control policy that may be applied or even be
effective by default on a specific group node.
modification of those properties thus is from my point of view rather
a question of being allowed to manipulate the access control of the
group node than of changing the groups properties or adding/removing
a member from the group...
but that's just my gut feeling without knowing the details behind your
questions.
hope it helps anyway
regards
angela
Re: AccessControlProvider on security workspace. (JR2)
Posted by Ian Boston <ie...@tfd.co.uk>.
On 14 May 2010, at 07:04, Angela Schreiber wrote:
> hi ian
>
>> Would it be possible to use the AccessControlProvider from the default "content" workspace on the security workspace, provided the rep:* nodes were suitably protected with ACLs?
>
> sure. you can define the AccessControlProvider to be used
> in the configuration of each workspace separately.
>
> for this you have to add the following element to the workspace
> config:
>
> <Workspace>
> [...]
> <WorkspaceSecurity>
> <AccessControlProvider class="...">
> [... additional provider configuration ...]
> </AccessControlProvider>
> </WorkspaceSecurity>
> [...]
> </Workspace>
>
> hope this helps
> angela
>
Angela,
Yes,
thank you, one more question.
Do you think there would be a problem extending the rep:Group node from
[rep:Group] > rep:Authorizable
- rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
to
[rep:Group] > rep:Authorizable
- rep:members (WEAKREFERENCE) protected multiple < 'rep:Authorizable'
- rep:managers (STRING) protected multiple
- rep:viewers (STRING) protected multiple
I am not asking that the spec be extended since thats JSR work, just if its going to conflict with things in the future that you know of ?
rep:managers, if present specifies principals of users who can manage the group, giving them the same privileges, for this group as members of the Group Administrators group.
rep:viewers if present specified principals of users who can see the group.
Thanks
Ian
>
Re: AccessControlProvider on security workspace. (JR2)
Posted by Angela Schreiber <an...@day.com>.
hi ian
> Would it be possible to use the AccessControlProvider from the default "content"
> workspace on the security workspace, provided the rep:* nodes were suitably protected with ACLs?
sure. you can define the AccessControlProvider to be used
in the configuration of each workspace separately.
for this you have to add the following element to the workspace
config:
<Workspace>
[...]
<WorkspaceSecurity>
<AccessControlProvider class="...">
[... additional provider configuration ...]
</AccessControlProvider>
</WorkspaceSecurity>
[...]
</Workspace>
hope this helps
angela