[Geoserver-devel] Security improvements

GeoServer GeoServer Developer
1

Hello everyone,

I am currently having a look at what needs to happen to implement some additional features and improvements in the security system.

The first thing is making rules that combine layers and services, which is now impossible.
This seems like a pretty straight-forward improvement to me, but it will require quite some changes in the main module. A discussion with the people involved is going to be necessary. I was wondering though if there are any unexpected issues or loopholes about this I should be aware of? Perhaps a reason why people chose not to implement it earlier?

The other thing is that apparently there is a security leak through the GeoWebCache. An integration of geoserver security with GWC is needed. There is already a JIRA issue about this:
http://jira.codehaus.org/browse/GEOS-4217
It seems that people might have worked on this already or looked in to it in the past, so I would like to get in touch with these people, or any other people who need to be involved, if possible.

Kind Regards
Niels

2

Hi Niels

Beyond combining layer and services there are additional wishes & requirements. A customer of me wants to restrict access to formats, e. g. prohibit getMap requests using SVG.

I would vote for a powerful access control engine like (GEO) XACML. Some years ago I did a summer of code project mentored by Andrea concerning GEOXACML integration but due to lack of time, we did not finish. (The code is still a community module).

XACML is quite powerful and it is a standard. As a first step, I would prefer to switch from our property files to one XACML file without changing the current functionality. After this, we could enhance access control.

Anyways, this is quite an effort and I hope to find somebody funding this work.

Cheers
Christian

···

2013/6/11 Niels Charlier <niels@anonymised.com>

Hello everyone,

I am currently having a look at what needs to happen to implement some
additional features and improvements in the security system.

The first thing is making rules that combine layers and services, which
is now impossible.
This seems like a pretty straight-forward improvement to me, but it will
require quite some changes in the main module. A discussion with the
people involved is going to be necessary. I was wondering though if
there are any unexpected issues or loopholes about this I should be
aware of? Perhaps a reason why people chose not to implement it earlier?

The other thing is that apparently there is a security leak through the
GeoWebCache. An integration of geoserver security with GWC is needed.
There is already a JIRA issue about this:
http://jira.codehaus.org/browse/GEOS-4217
It seems that people might have worked on this already or looked in to
it in the past, so I would like to get in touch with these people, or
any other people who need to be involved, if possible.

Kind Regards
Niels

This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

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

–

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

3

On Wed, Jun 12, 2013 at 10:21 AM, Christian Mueller <
christian.mueller@anonymised.com> wrote:

Hi Niels

Beyond combining layer and services there are additional wishes &
requirements. A customer of me wants to restrict access to formats, e. g.
prohibit getMap requests using SVG.

I would vote for a powerful access control engine like (GEO) XACML. Some
years ago I did a summer of code project mentored by Andrea concerning
GEOXACML integration but due to lack of time, we did not finish. (The code
is still a community module).

XACML is quite powerful and it is a standard. As a first step, I would
prefer to switch from our property files to one XACML file without changing
the current functionality. After this, we could enhance access control.

While I'm not opposed to XACML per se, I'm rather worried about it's
complexity, a 3 lines property file equates to 100-200 loc of XACML, so any
movement in that direction should be followed by a proper GUI development
hiding the XACML complexity to the user, otherwise we'll end up with a
situation similar to app-schema, powerful but people often just end up
pulling hairs and looking for alternatives because they cannot get its
configuration right.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

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

4

The idea is to have an XACML engine for the developers, not for the users. The user never should configure XACML directly (I am not an enemy of my own).

Christian

···

2013/6/12 Andrea Aime <andrea.aime@anonymised.com>

On Wed, Jun 12, 2013 at 10:21 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:

–

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Niels

Beyond combining layer and services there are additional wishes & requirements. A customer of me wants to restrict access to formats, e. g. prohibit getMap requests using SVG.

I would vote for a powerful access control engine like (GEO) XACML. Some years ago I did a summer of code project mentored by Andrea concerning GEOXACML integration but due to lack of time, we did not finish. (The code is still a community module).

XACML is quite powerful and it is a standard. As a first step, I would prefer to switch from our property files to one XACML file without changing the current functionality. After this, we could enhance access control.

While I’m not opposed to XACML per se, I’m rather worried about it’s complexity, a 3 lines property file equates to 100-200 loc of XACML, so any movement in that direction should be followed by a proper GUI development hiding the XACML complexity to the user, otherwise we’ll end up with a situation similar to app-schema, powerful but people often just end up pulling hairs and looking for alternatives because they cannot get its configuration right.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

5

I agree with Andrea that i would be weary of complexity here, even if we do try to hide it from users. We took this approach with the authentication changes and imo it is not all that user friendly compared to other systems that offer similar authentication options.

