Authentication - Potential around a credential store/API

[Giuliano Taffoni]

Hi Brian
I am not sure about the credential exchange (malicious?) when you are talking about SSO where in practice you are exchanging a short living token.
The picture I have in mind is a client that contacts a  server and gets as reply a redirect to an IdP, then  the client authenticate to the IdP and is redacted back
To the service. It is standard with a browser, I am not sure what happens with a python client (eventually a cli). 

We had a long discussion in Trieste about how to allow a client to access multiple distributed sources and it is really a hot and complex topic.
Some of the complexity comes also from the needs for the client to “understand” more than one auth mechanism and IdP interactions,
For this reason, we are thinking In terms of SSO proxy (maybe an IVOA SSO proxy)  that as far as I understand acts as your  your meta-client (correct me If I misunderstood )
and with an identity linking system (I have different Internet personalities and I am not the only one :-)). We have a prototype for that, and again we are not
the only one that produced this sort of service.
 
The problem is that many of this concepts affects the Registry.

Regards
G.



> On 28 Mar 2019, at 18:37, Van Klaveren, Brian N. <bvan at slac.stanford.edu> wrote:
> 
> Hi All,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> So, there's at least three ways to go about this:
>  - the astroquery way, which I think means the client is specific to the backend, and you explicitly "login" for each one; or
>  - 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
>  - a generic meta-client that's is aware of properly configured backend clients, which can introspect the URL and select the client as appropriate
> 
> 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).
> 
> 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. 
> 
> I did some light hacking with keyring [ https://pypi.org/project/keyring/ ], to see what would be a secure way to store credentials, out of curiosity regarding this:
> https://gist.github.com/brianv0/34ecaac33ee5892caeb46d29364c7d14
> 
> In that gist
> • There's a yaml that roughly corresponds to a way of describing credentials
> • A user must declare the authentication context to the CredentialHelper. This is mostly because there's not an easy way to list credentials
>   - but the credentials could just be stored in one giant blob for the entire application

That is done by the proxy so the apps are not obliged to get this info. 

> • The CredentialHelper can tell you which credentials to use for a given URL.

Again if you have a proxy you can pic the identity you need for the URL (but the URL must advertise with identity/credetial it requires)

> • 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
> 
> 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. 
> 
> Brian

That’s my two cents
Regards
G.