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

[Paul Harrison]

> On 18 Nov 2024, at 13:42, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> 
> 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.

That seems frankly mad - a single provider forcing you to authenticate twice - that is about as anti-SSO as you can get…

To be fair, you probably mean that the authorisation is different on both - if it is true that the TAP service is public, but that some of the results will need authentication to see if the user is authorised, then the TAP service should still be the place that the authentication details are placed - A client should still offer the user the opportunity to authenticate if they want to be able to see everything that the service can offer.

> 
>  - 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.
> 
This is a more compelling reason on the face of it, but if you accept my initial premise that services should not be handing out datalink references to protected URLs outside their security domain, then this can also be solved by the datalink response containing the ivorn of the service that produced the datalink response.

Another reason why I favour “centralising” the authentication location information, rather than distributing it, is that naturally encourages a more SSO mind-set.

Having said all that, Microsoft Azure does return authentication URLs with the standard Bearer scheme

https://learn.microsoft.com/en-us/entra/msal/dotnet/advanced/extract-authentication-parameters

so perhaps I am fighting a losing battle…. (though note standard Bearer scheme)

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20241118/3a88466d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20241118/3a88466d/attachment-0001.p7s>