[Geoserver-devel] finer grained admin security

GeoServer GeoServer Developer
1

Hi all,

I am currently working on a project that has a requirement to add a bit more finer grained access control with regards to administration and the web ui. I am trying to think through what this should/could look like and it would be great to get some thoughts from others.

Basically the customer wants three groups of users.

  1. Full admin - has ability to configure anything and everything
  2. Workspace specific admin - has ability to configure only those things local to a workspace
  3. Regular - can access services, layer preview, etc…

Currently we only really have classes 1 and 3. So I have been thinking about what it would look like to support 2. For simplicity we’ll say for now that the class only applies to administrating data, and nothing else (although long term there will be other stuff once services, etc… can be local to a workspace).

My first thought was that this could easily be expressed with our current syntax. For instance, to give a role access to a single workspace you can:

topp..r = ROLE_TOPP
topp..w = ROLE_TOPP

This basically gives a user full read and write access to an entire workspace. But… does this mean both administrative access and data access through services. No, it means the latter… and surely we don’t want it to mean the former. So I wonder if a third type of access is required for administrative. So something like this:

topp..r = ROLE_TOPP
topp..w = ROLE_TOPP

topp.*.a = ROLE_TOPP_ADMIN

Would give service users read / write access to data, but another role is used for administration of that data. Or perhaps we don’t require a new access type, but just a slightly tweaked syntax. Rather than requiring the .. syntax what about just .. Like the following:

topp.r = ROLE_TOPP_ADMIN
topp.w = ROLE_TOPP_ADMIN

topp..r = ROLE_TOPP
topp..w = ROLE_TOPP

Since workspaces and stores themselves are never exposed through services… specifying permissions directly on a workspace could imply administrative privileges. Which begs the question that perhaps layers.properties are not the place for these permissions, since it is really meant for data security through services. Perhaps a separate file could be used for admin data security.

Anyways, sorry this is pretty jumbled… lots of things to think through… hopefully there are enough questions there to drive some good discussion.

-Justin

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

2

On Thu, Nov 3, 2011 at 7:47 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Basically the customer wants three groups of users.
1. Full admin - has ability to configure anything and everything
2. Workspace specific admin - has ability to configure only those things
local to a workspace
3. Regular - can access services, layer preview, etc...
Currently we only really have classes 1 and 3. So I have been thinking about
what it would look like to support 2. For simplicity we'll say for now that
the class only applies to administrating data, and nothing else (although
long term there will be other stuff once services, etc... can be local to a
workspace).

Makes sense to me, seems a nice step towards a GeoServer that
can support multitenancy (http://en.wikipedia.org/wiki/Multitenancy)

So I wonder if a third type of access is required for
administrative. So something like this:
topp.*.r = ROLE_TOPP
topp.*.w = ROLE_TOPP
topp.*.a = ROLE_TOPP_ADMIN
Would give service users read / write access to data, but another role is
used for administration of that data.

Yep, I would go for this one.
Question: administrative access still implies both read and write
access, or not?
If you can configure stuff, can you also read it? I guess so.
Can you also write it? Hum... maybe, maybe not?

Since workspaces and stores themselves are never exposed through services...
specifying permissions directly on a workspace could imply
administrative privileges. Which begs the question that perhaps
layers.properties are not the place for these permissions, since it is
really meant for data security through services. Perhaps a separate file
could be used for admin data security.

Meh, I would still use layers.properties, just for the sake of simplicity, but
no strong opinion on this one.

Anyways, let me expand a bit the topic.
The first though is that the above is just a simplistic representation based
on the old authorization subsystem but the actual api is as follows:

http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/security/ResourceAccessManager.java
http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/security/WorkspaceAccessLimits.java
(see also DataAccessLimits and subclasses).

To get just there I guess adding a administrable flag to
WorkspaceAccessLimits would do the
trick, and then expand SecureCatalogImpl to use that right as well
would partially do the trick.

I say only partially because it would allow to prevent writes on
catalog resources if you don't
have administrative rights, but it would still allow read only access,
which we have to provide
also for capabilties docs and normal service operation.
At the moment adminstrative access is controlled not in the catalog,
but at the outskirts of
the system, in the GUI and in RESTConfig security subsystems.
I guess if we move to a model that has admins per workspace we'll also
have to move that back
into the SecureCatalogImpl, but somehow tell the catalog that the
current access is not
a service one, but a administrative one. Maybe a thread local that the
GUI and REST config
setup when certain pages/resources are being accessed?

As a final note I'm wondering about the usefulness of having per
workspace administrator
without other changes thrown in the mix.
There are three things that are not managed at the workspace level:
a) the services configuration
b) the layer groups
c) the styles

