Authentication by non-browser clients

[Mark Taylor]

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/