Dear All,
in this post we would like to introduce an application we have developer here at
GeoSolutions in order to cope with the requirements coming from enterprise deployments in terms of Authentication and Authorization for
GeoServer; its name is
GeoRepository.
Whoever has been facing the technical problems involved with deploying
GeoServer inside an enterprise infrastructure following the
SOA paradigm knows that in such context Authorization and Authentication capabilities are usually provided by external services in order to centralize such feature, fostering reuse of existing capabilities, minimize risk of duplication of functionalities as well as to avoid duplication of users' credentials. Moreover in such context
Single Sign On (SSO) services are usually a must-have.
GeoServer comes with an
integrated security subsystem that is able to handle both Authentication and Authorization which is quite powerful and customizable, however we had the need to extend it further in order to be able to provide fine grained control over users' authorizations as well as in order to better integrate with existing A&A services.
A typical and yet simple usage scenario for
GeoRepository is depicted here below.
In these setups GeoServer is normally not exposed directly, there is normally a load balancer as well as an Apache configured to perform duties such as single sign on authentication, SSL encryption and connection with external monitoring tools such as Nagios or Hyperic.
As suggested the authentication is performed by Apache HTTPD via
LDAP;
GeoServer will therefore be responsible only for the authorization based on the current user. In order to do this,
GeoServer communicates with
GeoRepository in order to retrieve users' authorizations query limits (we will get to this later) and then applies them accordingly to the incoming requests (thus avoiding post-encoding filtering, see also this
white paper comparing internal vs external security systems).
In order to make this approach possible
GeoServer was
modified by Andrea Aime, the author of the existing Security Subsytem as described in the picture below.
GeoRepository obtains users' credentials from
LDAP and allows administrator to decorate them with additional parameters which are specific for restricting
GeoServer access to services and data (we will describe them shortly).
Now that we have seen the 10000 feet view let's delve into details of how us know provide additional details on how
GeoRepository seamlessly applies specific geospatial access policies to one or more
GeoServer instances
The possible types of authorizations that can be applied using GeoRepository are controlled via generic rules with priorities , are shown below.
Each rule comprises of:
- User
- Profile
- Instance (since GeoRepository can control more than one instance of GeoServer, the typical enterprise scenario having a cluster of machines serving geospatial requests)
- Service and Request which can be used to control grants on OGC services
- Workspace which can be used to control grants on GeoServer workspaces
- Layer which can be used to control grants on GeoServer layers
- Grant
- ALLOW grants access if the rule is satisfied, DENY denies access if the rule is satisfied
- LIMIT applies only when we have spatial restrictions available, in this case if the ruse is satisfied we basically perform an allow with spatial restrictions.
For ALLOW and LIMIT grants we can, under some conditions, set also additional limits which are called
details.
Available detail levels are:
- Layer Details allows us to specify refined rules for a specific GeoServer layer. As an instance it is possible to override the default style or to filter the available styles' list. It is also possible to specify CQL filters for reading and/or writing (when possible) GeoServer layers' attributes.
- Layer Attributes Details allows us to limit access to vector layer attributes. By default all attributes are readable/writable, but with this capability we can hide some of them or make them read only.
It is worth to point out that GeoRepository interprets rule by priority: higher priority rules (represented by a smaller integer number) are applied before rules at lower priority. Like in IPTABLES, the first match is considered valid and then executed.
The possibilities introduced by having GeoRepository work right next to GeoServer are quite a lot, let us list some of them:
- Fine grain control over which services, layers, workspaces, operations (of a service) a user can access
- Fine grain control over which geospatial area for a layer (being it raster or vector) a user can access
- Fine grain control over the WMS style that a use can apply for a layer with the possibility to perform style substitution on a per request basis depending on the credentials received
- Fine grain control over which attribute (for vector layers) or bands (for raster layers) a user can access (this way it is possible to hide/show sensible attributes depending on credentials)
As an example of full versus limited access to resources, check the difference in the following two layers previews. First one show administrator's preview, second one shows unprivileged user's preview, where some the attributes are hidden, the default style is forced by the access control and the geometries outside the restriction area have been .
We should set up an inline demo soon, meanwhile, if you want to know more about the features we currently support or about our roadmap, please, do not hesitate to
contact us.
