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? 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 ------------------------------------------------------- ------------------------------------------------------------------------------ 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
