[Geoserver-users] GSIP 16, Geoserver security. Feedback required

Hi all,
during the last week I did some research and implemented a prototype
of secured Geoserver on a branch.

I've created a tracking GSIP here:
http://docs.codehaus.org/display/GEOS/GSIP+16+-+Security+subsystem

Most of the information is here thought:
http://docs.codehaus.org/display/GEOSDEV/Geoserver+authentication+and+authorization+subsystem
http://docs.codehaus.org/display/GEOSDEV/Geoserver+security+prototype

Now it's feedback time. Tell us what you think about it.
Cheers
Andrea

:slight_smile: Can I ask for a class diagram (this may be a trick question - since I am sure you will use spring aspects?)...

JAAS - requirement to use files may kill me in a clustered environment
DACS - hard one, nice that WMS specific work examples exist but I agree that it is not ready, more useful to see how to pass credentials between cascading WMS or WFS instances
Seraph - seems hard to get into
jGuard - have not met this one
Acegi - I have heard of this one

Question on the integration front - are we going to serve up different capabilities documents based per user (or rather per user roll?) Or are you mostly looking to enable/disable the abilities of the Transaction operation (some users can insert but not delete etc....).

Do any of these recommendations boil down to an access control list against the data objects? Could we handle a data security audit...

Cheers,
Jody

Hi all,
during the last week I did some research and implemented a prototype
of secured Geoserver on a branch.

I've created a tracking GSIP here:
http://docs.codehaus.org/display/GEOS/GSIP+16+-+Security+subsystem

Most of the information is here thought:
http://docs.codehaus.org/display/GEOSDEV/Geoserver+authentication+and+authorization+subsystem
http://docs.codehaus.org/display/GEOSDEV/Geoserver+security+prototype

Now it's feedback time. Tell us what you think about it.
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
geoserver-devel List Signup and Options
  

Do note that our initial needs for the security framework are _very_ modest - the main motivation is to make it so versioning wfs always has a user to credit changes to. But we are interested in hearing what people want to eventually do this crazy security stuff, since we're hoping to pick a framework that will support that, eventually.

Chris

Jody Garnett wrote:

:slight_smile: Can I ask for a class diagram (this may be a trick question - since I am sure you will use spring aspects?)...

JAAS - requirement to use files may kill me in a clustered environment
DACS - hard one, nice that WMS specific work examples exist but I agree that it is not ready, more useful to see how to pass credentials between cascading WMS or WFS instances
Seraph - seems hard to get into
jGuard - have not met this one
Acegi - I have heard of this one

Question on the integration front - are we going to serve up different capabilities documents based per user (or rather per user roll?) Or are you mostly looking to enable/disable the abilities of the Transaction operation (some users can insert but not delete etc....).

Do any of these recommendations boil down to an access control list against the data objects? Could we handle a data security audit...

Cheers,
Jody

Hi all,
during the last week I did some research and implemented a prototype
of secured Geoserver on a branch.

I've created a tracking GSIP here:
http://docs.codehaus.org/display/GEOS/GSIP+16+-+Security+subsystem

Most of the information is here thought:
http://docs.codehaus.org/display/GEOSDEV/Geoserver+authentication+and+authorization+subsystem
http://docs.codehaus.org/display/GEOSDEV/Geoserver+security+prototype

Now it's feedback time. Tell us what you think about it.
Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Jody Garnett ha scritto:

:slight_smile: Can I ask for a class diagram (this may be a trick question - since I am sure you will use spring aspects?)...

Whoa, lots of questions :slight_smile:
Yeah, I'm going to use mostly aspects of some kind, so hard to make a class digram. The authentication is totally handled by using web filters
configured in a 200 lines spring config file.
The authorization on the web console requires a ROLE_ADMINISTRATOR role,
and it's configured again in that file.
The authorization on service access (service + method) is handled in a
sort of aspect (called operation interceptor) within the dispatcher.
The same will go for the data access level, something going withing
the Data class (will be handled in the catalog, anyways).

JAAS - requirement to use files may kill me in a clustered environment
DACS - hard one, nice that WMS specific work examples exist but I agree that it is not ready, more useful to see how to pass credentials between cascading WMS or WFS instances

DACS is basically no go from a java app point of view as far as I can see.
Anyways, if the credentials are just username/password we can replicate the http headers, but this works only if the user is the same in the two
servers. Hard case imho.

Seraph - seems hard to get into
jGuard - have not met this one
Acegi - I have heard of this one

Question on the integration front - are we going to serve up different capabilities documents based per user (or rather per user roll?) Or are you mostly looking to enable/disable the abilities of the Transaction operation (some users can insert but not delete etc....).

Yeah, that was the idea. If we set up data level security, the feature
types that Data will provide will be different depending on the user
credentials. We may limit the ft you may see, edit, or shave them
so that you see less attributes or less features.

Do any of these recommendations boil down to an access control list against the data objects? Could we handle a data security audit...

I would like to limit the default implementation to RBAC (role based access control) instead of using ACL. ACL are harder to deal with,
RBAC seems to provide a good balance between manageability and power.
Anyways, Spring does support ACL too, it's just a matter of configuring
a different user details provider and a different set of voters for
access control (that is, it's orthogonal to the code that actually
integrates into Data and Dispatcher).

Cheers
Andrea

Hello Andrea,

Andrea Aime <aaime@anonymised.com>, [20070502 - 12:18:36]

Hi all,
during the last week I did some research and implemented a prototype
of secured Geoserver on a branch.

I've created a tracking GSIP here:
http://docs.codehaus.org/display/GEOS/GSIP+16+-+Security+subsystem

