[Geoserver-devel] New Geoserver security features

GeoServer GeoServer Developer
1

Ian and me decided to open a thread on the developers list concerning

https://jira.codehaus.org/browse/GEOS-4702
https://jira.codehaus.org/browse/GEOS-4554

Each issue has a patch, unfortunately they are overlapping.

Ians patch has two major topics

a) Digesting passwords in the user.properties file
b) Encrypting passwords for geoserver stores

add a)
The user.properties file and the GeoserverUserDao are replaced by UserGroupServices and GrantedAuthorityServices by my patch. It will be possible to have more than one backend for users/groups. At the moment I deferred password digesting since I am investigating into authentication manager / authentication providers supporting CAS,proxy authentication,password authentication and so on. Not every user has to be authenticated by userid/password, nor has the user information to be stored within a geoserver backend implementation.

add b)
This topic is unique to Ians patch. Some comments

1)
I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism, but it would be nice to have the possibility to inject the master key using Spring.

2)
I would prefer a md5/aes 128 encryption as default and would avoid DES which is not state of the art and could be broken by brute force today (only 56 Bit key length).

3) Perhaps, there should be a possibility to turn this feature off after turning it on, not sure here.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion (PBE) feature. At the moment we cannot apply both patches simultaneously and I want a situation where we can continue work independently.

Opinions ?

Cheers
Christian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

2

How close is your work to being commit ready Christian? Is there any sort of timeline? If you plan to be in a position to commit work soon then I would say it would make sense for Ian to hold back part of the patch, but if it is still a while yet then imo it is not really fair to make him wait . Others may disagree but generally from my experience it is the developer on the longer term branch that has to carry the burden of merging after the fact, and simply has to deal with changes that have happened in the interim.

$0.02

-Justin

On Tue, Aug 30, 2011 at 10:04 PM, <christian.mueller@anonymised.com.> wrote:

Ian and me decided to open a thread on the developers list concerning

https://jira.codehaus.org/browse/GEOS-4702
https://jira.codehaus.org/browse/GEOS-4554

Each issue has a patch, unfortunately they are overlapping.

Ians patch has two major topics

a) Digesting passwords in the user.properties file
b) Encrypting passwords for geoserver stores

add a)
The user.properties file and the GeoserverUserDao are replaced by
UserGroupServices and GrantedAuthorityServices by my patch. It will be
possible to have more than one backend for users/groups. At the moment
I deferred password digesting since I am investigating into
authentication manager / authentication providers supporting CAS,proxy
authentication,password authentication and so on. Not every user has
to be authenticated by userid/password, nor has the user information
to be stored within a geoserver backend implementation.

add b)
This topic is unique to Ians patch. Some comments

I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism,
but it would be nice to have the possibility to inject the master key
using Spring.

I would prefer a md5/aes 128 encryption as default and would avoid DES
which is not state of the art and could be broken by brute force today
(only 56 Bit key length).

  1. Perhaps, there should be a possibility to turn this feature off
    after turning it on, not sure here.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion
(PBE) feature. At the moment we cannot apply both patches
simultaneously and I want a situation where we can continue work
independently.

Opinions ?

Cheers
Christian

This message was sent using IMP, the Internet Messaging Program.

Special Offer – Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you’ll get a free “Love Thy Logs” t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

Hi Christian,

1)
I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism,
but it would be nice to have the possibility to inject the master key
using Spring.

The web configuration could be an option, though I don't think people
will want that as the default as it requires a login to bootstrap the
server with the master password. I'm not sure of the advantage of
injecting the password via Spring over the other configuration
options. Can you elaborate?

2)
I would prefer a md5/aes 128 encryption as default and would avoid DES
which is not state of the art and could be broken by brute force today
(only 56 Bit key length).

