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