CODEWITHSUNDEEP
restaccess-control
Paul Turner
Paul Turner

Reputation: 39645

How can I express access-control through a REST-style service?

I'm trying to construct a family of REST-style services which are to be consumed by a variety of internal systems. The services maintain an internal access-control system which determines whether a user has access to perform actions on specific resources.

The front-end systems are expecting to have a way to test what access a user has to a specified resource so they can remove features on their UI which rely upon these operations, so they don't wind up issuing requests the service will block.

How can I convey this access-control information to my clients? Are there any conventions for expressing what you're allowed to do to any specified resource?

The objective is to pass enough information to the clients so that they should know what types of requests they can make of a resource without expecting a 403 response.

EDIT:

I was thinking of adding "supported actions" to links in my resources:

<contact>
    <addresses href="/contact/12345/addresses" actions="GET" />
</contact>

If a caller has no access to a resource, the link won't be in the document.

It does force me to be explicit about the actions available on each resource and that clients must read this information on every link I provide, and it doesn't make it easy to handle PUT requests (since you'll be specifying the URL you wish to work on).

Does this seem reasonable? Is there a better convention to achieve this?

EDIT:

For any future reader's reference, I decided to go with putting the available actions on links to existing resources, so callers don't need to make separate OPTION requests.

For creation of new resources by PUT requests, it was a little trickier, since the resources don't yet exist to describe via URL. In these cases, I decided to use a "child" link which describes an "add" mechanism:

<contact>
    <addresses href="/contact/12345/addresses" actions="GET">
        <add href="/contact/12345/addresses/[name]" actions="PUT"/>
    </addresses>
</contact>

It's a little close to describing an RPC-style interface, but it does describe the action (to add a new resource as a child of the address) and its absence from the document (in the first example) would be used to indicate that you don't have access to the resource.

On top of this, I will attempt to support OPTIONS so that clients can check on a resource-by-resource basis, should they have that need.

Upvotes: 1

Views: 438

Answers (1)

Mattie B
Mattie B

Reputation: 21309

I'm not aware of any REST conventions for querying roles.

I would personally implement a system where I'd issue a GET to (say) /users/johndoe/roles and expect to be returned a list of available roles.

Of course, that call itself should be protected in a way that only the specified user and administrators could retrieve the information.

EDIT: Based on your additional information, you might want to look at the HTTP OPTIONS method (if your clients can support it.) If you have already handled authentication via HTTP and you want to know what of the HTTP methods (GET, POST, etc.) you can perform on a given resource, OPTIONS can be used to convey this information to clients. For example:

OPTIONS /resource HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 28 Mar 2012 14:44:47 GMT
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Connection: close

Upvotes: 1

Related Questions