Authentication and DataLink

[Markus Demleitner]

Dear GWS,

On Mon, Jan 20, 2020 at 07:21:34PM +0100, alberto micol wrote:
> Very good question, at the right time for me, given that at ESO we
> are working on a datalink (and soda) that supports authentication.
> 
> My (yet poor) understanding is that the datalink_url will return a
> 401 with a WWW-Authenticate header field containing one or more
> challenges.
> Isn’t that enough for TOPCAT to know what to do?

Well, it's certainly what the creators of HTTP had in mind.

Now that we (as the VO community) apparently move to a one-URI model
again: Has anyone investigated which of the authentication mechansims
enumerated in SSO would be compatible with plain HTTP-based
negotiation?  And could we perhaps do without the others?


The alternative (which is what, I think, the plan so far has been)
would be:

(1) scrape off the last segment path part of the URI of the datalink
service, append "capabilties".

(2) retrieve that URI and parse it as a VOSI capabilities document.

(3) look for a capability element that has an interface that has an
access URL equal scheme://authority/path to your original datalink
URI (probably comparing scheme and authority case-insensitively, path
case-sensitively, but that's never really been defined for the VO;
certainly, the RegTAP makes no allowances for normalising URIs).

(4) if there are zero or more than one such capabilties...  well.  No
idea, really.  Lets pretend there's exactly one of them.

(5) look at the interfaces of that capabiltity element and their
securityMethods.  Choose one securityMethod convenient to you.

(6) extract its access URL, parse the original datalink URI, replace
the schema, authority, and path parts with the ones of the new access
URI, and go [there's a little snag here, too, because traditionally,
query parts are significant in our access URLs -- see many SCS access
URLs --, and if that's true, you'd have to merge these in some
fashion.  Hm]

I think you'll agree that a plain HTTP-based authentication
negotiation would be highly preferable.  I think the main problem
we've seen with it is that services may want to allow both
authenticated and non-authenticated access and vary responses,
perhaps showing additional links to authenticated clients.  

Given the alternative given above, perhaps we should tackle that
problem in a plain HTTP-way, too, by a little VO-specific extension?
For instance, we could say that clients can choose to add an

  Authorization: VO Anonymous

header "usually, but not necessarily, after receiving a 401
response", as RFC 2616 puts it.  Or just encourage UIs and APIs to
let users ask clients to include gratuitous Authorization headers?

That would do for VO clients.  *If* such interfaces are operated from
web browsers, you could still hack something with javascript.

Perhaps the Datalink case is actually a useful example to revisit the
auth negotiation business, because there, you may be jumping between
hosts quite liberally, and doing complex VOSI-type negotiation is
particularly incovenient given the ephemeral nature of the
interaction?

         -- Markus