authcheck endpoint

[Patrick Dowler]

I have had some time to think about this and also talk with Brian, who is
doing the work on this one. Here are my thoughts.

0. I'm think more broadly than just TAP because whatever we decide on
should be a useful addition to other services as well; at CADC we have ~35
RESTful web services which would end up using this; admittedly, that isn't
35 different pieces of s/w but it is 35 configured and deployed services
that our ops staff manage; so I'm looking for something we can write once
and configure the same way and it will work the same way in all instances

1. In principle, all endpoints would respond with these headers saying how
one could authenticate (optional or mandatory with a 401 response code); I
agree that a standard bootstrap endpoint to poke will make client writing
much easier so I agree that the feature is required

2. Although some endpoints have to function without auth (VOSI-capabilities
and VOSI-availability at a minimum), both of these can accept authenticated
requests (and usually ignore caller identity); in theory someone could
extend VOSI endpoints to do other kinds of actions and that could require
authentication (we have done that at CADC)... but the main point: I think
the concept of fine-grained auth (these endpoints require auth, these
endpoints support optional auth, and these ones don't have auth) is complex
without any real value. Clients can get away with the much simpler view of
"access service endpoint(s) anon" or "access service endpoint(s) with these
credentials" in all cases I have encountered.

3. We will have to standardise a few things: the "ivoa" challenge with
allowed props, the standard #tls-with-password form post, and the
well-known endpoint that is a quick request to get challenge headers; the
first two will naturally go into SSO (imo: 2.1). W.r.t the above points and
thinking about writing the spec, the bootstrap endpoint could be specified
in SSO or VOSI. Brian's prototyping showed us that it was simple to get the
challenge headers (or the x-vo-authenticated header) into every response
and that should happen anyway, so the bootstrap "authcheck" endpoint is
really a no-op endpoint. I'd prefer to rely on an existing endpoint rather
than make up a new thing... and when I think about the spec alterations I
immediately get to my proposal below

Proposal: I think the headers belong in all responses (SSO text) and
clients should bootstrap by calling the /capabilities endpoint (VOSI text).
It's general metadata about how to call the service: some in headers, some
in the body. The spec change would be to specify that the capabilities
should return challenges (or x-vo-authenticated). I'd also add that
capabilities should support http HEAD for clients that only want the auth
challenges. I'm not sure exactly how capabilities will evolve in future,
but it will be an endpoint to describe the service and these headers are
always legit in such a request. From an implementation pov, it was easy to
add this in our cadc-vosi library and rebuild and deploy services (Brian
did have to make a small change for HEAD support). It's an endpoint that's
already included by other standards, it isn't changing the concept of
"capabilities" and seems like the right place to recommend to client
writers.

Aside: At least for client use, I agree that securityMethod in capabilities
docs will probably fade away; how capabilities actually evolves is a
different issue and I have some "use cases" in that direction coming...


--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Wed, 23 Jun 2021 at 06:31, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

> Pat (and GWS),
>
> from the GWS auth telecon yesterday I understand you're sceptical about
> the requirement for an authcheck endpoint that I'd like to see,
> so this is to try to persuade you that it, or something doing a
> similar job, is (IMO) required.  I agree that as a service endpoint
> it looks kind of dumb since it apparently doesn't do anything,
> but I can't see how a client like topcat is going to do a good
> job of authenticated access - especially optionally authenticated
> access - to TAP-like services without it.
>
> I discussed the requirement in my talk at the Nov 2020 interop,
> see slide 6 of:
>
>    https://wiki.ivoa.net/internal/IVOA/InterOpNov2020GWS/auth.pdf
>
> The basic problem is that I (topcat) need to know before starting
> to access a service, for instance prior to metadata acquisition
> as well as to user query submission, what kind of authentication
> is appropriate.  That information could come from the content
> of the capabilities document (securityMethod details), but we
> seem to be moving away from that model to conveying the
> information by WWW-Authenticate challenges instead (which I support).
>
> So the question is how to provoke such a WWW-Authenticate challenge.
> I'd be quite happy to use one of the existing endpoints if it could
> be relied on to do the job, but none of them seem to fit, at least
> without some additional standardisation.
>
> If you're unconvinced that I need this information, I can try
> harder to persuade you.  If you think I can get it from existing
> endpoints, I'm happy to consider suggestions.  Otherwise - authcheck!
> Or similar.  I don't care what it's called, but Markus has
> implemented an endpoint with that name
> (http://dc.g-vo.org/tap/authcheck) so it'll do if nobody
> comes up with something better.
>
> If we can agree it's required, we can tackle the details of the
> requirements (endpoint name, what standard specifies it,
> which HTTP methods must be supported, whether it's mandatory
> for anon-only services, etc).
>
> Mark
>
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20210726/445c482a/attachment.html>