Introduction

The GeoServer security subsystem is comprised by several interrelated, but conceptually distinct, components. The purpose of this introduction is to describe them and explain how they interact before diving deep in to them.

Users and Roles Configuration

As a role based system, GeoServer allows to configure roles for different functions and link users to them.

A GeoServer User is an entity that can be authenticated by a computer system or network. For each User, GeoServer mantains the following information:

• Username.
• Password.
• Enabled/disabled flag.
• Additional information (email, name etc.) as a set of key/value pairs.

A GeoServer User Group is a set of user and each group has the following attributes:

• Username.
• Enabled/disabled flag.
• List of Users belonging to it.

Users and Groups are managed through a User/group service, through which it is possible to retrieve, add, edit and delete users and groups present in a storage (by default an XML file, but it can be a JDBC store as well).

• Listing of user.
• Listing of groups, including users affiliated with each group.
• User passwords.

Therefore a User/group service is mainly used in the authentication process to check if the credential in the incoming request are present in any user data storage.

Roles are instead managed by a Role service. It provides:

• List of roles.
• Calculation of role assignments for a given user.
• Mapping of a role to the system role ROLE_ADMINISTRATOR.
• Mapping of a role to the system role ROLE_GROUP_ADMIN.

Unlike User/group services, only one Role service is active at any given time.

When a User/group service loads information about a user or a group, it delegates to the Role service to determine which roles should be assigned to the user or group. The following diagram illustrates the interaction between User/group service and the Role service:

According to the diagram:

• The UserGroupService is asked to load the User.
• The UserGroupService will search the user in the underlyining roles source.
• The UserGroupService will ask the roles for the user to the RoleService.
• The RoleService will search for the roles matching the user in the underlyining roles source.
• The RoleService provides the user’s roles to the UserGroupService.
• The UserGroupService returns the user with roles.

Authentication chains configuration

Multiple authentication mechanisms may be active within GeoServer at a given time. These authentication mechanisms take the form of chains of authentication request filter.

A filter chain general functioning can be described as follow:

• Each filter in the chain processes a request and determines if it should be authenticated or not.
• If it detects that the request should be authenticated, it performs the necessary logic, like retrieving the username and password, invoking its authentication mechanism.
• It passes the request down to the next filter.

In the case of GeoServer, the authentication chain is actually made up of two chains: a filter chain, which determines if further authentication of a request is required, and a provider chain, which performs the actual authentication. The following diagram explains the relation between the two chains:

According to the diagram: the provider chain is concerned solely with performing the underlying authentication of a request and it is invoked by a filter in the chain if it detects that authentication is required.

To perform the authentication a provider might use a UserGroupService.

Request Types and authentication filter chains

In GeoServer multiple authentication filter chains can be defined each one applying to a different Request Type. By request type is meant the requests matched by a rule that can be defined from the GeoServer UI. The administrator can indeed configure a list of different filter chains and a matching rule for each of them. Only the first matching chain of the configured ordered list will be applied to any given request.

Service and Layer Security

Once a user has been authenticated by the filter chain and its role loaded, GeoServer will check if the user can access the resource he is trying to.

GeoServer indeed allows specifying rules to grant access to specific services and layers only to desired roles.

There are two main types of services to which apply a rule:

• OWS services (WFS, WMS, WCS, WMTS), with the possibility to define access rule globally or on a per operation basis.
• REST services, with the possibility to define access rule globally for a request path or on a per HTTP method basis.

The following list of uses examples explain the utility of service access rules:

• Securing the entire WFS service so only authenticated users have access to all WFS operations.
• Allowing anonymous access to read-only WFS operations such as GetCapabilities, but securing write operations such as Transaction.
• Disabling the WFS service in effect by securing all operations and not applying the appropriate roles to any users.
• Allowing only authenticated access to datastore REST endpoints.

The default service security configuration in GeoServer contains no rules and allows any anonymous user to access any operation of any service.

Layers can be secured as well by defining access rules. A Layer access rule can specify one of three available access mode:

• Read (can only read data).
• Write (can write data).
• Admin (can access and modify the configuration of a workspace/layer).

The following considerations apply to the access mode values:

• Write does not imply Read, but Admin implies both Write and Read.
• Read and Write apply to the data of a layer, while Admin applies to the configuration of a layer.
• As Admin mode only refers to the configuration of a workspace/layer, it is not required for any of the OGC services’ requests.

By default GeoServer grants read access to all the layers and write access only to the ADMIN.

Note

Layer security and Service Security cannot be combined. For example, it is not possible to specify access to a specific OWS service, only for one specific layer.