Hi,
I’ve just committed the bug fix for GWC passwords not being encrypted:
https://github.com/geoserver/geoserver/commit/b63b6a2e540fdfb490d58a1a5e7e3dc5aea3a5e3
One of the things I’ve implemented is making sure the password gets re-encoded as the global password encryption method is changed, using a SecurityManagerListener.
That works fine, however there is an annoying side effect: the post change event also gets triggered on startup, the event tells me nothing about an eventual change of the password encoder, and the standard password encoder does not produce stable passwords.
Long story short, the event handling code ends up thinking the password encryption method changed, and rewrites the config file.
Not a show stopper, but if one manages the gs configuration via version control, that will generate a local change which will result in conflicts at the next data dir update.
So I’m wondering, is it really necessary to trigger the post changed event in the init method?
As far as I can see there is nothing using it.
An alternative could be to provide the listener both the old and new config, and let them deduce that the event is an init one because there was no config previously
Opinions?
Cheers
Andrea
–
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
On Sun, Jul 7, 2013 at 10:18 AM, Christian Mueller <
christian.mueller@anonymised.com> wrote:
Hi Andrea
1) Our password encoders never produce the same result for identical plain
text passwords. The encoding uses a random salt.
2) The post changed event is used by GeoServerSecurityFilterChainProxy to
create the internal data structure for the filter chains.
3) What about checking the encrypted password
with GeoServerPasswordEncoder.isResponsibleForEncoding(..). If the current
config password encoder is responsible for the encrypted password, you can
skip the recode logic.
Yes, this approach crossed my mind. However... is it possible to have a
configurable password encoder, that would take parameters to run, and thus
with the same encoder, the password structure would be different? I'm
probably just thinking too much...
Cheers
Andrea
--
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
-------------------------------------------------------
The password encoders are injected as Spring beans (applicationSecurityContext.xml). Here is an example
If you have encrypted passwords and you change the “algorithm” property, it is not possible to decrypt these passwords. I think this is the only way to break the encoding/decoding schema. I think most people will not be able to interpret the value and will not change it.
People having those skills should know what they are doing.
I would go on with "“isResponsibleForEncdoing”
Cheers
···
2013/7/7 Andrea Aime <andrea.aime@anonymised.com>
On Sun, Jul 7, 2013 at 10:18 AM, Christian Mueller <christian.mueller@anonymised.com.3674…> wrote:
–
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH
Hi Andrea
-
Our password encoders never produce the same result for identical plain text passwords. The encoding uses a random salt.
-
The post changed event is used by GeoServerSecurityFilterChainProxy to create the internal data structure for the filter chains.
-
What about checking the encrypted password with GeoServerPasswordEncoder.isResponsibleForEncoding(…). If the current config password encoder is responsible for the encrypted password, you can skip the recode logic.
Yes, this approach crossed my mind. However… is it possible to have a configurable password encoder, that would take parameters to run, and thus with the same encoder, the password structure would be different? I’m probably just thinking too much…
Cheers
Andrea
–
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