Skip to end of metadata
Go to start of metadata

Introduction

The access control policy in M15 (Feb 2012) was the following:

  • The RO owner can execute all REST requests
  • Others can exexute all REST GET requests

This policy effectively prohibited collaboration and was clearly temporal. Below is the new mechanism that should replace it.

The new access control policy

Permissions

This access control policy applies only to ROSRS API, i.e. requests that refer to Research Objects. It does not apply to user management and access control itself.

For simplicity, it is assumed that all GET requests require the READ permission, while all other requests require the WRITE permission. This makes sense given the ?RODL interfaces - ver. 5 but may change in the future.

The WRITE permission does not include the READ permission.

Users

For simplicity, in the first implementation READ will apply to all users except the owner and WRITE to all authenticated users except the owner. The owner always has READ and WRITE permissions to his RO.

The next step could be to assign them to individual users or roles.

Granularity

For simplicity, in the first implementation permissions can be applied only to Research Objects.

The longterm vision is to assign them to any resource with URI but this is not supported by dLibra and will require a new access rights control engine.

The REST API

State of the art

After a short research it turns out that there are 2 approaches to access control REST APIs:

  1. Create a separate resource for permissions, i.e.:
    1. http://pulpproject.org/ug/UGREST-Permissions.html
    2. http://open.xerox.com/Help/Help%20on%20the%20REST%20API%20for%20Storage%20permissions
  2.  Add a subresource to existing resources, i.e.:
    1. https://developers.google.com/google-apps/documents-list/#managing_sharing_permissions_of_resources_via_access_control_lists_acls
    2. http://markmc.fedorapeople.org/rhevm-api/en-US/html-single/index.html#sect-REST_API_Guide-Common_Features-Resources-Permissions

In all cases, the permissions seem too complex to be expressed by only URIs, so they are expressed within XML files.

RODL API

Given our simple access control policy, the REST API can be rather minimalistic. We propose to take the first of the 2 approaches above and not to use XML.

To grant a permission:

POST /permissions/?resource=<resource_uri>&permission=<READ|WRITE>

Parameters: resource_uri - RO URI

Success: 200 OK

Failure: 400 Bad Request if the parameters are missing or incorrect

To revoke a permission:

DELETE /permissions/?resource_uri=<resource_uri>&permission=<READ|WRITE>

Parameters: resource_uri - RO URI

Success: 204 No Content

Failure: 400 Bad Request if the parameters are missing or incorrect

To show permissions:

GET /permissions/?resource_uri=<resource_uri>

Parameters: resource_uri - RO URI

Success: 200 OK and a single line with a list of permissions separated by commas

Failure: 400 Bad Request if the parameters are missing or incorrect

   

  • No labels