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

On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <vincent(a)massol.net>

> > On Mar 15, 2013, at 12:14 PM, Denis Gervalle <dgl(a)softec.lu> wrote: > > > On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <jv(a)xwiki.com> > wrote: > > > >> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <dgl(a)softec.lu>

> >>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <

> >> wrote: > >>> > >>>> > >>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle &lt;dgl(a)softec.lu&gt;

> >>>> > >>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <

> > > >>>> wrote: > >>>>> > >>>>>> > >>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle &lt;dgl(a)softec.lu&gt;

> >>>>>> > >>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <

> > > >>>>>> 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 <

> >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi devs, > >>>>>>>>>>>> > >>>>>>>>>>>> We have a new (component based) authorization module since

> >> while > >>>>>>>> now, > >>>>>>>>>>>> and I think 5.0 is the perfect time to introduce it as the > >> default > >>>>>>>>> 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.

> >>>> leave > >>>>>>>>>>>> this for a > >>>>>>>>>>>> later proposal.) > >>>>>>>>>>>> > >>>>>>>>>>>> So this vote is about changing the default in xwiki.cfg

> >>>>>> 5.0M2. > >>>>>>>>>>>> > >>>>>>>>>>>> pros: > >>>>>>>>>>>> - improved performance, since the new service is using

> >>>>>>>>>>>> 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 > >> opposed > >>>>>>>> to > >>>>>>>>>>>> boolean return) > >>>>>>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987,

> >> well > >>>>>>>> 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 > >> dependencies to > >>>>>>>>>>>> oldcore for security matters. > >>>>>>>>>>>> - possibility for third party to adapt the right settler to > >> their > >>>>>>>>>>>> special > >>>>>>>>>>>> needs (right decision is plugable) > >>>>>>>>>>>> - a consistant right evaluation with very few exception

> >> could > >>>>>>>> be > >>>>>>>>>>>> explained and documented > >>>>>>>>>>>> > >>>>>>>>>>>> cons: > >>>>>>>>>>>> - no more admin right per default, but since we have DW,

> >>>>>>>> initial > >>>>>>>>>>>> setup is no more a problem, and advanced users may use > >> superadmin. > >>>>>>>>>>>> - 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 > >> welcome. > >>>>>> What > >>>>>>>>> happen is that the user groups are evaluated independently to

> >>>>>>>> targeted > >>>>>>>>> entity, and therefore only in the user wiki. > >>>>>>>>> > >>>>>>>>> I admit this is a regression, but I have not cross lots of use > >> case > >>>>>> like > >>>>>>>>> those. The simple display in admin of Global user in local

> >> is > >>>>>> even > >>>>>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a > >> common > >>>>>>>>> usage. > >>>>>>>>> You may provide access to global group in a local wiki to

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

> >> case > >>>>>> to > >>>>>>>> have only global users and to create groups in the local wiki

> >>>>>> refer to > >>>>>>>> local users. > >>>>>>>> > >>>>>>> ^^^^^^^^ > >>>>>>> I suppose you means global users here. > >>>>>>> > >>>>>>> IMHO, having user managed by a separate entity (global admin),

> >>>> these > >>>>>>> same individual users grouped by another one (local admin) is

> >>>>>> uncommon > >>>>>>> delegation of authority to me (but I may be wrong). On the other > >> hand, > >>>>>>> having a local admin providing access to local ressources to

> >>>> group > >>>>>>> (and potentially some global users) makes more sense. In that

> >> the > >>>>>> same > >>>>>>> admin manage its users, and group its users, and the local admin > >> trust > >>>>>> the > >>>>>>> global admin to know its users. > >>>>>>> > >>>>>>> That said, I am not against any improvement on the way it

> >> it > >>>>>> is a > >>>>>>> common use case (moreover used by workspace), we should

> >>>> support > >>>>>>> it. However, I am convince that evaluating groups based on both

> >>>> 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 > >> that > >>>>>> would > >>>>>>> cause all wikis to be scanned, and I would really like to avoid > >> that to > >>>>>>> happen. So, it will be difficult to avoid partial caching, but

> >> need > >>>> 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

> >>>> cache > >>>>>>> valid. It means subwiki will be unable to share groups (I do not > >> think > >>>>>> this > >>>>>>> has ever worked), but it will keep performance on large farm. > >>>>>>> > >>>>>>> This would really need to be fixed sooner than later otherwise I > >> know > >>>>>>>> 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 > >> volunteering > >>>> 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 > >> service is > >>>>> unavailable. Couldn't we simply define which case needs to revert

> >> the > >>>>> old modules in the RN, and have 5.0 without this feature ? We may > even > >>>>> release XEM without it if workspace need so. > >>>> > >>>> I thought the config change you were proposing was global… I'm

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

> >> that > >>> special unsupported case. > >> > >> I don't see why you consider this use case as special, when all the > >> users are managed in the main wiki and you want local admins to be > >> able to manage groups in their wiki you need this. Or am I missing > >> something ? > >> > > > > I probably expressed myself badly. This is currently unsupported in

> new > > module. I am just saying that even if we release a 5.0 with this > > regression, a simple like in xwiki.cfg will put back the old right > service > > for those who need this. First, only XEM is impacted, second only user > with > > this kind of delegation need that. So, this is not the general case

> > Sure but it's not that simple. We certainly don't want users to be in a > situation where their wiki doesn't work, then they spend time trying to > understand. After a few days they post to the list and then only change

> config property. This will be bad for us. It has to work. Of course we > could put it in the Release Notes but it won't help much in practice. > > I'd prefer that we have someone committed to work on this before we

This is really a lot of works for just a single line commit (redefining

jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside. I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta) UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures This does not seems much to me in regards to the change. If you all

I would like to commit on master ASAP, so all of you may help fixing

tests. Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC. So, do you agree to go that way and give this long awaited improvement a real boost ?

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs