Authentication by non-browser clients

[Mark Taylor]

Dear DSP/GWS/GRID,

TL;DR:
------

Has there been any progress on the (tentatively-named) IVOA-IAM
document suggested in Malta by Sara?

If not, should I volunteer to draft such a document for review?


Details:
--------

Concerning how to allow non-browser clients to authenticate against
VO services, we have had presentations with essentially the same
technical content at several interops in recent years:

  Sara B: SSO_next open discussion (Malta 11/2024):
     https://wiki.ivoa.net/internal/IVOA/InterOpNov2024GWS/Interop_Malta_2024_Sara_Bertocco.pdf

  Mark T: Authentication in TOPCAT (Tucson 11/2023):
     https://wiki.ivoa.net/internal/IVOA/InterOpNov2023Apps/auth.pdf

  Mark T: Authentication for non-browser clients: progress (online 04/2022):
     https://wiki.ivoa.net/internal/IVOA/InterOpApr2022GWS/auth.pdf

In summary these address the problem of how non-browser clients
can discover and use an authentication method when pointed at a
(e.g. TAP or DataLink) service without having out-of-band knowledge
about such a service.  The answer is, briefly, to do the following:

   - use www-authenticate headers, in line with RFC 7235

   - probe the capabilities endpoint prior to using TAP,
        in order to get such a header

   - optionally use ivoa-defined www-authenticate schemes for
        auth method discovery (ivoa_cookie, ivoa_x509, maybe something
        for use with bearer tokens TBD) - though Basic Auth over HTTPS
        with or without out-of-band knowledge is also a possibility

Concerns were raised in discussion in Malta that since much of the
authentication infrastructure is out of our hands, the approach of
defining our own www-authenticate schemes may run into problems.
I don't understand the wider picture well enough to know how true
that is, but such custom schemes are already in place and working
in production services at ESAC (using ivoa_cookie for e.g. Gaia,
Euclid, PDS TAP and DataLink services) and at CADC (using ivoa_x509 -
currently a bit broken, but it was working), so we have a proof
by example that it works in at least some contexts.
DaCHS also uses the above outline, but with the standard Basic Auth
authentication scheme.  An approach which uses part of this proposal
(probe TAP capabilities endpoint to initiate authentication prior
to TAP usage, but use the standard Basic Auth scheme with a token
acquired out-of-band) is in use at Rubin
(https://rsp.lsst.io/v/usdfdev/guides/auth/using-topcat-outside-rsp.html)

So: no service is required to use any non-standard (VO-specific)
prescriptions offered here, but those prescriptions are in
operational use in some services and solving problems that do not
otherwise have solutions.

Implementation on the client side is available at least in the AUTH
library used by TOPCAT/STILTS (available as a standalone no-dependency
java library).  I don't know whether there are implementations
in other applications or libraries.

These client- and server-side implementations have been in place
and in production use for more than a year, but standardisation seems
to have stagnated.  At present, documentation for the proposal
is scattered and inconsistent; it's in the somewhat outdated
https://wiki.ivoa.net/twiki/bin/view/IVOA/SSO_next wiki page,
in the presentations listed above, and in running code.
Some of the content is also in the current unpublished github draft
of the SSO document thanks to a PR written by Brian Major
(https://github.com/ivoa-std/SSO/pull/10, merged in May 2022),
but it may require further review, and Sara's suggestion in Malta
(which I agree with) is for a new document with a different name
and reduced scope.

There is some more work to do on the proposal (better documentation
of authentication scope for certain schemes, some way to integrate OAuth)
but to me there's enough there to make it worth documenting properly
in its current state, at least in draft form.

I could make a presentation on all this at the upcoming interop,
but it would mostly just repeat what's been said before, so
I don't feel that on its own that would constitute progress.

Are there plans in place to move this forward?  If not, how do
DSP chair/vice-chair/members feel about me volunteering to draft
a (probably quite short) Note or a REC-track document documenting
the proposal for review by other DSP members?  I *might* manage
to have a draft ready by the interop.

Mark

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