Permissions in RESTful services

RESTful services are independent from clients. That means that services can be consumed by different clients like applications, UIs, and so on.

In the case of UIs, you need to take into account permissions in order to only provide the actions the user is allowed to use. This prevents from having a button or a link displayed in the UI and when the user clicks on it, a forbidden message is displayed. Such issue is mandatory when an application uses a Web API / RESTful service and supports users with different roles like admin and read-only for example.

Using permission resources

Dedicated resources can be provided to return specific permission, permissions for a domain or all permissions. On their side the resources of the application must leverage these permissions to check if they can be executed or not in the context of a particular user.

A dedicated resource is provided to get the permissions, as described below:

GET /permissions

Filtering must be also supported to get only a subset of permissions, as described below:

GET /permissions?categories=contacts

We can notice that permissions arent directly linked to UI issues but are related to elements of the Web API and what we cant do on them.

Using such approach, were able to get a set of permissions using only one call.

Leveraging the OPTIONS method

The HTTP OPTIONS method can be also used to determine communication requirements and the capabilities of the server without having to retrieve or perform an action on a resource. In conjonction with the header Allow, this can allow to return back the permissions associated with the resource, i.e. which methods the current user is allowed to call.

This header contains a list of HTTP methods, in fact, the ones that can use, i.e. the existing ones and the ones youre authorized.

The following request can be done like that:

OPTIONS /somepath

The corresponding response is described below. In this case, all methods can be used for the resource

HTTP/1.1 200 OK

Lets take now a concrete sample. We have two resources:

  • One regarding a list of contacts – method GET to get a list of contacts and method POST to add a contact
  • One regarding a single contact – method GET to get the contact, methid POST / PATCH to update (fully / partially) the contact and DELETE to delete the contact

See this link for more details:

If the current user has read-only permissions, he / she will have the following responses when using the method OPTIONS for these two resources:

OPTIONS /contacts

OPTIONS /contacts/contactid

The main drawback of this approach is that its per resource and you cant have all permissions for a specific domain in one call.

This entry was posted in Web API. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s