Hi Marco Yes, the extra note regarding performance was intended to remind people that expensive calculations may have a negative effect on overall permission evaluation performance. If the restriction check is fast, the impact is most likely insignificant. But take for example the node type name restriction: if one would change this to calculate the effective JCR nodetype with all the inheritance and mixins it might be quite slow compare to a simple string comparison.
It's just a extra word of caution because I regretted more than once for not being explicit in the documentation and assuming what I considered common sense. Then realized later on that my understanding of common sense in Oak is based on a bit of extra insight. Others may not necessarily have that insight such as I am likely shortsighted or ignorant in other areas 🙂 Hope that helps Angela ________________________________ From: Marco Piovesana <[email protected]> Sent: Wednesday, February 26, 2020 11:51 AM To: [email protected] <[email protected]> Subject: Re: custom restrictions on ACEs hi Angela, what I want is basically being able, when reading an ACE, to know if it was created because of a user request or not. So having a property that I can set when creating the ACE would have been sufficient. I think that the default authorization process works fine for what I need, so maybe implementing a custom one might be an overkill, but thanks for the tip, I didn't know about the examples. I have one more question, the documentation says that: "restrictions are part of the overall permission evaluation and thus may heavily impact overall read/write performance", that depends on how much work is required to validate the restriction right? if the validation itself is fast, then the impact on the performance is very limited, or there are other things that might decrease the performances? On Wed, Feb 26, 2020, 5:25 PM Angela Schreiber <[email protected]> wrote: > Hi Marco > > Depending on what you wish to achieve the restrictions may help. I am not > sure if fully understood what you are aiming for so it's a bit hard to tell > if restrictions will really do the trick. > > Depending on the actual needs and how well your access control > requirements fit into the default authorization model, it might be worth > exploring the ability to provide a custom authorization setup. If you find > yourself struggling to map your needs to a setup using the default > authorization, exploring a custom implementation might be worth the effort > and might also end up being more efficient in terms of maintaining the > setup and evaluation performance... but it really depends on the details. > In case you wish to explore that option, you will find some simplistic > examples/exercises in the oak-exercise module. > > The same exercise module also provides a few exercise lessons for > restrictions and how to write a custom restriction provider. Obviously > that's a lot easier that writing a custom authorization model. > > Hope that helps > Angela > ________________________________ > From: Marco Piovesana <[email protected]> > Sent: Wednesday, February 26, 2020 9:13 AM > To: [email protected] <[email protected]> > Subject: custom restrictions on ACEs > > Hi all, > I have an application where the ACEs (Access Control Entries) are applied > to a node by users and by the system itself. By the user when she/he wants > to share the node with some other users, by the system when the node has to > be available to some users in automatic, under specific conditions. The > user should not be able to modify an ACE added by the system. > Right now, when I read the ACL, I can't tell what ACE has been created by > the user and what has been created by the system. Reading the documentation > I saw that one possible solution might be using custom restrictions > < > https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html > > > when creating the ACE, but I'm not sure this is one of the intended usage > for the restrictions. Is there a better solution for this problem? > > Marco. >
