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