motivation for SSO_Next custom www-authenticate: {auth-scheme}

[Mark Taylor]

Hi Paul.

On Mon, 18 Nov 2024, Paul Harrison via grid wrote:

> As I have said earlier in this list, I have reservations about the custom auth scheme as it might not be acceptable to institutional security policies over which the IVOA has no control and header rewriting proxies/firewalls might just filter out/reject such things anyway.

I talked at the meeting to some people who said they didn't think that
was likely, but I have no insight into that myself.

> Having understood (I think) the motivation, I do not think that in an “SSO” environment there is a particularly compelling reason to add this extra complexity. The point being that if a particular IVOA service has been discovered in the registry and the client has used the registry based security information to allow the user to log-in, then if that service is returning urls in datalink responses that require further log-ins outside its own SSO security realm then it will be a pretty poor user experience anyway. Indeed I am not sure how the original service could even know about protected URLs to resources that exist outside its own immediate security realm without credentials itself to discover those resources, in which case access to those resources would be covered by the SSO federation of the original authentication.
> 
> The overall argument is that if you look at individual interactions with a random URL, then perhaps the custom www-authenticate headers are needed, but if you look at it in an SSO context then the authentication that was obtained by looking at the registered security information when first interacting with an IVOA service should be applicable to any end-points that service should return.

Here are a couple of scenarios in which the challenge-based approach
works and the registered auth info one doesn't:

  - An archive may have a TAP service in one security domain and
    data files (pointed to using DataLink) in another one, even if
    it manages both domains.  That might be because security 
    constraints are different for data products and TAP results, 
    or it might just be the way that the archive is set up.
    This was the case at ESDC for unreleased data prior to Gaia DR3,
    and it's one reason that we realised the registry-based approach
    wasn't going to work.

  - You might authenticate to make a TAP query, get a DataLink file,
    and save it for later use.  When you re-load it the next day, 
    your application no longer has the same authentication context, 
    and attempting to follow access_urls in the DataLink table will 
    give you 401s.  You don't know which registered service is
    associated with the authentication required, but challenges
    in the 401 headers can tell you how to authenticate.

Mark

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