<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div class="">Hi All,</div>
<div class=""><br class="">
</div>
<div class="">Honestly I'm not sure if this should be in Apps or GWS, but since I had mostly been thinking about this in the context of SSO I'll send it to GWS.</div>
<div class=""><br class="">
</div>
<div class="">I was playing around with hacking up PyVO for authentication, and realized that it's one-client approach meant we could accidentally send credentials from one provider to different providers. So at first I wrapped the pyvo.utils.http.session.request
 method which introspected the URL and would only apply auth if the request was to our domain.</div>
<div class=""><br class="">
</div>
<div class="">This is again, fine, if you're only talking to one service/instance at a time, but we have prod and test instances, and the credentials aren't exactly the same, so that code would need to be more complicated.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">So, there's at least three ways to go about this:</div>
<div class="">&nbsp;- the astroquery way, which I think means the client is specific to the backend, and you explicitly &quot;login&quot; for each one; or</div>
<div class="">&nbsp;- a generic client that is configured with an authentication mechanism that can introspect the URL and apply credentials as appropriate (this seems typical - it's the case with pyvo via pyvo.); or</div>
<div class="">&nbsp;- a generic meta-client that's is aware of properly configured backend clients, which can introspect the URL and select the client as appropriate</div>
</div>
<div class=""><br class="">
</div>
<div class="">I know Mark talked on per-site authentication a bit at the last interop - I'm not sure what approach he was using (feel free to chime in).</div>
<div class=""><br class="">
</div>
<div class="">I was thinking that it could be useful to have a generic credential manager and API, similar to git-credential-store or git-credential-cache, for all three client strategies.&nbsp;</div>
<div class=""><br class="">
</div>
<div class="">I did some light hacking with keyring [&nbsp;<a href="https://pypi.org/project/keyring/" class="">https://pypi.org/project/keyring/</a>&nbsp;], to see what would be a secure way to store credentials, out of curiosity regarding this:</div>
<div class=""><a href="https://gist.github.com/brianv0/34ecaac33ee5892caeb46d29364c7d14" class="">https://gist.github.com/brianv0/34ecaac33ee5892caeb46d29364c7d14</a></div>
<div class=""><br class="">
</div>
<div class="">In that gist</div>
<div class="">• There's a yaml that roughly corresponds to a way of describing credentials</div>
<div class="">• A user must declare the authentication context to the&nbsp;CredentialHelper. This is mostly because there's not an easy way to list credentials</div>
<div class="">&nbsp; - but the credentials could just be stored in one giant blob for the entire application</div>
<div class="">• The CredentialHelper can tell you which credentials to use for a given URL.</div>
<div class="">• If PyVO was using this, for example, might call `get_credential` for every URL and modify the auth object for it's `pyvo.util.http.session.request` as appropriate</div>
<div class=""><br class="">
</div>
<div class="">Anyway, I thought I'd just post these ideas to see if they are interesting to anyone. From an interop standpoint - an IVOA credential manager could be useful as more authenticated services come online, and it might mean less futzing for users
 that may be accessing multiple authenticated endpoints on TOPCAT, and PyVO or astroquery, for example.&nbsp;</div>
<div class=""><br class="">
</div>
<div class="">Brian</div>
</body>
</html>