GSIP 159

GSIP 159 - GeoWebCache data security API

Overview

Add an extension point to GeoWebCache allowing for a security check based on the layer and extent of the tile. Add an implementation of this extension point to GeoServer's GWC integration.

API changes will primarily be upstream in GeoWebCache but as it does not presently have a formal proposal system, the most active GWC developers are also GeoServer developers, and this has security implications for GeoServer, this proposal will be handled as a GSIP.

Proposed By

Kevin Smith

Assigned to Release

This proposal is for GeoServer 2.12 and GeoWebCache 1.12.

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

Currently GeoServer intercepts requests to its embedded GWC instance, pareses them and then does a security check against its catalog to determine if the request should be allowed to proceed. This is brittle in the face of new services or differences between how the security check and actual service implementation interpret the request.

This will also open the possibility of a stand alone layer/location specific security system in upstream GeoWebCache.

Proposal

Filter to check that the request is allowed.

interface SecurityFilter {
  public void checkSecurity(TileLayer layer, BoundingBox extent, SRS srs, Object securityContext) throws SecurityException;
}

Extension point that the GeoWebCacheDispatcher can call to generate appropriate security context object to be stored on the resulting Conveyor

interface SecurityContextProvider<Context> {
  public Context getSecurityContext(HttpRequest request)
}

Add accessors for a securityContext property to Conveyor. GeoWebCacheDispatcher calls Service.getConveyor to get a Conveyor, then handles it. The context would be attached in between those steps.

conv = service.getConveyor(request, response);
securityContext = securityContextProvider.getSecurityContext(request);
conv.setSecurityContext(securityContext);

Add a SecurityException class. Allow it to wrap another exception so it can wrap the GeoServer one, which might then be extracted if need be. Amend method signatures to allow throwing this exception.

Alternatives/Variations

• The existing RequestFilter extension point might be used instead of making upstream changes, or the SecurityFilter might be made as a subclass of it or otherwise use it.

• GWC already has a dependency on Spring Security and it is also a component in GeoServer's security system. We might make use of this for the security context with the integration then simply bridging the context across. Input from someone more familiar with Spring Security and how it's used in GeoServer would be helpful.

• Possibly Security context is a collection so that multiple SecurityContextProviders can be used. It's up to the SecurityFilter to select the context or contexts that are appropriate.

• Instead of throwing SecurityException, checkSecurity could return @Nullable SecurityException or Optional<SecurityException> which might be more amenable to streams/lambdas.

• Instead of a security filter standard across the system, let the tile layer implementation handle security in whatever way it sees fit based on the conveyor's security context.

Backwards Compatibility

In the absence of a security check implementation, stand alone GeoWebCache will behave as it already does. The security GeoWebCache integration in GeoServer is not intended as an extension point to developers so replacing it should not affect anyone and its configuration consists of a flag to turn it on or off which can be maintained. This change should have no compatibility issues.

Some GWC APIs will change in a non-backward compatible way by adding a new checked exception (SecurityExcpetion)

Discussion

Voting

Project Steering Committee:

• Alessio Fabiani:
• Andrea Aime:
• Ben Caradoc-Davies:
• Brad Hards:
• Christian Mueller:
• Ian Turton:
• Jody Garnett:
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini:

Links