You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by "jorgeeflorez ." <jo...@gmail.com> on 2019/05/23 18:03:36 UTC
Users, groups and permissions
Hello,
I have been reading regarding Jackrabbit and Oak security and I think I
understand. but I would like to confirm before implementing something...
When I create a group and assign a permission (e.g. rep:write) to that
group over a node path.
If I assign an user to that group then the user will have the permission
that I gave to that group over that node?
If I remove that user from the group the permission will be removed?
From what I understand from here
https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html that
will not happen, and I will have to make it happen, am I right?
Thanks.
Re: Users, groups and permissions
Posted by "jorgeeflorez ." <jo...@gmail.com>.
Hi Angela,
thank you, you helped me a lot. I will put a breakpoint where you say and I
will check what's going on.
Regards.
Jorge
El vie., 24 may. 2019 a las 8:03, Angela Schreiber
(<an...@adobe.com.invalid>) escribió:
> Hi Jorge
>
> If you are not using the default setup, the general notes should still
> apply... that is:
> What goes into the Subject upon authentication (or comes with the Subject
> in case of pre-authenticated login) is used for the permission evaluation.
> So, in other words: the relevant piece is the set of principals that is
> passed to the PermissionProvider and how the configured permission
> provider(s) (default implemenation or custom, single provider or
> composition of many) evaluate the effective permissions for these
> principals.
>
> If you are interested in the inner workings of Oak, you may start your
> investigation at MutableRoot line 127. There you can see how the
> PermissionProvider is constructed based on the principal set associated
> with the Subject, which in turn has been passed to the Root object upon
> construction in ContentSessionImpl line 105.
>
> How permissions are evaluation in a custom security setup obviously
> depends both on the authentication setup and how the set of principals is
> computed therein and the authorization mechanism i.e. how permissions for
> these principals are collected/weighted/ordered/evaluated.
>
> Hope that helps
> Angela
>
> ________________________________________
> From: jorgeeflorez . <jo...@gmail.com>
> Sent: Friday, May 24, 2019 2:25 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: Re: Users, groups and permissions
>
> Hello Angela,
>
> thank you for taking your time and writing this awesome reply. You saved my
> life :)
> It is clear to me now how it works by default. It seems that we are not
> using the default security setup for Oak. I will have to look into it.
>
> Best regards.
>
> Jorge Flórez
>
> El vie., 24 may. 2019 a las 2:03, Angela Schreiber
> (<an...@adobe.com.invalid>) escribió:
>
> > Hi Jorge
> >
> > The
> https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html
> > are not directly related to permission evaluation. This is just an
> optional
> > add on to perform specific verification or action upon modification of
> the
> > set of members of a given group.... e.g. write a log message.
> >
> > When it comes to permissions it all boils down to the set of principals
> > contained in the Subject after the Repository login and whether that set
> of
> > principals is granted permission to perform a given read/write action.
> >
> > So, for simplicity let's look at the default setup as present with Oak
> out
> > of the box:
> > - the default authentication will
> > > verify the passed Credentials object,
> > > lookup the user associated with the Credentials and get it's
> principal
> > > resolve the declared and inherited group membership for that user and
> > get the group principals
> > > update the subject with the complete set of principals both for the
> > user and it's groups
> > - the default authorization will
> > > look at the permission entries for the set of principals and the
> > target path and all it's ancestors
> > > verify if a given action is granted (or denied) for any of the user
> > principals or any of the group principals
> > > if it is neither granted or explicitly denied, permission is not
> > granted
> > see https://jackrabbit.apache.org/oak/docs/security/permission.html
> and
> >
> >
> https://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
> > for details and examples.
> >
> > So, back to your initial question:
> > If you take the default security setup of Oak, assign permissions to a
> > group principal at /test/path and assign your user to that group will
> > result in your user inheriting the permissions of the group. if you
> remove
> > the user from the group again, the subject upon login will no longer be
> > populated with the group principal and therefore the user no longer
> > inherits the permissions granted/denied to that group.
> > similarly, if you remove that permission entry again and persist the
> > change, the test group and all of it's members will no longer get that
> > permission granted/denied (assuming there is no other entry that has the
> > same effect).
> >
> > Kind regards
> > Angela
> >
> > ________________________________________
> > From: jorgeeflorez . <jo...@gmail.com>
> > Sent: Thursday, May 23, 2019 8:03 PM
> > To: oak-dev@jackrabbit.apache.org
> > Subject: Users, groups and permissions
> >
> > Hello,
> >
> > I have been reading regarding Jackrabbit and Oak security and I think I
> > understand. but I would like to confirm before implementing something...
> > When I create a group and assign a permission (e.g. rep:write) to that
> > group over a node path.
> > If I assign an user to that group then the user will have the permission
> > that I gave to that group over that node?
> > If I remove that user from the group the permission will be removed?
> >
> > From what I understand from here
> > https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html
> that
> > will not happen, and I will have to make it happen, am I right?
> >
> > Thanks.
> >
>
Re: Users, groups and permissions
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Jorge
If you are not using the default setup, the general notes should still apply... that is:
What goes into the Subject upon authentication (or comes with the Subject in case of pre-authenticated login) is used for the permission evaluation. So, in other words: the relevant piece is the set of principals that is passed to the PermissionProvider and how the configured permission provider(s) (default implemenation or custom, single provider or composition of many) evaluate the effective permissions for these principals.
If you are interested in the inner workings of Oak, you may start your investigation at MutableRoot line 127. There you can see how the PermissionProvider is constructed based on the principal set associated with the Subject, which in turn has been passed to the Root object upon construction in ContentSessionImpl line 105.
How permissions are evaluation in a custom security setup obviously depends both on the authentication setup and how the set of principals is computed therein and the authorization mechanism i.e. how permissions for these principals are collected/weighted/ordered/evaluated.
Hope that helps
Angela
________________________________________
From: jorgeeflorez . <jo...@gmail.com>
Sent: Friday, May 24, 2019 2:25 PM
To: oak-dev@jackrabbit.apache.org
Subject: Re: Users, groups and permissions
Hello Angela,
thank you for taking your time and writing this awesome reply. You saved my
life :)
It is clear to me now how it works by default. It seems that we are not
using the default security setup for Oak. I will have to look into it.
Best regards.
Jorge Flórez
El vie., 24 may. 2019 a las 2:03, Angela Schreiber
(<an...@adobe.com.invalid>) escribió:
> Hi Jorge
>
> The https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html
> are not directly related to permission evaluation. This is just an optional
> add on to perform specific verification or action upon modification of the
> set of members of a given group.... e.g. write a log message.
>
> When it comes to permissions it all boils down to the set of principals
> contained in the Subject after the Repository login and whether that set of
> principals is granted permission to perform a given read/write action.
>
> So, for simplicity let's look at the default setup as present with Oak out
> of the box:
> - the default authentication will
> > verify the passed Credentials object,
> > lookup the user associated with the Credentials and get it's principal
> > resolve the declared and inherited group membership for that user and
> get the group principals
> > update the subject with the complete set of principals both for the
> user and it's groups
> - the default authorization will
> > look at the permission entries for the set of principals and the
> target path and all it's ancestors
> > verify if a given action is granted (or denied) for any of the user
> principals or any of the group principals
> > if it is neither granted or explicitly denied, permission is not
> granted
> see https://jackrabbit.apache.org/oak/docs/security/permission.html and
>
> https://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
> for details and examples.
>
> So, back to your initial question:
> If you take the default security setup of Oak, assign permissions to a
> group principal at /test/path and assign your user to that group will
> result in your user inheriting the permissions of the group. if you remove
> the user from the group again, the subject upon login will no longer be
> populated with the group principal and therefore the user no longer
> inherits the permissions granted/denied to that group.
> similarly, if you remove that permission entry again and persist the
> change, the test group and all of it's members will no longer get that
> permission granted/denied (assuming there is no other entry that has the
> same effect).
>
> Kind regards
> Angela
>
> ________________________________________
> From: jorgeeflorez . <jo...@gmail.com>
> Sent: Thursday, May 23, 2019 8:03 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: Users, groups and permissions
>
> Hello,
>
> I have been reading regarding Jackrabbit and Oak security and I think I
> understand. but I would like to confirm before implementing something...
> When I create a group and assign a permission (e.g. rep:write) to that
> group over a node path.
> If I assign an user to that group then the user will have the permission
> that I gave to that group over that node?
> If I remove that user from the group the permission will be removed?
>
> From what I understand from here
> https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html that
> will not happen, and I will have to make it happen, am I right?
>
> Thanks.
>
Re: Users, groups and permissions
Posted by "jorgeeflorez ." <jo...@gmail.com>.
Hello Angela,
thank you for taking your time and writing this awesome reply. You saved my
life :)
It is clear to me now how it works by default. It seems that we are not
using the default security setup for Oak. I will have to look into it.
Best regards.
Jorge Flórez
El vie., 24 may. 2019 a las 2:03, Angela Schreiber
(<an...@adobe.com.invalid>) escribió:
> Hi Jorge
>
> The https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html
> are not directly related to permission evaluation. This is just an optional
> add on to perform specific verification or action upon modification of the
> set of members of a given group.... e.g. write a log message.
>
> When it comes to permissions it all boils down to the set of principals
> contained in the Subject after the Repository login and whether that set of
> principals is granted permission to perform a given read/write action.
>
> So, for simplicity let's look at the default setup as present with Oak out
> of the box:
> - the default authentication will
> > verify the passed Credentials object,
> > lookup the user associated with the Credentials and get it's principal
> > resolve the declared and inherited group membership for that user and
> get the group principals
> > update the subject with the complete set of principals both for the
> user and it's groups
> - the default authorization will
> > look at the permission entries for the set of principals and the
> target path and all it's ancestors
> > verify if a given action is granted (or denied) for any of the user
> principals or any of the group principals
> > if it is neither granted or explicitly denied, permission is not
> granted
> see https://jackrabbit.apache.org/oak/docs/security/permission.html and
>
> https://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html
> for details and examples.
>
> So, back to your initial question:
> If you take the default security setup of Oak, assign permissions to a
> group principal at /test/path and assign your user to that group will
> result in your user inheriting the permissions of the group. if you remove
> the user from the group again, the subject upon login will no longer be
> populated with the group principal and therefore the user no longer
> inherits the permissions granted/denied to that group.
> similarly, if you remove that permission entry again and persist the
> change, the test group and all of it's members will no longer get that
> permission granted/denied (assuming there is no other entry that has the
> same effect).
>
> Kind regards
> Angela
>
> ________________________________________
> From: jorgeeflorez . <jo...@gmail.com>
> Sent: Thursday, May 23, 2019 8:03 PM
> To: oak-dev@jackrabbit.apache.org
> Subject: Users, groups and permissions
>
> Hello,
>
> I have been reading regarding Jackrabbit and Oak security and I think I
> understand. but I would like to confirm before implementing something...
> When I create a group and assign a permission (e.g. rep:write) to that
> group over a node path.
> If I assign an user to that group then the user will have the permission
> that I gave to that group over that node?
> If I remove that user from the group the permission will be removed?
>
> From what I understand from here
> https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html that
> will not happen, and I will have to make it happen, am I right?
>
> Thanks.
>
Re: Users, groups and permissions
Posted by Angela Schreiber <an...@adobe.com.INVALID>.
Hi Jorge
The https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html are not directly related to permission evaluation. This is just an optional add on to perform specific verification or action upon modification of the set of members of a given group.... e.g. write a log message.
When it comes to permissions it all boils down to the set of principals contained in the Subject after the Repository login and whether that set of principals is granted permission to perform a given read/write action.
So, for simplicity let's look at the default setup as present with Oak out of the box:
- the default authentication will
> verify the passed Credentials object,
> lookup the user associated with the Credentials and get it's principal
> resolve the declared and inherited group membership for that user and get the group principals
> update the subject with the complete set of principals both for the user and it's groups
- the default authorization will
> look at the permission entries for the set of principals and the target path and all it's ancestors
> verify if a given action is granted (or denied) for any of the user principals or any of the group principals
> if it is neither granted or explicitly denied, permission is not granted
see https://jackrabbit.apache.org/oak/docs/security/permission.html and
https://jackrabbit.apache.org/oak/docs/security/permission/evaluation.html for details and examples.
So, back to your initial question:
If you take the default security setup of Oak, assign permissions to a group principal at /test/path and assign your user to that group will result in your user inheriting the permissions of the group. if you remove the user from the group again, the subject upon login will no longer be populated with the group principal and therefore the user no longer inherits the permissions granted/denied to that group.
similarly, if you remove that permission entry again and persist the change, the test group and all of it's members will no longer get that permission granted/denied (assuming there is no other entry that has the same effect).
Kind regards
Angela
________________________________________
From: jorgeeflorez . <jo...@gmail.com>
Sent: Thursday, May 23, 2019 8:03 PM
To: oak-dev@jackrabbit.apache.org
Subject: Users, groups and permissions
Hello,
I have been reading regarding Jackrabbit and Oak security and I think I
understand. but I would like to confirm before implementing something...
When I create a group and assign a permission (e.g. rep:write) to that
group over a node path.
If I assign an user to that group then the user will have the permission
that I gave to that group over that node?
If I remove that user from the group the permission will be removed?
From what I understand from here
https://jackrabbit.apache.org/oak/docs/security/user/groupaction.html that
will not happen, and I will have to make it happen, am I right?
Thanks.