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
<workspace>.<layer>.<permission> syntax what about just
<workspace>.<permission>. 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.
------------------------------------------------------------------------------
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