This is the default and is configurable. Pluggable providers (bouncy
castle for instance) should be supported, too. Again, the primary goal
is to keep plaintext passwords from lying around. If an intruder has
physical access to the datastore files, there will be trouble beyond
the threat of brute force password cracking. For example, why use the
sqlserver password when you can just log in using the integrated
security? Or add a jar to the classpath that loads a component into
the spring context and grabs all of the decoded passwords from the
catalog. My point is, a determined intruder will be able to get the
password or access the systems somehow (spear-phishing?) - the goal is
to provide reasonable security. I agree that a default non-random
password is not reasonable security (will fix this) - this was left
over from when the system was enabled by default.

3) Perhaps, there should be a possibility to turn this feature off
after turning it on, not sure here.

The feature is opt-in so anyone enabling it should know what they are
doing. Recovery of the digested user passwords is not possible by
design.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion
(PBE) feature. At the moment we cannot apply both patches
simultaneously and I want a situation where we can continue work
independently.

Opinions ?

For the moment, perhaps they should coexist, disabled by default?

Regards,
-Ian

4

Zitat von Justin Deoliveira <jdeolive@anonymised.com>:

How close is your work to being commit ready Christian? Is there any sort of
timeline? If you plan to be in a position to commit work soon then I would
say it would make sense for Ian to hold back part of the patch, but if it is
still a while yet then imo it is not really fair to make him wait . Others
may disagree but generally from my experience it is the developer on the
longer term branch that has to carry the burden of merging after the fact,
and simply has to deal with changes that have happened in the interim.

The patch is the result from GSOC 2011 and is ready since about a week. I wait for Andrea as my mentor to review. My primary sorrow is that Ians patch introduces password digesting to GeoserverUserDoa/users.properties and after my patch is applied, an automatic migration from users properties takes place. For the new authentication concept(CAS, proxy authentication,....) I will have to rollback most of the Ians changes concerning user passwords, the job will not become easier.

Lets wait for Andreas review ?

$0.02

-Justin

On Tue, Aug 30, 2011 at 10:04 PM, <christian.mueller@anonymised.com> wrote:

Ian and me decided to open a thread on the developers list concerning

https://jira.codehaus.org/browse/GEOS-4702
https://jira.codehaus.org/browse/GEOS-4554

Each issue has a patch, unfortunately they are overlapping.

Ians patch has two major topics

a) Digesting passwords in the user.properties file
b) Encrypting passwords for geoserver stores

add a)
The user.properties file and the GeoserverUserDao are replaced by
UserGroupServices and GrantedAuthorityServices by my patch. It will be
possible to have more than one backend for users/groups. At the moment
I deferred password digesting since I am investigating into
authentication manager / authentication providers supporting CAS,proxy
authentication,password authentication and so on. Not every user has
to be authenticated by userid/password, nor has the user information
to be stored within a geoserver backend implementation.

add b)
This topic is unique to Ians patch. Some comments

1)
I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism,
but it would be nice to have the possibility to inject the master key
using Spring.

2)
I would prefer a md5/aes 128 encryption as default and would avoid DES
which is not state of the art and could be broken by brute force today
(only 56 Bit key length).

3) Perhaps, there should be a possibility to turn this feature off
after turning it on, not sure here.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion
(PBE) feature. At the moment we cannot apply both patches
simultaneously and I want a situation where we can continue work
independently.

Opinions ?

Cheers
Christian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

5

Zitat von Ian Schneider <ischneider@anonymised.com>:

Hi Christian,

1)
I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism,
but it would be nice to have the possibility to inject the master key
using Spring.

The web configuration could be an option, though I don't think people
will want that as the default as it requires a login to bootstrap the
server with the master password. I'm not sure of the advantage of
injecting the password via Spring over the other configuration
options. Can you elaborate?

Sorry, my fault here. I meant the PBEConfig interface here. Why not have a default implementation. Code snippet

PBEConfig c = GeoserverExtensions.bean(PBEConfig.class);
if (c==null)
     c= .... // use default impl with GeoserverExtensions.property(..)

Users can implement their own PBEConfig and inject it using spring.

This allows users to get their master password from wherever the want to.

2)
I would prefer a md5/aes 128 encryption as default and would avoid DES
which is not state of the art and could be broken by brute force today
(only 56 Bit key length).

This is the default and is configurable. Pluggable providers (bouncy
castle for instance) should be supported, too. Again, the primary goal
is to keep plaintext passwords from lying around. If an intruder has
physical access to the datastore files, there will be trouble beyond
the threat of brute force password cracking. For example, why use the
sqlserver password when you can just log in using the integrated
security? Or add a jar to the classpath that loads a component into
the spring context and grabs all of the decoded passwords from the
catalog. My point is, a determined intruder will be able to get the
password or access the systems somehow (spear-phishing?) - the goal is
to provide reasonable security. I agree that a default non-random
password is not reasonable security (will fix this) - this was left
over from when the system was enabled by default.

Yep, I agree, there are many possibilities to attack. Perhaps I am little bit paranoid since my "Applied IT Security" study, but I feel uncomfortable using a weak 56 Bit DES instead an 128 Bit AES if I know the danger in advance. At the end of the day, you should decide.

3) Perhaps, there should be a possibility to turn this feature off
after turning it on, not sure here.

The feature is opt-in so anyone enabling it should know what they are
doing. Recovery of the digested user passwords is not possible by
design.

I was talking only about the encrypted store passwords. But again, I will leave the decision up to you.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion
(PBE) feature. At the moment we cannot apply both patches
simultaneously and I want a situation where we can continue work
independently.

Opinions ?

For the moment, perhaps they should coexist, disabled by default?

The overlapping area is password digesting. I stopped my work at the first time I examined your patch. Your patch modifies GeoserverUserDao which is gone after applying my patch. If we apply your patch, I have to rework mine and have to rollback most of your work concerning password digesting. Thats the reason why I proposed to make an isolated patch for store passwords.

Regards,
-Ian

Anyways, we have to wait until Andrea has reviewed my patch.
Cheers
Christian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

6

Ah ok, didn’t know, not in the GSOC loop. It sounds close so by all means I think it is appropriate to hold up the patch in order to synchronize up. Just was thinking that if it was still months away that it would make sense to go with the patch as is.

On Thu, Sep 1, 2011 at 12:41 AM, <christian.mueller@anonymised.com> wrote:

Zitat von Justin Deoliveira <jdeolive@anonymised.com>:

How close is your work to being commit ready Christian? Is there any sort of
timeline? If you plan to be in a position to commit work soon then I would
say it would make sense for Ian to hold back part of the patch, but if it is
still a while yet then imo it is not really fair to make him wait . Others
may disagree but generally from my experience it is the developer on the
longer term branch that has to carry the burden of merging after the fact,
and simply has to deal with changes that have happened in the interim.

The patch is the result from GSOC 2011 and is ready since about a week. I wait for Andrea as my mentor to review. My primary sorrow is that Ians patch introduces password digesting to GeoserverUserDoa/users.properties and after my patch is applied, an automatic migration from users properties takes place. For the new authentication concept(CAS, proxy authentication,…) I will have to rollback most of the Ians changes concerning user passwords, the job will not become easier.

Lets wait for Andreas review ?

$0.02

-Justin

On Tue, Aug 30, 2011 at 10:04 PM, <christian.mueller@anonymised.com> wrote:

Ian and me decided to open a thread on the developers list concerning

https://jira.codehaus.org/browse/GEOS-4702
https://jira.codehaus.org/browse/GEOS-4554

Each issue has a patch, unfortunately they are overlapping.

Ians patch has two major topics

a) Digesting passwords in the user.properties file
b) Encrypting passwords for geoserver stores

add a)
The user.properties file and the GeoserverUserDao are replaced by
UserGroupServices and GrantedAuthorityServices by my patch. It will be
possible to have more than one backend for users/groups. At the moment
I deferred password digesting since I am investigating into
authentication manager / authentication providers supporting CAS,proxy
authentication,password authentication and so on. Not every user has
to be authenticated by userid/password, nor has the user information
to be stored within a geoserver backend implementation.

