SSO major editing

[James Tocknell]

Hi All

I added some notes on OAuth/OIDC that I'd been collecting to the end of https://wiki.ivoa.net/twiki/bin/view/IVOA/SSO_next (which I said I'd do ages ago, also let me know if I've messed up something, it's the first time I've tried using twiki). I agree with Mark that standardising now IVOA cookie+client cert, plus specifying how to do discovery, rather than trying to get something using OAuth/OIDC into, makes more sense (because OAuth/OIDC is a mess, and it's not always clear what parts clients and servers support). Maybe in parallel to finalising whatever SSO next will be called, those who have OAuth/OIDC servers should document what they're using so we can see what the common baseline is? For example, at AAO and Data Central, we use Apereo CAS (https://apereo.github.io/cas/7.0.x/index.html) for our SSO across all the services we can get to support it (and it documents what OAuth/OIDC flows it supports); and I know the ESO archive uses at least the "resource owner credentials flow" (or "password grant", there's various names for the same thing), which is unfortunately going away in OAuth 2.1, as otherwise it would be the easiest for non-browser clients to implement, having written a wrapper around it for accessing the ESO archive, but what do other groups use? Should we make a page under the SSO next page where we tabulate that?

Regards
James

________________________________________
From: grid <grid-bounces at ivoa.net> on behalf of Mark Taylor via grid <grid at ivoa.net>
Sent: Monday, 13 May 2024 6:14 PM
To: Paul Harrison
Cc: Grid and Web Services WG
Subject: Re: SSO major editing

Paul,

thanks for your comments.

On Mon, 13 May 2024, Paul Harrison wrote:

> > What we do need is the description of how to initiate authenticated
> > access to VO services from non-browser clients, since there are in
> > general not standards on the wider internet about how to do this.
> > That is more or less the scope of what's written in the SSO_next wiki
> > page, though the text there is somewhat out of date; I claim that the
> > standards text we really require in this area is basically what I
> > presented on the pages labelled (bottom right) 3, 4 and 6 of my Apps
> > presentation from Tucson:
> > https://wiki.ivoa.net/internal/IVOA/InterOpNov2023Apps/auth.pdf<https://wiki.ivoa.net/internal/IVOA/InterOpNov2023Apps/auth.pdf>
> >
> Again I agree that it is only non-browser clients that are a “problem” in that the various “flows” that occur
> in browser based interactions are generally directed by pages presented to the user who then makes decisions based on instructions presented. There are a number of actions that browsers do such as presenting cookies and headers in subsequent requests that any non-browser client should be expected to do also, that do not necessarily need “standardising”. I guess what I am saying is that making a broad statement like “non-browser clients should behave like browsers wherever possible" (and then list the exceptions/extensions) is a more future-proof statement than repeating all the things that browsers do with 401 and www-authenticate headers etc.

Sure, I would take that as read. The thing that is missing is the
bootstrapping: how does a non-browser client, armed only with (e.g.)
a TAP service URL, figure out how to initiate authenticated
communications with it (determine what authentication method is in use,
and what steps to take to acquire a token/cookie/whatever).
There do not appear to be industry standards for addressing this problem.
Once a non-browser client is in possession of enough information for
it to behave like a browser as far as authenticated communications go,
we do not need IVOA text to say any more.

> > So I make the provocative suggestion that the SSO document should be
> > rewritten more or less from scratch, including some but not much text
> > from its current form, describing only(?) how non-browser clients
> > can interact with authenticated services in a VO-standard way.
> > It should describe in detail how such interaction works,
> > but only for those authentication methods where we actually
> > understand how to do it (currently: BasicAA, cookies and X.509
> > certificates; hopefully bearer tokens will be added at some point).
>
> The only problem with this is that bearer tokens are probably the most prevalent SSO mechanism at the moment, and consequently the most urgent to tackle.

The TOPCAT public release already contains working code based on
the SSO_next wiki page that talks to ESAC using cookies and CADC
using certificates.

I would love to prototype something to work with bearer tokens
if there is a service provider out there that will participate!
If that sounds like you, please get in touch.

I have an idea of how to address the remaining problems with bearer
tokens within this framework (essentially: deliver the token as if
it was a cookie and use existing scoping rules from RFC 2965).
However, without any implementation on either side I think it
would be premature to write standards text codifying this approach.

Mark

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