From m.b.taylor at bristol.ac.uk Fri Jul 3 19:56:24 2020 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Fri, 3 Jul 2020 18:56:24 +0100 (BST) Subject: Authentication progress In-Reply-To: References: Message-ID: 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/