Sounds good Christian.
I would say separate patches would be better. Makes them easier to review
in isolation.
Thanks for working through this. I'll try to make myself as available as I
can do review the patches as they come forth.
-Justin
On Thu, Aug 22, 2013 at 10:39 AM, Christian Mueller <
christian.muel...@os-solutions.at> wrote:
> Hi Justin
>
> So we have an agreement. I will do the following steps:
>
>
> 1) Prepare a patch with the root login chain and push it to my github
> repository for review. (Including tests and sphinx documentation)
>
> 2) Kick out the root login code/tests for each auth filter. This is quite
> a mechanical work.
>
> Or is it better to combine 1) and 2) in a single commit resulting in a
> "monster" patch.
>
> Cheers
>
>
> On Wed, Aug 21, 2013 at 9:20 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> My thought is that it would not show up in the config.xml file, and just
>> be something completely transparent to the user. And only have things in
>> config.xml that would be user configurable.
>>
>>
>> On Wed, Aug 21, 2013 at 10:55 AM, Christian Mueller <
>> christian.muel...@os-solutions.at> wrote:
>>
>>> Hi Justin
>>>
>>> I will use a constant filter chain in any case. The question is if this
>>> chain is stored in the security/config.xml
>>> or injected on start. We have a hook for this, as an example look at the
>>> last method in
>>>
>>>
>>> https://github.com/geoserver/geoserver/blob/master/src/extension/security/cas/src/main/java/org/geoserver/security/cas/GeoServerCasAuthenticationProvider.java
>>>
>>>
>>> The CAS module adds this chain behind the scenes (you cannot see it in
>>> the GUI) to receive proxy granting tickets from the CAS server.
>>>
>>> Storing in security/config.xml needs migration code. Can I backport this
>>> change to the 2.4.x branch ?. I think this is not possible.
>>>
>>> I have no preferences here, but however we do it, I will have to start
>>> some investigations.
>>>
>>> Cheers
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 16, 2013 at 4:53 PM, Justin Deoliveira <jdeol...@opengeo.org
>>> > wrote:
>>>
>>>> Hmmm... well my preference would probably be to implement the idea of a
>>>> constant filter chain. The security system is already complex enough and
>>>> this sort of seems like lumping more stuff on rather than fixing a core
>>>> issue. But i understand if implementing the idea of a constant filter chain
>>>> is more work than this approach. Do you have an idea of what the effort
>>>> involved in the two approaches is?
>>>>
>>>>
>>>> On Thu, Aug 15, 2013 at 9:32 AM, Christian Mueller <
>>>> christian.muel...@os-solutions.at> wrote:
>>>>
>>>>> No, the root login chain is hard coded in Java and will use its own
>>>>> digest authentication filter (created on startup). The idea is to build
>>>>> the
>>>>> whole chain on the fly at system startup without using configuration
>>>>> information from the security directory. The chain itself is injected at
>>>>> first position in the filter chain list.
>>>>>
>>>>> I could image a java property like
>>>>>
>>>>> -DNO_ROOT_LOGIN=true
>>>>>
>>>>> If somebody wants to deactivate the root login for production systems.
>>>>> (Can be enabled by a GeoServer restart without this system property).
>>>>>
>>>>> How does this sound ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 15, 2013 at 3:32 PM, Justin Deoliveira <
>>>>> jdeol...@opengeo.org> wrote:
>>>>>
>>>>>> So is there anything that will stop the user from misconfiguring the
>>>>>> root login chain?
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 14, 2013 at 6:01 AM, Christian Mueller <
>>>>>> christian.muel...@os-solutions.at> wrote:
>>>>>>
>>>>>>> Hi Justin
>>>>>>>
>>>>>>> Yep, with talked about a constant system filter chain, but it is not
>>>>>>> implemented yet. At the moment, each authentication filter has the
>>>>>>> burden
>>>>>>> to handle the login for the root user.
>>>>>>>
>>>>>>> Your understanding of the issue is correct.
>>>>>>>
>>>>>>> I would be happy to have a constant URI for the root login and kick
>>>>>>> out all the root login code and tests scattered over the security code.
>>>>>>>
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 14, 2013 at 1:27 PM, Justin Deoliveira <
>>>>>>> jdeol...@opengeo.org> wrote:
>>>>>>>
>>>>>>>> Hi Christian,
>>>>>>>>
>>>>>>>> I thought this issue was addressed previously with the idea of a
>>>>>>>> constant filter chain, one that the user could not take away through
>>>>>>>> misconfiguration. Is that not he case?
>>>>>>>>
>>>>>>>> The idea sounds reasonable but i want to make sure i understand the
>>>>>>>> issue.
>>>>>>>>
>>>>>>>> -Justin
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Aug 8, 2013 at 9:43 AM, Christian Mueller <
>>>>>>>> christian.muel...@os-solutions.at> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The issue is about disabling the login page if no form based login
>>>>>>>>> is possible.
>>>>>>>>>
>>>>>>>>> https://jira.codehaus.org/browse/GEOS-5958
>>>>>>>>>
>>>>>>>>> All these security configuration issues may be dangerous if a
>>>>>>>>> configuration error happens. At the end of the day, the admin can
>>>>>>>>> lock out
>>>>>>>>> itself.
>>>>>>>>>
>>>>>>>>> IMHO, a dedicated login for the root user with the master password
>>>>>>>>> should always be possible. (The "root" user has administrative
>>>>>>>>> privileges).
>>>>>>>>>
>>>>>>>>> My idea:
>>>>>>>>>
>>>>>>>>> - Add a special filter chain /web/rootlogin (checked before
>>>>>>>>> /web/**)
>>>>>>>>> - Force digest authentication, no GUI needed, the browser pops up
>>>>>>>>> a login box
>>>>>>>>> - Upon success, redirect the the request to /web/
>>>>>>>>>
>>>>>>>>> This is quite a simple solution and helps fixing GEOS-5958.
>>>>>>>>> Additionally, I can remove a lot of code concerning the root login in
>>>>>>>>> the
>>>>>>>>> individual authentication filters and test cases.
>>>>>>>>>
>>>>>>>>> Opinions ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> DI Christian Mueller MSc (GIS), MSc (IT-Security)
>>>>>>>>> OSS Open Source Solutions GmbH
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>>>>>>>> It's a free troubleshooting tool designed for production.
>>>>>>>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>>>>>>>> Download for free and get started troubleshooting in minutes.
>>>>>>>>>
>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>>>>>>>> _______________________________________________
>>>>>>>>> GeoTools-Devel mailing list
>>>>>>>>> GeoTools-Devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Justin Deoliveira
>>>>>>>> OpenGeo - http://opengeo.org
>>>>>>>> Enterprise support for open source geospatial.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> DI Christian Mueller MSc (GIS), MSc (IT-Security)
>>>>>>> OSS Open Source Solutions GmbH
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Justin Deoliveira
>>>>>> OpenGeo - http://opengeo.org
>>>>>> Enterprise support for open source geospatial.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> DI Christian Mueller MSc (GIS), MSc (IT-Security)
>>>>> OSS Open Source Solutions GmbH
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Justin Deoliveira
>>>> OpenGeo - http://opengeo.org
>>>> Enterprise support for open source geospatial.
>>>>
>>>
>>>
>>>
>>> --
>>> DI Christian Mueller MSc (GIS), MSc (IT-Security)
>>> OSS Open Source Solutions GmbH
>>>
>>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
>
>
> --
> DI Christian Mueller MSc (GIS), MSc (IT-Security)
> OSS Open Source Solutions GmbH
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
