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

[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