On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote: > >> 2013/3/14 Denis Gervalle <[email protected]> >> >>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected] >>>> wrote: >>> >>>> Hi Denis, >>>> >>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>> >>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> >> wrote: >>>>> >>>>> Hi devs, >>>>>> >>>>>> We have a new (component based) authorization module since a 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: >>>>>> >>>>>> >>>>>> >>> xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** >>>>>> 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 opposed >> to >>>>>> boolean return) >>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as 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 that could >> 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 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 the >> 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 Group 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 achieve the >> same >>> goals. >>> >>> >> This looks to be indeed a big regression. It's quite a common use case 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 hand, > having a local admin providing access to local ressources to global group > (and potentially some global users) makes more sense. In that way, 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 works, if it 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 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 we 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 our 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? Thanks -Vincent >> 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 think even Workspaces is using that so XEM by default would fail with >> this. >> >> Ludovic >> >>> >>>> >>>> Jérôme >>>> >>>> >>>> - may exhibit some other minor differences compare to existing >>>>>> implementation (but mostly consistency fixes) >>>>>> - test could be improved, critical part (right, settler, data >>>>>> structure, >>>>>> cache) are covered at almost 100%, api at 60%, this is probably >> better >>>>>> than the old right service >>>>>> - documentation should be improved, but this is not worse than the >>> old >>>>>> one anyway >>>>>> >>>>>> Since I use the new module in all my production servers for several >>>>>> months >>>>>> with success, and I really think that if we do not do it now we will >>>>>> never >>>>>> go ahead, here is my big +1 >>>>>> >>>>>> WDYT ? _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
