<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">I don't know if this helps you much, but I think it's probably worth referencing the handling of realms ("protection spaces") from rfc7235:</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://tools.ietf.org/html/rfc7235#page-5" class="">https://tools.ietf.org/html/rfc7235#page-5</a></div>
<div class=""><br class="">
</div>
<div class="">
<pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"> The "realm" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection.
A protection space is defined by the canonical root URI (the scheme
and authority components of the effective request URI; see <a href="https://tools.ietf.org/html/rfc7230#section-5.5" class="">Section</a>
<a href="https://tools.ietf.org/html/rfc7230#section-5.5" class="">5.5 of [RFC7230]</a>) of the server being accessed, in combination with
the realm value if present. These realms allow the protected
resources on a server to be partitioned into a set of protection
</pre>
</div>
<div class="">
<pre class="newpage" style="font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; break-before: page; font-variant-ligatures: normal; orphans: 2; widows: 2;"> spaces, each with its own authentication scheme and/or authorization
database. The realm value is a string, generally assigned by the
origin server, that can have additional semantics specific to the
authentication scheme. Note that a response can have multiple
challenges with the same auth-scheme but with different realms.
The protection space determines the domain over which credentials can
be automatically applied. If a prior request has been authorized,
the user agent MAY reuse the same credentials for all other requests
within that protection space for a period of time determined by the
authentication scheme, parameters, and/or user preferences (such as a
configurable inactivity timeout). Unless specifically allowed by the
authentication scheme, a single protection space cannot extend
outside the scope of its server.
For historical reasons, a sender MUST only generate the quoted-string
syntax. Recipients might have to support both token and
quoted-string syntax for maximum interoperability with existing
clients that have been accepting both notations for a long time.
</pre>
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">In addition to that, I believe it's also the case that, if you first login for
<a href="https://example.com/protected/" class="">https://example.com/protected/</a> in a browser, the browser will forward the authorization header for everything under that domain by default after that, but if you try to go to
<a href="https://example.com/protected" class="">https://example.com/protected</a> (even without the "/"), it won't forward that information on the first request, nor would it forward if it was
<a href="https://example.com/" class="">https://example.com/</a>. I believe it _should_ forward it those domains those requests returned a "401" with the same realm, although I haven't verified this.</div>
<div class=""><br class="">
</div>
<div class="">I would also note that I think this also means that authentication for a domain <a href="https://example.com" class="">https://example.com</a>, would be expected to not be valid for a subdomain <a href="https://protected.example.com" class="">https://protected.example.com</a> and
not forwarded.</div>
<div class=""><br class="">
</div>
<div class="">It's probably also worth referencing some of the HTTP state management RFC too, with respect to how cookies are handled (and some of the semantics in there around subdomains as well):</div>
<div class=""><a href="https://tools.ietf.org/html/rfc6265#section-4.1.2.3" class="">https://tools.ietf.org/html/rfc6265#section-4.1.2.3</a></div>
<div class=""><br class="">
</div>
<div class="">Brian</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jan 17, 2020, at 5:55 AM, Mark Taylor <<a href="mailto:M.B.Taylor@bristol.ac.uk" class="">M.B.Taylor@bristol.ac.uk</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi GWS (and maybe lurking DAL people),<br class="">
<br class="">
I have a question about how authentication is supposed to work<br class="">
with DataLink (and possibly similar services), related to some <br class="">
experimentation I'm doing with the Gaia archive.<br class="">
<br class="">
In Gaia's case there is an authenticated TAP service, which returns tables<br class="">
that may have a datalink_url column pointing at DataLink resources.<br class="">
The DataLink resources themselves also require authenticated access.<br class="">
As currently implemented, the Gaia service requires *different*<br class="">
credentials (separate cookies) for the TAP and DataLink services,<br class="">
though even if the authentication was the same I see difficulties.<br class="">
<br class="">
My prototype auth-capable TOPCAT negotiates authentication when<br class="">
the user chooses a TAP service: it finds out what auth methods<br class="">
are available from the tap/capabilities file, offers that choice<br class="">
to the user, and asks for credentials as appropriate. It then<br class="">
takes care to use these credentials for subsequent interactions<br class="">
with that TAP service. There are a few things to iron out still,<br class="">
but the basic model can be made to work.<br class="">
<br class="">
However, DataLink, at least as used from TOPCAT, isn't like that.<br class="">
The user doesn't select a DataLink service from a list and then<br class="">
declare that they want to start interacting with it.<br class="">
Rather a URL that points at a DataLink service gets used as a<br class="">
source of tables in some other context. Typical usage:<br class="">
the user configures an "activation action" that causes the<br class="">
table referenced by the datalink_url column to get loaded into<br class="">
TOPCAT when a table row is selected<br class="">
(<a href="http://www.starlink.ac.uk/topcat/sun253/LoadTableActivationType.html" class="">http://www.starlink.ac.uk/topcat/sun253/LoadTableActivationType.html</a>).<br class="">
In this case, as far as TOPCAT's concerned this is just a URL pointing<br class="">
at a table, and it doesn't know either that it's from a DataLink service <br class="">
or that it's associated with given TAP service (with particular <br class="">
authentication). So it doesn't know what authentication to use, <br class="">
or even that it is supposed to retrieve it using authenticated access <br class="">
(until it gets an access error).<br class="">
<br class="">
This problem has only recently occurred to me. I have some half-baked<br class="">
ideas about how to tackle it, but they all seem problematic.<br class="">
I might be missing something obvious. Is there somebody with a clear<br class="">
idea of how they would expect this to work, in particular from a<br class="">
user experience point of view?<br class="">
<br class="">
Thanks<br class="">
<br class="">
Mark<br class="">
<br class="">
--<br class="">
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br class="">
<a href="mailto:m.b.taylor@bris.ac.uk" class="">m.b.taylor@bris.ac.uk</a> +44-117-9288776 <a href="http://www.star.bris.ac.uk/~mbt/" class="">http://www.star.bris.ac.uk/~mbt/</a><br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>