Most of the information is here thought:
http://docs.codehaus.org/display/GEOSDEV/Geoserver+authentication+and+authorization+subsystem
http://docs.codehaus.org/display/GEOSDEV/Geoserver+security+prototype

Now it's feedback time. Tell us what you think about it.

While reading your email I thought about the OWSProxy-framework which
ships with deegree[1]. There is a role-based user-management which
implements a layer-based security for OWS-services (WMS, WFS, WFS-T,
WFS-G). Apart from that you could use Geoserver as a WFS behind this
security-proxy as well.

This can be secured through https access and using the client-program
InteProxy[2] which handels the user-management and transparent
security proxying on the client side (e.g. when using *JUMP, UDIG).

Perhaps everything is there you need for your security-framework?

Just my thoughts,

Best regards

  Stephan Holl

[1] http://www.deegree.org
[2] http://inteproxy.wald.intevation.org

--
Stephan Holl <stephan.holl@anonymised.com>, http://intevation.de/~stephan
Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Stephan Holl ha scritto:

While reading your email I thought about the OWSProxy-framework which
ships with deegree[1]. There is a role-based user-management which
implements a layer-based security for OWS-services (WMS, WFS, WFS-T,
WFS-G). Apart from that you could use Geoserver as a WFS behind this
security-proxy as well.

This can be secured through https access and using the client-program
InteProxy[2] which handels the user-management and transparent
security proxying on the client side (e.g. when using *JUMP, UDIG).

Perhaps everything is there you need for your security-framework?

Heh, I guess one day I should really stop hacking Geoserver like crazy
and have a look around in the Degree world.

I looked a bit at inteproxy and OWSProxy and they look nice, and practical too, good way to add security in a world that has so far
neglected it completely.

Yet, no, it does not fit my bill. The main driver for adding a security
framework to Geoserver (besides beying ashamed of not having one) is
that for WFS-V (versioning WFS) I need to know who's the user that's
accessing Geoserver to mark the commit record with the user name.
Having an external solution handling security does not allow for that.
Besides that, I want to play with standard security protocols.

Yet, iGeoSecurity seems to have a good design and offers lots, so
I'll at least try to reuse some of the ideas.

Geoserver 1.6.x will ship with HTTP basic authentication (on the service level), but will allow integrators to leverage the full stack of Acegi
authentication modules, which provide for digest, certificate based, or
CAS credential providing, as well as a ton of authentication backends
(file, database, operating system, LDAP, and others).

Using InteProxy would be interesting since, as iGeoSecurity and
inteproxy both point out, most clients do not know about security at all. Would it be possible to make InteProxy work against the HTTP
basic authentication protocol? Otherwise, I guess writing an Acegi
authenticator that can the user/password GET parameters would not
be difficult, thought I'm not sure how would that play with
POST based requests (we handle mixed GET/POST requests in the WMS layer
but it's a bit messy).

Cheers
Andrea

Hello Andrea,

Andrea Aime <aaime@anonymised.com>, [20070507-09:58:41]:

Stephan Holl ha scritto:

> While reading your email I thought about the OWSProxy-framework
> which ships with deegree[1]. There is a role-based user-management
> which implements a layer-based security for OWS-services (WMS, WFS,
> WFS-T, WFS-G). Apart from that you could use Geoserver as a WFS
> behind this security-proxy as well.
>
> This can be secured through https access and using the
> client-program InteProxy[2] which handels the user-management and
> transparent security proxying on the client side (e.g. when using
> *JUMP, UDIG).
>
> Perhaps everything is there you need for your security-framework?

Heh, I guess one day I should really stop hacking Geoserver like crazy
and have a look around in the Degree world.

:slight_smile:

I looked a bit at inteproxy and OWSProxy and they look nice, and
practical too, good way to add security in a world that has so far
neglected it completely.

Yes, indeed. That was the idea.

Yet, no, it does not fit my bill. The main driver for adding a
security framework to Geoserver (besides beying ashamed of not having
one) is that for WFS-V (versioning WFS) I need to know who's the user
that's accessing Geoserver to mark the commit record with the user
name. Having an external solution handling security does not allow
for that. Besides that, I want to play with standard security
protocols.

It could. As we currently keep track of each GetMap WMS-request it
should be faily easy to track WFS-UPDATE-statements.

Yet, iGeoSecurity seems to have a good design and offers lots, so
I'll at least try to reuse some of the ideas.

Geoserver 1.6.x will ship with HTTP basic authentication (on the
service level), but will allow integrators to leverage the full stack
of Acegi authentication modules, which provide for digest,
certificate based, or CAS credential providing, as well as a ton of
authentication backends (file, database, operating system, LDAP, and
others).

Using InteProxy would be interesting since, as iGeoSecurity and
inteproxy both point out, most clients do not know about security at
all. Would it be possible to make InteProxy work against the HTTP
basic authentication protocol?

It does so, but was disabled by now. It should be somewhere inside the
code (commented). You are invited to ask on the
inteproxy-devel-list[1] though, because I do not know for sure :slight_smile:

Otherwise, I guess writing an Acegi
authenticator that can the user/password GET parameters would not
be difficult, thought I'm not sure how would that play with
POST based requests (we handle mixed GET/POST requests in the WMS
layer but it's a bit messy).

I will definetly keep an eye on your implementation inside geoserver
since security is a very interesting (and important) task for SDIs.

Best regards

  Stephan Holl

[1] http://lists.wald.intevation.org/mailman/listinfo/inteproxy-devel

--
Stephan Holl <stephan.holl@anonymised.com>, http://intevation.de/~stephan
Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner