From james.tocknell at mq.edu.au  Mon Dec  9 08:03:28 2024
From: james.tocknell at mq.edu.au (James Tocknell)
Date: Mon, 9 Dec 2024 07:03:28 +0000
Subject: motivation for SSO_Next custom www-authenticate: {auth-scheme}
In-Reply-To: <20241118182302.ciew72ph4if2tccg@victor>
References: <4DED6E10-B244-47DA-AAC4-169EC18C14B4@manchester.ac.uk>
 <3894b590-e2b-5fcc-cec3-7fb2e66ca58f@andromeda.star.bris.ac.uk>
 <0B6E7448-9499-42E9-A7C7-CC14F7708D4D@manchester.ac.uk>
 <9c9aa6f2-c193-3f79-ad83-9697b895974a@andromeda.star.bris.ac.uk>
 <0537CA80-1320-45CC-A992-9E5A7A1536C4@manchester.ac.uk>
 <20241118182302.ciew72ph4if2tccg@victor>
Message-ID: <MEYPR01MB6776FA50E5E0BD3D6E05D4A9C03C2@MEYPR01MB6776.ausprd01.prod.outlook.com>

Hi All

>From my perspective, SSO-next has two parts:

1. Rather than trying to look up details from somewhere else
(as is the case with the current SSO rec),
the use of the standard WWW-Authenticate/Authorization
(and Proxy-Authenticate/Proxy-Authorization) HTTP headers
means that we don't need to define how to handle standard flows like Basic Auth,
and standard web clients can be used (rather than something that needs to know
about VO standards).

2. Being able to accept arbitrary non-browser clients (i.e. data providers don't
need to add clients to their system, nor do developers need to fill out web form
to be part of the VO) by providing the missing context that some systems provide
via either being tied to specific platforms (this is where the ivoa-oauth part I
talked about at the interop comes in), or by supplementing the possible options
where there is no standard way to signal that a specific method is needed
(i.e. TLS, cookies).

(1) is the VO doing what everyone else does, (2) is the VO adding in the missing
puzzle pieces (and hopefully we can either replace our pieces with standard
ones, or we make them the actual standard so we can be more interoperable).

I think the main concern was WAFs (Web Application Firewalls) or other security
devices that force themselves between the user and the data provider messing
with the contents of the headers? The use of "Token" (which isn't standard)
seems widespread (I've seen it used by different Python web frameworks to
provide API keys), and AWS has their custom header
(https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html),
so I'm not too concerned that using something that starts with "ivoa-" will
break. The main thing that seems to happen is there's some proxy service in
front or as part of a cloud service and *that* also uses the standard
authentication headers (and so the headers will be overridden because the proxy
service is using them), but then presumably the client needs to know how to
handle logging into the proxy (which would be covered by the first part), and
given that login does the backend half already receive some indication of a
user, and maybe what's required is the service maps whatever identity it is
provided by the cloud service to that of the user (but from the VO perspective
this shouldn't be an issue)?

Paul's link to the Azure authentication is interesting, in that it seems similar
to what ivoa-oauth is trying to achieve, but is more bespoke and is assuming
Azure URLs. Reading rfc6750 and rfc9110 carefully
(https://datatracker.ietf.org/doc/html/rfc9110#name-authentication-scheme-exten
is worth reading through), Azure's usage is legitimate,
so for ivoa-oauth we could just use Bearer and use some additional parameters to
specify when to start the discovery process.

Regards
James

________________________________________
From: grid <grid-bounces at ivoa.net> on behalf of Markus Demleitner via grid <grid at ivoa.net>
Sent: Tuesday, 19 November 2024 5:23 AM
To: grid at ivoa.net
Subject: Re: motivation for SSO_Next custom www-authenticate: {auth-scheme}

Hi Paul (and Mark),

Two brief interjections from the Registry side of this matter:

On Mon, Nov 18, 2024 at 03:46:29PM +0000, Paul Harrison via grid wrote:
> > On 18 Nov 2024, at 15:17, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> >> 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.
> >
> > Where? As it stands the DataLink response table has no column
> > for such an ivorn.

(a) Please don't say IVORN; while we wrote Identifiers 2, we tried to
figure out what that might be and couldn't find a meaning that would
actually make sense. So: it's IVOID (or ivoid if you prefer; we're
talking to humans, and so a certain amount of case insensitivity is
fine even with me) throughout.

(b) We don't *have* a way to attach information on Authn requirements
in the Registry at this time either, and for now we have largely
given up on defining any. So, before we think about...

> If the mechanism does not exist yet it could be added, but the
> service self description
> https://www.ivoa.net/documents/DataLink/20231215/REC-DataLink-1.1.html#tth_sEc4.4<https://www.ivoa.net/documents/DataLink/20231215/REC-DataLink-1.1.html#tth_sEc4.4>
> would seem to be the place. The example shown does not have the

...going this way, we'd first have to say at least *what sort* of
information clients would find when resolving the IVOID. I'm happy
to cast any sensible plan into the VOResource schema, but so far I
don't even know what to cast.

-- Markus