[Geoserver-devel] GSIP 57 - Improving GeoServer authorization framework

Hi,
following up last week mail I prepared a GSIP to improve the
authorization framework
built into the GeoServer catalog:
http://geoserver.org/display/GEOS/GSIP+57+-+Improving+GeoServer+authorization+framework

Opinions and votes welcomed!

Cheers
Andrea

PS:
Also, at GeoSolutions we spent a bit of time lately thinking about
security and wrote
down a tech report on the possible technologies to secure a geospatial
server, evaluating
pros and cons of each (including the all popular security proxy approach).
If you're curious about it you can find it here:
http://geo-solutions.blogspot.com/2010/12/developers-corner-improving-geoserver.html
http://demo.geo-solutions.it/share/securing_geoserver.pdf

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

+0 here


Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 349 82.27.000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
http://twitter.com/simogeo

On Mon, Dec 20, 2010 at 5:00 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
following up last week mail I prepared a GSIP to improve the
authorization framework
built into the GeoServer catalog:
http://geoserver.org/display/GEOS/GSIP+57±+Improving+GeoServer+authorization+framework

Opinions and votes welcomed!

Cheers
Andrea

PS:
Also, at GeoSolutions we spent a bit of time lately thinking about
security and wrote
down a tech report on the possible technologies to secure a geospatial
server, evaluating
pros and cons of each (including the all popular security proxy approach).
If you’re curious about it you can find it here:
http://geo-solutions.blogspot.com/2010/12/developers-corner-improving-geoserver.html
http://demo.geo-solutions.it/share/securing_geoserver.pdf


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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



Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d


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

I'm always keen to see enhancements to security features, and this
seems a solid step in the right direction. Can I just clarify that
backwards compatibility will be handled by wrapping implementations of
DataAccessManager (the compatibility section hasn't been updated from
the template).

--
Mark

On 21 December 2010 03:00, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
following up last week mail I prepared a GSIP to improve the
authorization framework
built into the GeoServer catalog:
http://geoserver.org/display/GEOS/GSIP+57+-+Improving+GeoServer+authorization+framework

Opinions and votes welcomed!

Cheers
Andrea

PS:
Also, at GeoSolutions we spent a bit of time lately thinking about
security and wrote
down a tech report on the possible technologies to secure a geospatial
server, evaluating
pros and cons of each (including the all popular security proxy approach).
If you're curious about it you can find it here:
http://geo-solutions.blogspot.com/2010/12/developers-corner-improving-geoserver.html
http://demo.geo-solutions.it/share/securing_geoserver.pdf

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Mark Leslie
Geospatial Software Architect
LISAsoft

-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------

LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com

Looks good Andrea. +1 with a couple of questions

1) The only wrinkle I can see is the use of List<Name> for VectorAccessLimits when used with app-schema xpaths.
2) I also wondered about the RasterLimits; do you not need a ParameterDescriptor in order to define the allowable range (sorry if I am rusty on the raster parameter stuff).

Jody

On 21/12/2010, at 3:00 AM, Andrea Aime wrote:

Hi,
following up last week mail I prepared a GSIP to improve the
authorization framework
built into the GeoServer catalog:
http://geoserver.org/display/GEOS/GSIP+57+-+Improving+GeoServer+authorization+framework

Opinions and votes welcomed!

Cheers
Andrea

PS:
Also, at GeoSolutions we spent a bit of time lately thinking about
security and wrote
down a tech report on the possible technologies to secure a geospatial
server, evaluating
pros and cons of each (including the all popular security proxy approach).
If you're curious about it you can find it here:
http://geo-solutions.blogspot.com/2010/12/developers-corner-improving-geoserver.html
http://demo.geo-solutions.it/share/securing_geoserver.pdf

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

looks like a good idea.

my first thought was how does this relate to GeoXACML - and I see you
have been thinking about this - is it possible to map out what
GeoXACML would require and how this proposal supports this? If I was
an expert in GeoXACML I'd do this myself - but I'd then be in the dark
about both ends of the equation.

I also note the similarity with the OpenStreerMap - where there are a
bunch of "tags" - i.e. standard attributes that have defined names and
domains, but users can add others. This leads to two possible future
extensions:
1) ability to tag (annotate) features with additional attributes not
in the schema
2) ability to constrain the range of an attribute - i.e. contributors
can set status = "proposed", but only editors can set
status="accepted"

