You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by husbas <hu...@gmail.com> on 2011/05/31 12:36:39 UTC
Using rescrictions in Principal based ACL
Hi,
I am trying to use Principal based ACL but am not getting a clear idea of
how the restrictions work.
For example, if I want to allow a newly created user / group to access the
workspace, how do I do it (I have removed Everyone ACE with full read
access)?
CAn you please help me on this.
-Husain
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Using-rescrictions-in-Principal-based-ACL-tp3562758p3562758.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Using rescrictions in Principal based ACL
Posted by husbas <hu...@gmail.com>.
I have one more doubt with Principal based ACL Providers
I created a user using UserManager and have a blank ACL in the repository.
That is there are no ACE for the uesr. However, the user still has complete
access to the repository. Is that the default policy? How can I change that?
I am using Principal based ACLProvider.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Using-rescrictions-in-Principal-based-ACL-tp3562758p3565825.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Using rescrictions in Principal based ACL
Posted by husbas <hu...@gmail.com>.
>the acls reside in a workspace an not the whole repository...
>not sure what you mean.
I was not clear enough.
Basically I created a user and created an ACE entry for it with jcr:read for
path "/". This worked fine and the user got read access to the full
workspace. Then I removed all the ACE entries for this user. So the policy
rep:accesscontrol/rep:security...../t/to/tom/rep:policy (I don't have the
exact node path right now) exists but there are no ACEs within, its a policy
node with no entries.
Does this mean that the user still has the jcr:read or some set of default
permissions?
-Husain
On Wed, Jun 1, 2011 at 6:50 PM, Angela Schreiber-2 [via Jackrabbit] <
ml-node+3566044-1013664766-241589@n4.nabble.com> wrote:
> hi husain
>
> > Another one.
> > I created a user using UserManager and have a blank ACL in the
> repository.
>
> the acls reside in a workspace an not the whole repository...
> not sure what you mean.
>
> > That is there are no ACE for the uesr. However, the user still has
> complete
> > access to the repository. Is that the default policy? How can I change
> that?
> > I am using Principal based ACLProvider.
>
> what are the permissions granted to the everyone group?
> if i remember correctly the default setup grants jcr:read privilege to
> everyone. this can be turned off by setting the omit-default-permission
> parameter in the ac-provider configuration. (if the ace has already
> been created before you need to remove it using the API).
>
> is this what you are looking for?
> angela
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://jackrabbit.510166.n4.nabble.com/Using-rescrictions-in-Principal-based-ACL-tp3562758p3566044.html
> To unsubscribe from Using rescrictions in Principal based ACL, click here<http://jackrabbit.510166.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3562758&code=aHVzYWluLmJhc3Jhd2FsYUBnbWFpbC5jb218MzU2Mjc1OHwzMzkxMjY0ODc=>.
>
>
--
Husain
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Using-rescrictions-in-Principal-based-ACL-tp3562758p3566276.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Using rescrictions in Principal based ACL
Posted by Angela Schreiber <an...@adobe.com>.
hi husain
> Another one.
> I created a user using UserManager and have a blank ACL in the repository.
the acls reside in a workspace an not the whole repository...
not sure what you mean.
> That is there are no ACE for the uesr. However, the user still has complete
> access to the repository. Is that the default policy? How can I change that?
> I am using Principal based ACLProvider.
what are the permissions granted to the everyone group?
if i remember correctly the default setup grants jcr:read privilege to
everyone. this can be turned off by setting the omit-default-permission
parameter in the ac-provider configuration. (if the ace has already
been created before you need to remove it using the API).
is this what you are looking for?
angela
Re: Using rescrictions in Principal based ACL
Posted by husbas <hu...@gmail.com>.
Thanks. This helped a lot.
Another one.
I created a user using UserManager and have a blank ACL in the repository.
That is there are no ACE for the uesr. However, the user still has complete
access to the repository. Is that the default policy? How can I change that?
I am using Principal based ACLProvider.
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Using-rescrictions-in-Principal-based-ACL-tp3562758p3565701.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Using rescrictions in Principal based ACL
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 31.05.11 16:23, "Angela Schreiber" <an...@adobe.com> wrote:
>I would rather use the PrincipalManager for examples as this clarifies
>the relation between principals and access control. Retrieving the
>Principal from a given User object is of course valid... but in order
>to have a generic example it is important IMO to clarify that User
>Management isn't prerequisite for access control at all. Similarly
>an ACE might be defined for a Principal that isn't known as User to
>the repository but just exposed by the PrincipalManager (by means of
>a custom PrincipalProvider).
Good point, i was partly confused by that separation as well. I clarified
it in the example code, providing both ways and explaining why the
separation is needed.
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: Using rescrictions in Principal based ACL
Posted by Angela Schreiber <an...@adobe.com>.
On 5/31/11 3:53 PM, Alexander Klimetschek wrote:
> I updated http://wiki.apache.org/jackrabbit/AccessControl a bit (wanted to
> finish that for a long time...). Please correct any mistakes I might have
> made.
One thing that I just happen to see without having a careful look at it:
I would rather use the PrincipalManager for examples as this clarifies
the relation between principals and access control. Retrieving the
Principal from a given User object is of course valid... but in order
to have a generic example it is important IMO to clarify that User
Management isn't prerequisite for access control at all. Similarly
an ACE might be defined for a Principal that isn't known as User to
the repository but just exposed by the PrincipalManager (by means of
a custom PrincipalProvider).
regards
angela
Re: Using rescrictions in Principal based ACL
Posted by Alexander Klimetschek <ak...@adobe.com>.
I updated http://wiki.apache.org/jackrabbit/AccessControl a bit (wanted to
finish that for a long time...). Please correct any mistakes I might have
made.
Regards,
Alex
On 31.05.11 14:39, "Angela Schreiber" <an...@adobe.com> wrote:
>hi husain
>
>> What does the rep:glob stands for and how does it affects the
>>permissions?
>
>the default ACL (without the rep:glob restriction) effects the whole
>subtree defined by the target node. the optional rep:glob restriction
>allows you to limit the effect to certain items in that subtree
>without having the create a separate policy at every single location
>that matches.
>
>the matching is similar to the one defined by Node.getNodes(String[]),
>except that it works for paths an not only for names.
>
>examples for a path /foo without and with rep:glob restriction:
>
>--------------------------------------------------------------------------
>---
>rep:glob | Matches
>--------------------------------------------------------------------------
>---
> |
> null | matches /foo and all its children
> |
>--------------------------------------------------------------------------
>---
> |
> "" | matches /foo only
> * | siblings of foo and foo's and the siblings' descendants
> /*cat | all children of /foo whose path ends with "cat"
> /*/cat | all non-direct descendants of /foo named "cat"
> /cat* | all descendant path of /foo that have the direct
> foo-descendant segment starting with "cat"
> *cat | all siblings and descendants of foo that have a
> name ending with cat
> */cat | all descendants of /foo and foo's siblings that have
> a name segment "cat"
> cat/* | all descendants of '/foocat'
> /cat/* | all descendants of '/foo/cat'
> *cat/* | all descendants of /foo that have an intermediate
> | segment ending with 'cat'
> |
>--------------------------------------------------------------------------
>---
>
>please not that this restriction does not distinguish between child
>nodes and properties of a node as it performs a simplistic path-matching.
>
>regards
>angela
>
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: Using rescrictions in Principal based ACL
Posted by Angela Schreiber <an...@adobe.com>.
hi husain
> What does the rep:glob stands for and how does it affects the permissions?
the default ACL (without the rep:glob restriction) effects the whole
subtree defined by the target node. the optional rep:glob restriction
allows you to limit the effect to certain items in that subtree
without having the create a separate policy at every single location
that matches.
the matching is similar to the one defined by Node.getNodes(String[]),
except that it works for paths an not only for names.
examples for a path /foo without and with rep:glob restriction:
-----------------------------------------------------------------------------
rep:glob | Matches
-----------------------------------------------------------------------------
|
null | matches /foo and all its children
|
-----------------------------------------------------------------------------
|
"" | matches /foo only
* | siblings of foo and foo's and the siblings' descendants
/*cat | all children of /foo whose path ends with "cat"
/*/cat | all non-direct descendants of /foo named "cat"
/cat* | all descendant path of /foo that have the direct
foo-descendant segment starting with "cat"
*cat | all siblings and descendants of foo that have a
name ending with cat
*/cat | all descendants of /foo and foo's siblings that have
a name segment "cat"
cat/* | all descendants of '/foocat'
/cat/* | all descendants of '/foo/cat'
*cat/* | all descendants of /foo that have an intermediate
| segment ending with 'cat'
|
-----------------------------------------------------------------------------
please not that this restriction does not distinguish between child
nodes and properties of a node as it performs a simplistic path-matching.
regards
angela
Re: Using rescrictions in Principal based ACL
Posted by husbas <hu...@gmail.com>.
Thanks a lot for quick response.
I am struggling with Access Control since couple of days and have got quite
a few doubts. appreciate your help.
What does the rep:glob stands for and how does it affects the permissions?
--
View this message in context: http://jackrabbit.510166.n4.nabble.com/Using-rescrictions-in-Principal-based-ACL-tp3562758p3562811.html
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
Re: Using rescrictions in Principal based ACL
Posted by Angela Schreiber <an...@adobe.com>.
hi husain
> I am trying to use Principal based ACL but am not getting a clear idea of
> how the restrictions work.
> For example, if I want to allow a newly created user / group to access the
> workspace, how do I do it (I have removed Everyone ACE with full read
> access)?
since the principal-based acls are not stored with the resource
you have to specify the target node's path as restriction. the
restrictions allowed/mandated by the ACL are:
----------------------------------------------------
restr.name | | value type
----------------------------------------------------
rep:nodePath | mandatory | PATH
rep:glob | optional | STRING
----------------------------------------------------
in other words: you always have define a restriction map containing
at least a rep:nodePath + PATH-value entry when creating a new ACE.
see also JackrabbitAccessControlList#addEntry(Principal principal,
Privilege[] privileges, boolean isAllow, Map<String, Value> restrictions)
hope that helps.
regards
angela