Geoserver Probe Explained

The GeoServer Probe

The probe that we install in GeoServer in order to relay on GeoFence for authentication and authorization integrates into the GeoServer authentication and authorization subsystem smoothly.

It is shipped with a user interface for its configuration, it also provide an in-memory cache to cache authorizations and reduce network traffic (see next sections) moreover it provides a basic REST interface to interact with the cache itself from external applications.

The Probe is basically a GeoServer extensions and as such needs to be installed.

Basic Configuration

As show in the image below the Probe comes a complete GUI.

It contains the following sections:

General settings

In this section the user can configure:

• the GeoServer Instance name to be passed to GeoFence. Please, do notice that this can be shared between multiple GeoServer that are willing to share the same set of Rules from a GeoFence instance.
• the GeoFence URL for connecting to the rule service

Options

This section allows users to control following options:

• Allow remote and inline layers in SLD option to allow usage of remote and inline layers in SLDs (defaults to false)
• Allow SLD and SLD_BODY parameters in requests option to allow usage of the SLD or SLD_BODY requests parameters (defaults to false)
• Authenticated users can write option to allow write access to authenticated users; by default only admins have write permissions, all other users can only read
• Use GeoServer roles to get authorizations

Cache

In this section a use can interact with the in-memory cache for rules coming from GeoFence. More information can be found in the sections below.

Probe Configuration Persistence

The Probe configuration is persisted by default inside a geofence.properties file within the GeoFence directory inside the data directory.

The content looks like this:

### GeoFence Module configuration file
### 
### GeoServer will read this file at boot time.
### This file may be automatically regenerated by GeoServer, so any changes beside the property values may be lost.
### GeoFence main configuration
#it's the name that GeoServer uses to identify itself when sending authorization requests to GeoFence (GeoFence may handle the authorizations for independent GeoServer instances). It defaults to default-gs
instanceName=default-gs 
# the URL of the listening GeoFence endpoint. It defaults to http://localhost:8181/geofence/remoting/RuleReader
servicesUrl=http://localhost:8081/geofence/remoting/RuleReader 
allowRemoteAndInlineLayers=false
allowDynamicStyles=false
grantWriteToWorkspacesToAuthenticatedUsers=false
#choice of the principal used for security in building access permission; by default the username of the Geoserver authenticated user is used, together with its Geofence defined groups memberships. When this option is true, one of the Geoserver roles owned by the user is mapped to a Geofence group with the same name and used for rule matching. To make sure that only one role is chosen, a list of recognized roles can be specified using the acceptedRoles paramete (defaults to false).
useRolesToFilter=false
# list of roles accepted as group names for rule matching when useRolesToFilter is true.
acceptedRoles=
### Cache configuration
cacheSize=1000
cacheRefresh=30000
cacheExpire=60000

The location where to find the configuration file can be overriden in case multiple instances of GeoServer where running in parallel and sharing the same data directoy by

Cache

The probe includes a small in-process cache to cache authorizations in memory in the local instance to avoid sending too many calls to GeoFence instances which might cause performance problems.

The cache implementation can be configured from the user interface as there is a specific section shown in the image below:

There is a button that you can use to invalidate the cache contents moreover you can inspects statistics on usage of the cache and you can also administer the cache settings as per the values below:

• Size of the rule cache: the number of the entries that will fit in the map before older entries are evicted
• Cache refresh interval (ms): after this number of millisecs, an entry may be reloaded;
• Cache expire interval (ms): after this number of millisecs, an entry is invalid and can be evicted from the cache.

The configuration settings for the cache are also available in the geofence.properties files located inside the geofence directory within the GeoServer data directory:

Here a basic example of the content of the file:

cacheSize=3000
cacheRefresh=30000
cacheExpire=60000

where:

• cacheSize: maps to the element Size of the rule cache in the GUI
• cacheRefresh: maps to the element Cache refresh interval (ms) in the GUI
• cacheExpire: maps to the element Cache expire interval (ms) in the GUI

Disabling the Probe Cache

The Probe Cache can be disable by setting the Cache Size to 0 either in the GUI or in the geofence.properties file.

Alternatively, since the cache implementation is injected into the GeoServer “rule client” using Spring. It may be easily removed by editing the file

src/geoserver/security/src/main/resources/applicationContext.xml

for the Probe which you can find that file inside the geofence-security-XX-SNAPSHOT.jar file.

Search for the following snippet:

    <!-- You may replace the cachedRuleReader ref with ruleReaderService ref in order to disable the caching -->
    <alias name="cachedRuleReader" alias="ruleReaderService"/>

and comment this alias.

Interacting with the Probe Cache via REST

A few of REST URLs have been added in order to interact with the cache:

• http://server:port/geoserver/rest/ruleCache/info An authenticated HTTP GET on this URL will give you some statistics info on the cache usage
• http://server:port/geoserver/rest/ruleCache/invalidate An authenticated HTTP PUT on this URL will invalidate all the entries in the cache, forcing the reload of the data. This call is extremely handy in order to clean caches once you have edited rules in GeoFence.