SSO major editing

Paul Harrison paul.harrison at manchester.ac.uk
Mon May 13 09:50:57 CEST 2024



> On 7 May 2024, at 15:54, Mark Taylor via grid <grid at ivoa.net> wrote:
> 
> My personal feeling about the SSO document up till now is that 
> there's quite a bit of text that's not serving much purpose.  
> It contains a list of auth technologies "approved for use in the 
> IVOA-SSO profile", but since these don't have to be interoperable, 
> I don't see the purpose of constraining the list in this way, 
> or of discussing them in a VO standard.  These sections also come
> with some "commentary", but IMHO there is little useful information in 
> there, since they reference back to the original (e.g. IETF) standards.
> 

This has also been my personal feeling about an SSO “standard” from the early days - SSO is 
in general driven by “market forces” outside the IVOA control - so that perhaps the whole aim should be 
an SSO “endorsed note” as we should only be describing patterns of using existing protocols rather than defining our own.

> So I think the scope of this document should be reconsidered.
> We no longer require the SecurityMethod definitions, having
> decided that this is not a Registry matter.  And I don't see much 
> point in providing an "approved" list of web-based technologies 
> for authentication.
> 
> 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://urldefense.com/v3/__https://wiki.ivoa.net/internal/IVOA/InterOpNov2023Apps/auth.pdf__;!!PDiH4ENfjr2_Jw!AKps2DM2YmM6cen6JUxi2nOhmXXFXhAZ8VTamNKHiKQkZ5Tq1JYGm2vnqIm_yAH1TBeet3riI0gmxOQK-Sd5$[wiki[.]ivoa[.]net]
> 
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.



> 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 document would perhaps acquire a new name or become a different
> document in the process.  If GWS agrees this is a good way forward,
> I'm willing to draft such a document.


> 
> I am aware that this suggestion is highly oriented to the requirements
> of TOPCAT/me (as well as other non-browser clients like PyVO).
> But I don't currently see what else we need in terms of VO-specific
> standardisation in this area.  If you have examples of such things,
> please disagree with me!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20240513/b9714239/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20240513/b9714239/attachment-0001.p7s>


More information about the grid mailing list