This page last changed on Mar 03, 2010 by aaime.

This page is a work in progress, it contains some notes on possible evolution directions for the GeoServer built-in security.


The current authentication mechanism is based on http basic authentication, plus cookie based remember me functionality, and a very simple property based file containing users, passwords and roles.

In the future I guess we'll want to make the two aspects pluggable:

  • what authentication mechanism to use (basic, digest, CAS, ..., use of remember me cookies and so on)
  • the user database itself (property, relational database, LDAP, ...)

Ideally this should be obtained in a way that:

  • allows to add a new option by just dropping in some jars
  • allows the admin to choose which plugins to use on the GUI (this is debatable btw, alternatively we enable the only plugin that has been dropped in). There is also the issue of how to deal with a misconfigured security (e.g., so misconfigured that the admin himself won't be able to login anymore...)
  • allows the admin to configure the details of each plugin via the GUI as well (e.g., LDAP server location and access information, and so on)

The question remains on whether the above is doable at all. For example C2C has implemented a CAS LDAP solution with Acegi, but the level of customization is both heavy and very detailed, makes one wonder if it's actually possible to decouple it in discreet, pluggable and configurable modules (this is some R&D that still needs to be done)


The current authorization mechanism is already pluggable, but works only against data and only in terms of full read/write, and cannot take into consideration contextual information such as the type of service used to reach to the data.

A more general mechanism is desirable that allows to exert security at the feature level (by expressing filters on what a role can or cannot do) and that can take into account also the service and method. For example, certain columns should be accessible when drawing a map, but not be available in GetFeatureInfo or GetFeature.

XACML should provide a way to express the above security constraint, however as of now I have strong reservation on it being actually configurable by a non programmer, in order to express a full lockdown the property file can use a single line, in XACML that converts in around a hundred lines. The format is extremely verbose and thus should be accompained by a GUI, or else, replaced with something simpler and more effective.

In both cases we're still talking about data security, there is no way to express administration level security at the moment, either one is the admin, or she's not. There is however a way to express more granular access via the REST security.

REST security

The REST security is path based, it associates a path expression and the REST methods with a set of authorized users. This can be used for anything, and in particular it allows for granular access control of REST config, resulting in a good admin level security control that allows users other than the administrator to control only part of the GeoServer resources admin wise.

In general it would be nice to push this control down to the catalog level so that it is shared with the Wicket GUI. It would be however duplicated anyways, because the REST security configuration needs to cover resources other that just REST config (e.g., any other resource exposed via REST).

Alternatively it might be interesting to have the Wicket GUI stop accessing the catalog directly and use the REST config API to talk with the catalog. This would have the advantage of fostering the development of a stable java based RESTConfig client and keep the REST api in check, with the obvious disadvantage of having to do network communication in order to talk to something available in process is very much backwards (am I the only one noticing the elephant in the room there?).

Document generated by Confluence on May 14, 2014 23:00