Skip to content

GSIP 120

mcrmcr edited this page Jun 24, 2015 · 10 revisions

GSIP 120 - REST API for access control

Overview

Proposed By

Christian Mueller

Assigned to Release

GeoServer 2.8.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/catalog
  • /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": "*"
}

The XML format for the catalog mode:

<catalog>
  <mode>HIDE</mode>
</catalog>

The JSON format for the catalog mode:

{
   "mode":"HIDE"
}

Reading the catalog mode

The catalog mode can be read using the HTTP GET method Return codes:

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

Setting the catalog mode

The catalog mode is set using the HTTP PUT method. Valid modes are HIDE,MIXED and CHALLENGE. Return codes:

  • 200 if the request is ok
  • 403 if the user has no administrative privileges.
  • 404 if the request body is malformed
  • 422 for an invalid mode

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 +1
  • Ben Caradoc-Davies +1
  • Christian Mueller +1
  • Gabriel Roldán
  • Jody Garnett +1
  • Jukka Rahkonen +1
  • Justin Deoliveira
  • Phil Scadden +1
  • Simone Giannecchini +1

Committers:

Links

https://osgeo-org.atlassian.net/browse/GEOS-6726

Clone this wiki locally