Hi Andrea, thanks for the feedback. Comments inline.
On Sat, Nov 5, 2011 at 5:12 AM, Andrea Aime <[email protected]>wrote:
> On Thu, Nov 3, 2011 at 7:47 PM, Justin Deoliveira <[email protected]>
> 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.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