a) one can live without I guess (assuming everybody is ok with
providing the same services
and exposing the same service metadata), b) is annoying, c) though is
a substantial roadblock
if you plan to give these admins a wms service to play with (but it
would not affect
wfs/wcs/wps).

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

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

3

Hi Andrea, thanks for the feedback. Comments inline.

On Sat, Nov 5, 2011 at 5:12 AM, Andrea Aime <andrea.aime@anonymised.com…> wrote:

On Thu, Nov 3, 2011 at 7:47 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Basically the customer wants three groups of users.

  1. Full admin - has ability to configure anything and everything
  2. Workspace specific admin - has ability to configure only those things
    local to a workspace
  3. Regular - can access services, layer preview, etc…
    Currently we only really have classes 1 and 3. So I have been thinking about
    what it would look like to support 2. For simplicity we’ll say for now that
    the class only applies to administrating data, and nothing else (although
    long term there will be other stuff once services, etc… can be local to a
    workspace).

Makes sense to me, seems a nice step towards a GeoServer that
can support multitenancy (http://en.wikipedia.org/wiki/Multitenancy)

So I wonder if a third type of access is required for
administrative. So something like this:
topp..r = ROLE_TOPP
topp..w = ROLE_TOPP
topp.*.a = ROLE_TOPP_ADMIN
Would give service users read / write access to data, but another role is
used for administration of that data.

Yep, I would go for this one.
Question: administrative access still implies both read and write
access, or not?

That is what I had in mind yes.

If you can configure stuff, can you also read it? I guess so.
Can you also write it? Hum… maybe, maybe not?

I guess a case can be made either way… but i mind it seems more natural to have admin encompass read/write privileges as well.

Since workspaces and stores themselves are never exposed through services…
specifying permissions directly on a workspace could imply
administrative privileges. Which begs the question that perhaps
layers.properties are not the place for these permissions, since it is
really meant for data security through services. Perhaps a separate file
could be used for admin data security.

Meh, I would still use layers.properties, just for the sake of simplicity, but
no strong opinion on this one.

I agree. And if we are using a different “admin” flag then I think it slots into layers.properties quite easily.

Anyways, let me expand a bit the topic.
The first though is that the above is just a simplistic representation based
on the old authorization subsystem but the actual api is as follows:

http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/security/ResourceAccessManager.java
http://svn.codehaus.org/geoserver/trunk/src/main/src/main/java/org/geoserver/security/WorkspaceAccessLimits.java
(see also DataAccessLimits and subclasses).

To get just there I guess adding a administrable flag to
WorkspaceAccessLimits would do the
trick, and then expand SecureCatalogImpl to use that right as well
would partially do the trick.

I say only partially because it would allow to prevent writes on
catalog resources if you don’t
have administrative rights, but it would still allow read only access,
which we have to provide
also for capabilties docs and normal service operation.
At the moment adminstrative access is controlled not in the catalog,
but at the outskirts of
the system, in the GUI and in RESTConfig security subsystems.
I guess if we move to a model that has admins per workspace we’ll also
have to move that back
into the SecureCatalogImpl, but somehow tell the catalog that the
current access is not
a service one, but a administrative one. Maybe a thread local that the
GUI and REST config
setup when certain pages/resources are being accessed?

Yeah, I had this exact thought. And what I was thinking was just this. A thread local to be set by each web request and rest request. GeoServerApplication.newRequestCycle() would seem a good place to set it for the former, and a rest dispatcher callback in restconfig for the latter.

As a final note I’m wondering about the usefulness of having per
workspace administrator
without other changes thrown in the mix.
There are three things that are not managed at the workspace level:
a) the services configuration
b) the layer groups
c) the styles

a) one can live without I guess (assuming everybody is ok with
providing the same services
and exposing the same service metadata), b) is annoying, c) though is
a substantial roadblock
if you plan to give these admins a wms service to play with (but it
would not affect
wfs/wcs/wps).

Agreed, and actually the work that is funding this will also be pushing for these features as well. Actually I have a patch pretty much ready for (a), with a proposal. Layer groups and styles are a bit trickier as we discussed on the list a month back or so. I want to focus a bit more discussion on this before proceeding.

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

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