Unless you spend a lot of time designing the user interface up front undoubtedly development complexity will creep through. Case in point: currently the user needs to know what user group and role services are. For power users this may not be an issue, they probably like the flexibility, but for the average user it’s confusing.

···

On Wed, Jun 12, 2013 at 3:20 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:

The idea is to have an XACML engine for the developers, not for the users. The user never should configure XACML directly (I am not an enemy of my own).

Christian

This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

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.

2013/6/12 Andrea Aime <andrea.aime@anonymised.com>

On Wed, Jun 12, 2013 at 10:21 AM, Christian Mueller <christian.mueller@anonymised.com> wrote:

–

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hi Niels

Beyond combining layer and services there are additional wishes & requirements. A customer of me wants to restrict access to formats, e. g. prohibit getMap requests using SVG.

I would vote for a powerful access control engine like (GEO) XACML. Some years ago I did a summer of code project mentored by Andrea concerning GEOXACML integration but due to lack of time, we did not finish. (The code is still a community module).

XACML is quite powerful and it is a standard. As a first step, I would prefer to switch from our property files to one XACML file without changing the current functionality. After this, we could enhance access control.

While I’m not opposed to XACML per se, I’m rather worried about it’s complexity, a 3 lines property file equates to 100-200 loc of XACML, so any movement in that direction should be followed by a proper GUI development hiding the XACML complexity to the user, otherwise we’ll end up with a situation similar to app-schema, powerful but people often just end up pulling hairs and looking for alternatives because they cannot get its configuration right.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

6

On Wed, Jun 12, 2013 at 4:37 PM, Justin Deoliveira <jdeolive@anonymised.com>wrote:

I agree with Andrea that i would be weary of complexity here, even if we
do try to hide it from users. We took this approach with the authentication
changes and imo it is not all that user friendly compared to other systems
that offer similar authentication options.

Unless you spend a lot of time designing the user interface up
front undoubtedly development complexity will creep through. Case in point:
currently the user needs to know what user group and role services are. For
power users this may not be an issue, they probably like the flexibility,
but for the average user it's confusing.

Agreed, make a workshop recently and people were confused by the many
options available (why are there multiple services, why are role services
separate, why is LDAP showing up in multiple places and so on): for a power
user it makes sense, but for the common one it's a maze to get lost in.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

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

7

Two topics here :slight_smile:

About access control. I worked with SUNs XACML implementation and it has a very good Java API. It is not necessary to bother about the XML stuff, the library does it behind the scenes. The only thing I wanted to point out is that if we add access control features we should discuss the current access control system. (I am not insisting on XACML, but it is powerful).

About security system confusion. What about packaging the LDAP and JDBC stuff as an extension ?. And yes, the documentation is not finished and some docs are not up to date. I am working on this in my spare time if possible.

Cheers
Christilan

···

2013/6/12 Andrea Aime <andrea.aime@anonymised.com1268…>

On Wed, Jun 12, 2013 at 4:37 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

–

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

I agree with Andrea that i would be weary of complexity here, even if we do try to hide it from users. We took this approach with the authentication changes and imo it is not all that user friendly compared to other systems that offer similar authentication options.

Unless you spend a lot of time designing the user interface up front undoubtedly development complexity will creep through. Case in point: currently the user needs to know what user group and role services are. For power users this may not be an issue, they probably like the flexibility, but for the average user it’s confusing.

Agreed, make a workshop recently and people were confused by the many options available (why are there multiple services, why are role services separate, why is LDAP showing up in multiple places and so on): for a power user it makes sense, but for the common one it’s a maze to get lost in.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

8

All right. Thanks for the advice.

For now I'm trying to estimate what is needed for just the upgrades I mentioned earlier.
The client is initially interested in having the ability to specify rules on layers with services combined.
I don't think if changing the whole system first is an option here in terms of funding.

On the other side of course, it would be stupid to make changes that will be redone completely later anyway.
And of course changes like this must be supported by the community beforehand.

With all these things in mind, what do you think is the best approach here.
How does everyone think of the idea of extending the current security system with this feature ? Would such a proposal pass? Are there any other concerns I should be aware of?

Cheers
Niels

On 12/06/13 17:56, Christian Mueller wrote:

Two topics here :slight_smile:

About access control. I worked with SUNs XACML implementation and it has a very good Java API. It is not necessary to bother about the XML stuff, the library does it behind the scenes. The only thing I wanted to point out is that if we add access control features we should discuss the current access control system. (I am not insisting on XACML, but it is powerful).

About security system confusion. What about packaging the LDAP and JDBC stuff as an extension ?. And yes, the documentation is not finished and some docs are not up to date. I am working on this in my spare time if possible.

Cheers
Christilan

2013/6/12 Andrea Aime <andrea.aime@anonymised.com <mailto:andrea.aime@anonymised.com>>

    On Wed, Jun 12, 2013 at 4:37 PM, Justin Deoliveira
    <jdeolive@anonymised.com <mailto:jdeolive@anonymised.com>> wrote:

        I agree with Andrea that i would be weary of complexity here,
        even if we do try to hide it from users. We took this approach
        with the authentication changes and imo it is not all that
        user friendly compared to other systems that offer similar
        authentication options.

        Unless you spend a lot of time designing the user interface up
        front undoubtedly development complexity will creep through.
        Case in point: currently the user needs to know what user
        group and role services are. For power users this may not be
        an issue, they probably like the flexibility, but for the
        average user it's confusing.

    Agreed, make a workshop recently and people were confused by the
    many options available (why are there multiple services, why are
    role services separate, why is LDAP showing up in multiple places
    and so on): for a power user it makes sense, but for the common
    one it's a maze to get lost in.

    Cheers
    Andrea

    -- ==
    Our support, Your Success! Visit http://opensdi.geo-solutions.it
    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 <tel:%2B39%200584%20962313>
    fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
    mob: +39 339 8844549 <tel:%2B39%20%C2%A0339%208844549>

    http://www.geo-solutions.it
    http://twitter.com/geosolutions_it

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

--
DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

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

9

On Wed, Jun 12, 2013 at 11:49 PM, Niels Charlier <niels@anonymised.com> wrote:

With all these things in mind, what do you think is the best approach
here.
How does everyone think of the idea of extending the current security
system with this feature ? Would such a proposal pass? Are there any other
concerns I should be aware of?

Personally not against extending the existing one.

However I'd like to toss in one more data point. Geosolutions is going to
release, in the next few days GeoFence, a open source advanced security
plugin for GeoServer (plus stand alone rule config application) that has
several interesting features, including the ones you're looking at:
* setup rules mixing user/roles, services request and data
* rule setup and evaluation following an iptables style (first one matching
wins)
* filter returned data based on CQL filters (including thus spatial
filtering, but not limited to it)
* reduce the number of returned attributes
* cut raster data on a specified geometry
* force a specific layer style based on the current user

This old blog post talks a bit about it, with some screenshots (it still
refers to it as GeoRepository, its old name).
http://geo-solutions.blogspot.it/2011/05/preview-georepository-advanced.html

The git repo should be opened up in the next few days, have a look at:
https://github.com/geosolutions-it

I'll let you know when the public release is done

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

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

10

Hello Andrea,

That actually seems to be what they are looking for, filter based security was another thing they are interested in.

How would this plugin integrate with GeoWebCache?

Cheers
Niels

On 14/06/13 10:44, Andrea Aime wrote:

On Wed, Jun 12, 2013 at 11:49 PM, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:

    With all these things in mind, what do you think is the best
    approach here.
    How does everyone think of the idea of extending the current
    security system with this feature ? Would such a proposal pass?
    Are there any other concerns I should be aware of?

Personally not against extending the existing one.

However I'd like to toss in one more data point. Geosolutions is going to release, in the next few days GeoFence, a open source advanced security plugin for GeoServer (plus stand alone rule config application) that has several interesting features, including the ones you're looking at:
* setup rules mixing user/roles, services request and data
* rule setup and evaluation following an iptables style (first one matching wins)
* filter returned data based on CQL filters (including thus spatial filtering, but not limited to it)
* reduce the number of returned attributes
* cut raster data on a specified geometry
* force a specific layer style based on the current user

This old blog post talks a bit about it, with some screenshots (it still refers to it as GeoRepository, its old name).
http://geo-solutions.blogspot.it/2011/05/preview-georepository-advanced.html

The git repo should be opened up in the next few days, have a look at:
https://github.com/geosolutions-it

I'll let you know when the public release is done

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

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

11

On Fri, Jun 14, 2013 at 2:45 PM, Niels Charlier <niels@anonymised.com> wrote:

Hello Andrea,

That actually seems to be what they are looking for, filter based security
was another thing they are interested in.

How would this plugin integrate with GeoWebCache?

It would not, the plugin just uses the GeoServer authorization engine,
which in turn only works when you actually
access data, once tiles are cached there is no way to stop GWC.

Or else, there would be I guess... there is a notion of a tile filter in
GWC (can't quite remember its name), you could
use it to decide whether the tile is authorized or not.

Now, mixing data based filters and caching poses some interesting issues
though... basically the current user
becomes yet another param on which you have to split tile caches, as one
user view of the data is different
from the others.
Generally speaking users with the same roles should be able to see them
same contents, but a security
subsystem is free to override that on a user by user basis (beyond their
roles)
so... uh... things get really complicated at that point....

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

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