authcheck endpoint

[Mark Taylor]

Pat,

I am about 90% in agreement with this.  The idea of providing the
required information in /capabilities headers is something I can
work with, and if this is put in place as a de facto or actual
standard by those providers with non-trivial authentication
requirements, it will be enough for me to write working auth
client code in topcat.

The 10% I don't agree with relates to your point (2): what your
proposal doesn't give you that a dedicated /authcheck would
is the option to say that authentication is mandatory
(since /capabilities has to return 200 always rather than
optionally returning 401).
So a client such as topcat can say to the user: "you're about to
use this service, would you like to authenticate?" but not
distinguish the cases "would you like to authenticate in order
to get enhanced access?" and "if you don't authenticate you
can't use the service at all".  If the user fails to authenticate
for a TAP service that requires authentication they'll find out
eventually (401 responses to sync/async queries); at that point
I suppose the client had better give the user a second chance
to authenticate which is probably going to be messy but not
impossible.

So I disagree that distinguishing mandatory and optional auth
has no real value.  But I take the point that distinguishing
which endpoints potentially require such mandatory auth from
those that do not is complicated, especially to do it in a way
that refers only to VOSI or SSO rather than client protocols
such as TAP (and actually that applies on the client side as
well as the server side).  So I'm (fairly) happy to go along
with your proposal if those implementing the relevant services
are on board.

Mark

On Mon, 26 Jul 2021, Patrick Dowler wrote:

> 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/
> >
> 

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