motivation for SSO_Next custom www-authenticate: {auth-scheme}

[Paul Harrison]

Hi,

I have to admit that I had been ignorant of the actual motivation for the https://wiki.ivoa.net/twiki/bin/view/IVOA/SSO_next custom www-authenticate header auth schemes until the just finished Interop meeting - i.e. why just having the authentication information in the registry was seen as not sufficient - I learnt that the motivation was that the urls returned in a datalink response might require authentication. In my defence, I do not think that this motivation is documented in either the wiki page or the pull request on the SSO document.

As I have said earlier in this list, I have reservations about the custom auth scheme as it might not be acceptable to institutional security policies over which the IVOA has no control and header rewriting proxies/firewalls might just filter out/reject such things anyway.

Having understood (I think) the motivation, I do not think that in an “SSO” environment there is a particularly compelling reason to add this extra complexity. The point being that if a particular IVOA service has been discovered in the registry and the client has used the registry based security information to allow the user to log-in, then if that service is returning urls in datalink responses that require further log-ins outside its own SSO security realm then it will be a pretty poor user experience anyway. Indeed I am not sure how the original service could even know about protected URLs to resources that exist outside its own immediate security realm without credentials itself to discover those resources, in which case access to those resources would be covered by the SSO federation of the original authentication.

The overall argument is that if you look at individual interactions with a random URL, then perhaps the custom www-authenticate headers are needed, but if you look at it in an SSO context then the authentication that was obtained by looking at the registered security information when first interacting with an IVOA service should be applicable to any end-points that service should return.

Paul.


-------------- 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/20241118/28e10245/attachment.p7s>