Lets say you have a 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.
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.
ADDENDUM:
A few people have asked if it is opening up a security hole. Nothing I am saying here is proposing a change the existing security approach. If you want to make sure a user is authenticated before telling them this information, do so. If you only want to return role information for a user that already has that role, go for it.
There is a flip side here, to protecting the user. If user does not know what role is required, and she wants to create a delegation to some other user, she cannot safely do that; she has to provide the full set of roles she has in that delegation. Without telling people what key opens the door, they have to try every key they own.
This seems like a mostly sane way of doing such things but I’m sure there are some people who would wonder if exposing the information in this fashion is a security issue. Or would you shape the info depending on the existing roles of the current user?
Also, what benefit/difference does this have over more verbose hypermedia in the resources that surround any given one for which you would enable this OPTIONS support? In situations like this and other “capabilities” type discovery it’s unclear to me what the advantage out of band handling provides. Is it that we expect people to be making requests in isolation from other requests?
This has come up a few times. I think it is the knee-jerk reaction of “aaaah! security!” as opposed to an actual problem. If you need to be authenticated for the GET call, you may need to be authenticated for the OPTIONS call. If a GET would returna 403, this is not exposing any more information…it might actually be exposing less. You are not saying that the resource exists, just that if it does, you need such a role to access it.
Hiding the role required from a user is a much bigger security problem. I’ll try to write that up in a separate post.