List<Name> when its a list of attributes is an impedance mismatch -
its a list of attributes, so you want property names, not general
names, which should allow for schemas of complexity Simple Features
level 1 and above .

Rob

On Wed, Dec 22, 2010 at 7:02 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Looks good Andrea. +1 with a couple of questions

1) The only wrinkle I can see is the use of List<Name> for VectorAccessLimits when used with app-schema xpaths.
2) I also wondered about the RasterLimits; do you not need a ParameterDescriptor in order to define the allowable range (sorry if I am rusty on the raster parameter stuff).

Jody

On 21/12/2010, at 3:00 AM, Andrea Aime wrote:

Hi,
following up last week mail I prepared a GSIP to improve the
authorization framework
built into the GeoServer catalog:
http://geoserver.org/display/GEOS/GSIP+57+-+Improving+GeoServer+authorization+framework

Opinions and votes welcomed!

Cheers
Andrea

PS:
Also, at GeoSolutions we spent a bit of time lately thinking about
security and wrote
down a tech report on the possible technologies to secure a geospatial
server, evaluating
pros and cons of each (including the all popular security proxy approach).
If you're curious about it you can find it here:
http://geo-solutions.blogspot.com/2010/12/developers-corner-improving-geoserver.html
http://demo.geo-solutions.it/share/securing_geoserver.pdf

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months. Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+1 on the GSIP, as long as Mark’s backwards compatibility concerns are addressed, though I’m pretty sure they are. This sounds like a solid step towards an awesome security system.

Nice paper too, I’ll definitely be pointing people to it to explain why all the proxy projects aren’t that great. One thing you might consider in the paper is explicitly addressing the one advantage of a proxy - that you can secure many servers. I think with WMS and WFS cascading we now have a great answer to that, since you can back other servers on to the security settings. I like the idea of the WMSLimits being passed back to other GeoServers, so that if someone were to use a GeoServer as a pure proxy it’d be smarter than other GeoServers.

Maybe sometime we should strip out all the other functionality from GeoServer and just have WMS/WFS datastores + security enabled and announce the new ‘GS Secure Proxy Project’ :wink:

On Mon, Dec 20, 2010 at 8:00 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
following up last week mail I prepared a GSIP to improve the
authorization framework
built into the GeoServer catalog:
http://geoserver.org/display/GEOS/GSIP+57±+Improving+GeoServer+authorization+framework

Opinions and votes welcomed!

Cheers
Andrea

PS:
Also, at GeoSolutions we spent a bit of time lately thinking about
security and wrote
down a tech report on the possible technologies to secure a geospatial
server, evaluating
pros and cons of each (including the all popular security proxy approach).
If you’re curious about it you can find it here:
http://geo-solutions.blogspot.com/2010/12/developers-corner-improving-geoserver.html
http://demo.geo-solutions.it/share/securing_geoserver.pdf


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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



Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d


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

On Tue, Dec 21, 2010 at 9:02 PM, Jody Garnett <jody.garnett@…403…> wrote:

Looks good Andrea. +1 with a couple of questions

  1. The only wrinkle I can see is the use of List for VectorAccessLimits when used with app-schema xpaths.

Ah, yeah, sounds like a good idea. Wondering, is Name good enough?
Does it have enough namespace context?

  1. I also wondered about the RasterLimits; do you not need a ParameterDescriptor in order to define the allowable range (sorry if I am rusty on the raster parameter stuff).

A reader takes an array of GeneralParameterValue, so no descriptors.
Confluence is unreachable so I cannot verify, but I may have to change
that array of params to GeneralParameterValue (I think I used ParameterValue instead)

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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


On Tue, Dec 21, 2010 at 6:10 AM, Mark Leslie <mrk.leslie@anonymised.com3…> wrote:

I’m always keen to see enhancements to security features, and this
seems a solid step in the right direction. Can I just clarify that
backwards compatibility will be handled by wrapping implementations of
DataAccessManager (the compatibility section hasn’t been updated from
the template).

Good catch. I’ll add that as soon as confluence is back up and running

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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


On Tue, Dec 21, 2010 at 10:10 PM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

looks like a good idea.

