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 (<anch...@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 . <jorgeeduardoflo...@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 > (<anch...@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 . <jorgeeduardoflo...@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. > > >
