Developer’s Corner: Authenticating dummy clients in GeoServer
In this blog post we’ll introduce a simple authentication method we developed for GeoServer that allows to deal with security unaware clients.
GeoServer can be configured to force a user to authenticate, either directly when trying to access the capabilities document (challenge mode) or when trying to access a protected resource (mixed mode). GeoServer will send a “http basic authentication” challenge, that will force browsers to show up the “username/password” authentication dialog, and make other desktop application ask and send over the user credentials.
There are surely more secure means to authenticate a user, yet basic http authentication is the minimum common denominator, something that most clients support, and coupled with HTTPS transport it provides a good starting point for a secured site.
Unfortunately there are clients out there that cannot even deal with basic authentication.
Some of the existing solutions deal with this by making you install a little desktop proxy software that the other software can connect to, with the proxy dealing with all security considerations. That is fine when you are in control of the client side, but not practical when the user is not able, willing, or allowed to install extra software on their machine.
To allow for some level of authentication and security in those cases we developed a community module called “authkey”, or “Key authentication module”, where all that is requested to the client is to add a unique key indentifying the user into the capabilities request.
And voilà, the user associated to that code will be recognized. The capabilities document returned will also contain back links to GeoServer that replicate the same code, so that also GetMap and GetFeatureInfo requests will work under that same user.
This way the authentication is done without the software having to willingly participate in the authentication mechanism.
The default implementation of the module will look for a property file that configures the associations between the unique codes and the existing users, but different solutions can be plugged in that allow for authentication via hardware code tokens, or daily tokens, or whatever solution you might come up with: see the documentation for more details on the configuration and instructions on how to write your own plugin.
Of course the solution is simple, but coupled with HTTPS it’s more or less as secure as using basic authentication, and allows a wider range of client software solutions to participate in the game.
What about you, looking for some missing GeoServer security features? Interested in knowing more about our Enterprise Services? Let us know!
The GeoSolutions team,