[Geoserver-devel] Allowing first, very light pluggability of user authentication source

Andrea_Aime4 · April 19, 2011, 8:42am

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

-------------------------------------------------------

Christian_Mueller · April 19, 2011, 10:55am

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 <andrea.aime@anonymised.com>:

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.

Andrea_Aime4 · April 19, 2011, 11:09am

On Tue, Apr 19, 2011 at 12:55 PM, <christian.mueller@anonymised.com> wrote:

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.

We'd have to modify just one line in the current config:

make that use the GeoServerUserDetailsProxy instead, and have
that one first look in the spring context for any implementation of
UserDetailsService, if none is found it's going to instantiate
a GeoServerUserDao and delegate to it

So I guess it should be fine? The only thing I'd need from the new pluggable
system is to allow this extension to keep on working, that is, even in 2.2.x
if someone pops in the classpath and spring context a custom UserDetailsService
GS should try to use that one (provided the auth chain is at all compatible
with it, that is, basic or digest auth, I guess for other
authentication mechansms
it might not make sense).