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 (<[email protected]>) 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 . <[email protected]> > Sent: Thursday, May 23, 2019 8:03 PM > To: [email protected] > 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. >
