Authentication by non-browser clients

[Bertocco, Sara]

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dsp/attachments/20250428/e0fd2204/attachment.htm>