Users with different access rights in HTTP Authentication

[Martin Atkins-2]

I have run into a situation where I don't believe the HTTP specification
is clear so I was hoping that folks here might be able to weigh in on
what the correct approach might be.

Imagine that I have a resource at some HTTP URL. This resource supports
the GET, PUT and DELETE methods.

In response to a request with any of those three methods, the resource
returns a valid 401 Unauthorized response containing a challenge.

If I recieve a request that has valid authentication credentials for a
user that only has access rights to read and not to modify the resource,
what is the appropriate response status code to use when that request
uses the PUT or DELETE methods?

Here are some options I've been considering:

* Return 405 Method Not Allowed, and indicate in the "Allow" response
header the methods that this particular authenticated user is allowed to
perform. (i.e. Allow: GET)

* Return 403 Forbidden, indicating that the authentication was
successful and that this method is supported but this particular client
is not allowed perform the request. The "Allow" response header here
will have the value "GET, PUT, DELETE".

* Return 401 Unauthorized with another challenge, indicating that the
supplied credentials are not acceptable for this resource. This of
course means that the client is unable to distinguish between an invalid
credentials error and an insufficient access error.

I'd be interested to hear some feedback on which of these approaches
would be best, or indeed recieve any suggestions on alternative
approaches that work better with web architecture.

Thanks,
Martin

[Julian Reschke]

Martin Atkins wrote:

>
> I have run into a situation where I don't believe the HTTP specification
> is clear so I was hoping that folks here might be able to weigh in on
> what the correct approach might be.
>
> Imagine that I have a resource at some HTTP URL. This resource supports
> the GET, PUT and DELETE methods.
>
> In response to a request with any of those three methods, the resource
> returns a valid 401 Unauthorized response containing a challenge.
>
> If I recieve a request that has valid authentication credentials for a
> user that only has access rights to read and not to modify the resource,
> what is the appropriate response status code to use when that request
> uses the PUT or DELETE methods?
>
> Here are some options I've been considering:
>
> * Return 405 Method Not Allowed, and indicate in the "Allow" response
> header the methods that this particular authenticated user is allowed to
> perform. (i.e. Allow: GET)

The description for 405 is not very clear, but the one for "Allow" is
(IMHO):

"The Allow entity-header field lists the set of methods supported by the
resource identified by the Request-URI." --
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7>

So no, this doesn't fit.

> * Return 403 Forbidden, indicating that the authentication was
> successful and that this method is supported but this particular client
> is not allowed perform the request. The "Allow" response header here
> will have the value "GET, PUT, DELETE".

Exactly.

> * Return 401 Unauthorized with another challenge, indicating that the
> supplied credentials are not acceptable for this resource. This of
> course means that the client is unable to distinguish between an invalid
> credentials error and an insufficient access error.

"If the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials." --
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4.2>

So, 401 is IMHO incorrect as well.

> I'd be interested to hear some feedback on which of these approaches
> would be best, or indeed recieve any suggestions on alternative
> approaches that work better with web architecture.
>
> Thanks,
> Martin

Best regards, Julian

[Martin Atkins-2]

Thanks for the response.

Julian Reschke wrote:

>>
>> * Return 405 Method Not Allowed, and indicate in the "Allow" response
>> header the methods that this particular authenticated user is allowed
>> to perform. (i.e. Allow: GET)
>
> The description for 405 is not very clear, but the one for "Allow" is
> (IMHO):
>
> "The Allow entity-header field lists the set of methods supported by the
> resource identified by the Request-URI." --
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7>
>
> So no, this doesn't fit.
>

So I guess the thought here is that the text says "methods supported"
rather than "methods allowed", which implies that it is not user-sensitive.

If Allow is not supposed to reflect the access rights of the remote
user, can you suggest an alternative mechanism by which I can tell the
client "You can GET but you don't have access to PUT or DELETE?"

(Currently I'm using "Allow" for this, but now that you've called out
that specific sentence I agree that it does not seem to be intended to
reflect access rights.)

The need is letting user-agents that retrieve the resource know ahead of
time that a PUT or DELETE will not be allowed so that the UI can reflect
this, for example by displaying a "Read-only" indicator and disabling
the "Save" button.

[Julian Reschke]

Martin Atkins wrote:

>>> * Return 405 Method Not Allowed, and indicate in the "Allow" response
>>> header the methods that this particular authenticated user is allowed
>>> to perform. (i.e. Allow: GET)
>>
>> The description for 405 is not very clear, but the one for "Allow" is
>> (IMHO):
>>
>> "The Allow entity-header field lists the set of methods supported by
>> the resource identified by the Request-URI." --
>> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7>
>>
>> So no, this doesn't fit.
>>
>
> So I guess the thought here is that the text says "methods supported"
> rather than "methods allowed", which implies that it is not user-sensitive.

Yes.

> If Allow is not supposed to reflect the access rights of the remote
> user, can you suggest an alternative mechanism by which I can tell the
> client "You can GET but you don't have access to PUT or DELETE?"

You mean, without trying? RFC 3744 is one potential answer, if you can
accept a WebDAV basis.

> ...

BR, Julian