Re: [xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0

On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <vincent(a)massol.net>

> > On Mar 15, 2013, at 10:50 AM, Denis Gervalle &lt;dgl(a)softec.lu&gt; wrote: > >> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol &lt;vincent(a)massol.net&gt; > wrote: >> >>> >>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle &lt;dgl(a)softec.lu&gt; wrote: >>> >>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost &lt;ludovic(a)xwiki.com&gt; >>> wrote: >>>> >>>>> 2013/3/14 Denis Gervalle &lt;dgl(a)softec.lu&gt; >>>>> >>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < >>> jerome(a)velociter.fr >>>>>>> wrote: >>>>>> >>>>>>> Hi Denis, >>>>>>> >>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>>>> >>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle &lt;dgl(a)softec.lu&gt; >>>>> wrote: >>>>>>>> >>>>>>>> Hi devs, >>>>>>>>> >>>>>>>>> We have a new (component based) authorization module since a

>>>>> now, >>>>>>>>> and I think 5.0 is the perfect time to introduce it as the

>>>>>> right >>>>>>>>> service. First, I simply propose to change the default in > xwiki.cfg: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>

>>>>>>>>> internal.**XWikiCachingRightService >>>>>>>>> >>>>>>>>> (Later, I propose that we deprecate that bridge and that we > create a >>>>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But > leave >>>>>>>>> this for a >>>>>>>>> later proposal.) >>>>>>>>> >>>>>>>>> So this vote is about changing the default in xwiki.cfg before >>> 5.0M2. >>>>>>>>> >>>>>>>>> pros: >>>>>>>>> - improved performance, since the new service is using caching >>>>>>>>> techniques >>>>>>>>> and a single page load required lots of calls to it. >>>>>>>>> - ability for extension to add new rights >>>>>>>>> - define right declaratively >>>>>>>>> - separate method for checking and verifying right (throws

>>>>> to >>>>>>>>> boolean return) >>>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as

>>>>> as >>>>>>>>> some unstated ones >>>>>>>>> >>>>>>>>> Also XWIKI-4550 >>>>>>>> >>>>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>>>> - no more admin right per default >>>>>>>>> - being in good position to improve it and release

>>>>>>>>> oldcore for security matters. >>>>>>>>> - possibility for third party to adapt the right settler to

>>>>>>>>> special >>>>>>>>> needs (right decision is plugable) >>>>>>>>> - a consistant right evaluation with very few exception that

>>>>> be >>>>>>>>> explained and documented >>>>>>>>> >>>>>>>>> cons: >>>>>>>>> - no more admin right per default, but since we have DW, the >>>>> initial >>>>>>>>> setup is no more a problem, and advanced users may use

>>>>>>>>> - groups are only checked from the user wiki, not from the > accessed >>>>>>>>> entity wiki. >>>>>>>>> >>>>>>>> >>>>>>> This sound like a big regression. >>>>>>> >>>>>>> Can you explicit more ? Does this mean that adding a global (main >>> wiki) >>>>>>> user in a local group has no effect ? >>>>>>> >>>>>> >>>>>> You have got it right. This could be improved, and help is

>>> What >>>>>> happen is that the user groups are evaluated independently to the >>>>> targeted >>>>>> entity, and therefore only in the user wiki. >>>>>> >>>>>> I admit this is a regression, but I have not cross lots of use

>>> like >>>>>> those. The simple display in admin of Global user in local Group

>>> even >>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a

>>>>>> usage. >>>>>> You may provide access to global group in a local wiki to achieve

>>>>> same >>>>>> goals. >>>>>> >>>>>> >>>>> This looks to be indeed a big regression. It's quite a common use

>>> to >>>>> have only global users and to create groups in the local wiki that >>> refer to >>>>> local users. >>>>> >>>> ^^^^^^^^ >>>> I suppose you means global users here. >>>> >>>> IMHO, having user managed by a separate entity (global admin), and > these >>>> same individual users grouped by another one (local admin) is very >>> uncommon >>>> delegation of authority to me (but I may be wrong). On the other

>>>> having a local admin providing access to local ressources to global > group >>>> (and potentially some global users) makes more sense. In that way,

>>> same >>>> admin manage its users, and group its users, and the local admin

>>> the >>>> global admin to know its users. >>>> >>>> That said, I am not against any improvement on the way it works, if

>>> is a >>>> common use case (moreover used by workspace), we should obviously > support >>>> it. However, I am convince that evaluating groups based on both the > user >>>> and the targeted entity is not easily achievable and conduct to very >>>> complex partial caching. >>>> >>>> I have currently not implemented in the security module anything

>>> would >>>> cause all wikis to be scanned, and I would really like to avoid

>>>> happen. So, it will be difficult to avoid partial caching, but we

> to >>>> limit that at the higher level, the subwiki. This would allow to had > only >>>> scan both the wiki of the user and the target entry to consider our > cache >>>> valid. It means subwiki will be unable to share groups (I do not

>>> this >>>> has ever worked), but it will keep performance on large farm. >>>> >>>> This would really need to be fixed sooner than later otherwise I

>>>>> plenty of projects for which migration to 5.0 would be almost > impossible >>>>> >>>> >>>> I will need helps to achieve that for 5.0 >>> >>> ok so before changing anything we need a plan i.e. someone

> to >>> work on this, right? >>> >> >> Do we really need that for 5.0 ? >> Using the new module as a default does not means the old right

>> unavailable. Couldn't we simply define which case needs to revert to

It was, but I was not aware that workspace may need (to be confirmed)

special unsupported case.