<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This has been interesting, but I'll chime in here on the custom/ivoa auth schemes. The idea of those is that they are used in www-authenticate header challenges to convey some info about how a client can acquire the credentials but they are never used with authorization header to authenticate. When actually authenticating, clients use standard mechanisms (cookie: <blah>, authorization: bearer <blah>, etc)<br></div><div class="gmail_default" style="font-size:small"> </div><div class="gmail_default" style="font-size:small">The reason for inventing ivoa challenges is that existing challenges (eg bearer from that RFC mark mentioned) have their own set of additional properties they can convey when used in the www-authenticate (eg errors for expires token) and it did not look like adding more of our own was valid.<br></div><div><br></div><div><div style="font-size:small" class="gmail_default">As for actual naming, we had sort of settled on "ivoa_bearer" meaning "how to get a token", "ivoa_x509" for "how to get a certificate", and "ivoa_cookie" for "how to get a login cookie".<br></div></div><br><div style="font-size:small" class="gmail_default">Anyway, kudos to James for taking another stab at this, and I think the 'allowed_domains' bit is the missing bit that tries to prevent enabling phishing attacks (sending tokens to a rogue service in a different domain). That's the bit that we always found missing from the sea of standards in this area. Well, cookies have the implicit host/domain name and realm stuff, but that ends up making issuing cookies for multiple domains (<a href="http://cadc-ccda.hia-iha.nrc-cnrc.gc.ca">cadc-ccda.hia-iha.nrc-cnrc.gc.ca</a> and <a href="http://canfar.net">canfar.net</a>) a pain.</div><div style="font-size:small" class="gmail_default"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Oct 2024 at 04:18, Paul Harrison via grid <<a href="mailto:grid@ivoa.net">grid@ivoa.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 11 Oct 2024, at 09:41, Mark Taylor via grid <<a href="mailto:grid@ivoa.net" target="_blank">grid@ivoa.net</a>> wrote:<br>
> <br>
> On Thu, 10 Oct 2024, Russ Allbery via grid wrote:<br>
> <br>
>>> There'd also the weirdness of the challenge being `ivoa-oauth2` and the<br>
>>> response being `bearer`, but that's a minor thing.<br>
>> <br>
>> Honestly, I'd rather fix that as well: make the challenge be bearer but<br>
>> add other IVOA-specific attributes to tell the client how to go get that<br>
>> bearer token following our protocol.<br>
> <br>
> We could do that, but I don't know why it would be desirable,<br>
> and I don't see a problem with the challenge auth-scheme and the<br>
> first token in the Authorization header having different values.<br>
> The other SSO_next schemes don't follow that pattern; ivoa_cookie<br>
> and ivoa_x509 don't use the Authorization header at all.<br>
> <br>
> If we use "bearer" as www-authenticate challenge auth scheme,<br>
> then we're sitting on top of RFC6750 and might possibly run into<br>
> compatibility issues with that standard or interfere with other<br>
> Bearer-related auth-param namespaces.  If we use our own scheme<br>
> "ivoa-oauth2" we can do what we want.<br>
<br>
I have some reservations about the whole approach of having our own auth schemes<br>
<br>
* Security is important and the SSO protocols are fairly complex, so it is probably good practice to use established libraries/servers in the implementation - the libraries might not have easy hooks to change the headers from the “standard” ones.<br>
* It might be the case that various firewall/proxy settings might reject non-standard header values.<br>
* Although it seems like an obvious thing to put in the URL of where to access a Bearer token in the www-authenticate header it does not seem to be done particularly widely - perhaps again this is done for security reasons so that it is not easy for a bot to attempt a denial of service attack on the authentication service. - We do have a solution for this as the service will have been discovered in the registry, so the information could be there.<br>
<br>
Paul..</blockquote></div>