Skip to content
Emanuele Tajariol edited this page Dec 18, 2020 · 4 revisions

GeoFence is a webapp that provides an authorization engine to GeoServer.

Authorizations are expressed as a priority-based rule set, in a similar way as iptables does.

Rules can be matched against user, user group, GeoServer instance, caller's IP address, name of OGC service, name of OGC request, workspace and layername.

When a request is made to GeoServer, GeoServer sends an authorization query to GeoFence, which will reply if the requesting user can (or can't) get access to the resource, and optionally which constraints are to be applied on the resource before it is made available to the user. Examples of constraints may be an allowed polygon for a given user which will crop all of its WMS getMap requests, or hiding a certain attribute from all the features from a given layer.

In GeoFence you can create entries for these kinds of objects:

user
A user that can make requests to GeoServer. Note that GeoServer users are not also GeoFence users (i.e. users that can log into GeoFence GUI).
group
A regroupment of users. GeoServer has no concept of this kind of group. It is only used at GeoFence level to express authorization rules for a group of users at once.
instance
A GeoServer instance. The instance name specified here shall match the name with which a GeoServer identifies itself when asking for an authorization check. You need to define the URL and the login credentials for the GeoServer instance in order for GeoFence to be able to ask the server some information (such as the list of workspaces, the list of layers, the attributes in a layer,...) when compiling the rules.

Note that there is no explicit concept of user role here. We'll deal with only one kind of role here, apart from the normal USER role, and that's the ADMIN. An ADMIN in GeoServer has access to everything; this means that, once authenticated as ADMIN, no further authorization requests will be made by GeoServer toward GeoFence. When editing users in the GeoFence GUI, an "is admin" checkbox will make the related user a GeoServer administrator.

Rules

A rule is defined by a priority value, a filter, an action, and optional constraints.

https://user-images.githubusercontent.com/717359/102611026-7c9e9200-412e-11eb-9bc9-1ebb2a40718f.png
priority
The priority is a positive integer number. When the filter selects the matching rules, the resulting rule list is sorted by priority. The lower the priority number, the highest the priority. Usually the first matching rule is the one that "wins" and determines the final result.

Filter

When GeoServer asks for an authorization, a filter is passed within the request. The filter specifies who made the request, and what is the object of the request. Such filter will be matched against the rule fields.

Please note that any one of these fields may be not defined in a rule. In that case, the rule will match any value in the request. E.g.: a GeoServer filter with user "Tizio" will match any rule with "Tizio" set as user, and any rule with no user set (usually shown as a "*" in the GUI, meaning that any user will match that rule)

user
The requesting user. In the GUI, you will choose a given user from a dropdown menu.
group
The group the requesting user belongs to. In the GUI, you will choose a given group from a dropdown menu.
instance
The GeoServer instance the authorization request come from. In the GUI, you will choose a given instance from a dropdown menu.
address
The IP address a request is coming from. In the rule the administrator can specify an IPv4 address range in a CIDR notation (e.g. "10.10.0.0/16"). A rule will match only if the range in the rule includes the address in the filter.
service
The OGC service for which the authorization request is queried. From a dropdown menu you can select one from the most common ones, otherwise you can type in any other string for customized services.
request
The OGC request for which the authorization request is queried. From a dropdown menu you can select one from the most common ones, otherwise you can type in any other string for customized services.
workspace
The workspace of the requested resource. The related GeoServer instance will be queried via its REST interface to find out the list of available workspaces; The resulting workspace list will be shown in a dropdown menu.
layer
The requested layer. The related GeoServer instance will be queried via its REST interface to find out the list of available layers; The resulting layer list will be shown in a dropdown menu.

Action

The Action specifies the outcome of the rule, if matched (by the filter) and selected (according to priority).

  • ALLOW: merge all the LIMIT constraints and allow access to the resource.
  • DENY: discard all the LIMIT constraints and deny access to the resource.
  • LIMIT: add constraints to the final outcome. Constraints can be area constraints or access mode constraints.

Please check the rule matching page to understand how LIMIT constraints are merged.

Constraints

Constraints on the resource can be added only in ALLOWing rules. There are different kinds of constraints, and one ore more of them can be specified.

allowed area
an optional multipolygon constraints. It may be used wherever it applies: e.g.: getMap requests will be cropped, and only the graphical part internal to the multipolygon will be drawn. getFeatures will only return features that are internal or that intersect with the restriction multipolygon.
attribute access
only used in vector layers. For every attribute, the rule may assign the accessibility level: non accessible, read only, full read/write access.
cql_filter_read, cql_filter_write
these two constraints define CQL filters to limit the set of features that can be read or written.
available_styles
restrict the list of the available styles for the layer filtered in the current rule. It may be useful to remove the styles that use one or more inaccessible attributes.
default_style
override the default style for the the layer filtered in the current rule.
catalog mode
sets the catalog mode for the layer defined in the selected rule. Note that the catalog mode behaviour could interact with the access mode, so you may have to set an EXCLUDE value in the cql_filter_read.