Archive for July, 2010

Differential authorization of data within a given resource

The ROA Tech team recently had a discussion about the form a payload might take if you were authorized to see only part of the data requested.  Imagine the following hypothetical resource and its XML representation:

/employee/{id} returns:


<employee>
      <id/>
      <name/>
      <phone/>
      <paygrade/>
      <sickleave-balance/>
</employee>

For example, suppose that a receptionist requested such a record and that he was authorized to see name and phone number, but not the paygrade or sick leave balance.  What should be returned? There are several obivous ways of handling this situation.

One approach might be thought of as a “variable representation” solution.  The requester only gets back fields he is allowed to see.  Our receptionist would get back this simplified payload, with no mention of the forbidden data:

<employee>
      <id/>
      <name/>
      <phone/>
</employee>

If we chose instead always to return a fixed-form representation, several possibilities arise.  We might implement access to the resource by separate public and private URIs, returning only the appropriate fields:

/employee/public/{id}
/employee/private/{id}

Alternatively, we could stick with the single URI and an isomorphic payload, but fill the disallowed fields either with nulls or some sort of error value to indicate  that access is not allowed (a sort of per-field 403).

Is one of these solutions better than the others?  Each solution has its own strengths, and no consensus emerged during our discussion.

The “variable representation” solution is the one found in our own person webservice– you only get back what you’re allowed to see.  This keeps the security close to the datasource.  But it can also be hard to code against if the client needed to be smart enough to know that some fields might be invisible to some users.

The private/public approach is straightforward in its expectations, but cumbersome in its own way.  Now, the client might need to be smart enough to know which resource to request.   And is the public version always a subset of the public version?  A no answer has the possibility to complicate parsing of the payloads.

Isomorphic payloads are probably the easiest for the client to handle because the client can understand that payload without need of external knowledge of the resource’s structure or authorization model.  If all fields in the resource are to be returned (and ease of client use is the goal), it is preferable to include an error value for disallowed fields in order to disambiguate between data that are truly empty compared to those that are forbidden.

One final question troubles me about this last solution, though: are there cases where merely acknowledging the existence of a disallowed field represents a security concern?  Is it potentially worse to disclose that a datum exists but can’t be viewed than it is to omit it silently?  I have not been able to come up with an example of such a field, nor have I come up with a convincing argument that
it should not be a concern. Anybody want to chime in?

3 Comments