Skip to content

GSIP 120

Jody Garnett edited this page Jan 14, 2015 · 10 revisions

GSIP 120 - REST API for access control

Overview

Proposed By

Christian Mueller

Assigned to Release

GeoServer 2.7.0

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

Give a possibility to configure access control using a REST API.

Proposal overview

GeoServer uses three Java property files to store access control rules.

  • layers.properties for access control rules for layers
  • services.properties for access control rules for services
  • rest.properties for access control rules for REST requests

Those three files are managed by the admin GUI. This proposal is about adding a REST API for reading,adding,modifying and deleting access control rules.

Detailed presentation of changes

URIs

  • /security/acl/layers
  • /security/acl/services
  • /security/acl/rest

Supported formats

  • XML
  • JSON

The XML format contains of a set of "rule" elements. Each rule element has an attribute "resource" describing the resource to protect. The value of the "rule" element is a comma delimited list of role names or the asterisk. The standard layer.properties encoded in XML looks like:

<?xml version="1.0" encoding="UTF-8"?>
<rules>
 <rule resource="*.*.r">*</rule>
 <rule resource="*.*.w">*</rule>
</rules>

The same example in JSON:

{
"*.*.r": "*",
"*.*.w": "*"
}

Reading

The rules can be read using the HTTP GET method. All rules are returned, no filter technique is applied. Return codes:

  • 200 if the request is ok
  • 403 if the user has no administrative privileges.

Adding a set of rules

Rules can be added by using the HTTP POST method. Return codes:

  • 200 if all rules can be added
  • 500 for an internal server error (e.g malformed syntax in the request body)
  • 403 if the user has no administrative privileges.
  • 409 (conflict) if only one rule already exists, the whole transaction is aborted

Modifying a set of rules

Rules can be modified by using the HTTP PUT method. The request body contains the modified rules. Return codes:

  • 200 if all rules can be modified
  • 500 for an internal server error (e.g malformed syntax in the request body)
  • 403 if the user has no administrative privileges.
  • 409 (conflict) if only one rule does not exist, the whole transaction is aborted

Deleting a specific rule

A rule can be deleted by using the HTTP DELETE method. The rule itself is the last part of the URI.

Example: /security/acl/layers/*.*.w

Return codes:

  • 200 if the rule was deleted
  • 500 for an internal server error
  • 403 if the user has no administrative privileges.
  • 404 If a rule does not exist.

Slashes ("/") in a rule name must be encoded with %2F.

Example for the REST rule "/**;GET"

/security/acl/rest/%2F**;GET

Feedback

Backwards Compatibility

Voting

Project Steering Committee:

  • Alessio Fabiani
  • Andrea Aime
  • Ben Caradoc-Davies
  • Christian Mueller
  • Gabriel Roldán
  • Jody Garnett
  • Jukka Rahkonen
  • Justin Deoliveira
  • Phil Scadden
  • Simone Giannecchini

Committers:

Links

Clone this wiki locally