15 Mar
2013
15 Mar
'13
3:11 p.m.
On Fri, Mar 15, 2013 at 2:22 PM, Jerome Velociter <jerome(a)velociter.fr>wrote;wrote:
Le 15/03/13 10:33, Denis Gervalle a écrit :
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <ludovic(a)xwiki.com>
Since it cache all security decisions, it also need to keep track of user
and groups to evict those decisions when some event happen to them. The
simplest would be to know for sure all groups a user is in, so we know the
user is complete or missing from the cache. This would require scanning all
wikis to discover local groups. Obviously, this risk to be really poor on
performance, so I need to introduce support for "partial" caching of users
relations with groups. And I propose to think about it at wiki level, so we
know it will know it have information for this user in a given set of
subwiki. To take a right decision, it will need the user to be cached for
the main wiki, and the wiki the entity is in.
wrote:
2013/3/14 Denis Gervalle <dgl(a)softec.lu>
Can you explain why we would need to do that in this case ?
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <jerome(a)velociter.fr
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,
> wrote:
> Hi Denis,
>
> Le 14/03/13 22:59, Denis Gervalle a écrit :
>
> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <dgl(a)softec.lu>
>
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.
^^^^^^^^
Jérôme.
and I would really like to avoid that to
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
plenty of projects for which migration to 5.0
would be almost impossible
I will need helps to achieve that for 5.0
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 ?
>>>
>>> --
>>> Denis Gervalle
>>> SOFTEC sa - CEO
>>> eGuilde sarl - CTO
>>>
>>>
>>>
>> ______________________________****_________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/…
> <
>
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
______________________________**_________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/ma…