At a first look I see no big problems here, especially since I do not intend to backport to 2.1.x. I really would like to migrate to Spring 3.x on trunk and use Spring Security 3.x, I hope there are no showstoppers.
But I am a little bit in sorrow about the configuration. Which files have to be touched ?. I would like to avoid migration problems between 2.1.x and 2.2.x later on. Do you plan to add REST support for this configuration ?. Quoting Andrea Aime <[email protected]>: > Hi, > I'm looking into providing the ability for users to register their > own source of > GeoServer users/passwords/authorities. > > At the moment the system is wired up to always use the GeoServerUserDao, > which in turn backs onto a property file. > > What I'd like to do as a first pluggability step is to allow the > usage of other > Spring Security UserDetailsService implementations. > The approach would be the usual, look into the spring context for any > custom implementation of a UserDetailService, if one is found it is used, > otherwise we use the GeoServerUserDao. > This would allow to use a database backed set of users, a LDAP (but just > in the mode where GS gets the password back, instead of the > "bind" approach) or whatever else, such a custom remote service. > > Code wise we'd wire up a GeoServerUserDetailProxy in the spring context > instead of GeoServerUserDao, and the proxy would do the lookup and > decide what concrete UserDetailService implementation to use. > The current user management GUI would get disabled if the GeoServerUserDao > is not available (I was thinking of just hiding the menu items). > The code would be committed on 2.1.x and trunk, by default it would just use > the GeoServer default implementation so the change should be pretty much > harmless. > > Christian's work on the summer of code will take care of a much > larger refactor > allowing to use different authentication filter chains making the > entire authentication > pluggable. That's something much more powerful of course, yet something that > should retain the ability to just change the UserDetailsService and > leave everything > else in place as the default > > Opinions? > > 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 > mob: +39 333 8128928 > > 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. ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