my first thought was how does this relate to GeoXACML - and I see you
have been thinking about this - is it possible to map out what
GeoXACML would require and how this proposal supports this? If I was
an expert in GeoXACML I’d do this myself - but I’d then be in the dark
about both ends of the equation.

I’m actually no expert at GeoXACML, I mostly gathered Christian feedback
about what he needed to implement GeoXACML support in the catalog
security and fed it into the proposal

Last time I looked at GeoXACML I had a headache for two days, the specification
is massive.
We already created a generation of poor SLD writers banging their heads and
frustration at a blank xml editor trying to get something visual out of it,
I’d really would not like to do the same mistake with security, SLD specification
is a picnic to read, understand and use compared to XACML + GeoXACML
So I would like to make a GeoXACML plugin possible, but also keep it very
out of the way of core, and have only those that really need its fully power
to wield that nuke.

I also note the similarity with the OpenStreerMap - where there are a
bunch of “tags” - i.e. standard attributes that have defined names and
domains, but users can add others. This leads to two possible future
extensions:

  1. ability to tag (annotate) features with additional attributes not
    in the schema
  2. ability to constrain the range of an attribute - i.e. contributors
    can set status = “proposed”, but only editors can set
    status=“accepted”

List when its a list of attributes is an impedance mismatch -
its a list of attributes, so you want property names, not general
names, which should allow for schemas of complexity Simple Features
level 1 and above .

I lost you there. Is List good enough or do you think we need
something else, and if so, what?

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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


On Tue, Dec 21, 2010 at 11:33 PM, Chris Holmes <cholmes@anonymised.com501…> wrote:

+1 on the GSIP, as long as Mark’s backwards compatibility concerns are addressed, though I’m pretty sure they are. This sounds like a solid step towards an awesome security system.

Yep yep, definitely want to keep backwards compatibility, in fact the default security config implemetation
won’t be changed one bit, the proposal is to make a more powerful security possible, so
we are going to add all the machinery to make it possible but the default implementation
of ResourceAccessManager will back onto the existing implementation, meaning it won’t leverage
per row or attribute filters.

The implementation we’re getting funded for is going to integrate with a in-house external security
manager using SOAP services to communicate with it, so it’s not something we can contribute back,
however these changes should ease up both improving the GS built-in authorization system later
or pluggin in others.

Nice paper too, I’ll definitely be pointing people to it to explain why all the proxy projects aren’t that great. One thing you might consider in the paper is explicitly addressing the one advantage of a proxy - that you can secure many servers. I think with WMS and WFS cascading we now have a great answer to that, since you can back other servers on to the security settings. I like the idea of the WMSLimits being passed back to other GeoServers, so that if someone were to use a GeoServer as a pure proxy it’d be smarter than other GeoServers.

Cool, will add it to the document

Maybe sometime we should strip out all the other functionality from GeoServer and just have WMS/WFS datastores + security enabled and announce the new ‘GS Secure Proxy Project’ :wink:

Ha, yeah, why not. The WFS proxying would be pretty powerful as we’d be able to parse and
chew the data, WMS proxying would not be much better than the existing ones though,
as wms cascading would unfortunately just get back an image…

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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


On 22 December 2010 20:36, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Dec 21, 2010 at 6:10 AM, Mark Leslie <mrk.leslie@anonymised.com> wrote:

I'm always keen to see enhancements to security features, and this
seems a solid step in the right direction. Can I just clarify that
backwards compatibility will be handled by wrapping implementations of
DataAccessManager (the compatibility section hasn't been updated from
the template).

Good catch. I'll add that as soon as confluence is back up and running
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

With that update, I'm a very happy +1.

+0

Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

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

On Thu, Dec 23, 2010 at 12:34 AM, Mark Leslie <mrk.leslie@anonymised.com> wrote:

On 22 December 2010 20:36, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Dec 21, 2010 at 6:10 AM, Mark Leslie <mrk.leslie@anonymised.com> wrote:

I'm always keen to see enhancements to security features, and this
seems a solid step in the right direction. Can I just clarify that
backwards compatibility will be handled by wrapping implementations of
DataAccessManager (the compatibility section hasn't been updated from
the template).

Good catch. I'll add that as soon as confluence is back up and running
Cheers
Andrea
-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

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

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

With that update, I'm a very happy +1.

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel