Authentication by non-browser clients

[Mark Taylor]

Dear DSP,

with support from Sara and Jesus I have drafted a document on
this topic, starting from the text that Sara wrote.

This is now available at

   https://github.com/ivoa-std/IAP

I will present this draft (remotely) in the DSP session at the
upcoming Interop.  In the mean time, any comments on it
(e.g. as github issues or PRs) would be very welcome.

Thanks

Mark

On Mon, 28 Apr 2025, Mark Taylor wrote:

> Many thanks Sara.
> 
> I'll take a look at the current draft and consider what's the best
> way forward.
> 
> On Mon, 28 Apr 2025, Bertocco, Sara wrote:
> 
> > Hi Mark, everyone,
> > I really appreciate and accept Mark's offer. I think he is the right person
> > to describe in detail the authentication process for non-browser clients,
> > thanks to his expertise and experience in implementation (experience that I
> > do not have, which was evident to me when I tried to write the document).
> > The work I have done so far is available at
> > https://github.com/bertocco/IVOA-Authentication-Process. It is a draft, an
> > attempt to merge the wiki and presentations done so far on the topic at the
> > latest Interops. Maybe, something can be reused.
> > Mark, I leave the floor to you and, if I can be useful (re-reading the
> > document or helping with some section), I am available.
> > Cheers, Sara
> > 
> > On Thu, Apr 24, 2025 at 3:33 PM Mark Taylor via dsp <dsp at ivoa.net> wrote:
> > 
> > > 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/
> > >
> > 
> 
> --
> Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk          https://www.star.bristol.ac.uk/mbt/
> 

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