[Geoserver-devel] [Geotools-devel] Geoserver GSOC 2009

Andrea_Aime3 · March 13, 2009, 10:23am

Christian Müller ha scritto:

Jody I have not a seen a page for project proposals for geoserver.
(or should we use the one created for geotools).

I am not sure at the moment, but I have an idea doing a GeoXACML implementation which could deployed in geoserer as a servlet filter.

The idea of a GEOXAML driven security subsystem is certainly
a very good one, I would be interested in mentoring you in this one.

However, I would rather suggest not to implement it as a servlet
filter. There are quite some good reasons to avoid it:
- it has to replicate part of the work GeoServer is already doing
   (the request parsing)
- it is limited to the kind of request it can parse (say tomorrow
   we add WPS, or a restful WFS, or just SOAP request types for
   the existing services)

You have two lower level options at your disposal:
- a dispatcher plugin, that receives the requests in a parsed
   form already. Yet, that still requires you to know all the
   possible kinds of requests (just skips the parsing machinery)
- a geoserver security subsystem plugin, replacing the current
   DataAccessManager implementation with a custom one that is
   driven by GEOXAML directives

I cannot find much information about GEOXAML, and XAML itself
it huge, so it's likely that you'll find some limitations in
the current security subsystem extension points, but I can
work along with you and make the necessary changes to allow
a GEOXAML driven plugin to work at its full potential.

Interested?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Christian_Mueller · March 13, 2009, 3:57pm

Yep, working with you would make fun. And btw, it would make sense

First I have to say that I have looked for a proper OSS project. I decided to use SUNs XACML implementation as a base.
Since GeoXACML fits to a proxy architecture, I contacted some guys from the openSSO project, which is also driven by SUN.
Another reason was that openSSO has SAML support.

I had some EMail exchange with SUN guys and the result was

1) openSSO supports only XACML request/response but no handling of XACML policies
2) They will integrate SUN XACML in the future
3) After I described my expectations how SUN has to support me, there is a big silence

I think it is better and faster to do the work for geoserver.

The architecture:

The 2 main components are the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP).

PDP
The PDP should be a stand alone component, based on SUNs XACML, using JTS and CRS stuff from geotools (otherwise I would be my own enemy)
This is possible because the PDP gets (Geo)XACML reqeuests, uses (Geo)XACML policies and responds with (Geo)XACML responses. It should be further possible to deploy the PDP without geoserver.

PEP
This one could be geoserver specific. Creating the XACML request, querying the PDP and acting on the XACML response, that's it.

Later on, we can think about 2 important components.
1) PAP (Policy Administration Point), where the user can define its policies which is not so easy.
2) Do a SAML integration (openSAML)

christian

Andrea Aime writes:

Christian Müller ha scritto:

Jody I have not a seen a page for project proposals for geoserver.
(or should we use the one created for geotools).

I am not sure at the moment, but I have an idea doing a GeoXACML implementation which could deployed in geoserer as a servlet filter.

The idea of a GEOXAML driven security subsystem is certainly
a very good one, I would be interested in mentoring you in this one.

However, I would rather suggest not to implement it as a servlet
filter. There are quite some good reasons to avoid it:
- it has to replicate part of the work GeoServer is already doing
  (the request parsing)
- it is limited to the kind of request it can parse (say tomorrow
  we add WPS, or a restful WFS, or just SOAP request types for
  the existing services)

You have two lower level options at your disposal:
- a dispatcher plugin, that receives the requests in a parsed
  form already. Yet, that still requires you to know all the
  possible kinds of requests (just skips the parsing machinery)
- a geoserver security subsystem plugin, replacing the current
  DataAccessManager implementation with a custom one that is
  driven by GEOXAML directives

I cannot find much information about GEOXAML, and XAML itself
it huge, so it's likely that you'll find some limitations in
the current security subsystem extension points, but I can
work along with you and make the necessary changes to allow
a GEOXAML driven plugin to work at its full potential.

Interested?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime3 · March 13, 2009, 4:15pm

Christian Müller ha scritto:

Yep, working with you would make fun. And btw, it would make sense
First I have to say that I have looked for a proper OSS project. I decided to use SUNs XACML implementation as a base.
Since GeoXACML fits to a proxy architecture, I contacted some guys from the openSSO project, which is also driven by SUN.
Another reason was that openSSO has SAML support.
I had some EMail exchange with SUN guys and the result was
1) openSSO supports only XACML request/response but no handling of XACML policies
2) They will integrate SUN XACML in the future
3) After I described my expectations how SUN has to support me, there is a big silence

Well, I'm not surprised, they have their hands full already (Sun has
been cutting jobs quite a bit lately).

I think it is better and faster to do the work for geoserver.
The architecture:
The 2 main components are the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP).
PDP
The PDP should be a stand alone component, based on SUNs XACML, using JTS and CRS stuff from geotools (otherwise I would be my own enemy)
This is possible because the PDP gets (Geo)XACML reqeuests, uses (Geo)XACML policies and responds with (Geo)XACML responses. It should be further possible to deploy the PDP without geoserver.

If I read this correctly, the PDP is the component that decides
what you can and cannot do based on the current user roles and
the resource he's trying to access. This is the DataAccessManager
in GeoServer, see the DefaultDataAccessManager that is based
on the simple layers.properties security file.

PEP
This one could be geoserver specific. Creating the XACML request, querying the PDP and acting on the XACML response, that's it.
Later on, we can think about 2 important components.
1) PAP (Policy Administration Point), where the user can define its policies which is not so easy.
2) Do a SAML integration (openSAML)

Hmmm... looking at the spec it seems PDP and PEP can be two
separate services talking with each other using XML requests?
This seems overkill to me?
Anyways, the closest equivalent of the PEP in GeoServer is
the SecureCatalog, which in fact uses the DataAccessManager
extension point to allow for a pluggable authorization mechanism.
Your DataAccessManager implementation could talk to the
standalone PDP if you like, but I would very much like the
option of an integrated PDP, extra network requests make
the system more fragile and slower.

Ah, another thing, the way the security it's implemented
is totally transparent to dispatching and to the services,
but requires some extra work at the catalog level.
Basically, to make a vector example, the secure catalog
takes the raw feature sources and encapsulate them with
secured wrappers that will eventually throw security
exceptions if the service code tries to do something
the user is not authorized to (say, for example, writing).
So basically you either ask the PEP what the user can
do in advance given a certain layer, or you'll be
forced to make wrappers that made PDP requests each
time a method is called. Scale this to a situation
in which you're trying to control row level access and
you have a very secure but mostly unusable system
(think one PDP request per feature, oh my,
the very idea makes me sick).

If on the contrary the PDP is integrated you can inspect
the rules and know that the user can do in advance
(and turn that knowledge in a set of filters against
data).

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Christian_Mueller · March 16, 2009, 3:10pm

Hi Andrea

Thanks for your essay about security systems. The best will be to first implement a PDP and afterwards we will do the PEP.

Some questions

1) Should I start in the community directory of the 1.7.x brach, making a project "geoxacml" ?

2) Do you have a wish about the package names ?

3) Where should we put the announcement for GSOC 2009

4) Since we depend on sun xacml, here is the short license http://sunxacml.sourceforge.net/license.txt
I found a bug in the sun xacml implementation which I hat to fix (I created an official bug report). In this case, we have to package our own sun xacml jar file. Is this possible ? And how do we get this jar file in the mvn build ?.

christian

Justin_Deoliveira · March 16, 2009, 3:18pm

Christian Müller wrote:

Hi Andrea

Thanks for your essay about security systems. The best will be to first implement a PDP and afterwards we will do the PEP.

Some questions

1) Should I start in the community directory of the 1.7.x brach, making a project "geoxacml" ?

We have more or less moved 1.7.x to bug fixing only.. so trunk may be a more suitable place. However if no changes to the gs itself will be required then 1.7.x will work ok.

2) Do you have a wish about the package names ?

"org.geoserver.geoxacml" ?

3) Where should we put the announcement for GSOC 2009

I started a wiki page here:

http://geoserver.org/display/GEOS/Summer+of+Code+2009

Would be good if this project was listed there. Not sure what else you mean by "announcement"

4) Since we depend on sun xacml, here is the short license http://sunxacml.sourceforge.net/license.txt
I found a bug in the sun xacml implementation which I hat to fix (I created an official bug report). In this case, we have to package our own sun xacml jar file. Is this possible ? And how do we get this jar file in the mvn build ?.

The license would seem to permit redistribution. So it would be easy enough to deploy the changed lib in the opengeo maven repository.

christian

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
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.