Authentication progress

[Mark Taylor]

On Fri, 12 Jun 2020, Mark Taylor wrote:

> Supporting anonymous and authenticated access on a single endpoint
> ------------------------------------------------------------------
> 
>    Pat suggests that clients can provoke a challenge-bearing 401
>    response by supplyingn a dummy Authorization header:
> 
>        Authorization: tell-me-how-to-auth
> 
>    I think that would work, but I don't think it's necessary.
>    RFC 7235 section 4.1 says:
> 
>       A server generating a 401 (Unauthorized) response MUST send a
>       WWW-Authenticate header field containing at least one challenge.  A
>       server MAY generate a WWW-Authenticate header field in other response
>       messages to indicate that supplying credentials (or different
>       credentials) might affect the response.
> 
>    So I think that services which support anonymous-or-authenticated
>    accesses could just include the relevant WWW-Authenticate headers
>    on all responses (not just 401s).  Vanilla HTTP clients would
>    generally ignore these, but SSO-aware clients could look out
>    for this behaviour and supply Authenticate headers without ever
>    encountering a 401.  Unless I'm missing something.

Another option to address this would be to have a dedicated "authcheck"
endpoint for querying authentication.  The response headers would
behave the same way as other endpoints in the service except
that a service allowinbg both authenticated and anonymous
access should accompany 200 responses to anonymous access
with a WWW-Authenticate (RFC7235) challenge.

In more detail: if authenticated or unauthenticated access is attempted,
it should provoke a 200/401/403 response, following normal
HTTP rules, matching the behaviour that a similarly authenticated
request would see when using the associated VO service.  However, in
the case of a service that permits both authenticated and anonymous
access on the same endpoint, an anonymous request should provoke
a 200 response with an accompanying WWW-Authenticate header
(an authentication Challenge as defined in RFC7235 sec 4.1).
Thus clients attempting authenticated or unauthenticated access
must be prepared for

  * 200 with or without a challenge
  * 401 with a challenge
  * 403 with or without a challenge
  * 404

Additionally, the response SHOULD contain an X-VO-Authenticated
header giving the authenticated user ID if authentication has
been established.  The response body isn't important, and the
endpoint should support GET and HEAD.

>From the point of view of a client like topcat, this arrangement
would be handy for services like TAP where you want to configure the
authentication prior to doing real interaction with the service.
The client could work out the auth by looking at responses for
other service endpoints, but it's not clear which ones would
be suitable for that (e.g. capabilities shouldn't be authenticated
in any case; a sync TAP query might fail for non-auth reasons).
So I'd say it would be nice to have for auth-or-unauth services,
though obviously a new endpoint means more standardisation.

Markus, partly responsible for this suggestion, favours this plan
(and isn't very keen on either tell-me-how-to-auth dummy
authentication attempts or WWW-Authenticate headers on all responses);
he has implemented it at http://dc.g-vo.org/tap/authcheck:

   % curl -I http://dc.g-vo.org/tap/authcheck
   HTTP/1.1 200 OK
   Server: DaCHS/2.0 twistedWeb/18.9.0
   Date: Fri, 03 Jul 2020 17:43:34 GMT
   WWW-Authenticate: Basic realm="Gavo"
   Content-Type: text/plain
   Content-Length: 12

   % curl -I http://dc.g-vo.org/tap/authcheck --basic --user topcat:topcat
   HTTP/1.1 200 OK
   Server: DaCHS/2.0 twistedWeb/18.9.0
   Date: Fri, 03 Jul 2020 17:43:42 GMT
   Content-Type: text/plain
   X-Authenticated-Id: topcat
   Content-Length: 12

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/