[Galene] Re: Config branch [was: User management]

[Jeroen van Veen <jvanveen@protonmail.com>]

Thanks for the explanation! I regulary mix up authorisation and authentication :)
Such an authorisation scheme would be a great feature. It would be interesting at
some point to make authorisation methods pluggable in Pyrite (like "login with Github" or LDAP).
Would a change in a user's permissions mean that it would need to request a new token,
or should it be possible to change the permissions bound to a token from a Galène config file?

I also gave the multiple admin permission some more thought. Would it be an idea to make
the permission check for stats.json optional? E.g. if there are no admins configured,
then recordings won't be accessible and stats.json won't have basic auth?

I assume the admin permission is needed to deploy Galène without additional dependencies,
while having basic-auth secured endpoints for stats.json and recordings. In cases where a
proxy like Nginx and an in-between service like Pyrite admin is used, the access to
recordings (read directly from disk and proxied through Pyrite admin) and stats.json (http call
from Pyrite admin to http://localhost:8443/stats.json) don't seem to need an
additional security layer. What do you think?

Cheers,

Jeroen





‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Op vrijdag 29 oktober 2021 om 7:52 PM schreef Juliusz Chroboczek <jch@irif.fr>:

> > How would JWT authentication impact the storage of credentials in
>
> > Galene? I encountered JWT authentication recently and noticed it
> >
> > contains user information payload. Would that impact where the user's
> >
> > credentials may be stored?
>
> The client's credentials, not the user's credentials. The authorisation
>
> server doesn't authenticate users, it authorises clients.
>
> > For instance, would Galene call a configurable HTTP endpoint that will
> >
> > do the authentication and return a JWT?
>
> The JavaScript client will call the endpoint before it even attempts to
>
> connect to Galene's server. Galene will never see a password.
>
> The flow I'm currently envisioning is the following. The client JS
>
> queries the user for username and password, then performs a POST request
>
> to the authorization server. The authorisation server does its thing (for
>
> example, it consults an LDAP database), then returns a signed token
>
> indicating the permissions granted to the client. The client code then
>
> authentifies with the Galene server using the token. The client code will
>
> not need to parse the token, it will merely forward it from the auth
>
> server to Galene.
>
> (Other flows will be possible by changing the Javascript, for example
>
> flows where not only the server but also the client never sees a password,
>
> similar to the "login with github" feature, but that's something that I'm
>
> less likely to implement myself.)
>
> The only requirements are that (i) the auth server will need to know the
>
> private key associated to the public key stored by Galene, and (ii) the
>
> channel between the client JS and the auth server will need to be secure.
>
> > What user information will be stored by Galene?
>
> None at all. The only information stored in Galene is the public key
>
> associated with a given group. The auth server will need to sign its JWTs
>
> with the associated private key.
>
> > Would it make sense to have user deduplication with the current
> >
> > file/authentication scheme like this?
>
> Galene will no longer have the notion of users -- it will only know that
>
> a given client has been (temporarily) authorised to log into a given group
>
> with a given username. The username will no longer have any significance
>
> for Galene, it will merely be an opaque string that is displayed in the UI.
>
> > One last thing; in case a central users.json makes sense; would it be
> >
> > helpful to allow Galene to permit unknown fields, to be able to store
> >
> > additional arbitrary user information?
>
> You'll be welcome to do whatever you wish in the auth server. It is yet
>
> to be decided whether the current authorisation scheme will remain, or
>
> whether it will either be simplified or removed altogether.
>
> -- Juliusz