Authentication - Potential around a credential store/API

[Mark Taylor]

Brian,

On Thu, 28 Mar 2019, Van Klaveren, Brian N. wrote:

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

Good point.  In some circumstances TOPCAT could do that too: send
credentials intended for one service running HTTP Basic Authentication
to another such service.  Historically that has probably happened not
often, and mostly with services and credentials that don't take
authentication too seriously, but I should tighten it up in my
current round of authentication upgrades.
 
> 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

As Markus says, the Realm is one way to tackle this which goes beyond
examining the URL, at least as regards HTTP 401 challenge/response
authentication i.e. Basic and Digest authentication:

On Fri, 29 Mar 2019, Markus Demleitner wrote:

MD> Hmmmmm. I'd first like to split the problem space into SSO and
MD> non-SSO, the latter of which would comprise HTTP basic or
MD> equivalent authentication methods. In these, a service presents a
MD> "Realm" to the client (essentially saying what you're authenticating
MD> for; Web browsers apparently have by and large stopped showing these,
MD> though), and the client then requests the credentials for that
MD> "Realm" from the user (or a, possibly password-protected, cache).
MD>
MD> In that scenario, yes, more or less malicious services presenting
MD> realm names from other services and then snarfing cached credentials
MD> are possible, and indeed, troubled browser vendors in the mid-90ies.

The basic HTTP challenge-response authentication mechanism
(described in RFC 2617, updated by RFC 7235) is not as leaky as that:
the Realm has always been taken in conjunction with the root URL
to form the "protection space".  So:

MD> I *think* most browsers therefore cache their HTTP Basic credentials
MD> by host and realm, which probably is reasonable even in the VO.  If
MD> you switch to a mirror, you'll have to re-authenticate, but that
MD> doesn't sound like it's asked to much.

the standards require you do to that in any case if you're using
HTTP 401 challenge-response authentication properly.

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

Yes, I'm certainly interested in this.  I'm still working my way through
various aspects of getting authentication working and haven't thought
much yet about credential caching.  It would certainly be nice to have
something that users can set up once for all clients.  If I'm going
to use it from Java, it would have to be based on something that's
not OS- or Python/C-specific, which may or may not be feasible.
Something like a yaml-based file in a standard location would
probably be OK.

Thanks for sharing your thoughts, I'm all ears for bright ideas
relating to client authentication issues.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/