Authentication and DataLink

[Mark Taylor]

Markus,

it's not quite as bad as your sketch is it?  Given the "One URL to
rule them all" model from sec 2.4 of TAP 1.1, securityMethods
won't have individual accessURLs, so I don't think your items
(4) and (6) are necessary.  But it does still seem to be required
to retrieve and parse capabilities to make this work.
And (the point that's really bothering me) that will be potentially
true for any URL that a VO client such as topcat is going to access,
since in general there's no way to know without looking for capabilities
whether e.g. a URL assumed to point at a table is for a VOSI-compliant
service or not, or whether it has authenticated endpoints.
That could end up being a lot of overhead for those cases
(currently, overwhelmingly common) where a URL is pointing at a
non-VO-authenticated resource.

Given that, the capabilities-based route for services like DataLink
does not look nice.  Having the client behave more like a browser
(wait for a 401 challenge and then try to acquire credentials)
seems like a much better idea.
That still leaves the question of how the user or client knows where
to go to get those credentials.  A capabilities-based approach
offers a hook for obtaining that information (though we still don't
have even a prototype for how to do that), but I think with a
401 challenge/response you'd just have to know.

Mark


On Tue, 21 Jan 2020, Markus Demleitner wrote:

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

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