Adam Young: Using the OPTIONS Verb for RBAC

Lets say you have  RESTful Web Service.  For any given URL, you might support one or more of the HTTP verbs:  GET, PUT, POST, DELETE and so on.  A user might wonder what they mean, and which you actually support.  One way of reporting that is by using the OPTION Verb.  While this is a relatively unusual verb, using it to describe a resource is a fairly well known mechanism.  I want to take it one step further.

Both OpenStack and Kubernetes support scoped role based access control.  The OPTIONS verb can be used to announce to the world what role is associated with each verb.

Lets use Keystone’s User API as an example.  We have typical CRUD operations on users.

https://developer.openstack.org/api-ref/identity/v3/#list-users

Thus, the call OPTIONS https://hostname:port/v3/users

Could return data like this:

"actions": {
  "POST": {
     "roles": ["admin"]
  },
  "GET": {
     "roles": ["admin", "Member"]
  }
}

 

That would be in addition to any other data you might feel relevant to return there:  JSON-HOME type information on the “POST” would be helpful in creating a new User, for example.

Ideally, the server would even respond to both template and actual URLS.  Both these should return the same response:

/v3/users/{user_id}

/v3/users/DEEDCAFE

Regardless of whether the ID passed was actually a valid ID or not.


Source From: fedoraplanet.org.
Original article title: Adam Young: Using the OPTIONS Verb for RBAC.
This full article can be read at: Adam Young: Using the OPTIONS Verb for RBAC.

Advertisement


Random Article You May Like

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*