This page last changed on Mar 19, 2009 by


Implement spatial access control based on OGC GeoXACML specification
Backwards Compatability

Proposed By

Christian Mueller

Assigned to Release

GeoServer 2.0


In Progress


Security and access control is a very complex theme. Many systems have their own, non standard implementations to handle this requirement.

Access control for spatial data causes an additional requirement, protecting data and services based on geometries.

Supporting spatial authorization decisions in a standard, yet powerful manner is the target of this component.

Look at the following picture taken from the GeoXACML specification

The challenge is: 

Allow a user (call her Alice) access to spatial data within the green polygon, but deny access to the rest of the world.

Additionally to spatial access decisions, authorization based on a feature type  (allow or deny  access to the cities) or on a feature itself (allow/deny access to London) should be possible.


GeoXACML is an extension to the OASIS XACML specification. If you follow this link you will see that we are not talking about a trivial component. XACML handles access control for common services and allows extensions.

GeoXACML Extensions

  • Adding a data type "Geometry" (Point,LineString,Linearring,Polygons,Multipoint,MultiLine and Multipolygon). These geometries should be encoded/decoded in GML Version 2 or GML Version3.
  • Adding a lot of spatial functions (intersects,isWithin, union,intersection,......)
  • Coordinate transformations (which are not necessary to be compliant)

Components used for the implementation

  • SUNs XACML implementation as a starting point
  • The geometry handling is done by JTS, which is part of geotools
  • Coordinate transformation is done by geotools

The following picture (again taken from the GeoXACML specification) shows a very simplified architecture.

Alice sends an WMS request. The request is intercepted by the PEP (Policy Enforcement Point). The PEP creates an XACML request based on the WMS request and sends the XACML request to the PDP (Policy Decision Point).

The PDP looks for a proper XACML policy, computes an access decision and sends back a XACML response.  If the response is DENY, the PEP sends back the negative answer to Alice. If the response is PERMIT, the PEP forwards the WMS request to the WMS Server, doing business as usual.

The XML schema files can be found at the OASIS XACML page.

If PEP and PDP are within the same virtual machine , the xml encoding is not needed.

Development proposal

  1. Implementing the GeoXACML specification. Additionally, implementations of some XACML profiles are required (e.g role based authorization)
  2. Integration into GeoServer, Part 1. GeoServer should dispatch XACML requests to the GeoXACML component and react on the reply. Putting the policy xml files into the GEO_SERVER_DATA_DIR would  be a simple approach for a policy repository. Now, GeoServer can act as a GeoXACML Policy Decision Point for other systems.
  3. Integration into GeoServer, Part 2. Development of Policy Enforcement Points within GeoServer. GeoServer should be able to handle spatial access control for its own requests. This step needs involvement from the core developers to achieve the expected functionallity and avoid performance bottlenecks.

There is another component in XACML, called PAP (Policy Administration Point).In my opinion, it would not make much sense to succeed with points 1,2 and 3 without having a tool to manage GeoXACML policies.

These policies are powerfull, but quite complex. There exist some XACML policy editors (e.g ), but remember, we need a tool also supporting the spatial extensions. Some investigation is necessary.

Doing an own implementation for managing policies is heavy stuff, perhaps there are some volunteers.


Backwards Compatibility


Andrea Aime:
Alessio Fabiani
Justin Deoliveira:


[JIRA Task|]
[Email Discussion|]
[Wiki Page|]

example1.png (image/png)
architecture.png (image/png)
Document generated by Confluence on May 14, 2014 23:00