Protecting GeoServer with CAS in an Enterprise environment
Dear Readers,
in this post we will show a practical use case taking advantages from the GeoServer CAS authentication provider extension.
A small introduction first. As you may already know, GeoServer ships with an highly configurable security subsystem based on Spring Security. This has been completely re-engineered, providing a more secure and flexible authentication framework. We are not going to provide techincal details of the security framework in this blog, but it is worth to highlight few features which are quite interesting. Multiple authentication mechanisms can be active within GeoServer at a given time. The following figure illustrates the flow of a generic request.
Authentication Chain in GeoServer
Each GeoServer request is filtered through the authentication chain. The request is processed by each mechanism in the chain in order. If one of the mechanisms in the chain is able to successfully authenticate, the request moves to normal processing, otherwise the request is not routed any further and an authorization error (usually a HTTP 401) is returned to the user.
In the case of GeoServer , the authentication chain is actually made up of two chains: a filter chain, which determines if further authentication of a request is required, and a provider chain, which performs the actual authentication.
Authentication Chain in detail: filters and providers
The filter chain performs a variety of tasks, including:
- Gathering user credentials from a request, for example from Basic and Digest Authentication headers
- Handling events such as ending the session (logging out), or setting the “Remember Me” browser cookie
- Performing session integration, detecting existing sessions and creating new sessions if necessary
- Invoking the authentication provider chain to perform actual authentication
The filter chain is actually processed twice, before and after the request is handled. The provider chain is concerned solely with performing the underlying authentication of a request. It is invoked by the filter chain when a filter determines that authentication is required.
What is really important, is that the Authentication Providers are pluggable in GeoServer. It is possible to add/create extensions to the security framework, allowing GeoServer to authenticate against a wide variety of security protocols and systems.
We are going to see how to configure and use the CAS Authentication Provider in GeoServer, in a real-world use case where GeoSolutions helped his client NATO STO CMRE with devleoping a distributed geospatial processing infrastructure for MetOc data
First of all, let us introduce CAS, which stands for Central Authentication Service, is an enterprise Single Sign-On solution for web services. Single Sign-On (SSO) means a better user experience when running a multitude of web services, each with its own means of authentication. With a SSO solution, different web services may authenticate to one authorative source of trust, that the user needs to log in to, instead of requiring the end-user to log in into each separate service.
The objectives of this work was to allow CMRE users to
- run complex geoprocessing algorithms on demand
- store the results on a cluster of GeoServer instance with a complete lifecycle management
- manage the outcomes with the ability to visualize them on a map.
It is also worth to point that cluster of GeoServer instances is responsible for providing MetOC data and layers both as input for the algorithms (via WCS 2.0) as well as for the maps (via WMS with multiple dimensions).
A crucial requirement was that all the exposed web services were protected and not accessible by unauthenticated users by relying on the existing A&A infrastructure deployed at CMRE which is based on LDAP and CAS. This basically meant protecting the GeoServer endpoints via integration with the available CAS and LDAP services..
The following simplified diagram depicts the services exposed to the users and protected by CAS.
Complete Deployment Diagram of implemented solution
As said before, both MapStore and GeoServer have been protected by the CMRE CAS server. Thanks to that configuration, a user authenticated and authorized from the CMRE Portal, can now access the MapStore front-end or GeoServer data and services without any further authentication. On the other side, an unauthored user which tries to connect directly to MapStore or to GeoServer, will be immediately redirected to the CAS Login page, of the CMRE Portal.
In the following sections, we are going to see how we configured and setup the CAS Authentication Providers on GeoServer. First of all the CAS server must be available and running. The first step is to import the server certificates into the GeoServer java virtual machine. The following command line can be used from and administrator to export the certificates (CRT) from the CAS server:
Configuring certificates: step 1
Once the server.crt is available, the procedure to import the certificate into the java virtual machine is the following one:
Configuring certificates: step 2
Enter the keystore password and confirm the certificate to be trustable.
GeoServer should have been deployed with the CAS extension installed (check this page on how to intall an extension). Once the GeoServer is up and running, in order to configure the CAS Authentication Provider, you must click on the “Authentication” link of the GeoServer GUI, Security section, as shown in the picture below:
Configuring the CAS Authentication provider: step 1
Scroll down to the “Authentication Filters”
Configuring the CAS Authentication provider: step 2
and add a new “CAS” auth filter
Configuring the CAS Authentication provider: step 3
Fill in the CAS auth filter fields with the CAS server information and remember that the Single Sign On works only on HTTPS secured channels
Configuring the CAS Authentication provider: step 4
finally update the “Filter Chains” accordingly
Configuring the CAS Authentication provider: step 5
Once everything is correctly configures, GeoServer will be protected by CAS. Everytime an unauthorized user tries to access to the GeoServer GUI or to a layer or dataset, he will be redirected to the CAS server login page.
Configuring the CAS Authentication provider: step 6
On a successfull login, the CAS server assigns a token to the user which must be provided as a request parameter on all the subsequent requests to GeoServer. The same token can be used to successully login into the others web services protected by the CAS without passing through the login form again.
We would like to thank NATO STO CMRE for funding this work which was carried out as part of GeoSolutions Enterprise Support Services Plan.
