Authentication - Potential around a credential store/API

[Markus Demleitner]

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?


> 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