add b)
This topic is unique to Ians patch. Some comments

I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism,
but it would be nice to have the possibility to inject the master key
using Spring.

I would prefer a md5/aes 128 encryption as default and would avoid DES
which is not state of the art and could be broken by brute force today
(only 56 Bit key length).

  1. Perhaps, there should be a possibility to turn this feature off
    after turning it on, not sure here.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion
(PBE) feature. At the moment we cannot apply both patches
simultaneously and I want a situation where we can continue work
independently.

Opinions ?

Cheers
Christian

This message was sent using IMP, the Internet Messaging Program.

Special Offer – Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you’ll get a free “Love Thy Logs” t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

This message was sent using IMP, the Internet Messaging Program.

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

7

Hi Ian, some additional comments.

Your patch uses jasypt 1.7.x, I tried with the latest version 1.8, works.

The xpath expression with quotes
"//entry[@key='passwd']"
works for me on oracle jdk 1.6 64 Bit and ibm jdk 1.6 64 Bit.

I plan to support http digest authentication, but this is not possible with digested passwords since the server needs the plaintext password for its calculations. An alternative is to encrypt user passwords if digest authentication is required. As a consequence, I need the master key too.

Cheers
Christian

Zitat von Ian Schneider <ischneider@anonymised.com>:

Hi Christian,

1)
I would use this concept for the master key
http://www.jasypt.org/webconfiguration.html
The default should be the GeoserverExtensiosns.getProperty mechanism,
but it would be nice to have the possibility to inject the master key
using Spring.

The web configuration could be an option, though I don't think people
will want that as the default as it requires a login to bootstrap the
server with the master password. I'm not sure of the advantage of
injecting the password via Spring over the other configuration
options. Can you elaborate?

2)
I would prefer a md5/aes 128 encryption as default and would avoid DES
which is not state of the art and could be broken by brute force today
(only 56 Bit key length).

This is the default and is configurable. Pluggable providers (bouncy
castle for instance) should be supported, too. Again, the primary goal
is to keep plaintext passwords from lying around. If an intruder has
physical access to the datastore files, there will be trouble beyond
the threat of brute force password cracking. For example, why use the
sqlserver password when you can just log in using the integrated
security? Or add a jar to the classpath that loads a component into
the spring context and grabs all of the decoded passwords from the
catalog. My point is, a determined intruder will be able to get the
password or access the systems somehow (spear-phishing?) - the goal is
to provide reasonable security. I agree that a default non-random
password is not reasonable security (will fix this) - this was left
over from when the system was enabled by default.

3) Perhaps, there should be a possibility to turn this feature off
after turning it on, not sure here.

The feature is opt-in so anyone enabling it should know what they are
doing. Recovery of the digested user passwords is not possible by
design.

Proposal:
Ian, do you see a possibility to reduce your patch to the encrpytion
(PBE) feature. At the moment we cannot apply both patches
simultaneously and I want a situation where we can continue work
independently.

Opinions ?

For the moment, perhaps they should coexist, disabled by default?

Regards,
-Ian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

8

On Thu, Sep 1, 2011 at 9:06 AM, <christian.mueller@anonymised.com> wrote:

Anyways, we have to wait until Andrea has reviewed my patch.

Sorry guys, I'm buried with work, I'll have a look during the weekend.

Anyways, regardless of the review we have two partially incompatible patches
ready to be committed, what needs to be done is an exercise in communication
and collaboration: you and Ian need to find a way to harmonize the two patches
so that they can coexist with minimal re-working on both sides.

It has been unfortunate that this did not pop up earlier and we need to learn
to talk more in the future, but now we need to find a solution with the less
possible damage on the work done so far.

I will review both patches during the weekend and try to come up with
suggestions,
but imho it's really about Christian and Ian finding a solution that suits both.
They say a good compromise is equally unsatisfactory for both parties, so try to
find one in that direction :wink:

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------