Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <>
To: Jeroen van Veen <>
Cc: "" <>
Subject: [Galene] Re: Config branch [was: User management]
Date: Fri, 29 Oct 2021 19:52:11 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> 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

  reply	other threads:[~2021-10-29 17:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28 18:29 [Galene] User management Jeroen van Veen
2021-10-01 11:55 ` [Galene] " Juliusz Chroboczek
2021-10-01 14:05   ` Dave Taht
2021-10-01 14:20     ` [Galene] End-to-end encryption [was: User management] Juliusz Chroboczek
2021-10-01 14:38       ` [Galene] Re: End-to-end encryption Michael Ströder
2021-10-01 15:24       ` [Galene] Re: End-to-end encryption [was: User management] Dave Taht
2021-10-03 19:15   ` [Galene] Re: User management Jeroen van Veen
2021-10-26 19:02     ` [Galene] Config branch [was: User management] Juliusz Chroboczek
2021-10-27 18:23       ` [Galene] " Jeroen van Veen
2021-10-29  9:10       ` Jeroen van Veen
2021-10-29 17:52         ` Juliusz Chroboczek [this message]
2021-10-30  8:22           ` Jeroen van Veen
2021-10-01 14:43 ` [Galene] Re: User management Dernat Rémy
2021-10-03 19:15   ` Jeroen van Veen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='[Galene] Re: Config branch [was: User management]' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox