[VOTE] Use the new security-authorization module per default in XWiki 5.0

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Use the new security-authorization module per default in XWiki 5.0

Denis Gervalle-2
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
 - 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.
 - 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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.
>  - 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
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Jérôme Velociter
Hi Denis,

Le 14/03/13 22:59, Denis Gervalle a écrit :

> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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 ?

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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Caleb James DeLisle


On 03/14/2013 06:12 PM, Jerome Velociter wrote:

> Hi Denis,
>
> Le 14/03/13 22:59, Denis Gervalle a écrit :
>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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.

I'm not entirely sure what "no admin right by default" means. If default documents
are not installed with PR then it's a great improvement but also a major break
(we should have a vote for that specific rule change).
If I cannot get PR to run groovy scripts on the wiki w/o enabling superadmin then -1.

I think we can get a better idea of what this means by throwing together another
rights service which tries both the new service and the old one and logs a warning
if they disagree, running the functional tests with this information would tell
us a lot more about how this behaves in practice. We can also collect hard performance
data.

Thanks,
Caleb

>
> 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 ?
>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
In reply to this post by Jérôme Velociter
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[hidden email]>wrote:

> Hi Denis,
>
> Le 14/03/13 22:59, Denis Gervalle a écrit :
>
>  On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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.


>
> 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
> [hidden email]
> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
In reply to this post by Caleb James DeLisle
On Thu, Mar 14, 2013 at 11:28 PM, Caleb James DeLisle <
[hidden email]> wrote:

>
>
> On 03/14/2013 06:12 PM, Jerome Velociter wrote:
> > Hi Denis,
> >
> > Le 14/03/13 22:59, Denis Gervalle a écrit :
> >> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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.
>
> I'm not entirely sure what "no admin right by default" means. If default
> documents
> are not installed with PR then it's a great improvement but also a major
> break
> (we should have a vote for that specific rule change).
> If I cannot get PR to run groovy scripts on the wiki w/o enabling
> superadmin then -1.
>

No, you get it wrong. It simply means, that if the admin right is not
explicitly allowed, it is denied by default. The most important consequence
is for an empty DB, since you do not receive admin rights when your are a
"null" user. (Even more, a "null" user never receive rights)

This is not so serious since now we have the DW that reach PR right in its
own way, and is able to deploy a wiki. Only power user that are skipping
the DW and wanting to import a XAR will need to login as superadmin to do
so.


> I think we can get a better idea of what this means by throwing together
> another
> rights service which tries both the new service and the old one and logs a
> warning
> if they disagree, running the functional tests with this information would
> tell
> us a lot more about how this behaves in practice. We can also collect hard
> performance
> data.
>

Setting up this dual RightService is easy, making it pass over all possible
situation if really harder.

Please note that, while I propose to change the default, this does not
prevent a user to configure back the old RightService.
Note also, that both services could be used side-by-side, so that new
component using the new right service, may work in that configuration.

IMO, if we never decide to go forward, we have no chance to discover and
improve the new service. It was there during the whole 4.x cycle, and very
few committers look at it. A new major version release is therefore the
ideal time to go on. We can justify some breakage, and we may fix them
during the 5.x cycle.


>
> Thanks,
> Caleb
>
> >
> > 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 ?
> >
> > 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
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Caleb James DeLisle


On 03/14/2013 06:49 PM, Denis Gervalle wrote:

> On Thu, Mar 14, 2013 at 11:28 PM, Caleb James DeLisle <
> [hidden email]> wrote:
>
>>
>>
>> On 03/14/2013 06:12 PM, Jerome Velociter wrote:
>>> Hi Denis,
>>>
>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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.
>>
>> I'm not entirely sure what "no admin right by default" means. If default
>> documents
>> are not installed with PR then it's a great improvement but also a major
>> break
>> (we should have a vote for that specific rule change).
>> If I cannot get PR to run groovy scripts on the wiki w/o enabling
>> superadmin then -1.
>>
>
> No, you get it wrong. It simply means, that if the admin right is not
> explicitly allowed, it is denied by default. The most important consequence
> is for an empty DB, since you do not receive admin rights when your are a
> "null" user. (Even more, a "null" user never receive rights)
>
> This is not so serious since now we have the DW that reach PR right in its
> own way, and is able to deploy a wiki. Only power user that are skipping
> the DW and wanting to import a XAR will need to login as superadmin to do
> so.
>
>
>> I think we can get a better idea of what this means by throwing together
>> another
>> rights service which tries both the new service and the old one and logs a
>> warning
>> if they disagree, running the functional tests with this information would
>> tell
>> us a lot more about how this behaves in practice. We can also collect hard
>> performance
>> data.
>>
>
> Setting up this dual RightService is easy, making it pass over all possible
> situation if really harder.
>
> Please note that, while I propose to change the default, this does not
> prevent a user to configure back the old RightService.
> Note also, that both services could be used side-by-side, so that new
> component using the new right service, may work in that configuration.
>
> IMO, if we never decide to go forward, we have no chance to discover and
> improve the new service. It was there during the whole 4.x cycle, and very
> few committers look at it. A new major version release is therefore the
> ideal time to go on. We can justify some breakage, and we may fix them
> during the 5.x cycle.

Indeed we can't pass over every possibility but if we can run the functional
tests and have a good explanation for each discrepancy then the change is
pretty safe. Users who tread off the common path are used to bugs because
all software has little testing of uncommon codepaths.

Tentative +1 but I still really want to see some numbers :)

Thanks,
Caleb

>
>
>>
>> Thanks,
>> Caleb
>>
>>>
>>> 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 ?
>>>
>>> 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
>>> [hidden email]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Ludovic Dubost
In reply to this post by Denis Gervalle-2
2013/3/14 Denis Gervalle <[hidden email]>

> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[hidden email]
> >wrote:
>
> > Hi Denis,
> >
> > Le 14/03/13 22:59, Denis Gervalle a écrit :
> >
> >  On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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.
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
> > [hidden email]
> > http://lists.xwiki.org/**mailman/listinfo/devs<
> http://lists.xwiki.org/mailman/listinfo/devs>
> >
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
In reply to this post by Denis Gervalle-2
+1 for the idea in general. I'm sure there'll be details to iron out (as pointed out by Jerome and Ludovic). Maybe a first step (if you haven't already done so) would be to enable it on your machine (or somewhere else) and build the full codebase to see if all tests pass. I know quite a few functional that I know will fail and will need to be updated but they're easy to fix.

As part of this move I'd like that the old auth code be moved to legacy modules too. But for that to happen we need that friendly xwiki-oriented interface. Without that we won't be able to update our code to use the new module.

Do you plan to move the security module to commons too?

Thanks
-Vincent

On Mar 14, 2013, at 9:20 PM, Denis Gervalle <[hidden email]> 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
> - 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.
> - 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
In reply to this post by Denis Gervalle-2
+1 to do the switch right now but I think we need to support global
users in local groups in 5.0, need to be confirmed but I'm pretty sure
it's used in Workspaces.

On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]> 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
>  - 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.
>  - 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
In reply to this post by Ludovic Dubost
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]> wrote:

> 2013/3/14 Denis Gervalle <[hidden email]>
>
> > On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[hidden email]
> > >wrote:
> >
> > > Hi Denis,
> > >
> > > Le 14/03/13 22:59, Denis Gervalle a écrit :
> > >
> > >  On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
> 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


> 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
> > > [hidden email]
> > > http://lists.xwiki.org/**mailman/listinfo/devs<
> > http://lists.xwiki.org/mailman/listinfo/devs>
> > >
> >
> >
> >
> > --
> > Denis Gervalle
> > SOFTEC sa - CEO
> > eGuilde sarl - CTO
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Ludovic Dubost
> Founder and CEO
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Marius Dumitru Florea
In reply to this post by Denis Gervalle-2
+1 to try it out in 5.0M2.

Thanks,
Marius

On Thu, Mar 14, 2013 at 10:20 PM, Denis Gervalle <[hidden email]> 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
>  - 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.
>  - 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
In reply to this post by Denis Gervalle-2

On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]> wrote:
>
>> 2013/3/14 Denis Gervalle <[hidden email]>
>>
>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[hidden email]
>>>> wrote:
>>>
>>>> Hi Denis,
>>>>
>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>
>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
In reply to this post by vmassol
On Fri, Mar 15, 2013 at 8:42 AM, Vincent Massol <[hidden email]> wrote:

> +1 for the idea in general. I'm sure there'll be details to iron out (as
> pointed out by Jerome and Ludovic). Maybe a first step (if you haven't
> already done so) would be to enable it on your machine (or somewhere else)
> and build the full codebase to see if all tests pass. I know quite a few
> functional that I know will fail and will need to be updated but they're
> easy to fix.
>

I will work on that now, since most seems now favorable to this move.


> As part of this move I'd like that the old auth code be moved to legacy
> modules too. But for that to happen we need that friendly xwiki-oriented
> interface. Without that we won't be able to update our code to use the new
> module.
>

We may move the old implementation right now (but not sure we need too be
in hurry for that). The new module expose the bridge (that I would like to
mark deprecated as soon as we have an xwiki-oriented interface), so only
the API needs to be kept temporarily.
Regarding the xwiki-oriented interface, the main work is to define it, and
I would like to have others participating in that specs. Writing it should
be quite easy.


> Do you plan to move the security module to commons too?
>

It is not impossible on mid-terms. It depends what we intent to achieve.
What really link the module to XWiki is the structure of
MainWiki-SubWiki-Space-Document. And I have used some specialized
EntityReference (SecurityReference, UserSecurityReference and
GroupSecurityReference) to support that easily. However, it should not be
too complex to abstract more these SecurityReference.
That said, supporting global users in local groups goes to less
abstractions, and imply the module to knows more about the first two level
(MainWiki-SubWiki) than it does currently.


>
> Thanks
> -Vincent
>
> On Mar 14, 2013, at 9:20 PM, Denis Gervalle <[hidden email]> 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
> > - 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.
> > - 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
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
In reply to this post by vmassol
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]> wrote:

>
> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>
> > On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
> wrote:
> >
> >> 2013/3/14 Denis Gervalle <[hidden email]>
> >>
> >>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> [hidden email]
> >>>> wrote:
> >>>
> >>>> Hi Denis,
> >>>>
> >>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
> >>>>
> >>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
> >> 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?
>

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 to the
old modules in the RN, and have 5.0 without this feature ? We may even
release XEM without it if workspace need so.

WDYT ?


>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator

On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>>
>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
>> wrote:
>>>
>>>> 2013/3/14 Denis Gervalle <[hidden email]>
>>>>
>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> [hidden email]
>>>>>> wrote:
>>>>>
>>>>>> Hi Denis,
>>>>>>
>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>>>
>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>>>> 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?
>>
>
> 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 to 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 lost…

Thanks
-Vincent

> WDYT ?
>
>
>>
>> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]> wrote:

>
> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
>
> > On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
> >>
> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
> >> wrote:
> >>>
> >>>> 2013/3/14 Denis Gervalle <[hidden email]>
> >>>>
> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> >> [hidden email]
> >>>>>> wrote:
> >>>>>
> >>>>>> Hi Denis,
> >>>>>>
> >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
> >>>>>>
> >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
> >>>> 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?
> >>
> >
> > 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 to 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 lost…
>

It was, but I was not aware that workspace may need (to be confirmed) that
special unsupported case.
I am just saying that while I would like the new module as a default, this
does not prevent a user to use the old one until we properly support that
particular feature.


>
> Thanks
> -Vincent
>
> > WDYT ?
> >
> >
> >>
> >> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Jean-Vincent Drean
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]> wrote:
>
>>
>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
>>
>> > On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]>
>> wrote:
>> >
>> >>
>> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>> >>
>> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
>> >> wrote:
>> >>>
>> >>>> 2013/3/14 Denis Gervalle <[hidden email]>
>> >>>>
>> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>> >> [hidden email]
>> >>>>>> wrote:
>> >>>>>
>> >>>>>> Hi Denis,
>> >>>>>>
>> >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>> >>>>>>
>> >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>> >>>> 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?
>> >>
>> >
>> > 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 to 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 lost…
>>
>
> It was, but I was not aware that workspace may need (to be confirmed) 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 ?

JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

Denis Gervalle-2
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:
> > On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
> >>
> >> > On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]>
> >> wrote:
> >> >
> >> >>
> >> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
> >> >>
> >> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
> >> >> wrote:
> >> >>>
> >> >>>> 2013/3/14 Denis Gervalle <[hidden email]>
> >> >>>>
> >> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
> >> >> [hidden email]
> >> >>>>>> wrote:
> >> >>>>>
> >> >>>>>> Hi Denis,
> >> >>>>>>
> >> >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
> >> >>>>>>
> >> >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
> >> >>>> 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?
> >> >>
> >> >
> >> > 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 to
> 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 lost…
> >>
> >
> > It was, but I was not aware that workspace may need (to be confirmed)
> 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 the 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 IMO.

See my reply to Ludovic for more about how we need to work on that missing
feature.


>
> JV.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator

On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[hidden email]> wrote:

> On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[hidden email]> wrote:
>
>> On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[hidden email]> wrote:
>>> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[hidden email]>
>> wrote:
>>>
>>>>
>>>> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[hidden email]> wrote:
>>>>
>>>>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[hidden email]>
>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[hidden email]> wrote:
>>>>>>
>>>>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>> 2013/3/14 Denis Gervalle <[hidden email]>
>>>>>>>>
>>>>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <
>>>>>> [hidden email]
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Denis,
>>>>>>>>>>
>>>>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit :
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[hidden email]>
>>>>>>>> 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?
>>>>>>
>>>>>
>>>>> 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 to
>> 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 lost…
>>>>
>>>
>>> It was, but I was not aware that workspace may need (to be confirmed)
>> 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 the 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 IMO.

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 the 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 change the default so that we're sure someone is going to work on this.

In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?

Thanks
-Vincent

> See my reply to Ludovic for more about how we need to work on that missing
> feature.
>
>
>>
>> JV.
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
12