Puuh, long mail, answers inside Zitat von Andrea Aime <andrea.a...@geo-solutions.it>:
> 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? One reason is that I need an object model to develop against, especially for the GUI and the REST API. I am talking here only about configuration parameters like the jdbc connect params I need for the jdbc backend for /user/groups/roles. Other config options are schema validating yes/no for the xml backend store, a boolean property "reentrant" which causes the creation of a locking wrapper and so on. Other possibilities would be to work with individual java BeainInfo objects for each backend store ore using properties, but I fear this will produce more code on the GUI and REST. I dislike both of them. Conclusion: I would like to have a proper object model for the configuration issues. > 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. Yep, it should, "orthogonal" is a very good expression. > 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. What about using the CatalogInfo interface without registering this objects into the catalog ?. We can discuss integration if you see the whole thing in action ? > > 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. > Short outline: I have 4 main classes GeoserverUser implementing Spring UserDetails GeoserverUserGroup which is new GeoserverGrantedAuthority inherits Spring GrantedAuthority Additionally, there is an Interface GeoserverSecuritySystem which implements Spring UserDetailsService, a singleton is created by Spring injection. I took care that my classes behave like expected from Spring (studying the source code), only the calculation of UserDetails.getAuthorities is more complex, but this is not of interest to the spring security architecture. > 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. Yeah, I want the configuration objects to behave like other geoserver configuration objects. Individual files for backend implementations are independent. As an example, for the jdbc backend I need files for the DDL and the DML statements, no plan to make CatalogInfo objects for these files. > 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? I like the xml approach because of name spaces. As an example, I could combine the DDL xml file and the DML xml file into one xml file using 2 name spaces. If users dislike the xml property files, I could change that. > 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? There are 2 xml backends, one for user/group info and one for roles (GrantedAuthorities). The default deployment will have 2 xml files. > > 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. Not sure what your are meaning here, I did not invest much time how CatalogInfo works. I will start at DataStoreInfo to understand the architecture. > > Did you already think about a REST api for managing users and permissions? > What would be the resources, their granularity and representation? In a first step, I only want to handle the configuration using REST, but at the end of the day, I plan to offer the same possibilities for the GUI and the REST API. > > Cheers > Andrea Summary: I will go on developing an object model for configuration issues based on CatalogInfo. I want to defer/avoid altering the Catalog interface, perhaps I implement something similar for the security subsystem. I fear that I will produce a "monster" patch, so I want to find some boundaries not preventing further integration in the future. I hope my English is clear enough, one of my sons insists on going to the playground, no time to reread, no chance at the moment :-) > > > -- > ------------------------------------------------------- > 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 > > ------------------------------------------------------- > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ 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
