On Wed, Jun 29, 2011 at 4:12 PM, <christian.muel...@nvoe.at> wrote:
> In the meantime I have implemented xml and jdbc stores for user/group and
> role backend stores. The questions is how to integrate the configuration
> into gesoerver.
>
> 1) Work with with files and directories within GEOSERVER_DATA_DIR/security.
> I would use Java Properties serialized in XML.
>
> 2) Create CatalogInfo Objects and integrate the these configurations into
> the catalog.
>
> It should be possible to use REST to manage these backend stores.
>
> Or is it easier to start with 1) and defer 2).
>
Let's start with 2. Nothing prevents you from using the CatalogInfo
interfaces, but what would be
the reason?
Security has been so far a orthogonal concern to data and service
configuration and mostly
transparent, that is, most of the code does not know there even is a
security layer, I believe
it should stay that way.
CatalogInfo objects are instead known to the whole application, while you
can in theory change
the backend implementation everything works and plays against the
CatalogInfo sub-interface,
they define what we manage and what can be known about features, coverages
and the like.
The security subsytem is a different kind of beast, what we can say we know
about users
is often just the user name: different implementations of the
authentication/authorization
subsytem could have or not explicit roles, roles could be, or not, plain
strings, for all
we know the "thing" that describes the user access rights could be a complex
data structure.
Spring Security is very generic about users for this reason I believe, a
Authentication
has credentials (a generic object), authorities (a list of objects) and
details (guess what,
an object).
Now, of course the default implementation of the security subsystem needs to
know
something about the users, our current one says that a user has a list of
roles
which are strings for example.
And a new default implementation would be the same, but the notion that a
user
has a name and roles that are strings should be restricted to the specifics
of that
implementation (its management, its GUI, its rest interface),
without leaking in any other part of GeoServer.
So yeah, it could be made of CatalogInfo objects if you wish, I'm just
worried
that by seeing them as CatalogInfo there would be temptation to have them
known
in other parts of the system, to have the leak around.
Now, going back to persistence and REST. Those two are not necessarily
related, but
it helps to have the same persistence format, or at least a configurable one
that
can be bent to both usages, for those two.
I'm not sure what the rationale is for using property files in xml format
though?
As far as I know the only advantage over plain property files is that you
can store
multibyte chars in them?
Another curiosity is, what about the network of security objects to be
stored
in 3-5 XML files that we were talking about last time the topic popped up?
What is the current implementation plan?
Anyways, if you want to go property files I have nothing specific against
them,
though using XStream would have given you uniformity with how we already
manage configuration and rest resource encoding for the catalog, also with
interesting
bits on how to have the bits stored on disk relate to each other via ids,
whilst the
network format uses atom links in their place to ensure connectivity.
Did you already think about a REST api for managing users and permissions?
What would be the resources, their granularity and representation?
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
-------------------------------------------------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
