SSO major editing

[Mark Taylor]

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
> >
> 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/