Authentication - Potential around a credential store/API

[Giuliano Taffoni]

Hi Markus

> On 29 Mar 2019, at 14:43, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
> 
> Hi Brian,
> 
> On Thu, Mar 28, 2019 at 05:37:30PM +0000, Van Klaveren, Brian N. wrote:
>> 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
>> • The CredentialHelper can tell you which credentials to use for a given URL.
>> • 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
> 
> Hmmmmm. I'd first like to split the problem space into SSO and
> non-SSO, the latter of which would comprise HTTP basic or
> equivalent authentication methods. In these, a service presents a
> "Realm" to the client (essentially saying what you're authenticating
> for; Web browsers apparently have by and large stopped showing these,
> though), and the client then requests the credentials for that
> "Realm" from the user (or a, possibly password-protected, cache).
> 
> In that scenario, yes, more or less malicious services presenting
> realm names from other services and then snarfing cached credentials
> are possible, and indeed, troubled browser vendors in the mid-90ies.
> 
> I *think* most browsers therefore cache their HTTP Basic credentials
> by host and realm, which probably is reasonable even in the VO.  If
> you switch to a mirror, you'll have to re-authenticate, but that
> doesn't sound like it's asked to much.
> 
> Following this model, I'd probably rather structure your credentials
> records like this:
> 
> auth_record:
>  securityMethodId: #BasicAA
>  host: basic-ivoa.example.com
>  realm: group-members-only
>  username: foo
>  password: bar
> 
> However, I'd be surprised if there weren't already something like
> this for, say, python-requests, perhaps even with encrypted storage
> of the credentials (that I wouldn't consider terribly important given
> what we're talking about *here* if only people didn't re-use
> passwords).
> 
> 
> Considerations, I think, become rather different once you go properly
> SSO, where some service grants you tokens which give you access some
> other group of services (where, of course, these tokens can still be
> stolen, but that's another class of attacks).  Most of the time,
> these tokens will be rather short-lived, and so I don't think users
> would normally write them into a configuration file.  
> 
> Whatever credentials you use to authenticate to the token granting
> service might be eligible for storing in some file, though.
> 
> The link between the service and the token generator, however, is
> public data that users shouldn't have to store in a private
> configuration file (though a hypothetical creds library might still
> handle the information).
> 
> Perhaps not surprisingly, I think such information should come from
> the Registry, and I'd really like to prototype this there.  So, do
> you do the OAuth2 part already?  I see there's the token_endpoint,
> which looks like it is what a securityMethod on the interface would
> need to declare.  Use and X-oauth-basic I guess also have to go there
> (where oauth-basic sounds a bit scary).  What about redirect_uri?
> Would that be required in a registry record?
> 


Well I agree that this has an impact on the Registry, and we should understand 
how deep it is. 

Bye
G.


> 
>> 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.
> 
> I'm all for using as few different auth technologies as possible and
> then giving our users simple support for them; bonus points if we
> somehow magic things such that TOPCAT and astropy-based code could
> share credentials (but not if this complicates matters substantially
> beyond telling users where and how to store their username/password
> pairs).
> 
> Thanks for getting the ball rolling,
> 
>           Markus