Bringing the convo back on the public list since I think it’s important info for other devs and the PSC.
To answer the question I left the spring-security dependency as is because I was able to upgrade the spring dependency without it. While I don’t specifically have a need to upgrade spring security at the moment I think it’s a bad thing for the project to stay on an unmaintained version of it. And it will limit our ability to upgrade spring any further because moving to the core spring 4.x series will require an upgrade of spring-security to at least the 3.2.x version.
I think I wrote up some options to address (2) in a previous email but I’ll re-iterate here.
Option A: Simply require a GeoServer restart after changing security settings (authentication providers or security filters).
Option B: Do a major refactor of GeoServerSecurityManager and GeoServerFIlterChain so that instead of extending the spring security classes they delegate to them. That way the SS can be re-instantiated as needed when settings change.
Let me know if that all makes sense.
···
On Mon, Nov 16, 2015 at 8:57 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:
Hi Justin
I checked out your latest version of your “spring_upgrade” branch and I have seen you changed the spring-security version back to 3.0.5-RELEASE. Do you have a need to migrate to 3.2.9 ?
Cheers
Christian
On Thu, Nov 12, 2015 at 10:49 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:
@Justin, not so far, I hope to get a time gap at the weekend.
Christian
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
On Sat, Nov 7, 2015 at 6:14 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Circling back on this one. So until the cas issue can be sorted out it looks like any upgrade to spring security is a no go. I was however able to update the base spring version to the latest 3.2 version. That at least gets us onto a version that is currently still being maintained, albeit probably for not much longer. Here is the pull request.
https://github.com/geoserver/geoserver/pull/1327
@Christian: any luck looking at the cas issue?
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
On Sun, Oct 25, 2015 at 10:23 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:
Hi Justin
Currently we use cas-client-core.jar version 3.1.12, the new version of spring security needs version 3.3.3.
The API of org.jasig.cas.client.session.SingleSignOutHandler has changed. This is the reason for the compile errors.
Not easy to solve, will have a lookt at it.
Cheers
Christian
On Sat, Oct 24, 2015 at 6:43 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hey Christian,
Yes, I was planning to upgrade spring security as well. Unfortunately that is not proving to be very easy.
I tried jumping to 4.x but indeed the deprecated apis we are using are now gone. This impacts two of the most important classes in our security framework, one of them being GeoserverSecurityManager which more or less controls everything. Basically the base classes we are extending no long expose setter methods for various properties, with the only option begin to use constructor injection. Which is a major problem because we rely on those methods to change security configuration after the fact. I am not sure how to solve that… thoughts I have had (none of which are ideal).
-
Update GeoServerSecurityManager and GeoServerFilterChain to be non-singletons so we can re-instantiate them when configuration changes. This would be a pretty far reaching change, especially for the dependencies of GeoServerSecurityManager.
-
Require the user to restart GeoServer after making security configuration changes, or at least some kind of changes, basically when changing a provider or a filter.
-
Copy + modify versions of the base class from spring security into our codebase… and re-instate those method we need. A pretty ugly hack 
Anyways, all things considered that is a little dirtier than I can afford to get my hands
So I was thinking for now just upgrading to the latest 3.x versions. However that also leads to some issues in the cas module. Knowing nothing about how the cas extensions work I’m not seeing obvious alternatives to the method calls we were using.
If you would be willing to take a look that would be awesome in case it’’s obvious what to do. I’ve pushed the current changes up to a branch in my git repo:
https://github.com/jdeolive/geoserver/tree/spring-upgrade
Everything should compile up to extension/security/cas.
Thanks!
-Justin
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
On Sat, Oct 24, 2015 at 5:45 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:
HI Justin
Do you plan to migrate Spring Security too ? Maybe we are using some depricated APIs, please let me know.
Christian
On Fri, Oct 23, 2015 at 10:07 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Great, thanks guys. I’ll report back when I make some progress.
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
On Fri, Oct 23, 2015 at 1:37 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Oct 23, 2015 at 9:21 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
+1 Now is the time with a fresh master branch.
Agreed, +1
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.