GeoServer REST security configuration

Note

RESTful security configuration is available in GeoServer versions greater than 2.0.1.

In addition to providing the ability to secure OWS style services GeoServer also allows for the securing of RESTful services.

As with layer and service security, RESTful security configuration is based on Users and roles. Mappings from request uri to role are defined in a file named rest.properties located in the security directory of the GeoServer data directory.

Syntax

The following is the syntax for definiing access control rules for RESTful services (parameters in brackets [] are optional):

uriPattern;method[,method,...]=role[,role,...]

where:

• uriPattern is the ant pattern that matches a set of request uri’s.
• method is an HTTP request method, one of GET, POST, PUT, POST, DELETE, or HEAD
• role is the name of a predefined role. The wildcard ‘*’ is used to indicate the permission is applied to all users, including anonymous users.

A few things to note:

• uri patterns should account for the first component of the rest path, usually rest or api
• method and role lists should not contain any spaces

Ant patterns

Ant patterns are a commonly used syntax for pattern matching directory and file paths. The examples section contains some basic examples. The apache ant user manual contains more sophisticated cases.

Examples

Most of the examples in this section are specific to the rest configuration extension but any RESTful GeoServer service can be configured in the same manner.

Allowing only autenticated access to services

The most secure of configurations is one that forces any request to be authenticated. The following will lock down access to all requests:

/**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR

A slightly less restricting configuration locks down access to operations under the path /rest, but will allow anonymous access to requests that fall under other paths (for example /api):

/rest/**;GET,POST,PUT,DELETE=ROLE_ADMINISTRATOR

The following configuration is like the previous except it grants access to a specific role rather than the administrator:

/**;GET,POST,PUT,DELETE=ROLE_TRUSTED

Where ROLE_TRUSTED is a role defined in users.properties.

Providing anonymous read-only access

The following configuration allows anonymous access when the GET (read) method is used but forces authentication for a POST, PUT, or DELETE (write):

/**;GET=IS_AUTHENTICATED_ANONYMOUSLY
/**;POST,PUT,DELETE=TRUSTED_ROLE

Securing a specific resource

The following configuration forces authentication for access to a particular resource (in this case a feature type):

/rest/**/states*;GET=TRUSTED_ROLE
/rest/**;POST,PUT,DELETE=TRUSTED_ROLE

The following secures access to a set of resources (in this case all data stores):

/rest/**/datastores/*;GET=TRUSTED_ROLE
/rest/**/datastores/*.*;GET=TRUSTED_ROLE
/rest/**;POST,PUT,DELETE=TRUSTED_ROLE

Exercise

By default, on the workshop configuration, the REST methods have been protected to all.

Opening with a text editor the file:

${TRAINING_ROOT}/geoserver_data/security/rest.properties

you may notice how the methods are allowed only to the ADMINISTRATOR.

Default Workshop REST security configuration

1. Open up a new browser window and open the GeoServer home page. Make sure you’re logged out, so that the browser cannot recognize the administrator credentials:

   

   Logging out GeoServer

   

   Logged out of GeoServer

2. Browse to the following URL:

   http://localhost:8083/geoserver/rest
   

   GeoServer will ask you for credentials.

   

   Providing the administrator credentials will allow you to access the HTML output of the REST interface.

3. Now we are going to modify the REST security in order to allow any user to access the layers configuration, but deny the access to the datastores configuration. In order to do this, edit the file

   ${TRAINING_ROOT}/geoserver_data/security/rest.properties
   

   and modify the properties like below:

   /rest/**/datastores/*;GET=ROLE_ADMINISTRATOR
   /rest/**/datastores/*.*;GET=ROLE_ADMINISTRATOR
   /rest/**/coveragestores/*;GET=ROLE_ADMINISTRATOR
   /rest/**/coveragestores/*.*;GET=ROLE_ADMINISTRATOR
   /**;POST,PUT,DELETE=ROLE_ADMINISTRATOR
   

   Note

   You don’t need to restart GeoServer. The security options will be applied at runtime.

4. Save, open up a new browser window and go to

   http://localhost:8083/geoserver/rest
   

   GeoServer does not complain anymore for credentials, and will show you the main REST objects.

   

5. Navigate to /rest/workspaces/geosolutions. You should be able to see the list of all the available datastores and coveragestores.

   

6. If you now try to click on one of those, GeoServer will ask you again for credentials. Here below the new full rest.properties file.

   

   Note

   The rules must be written taking into account that the security sub-system works in Allow All mode, i.e. you need to write only the rules for the resources you want to protect.

7. Notice that with the previous configuration, anonymous users are still able to access the resources. If you navigate to /rest/layers/Mainrd.xml for instance, you are able to see the link to the layer resource.

   

   with the current configuration you are still able to retrieve the resource without authentication.

   localhost:8083/geoserver/rest/workspaces/geosolutions/datastores/Mainrd/featuretypes/Mainrd.xml
   

   GeoServer does not complain for credentials, and will show you the resource.

8. In order to protect the resources, edit the file

   ${TRAINING_ROOT}/geoserver_data/security/rest.properties
   

   and add the properties like below:

   /rest/**/featuretypes/*;GET=ROLE_ADMINISTRATOR
   /rest/**/featuretypes/*.*;GET=ROLE_ADMINISTRATOR
   /rest/**/coverages/*;GET=ROLE_ADMINISTRATOR
   /rest/**/coverages/*.*;GET=ROLE_ADMINISTRATOR
   

9. Save and try to access the resources again. You will now notice that GeoServer will ask for credentials. Here below the new full rest.properties file.