From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=protonmail.com (client-ip=185.70.43.22; helo=mail-4322.protonmail.ch; envelope-from=jvanveen@protonmail.com; receiver=) Authentication-Results: mail.toke.dk; dkim=pass (1024-bit key) header.d=protonmail.com header.i=@protonmail.com header.b=OZ0A4UJ3 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by mail.toke.dk (Postfix) with ESMTPS id 314818DA90A for ; Sat, 30 Oct 2021 10:22:53 +0200 (CEST) Date: Sat, 30 Oct 2021 08:22:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1635582172; bh=dI3GQ92hzY0TCmxDTFQYkCoQq/NXBJvrPbtf61nucd0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=OZ0A4UJ34HV7D307xnbveK5fjTnvI41j2xCI2G7sJRUBGG1I01xrXKoKPRFq6Al8/ wcz3kIIXdUN1vHQDLhcvKT7J9z6DR5yHqyaSDq8MQBNG7SCbZxSOGPY4nN5boJxCob TPqzYQ48kM8e8XGg8esII7nmiDtDlV+lHBhNu2xE= To: Juliusz Chroboczek From: Jeroen van Veen Message-ID: In-Reply-To: <87y26bwwfo.wl-jch@irif.fr> References: <9SCVvWIB9TfyEmG6di6LYCmoEeeJ_2Fsqzh8Y58_q0wSF1hRxJ_2I3YKATYXSCnaZQMJ6CdhvseVnbHsDmnSheS5b9SvRk1f9xhna0e2Y5Q=@protonmail.com> <87pmsp3qnx.wl-jch@irif.fr> <8735on1ues.wl-jch@irif.fr> <87y26bwwfo.wl-jch@irif.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch Message-ID-Hash: IU4FECA32FYERSBWZUUV3CG3F523O4FN X-Message-ID-Hash: IU4FECA32FYERSBWZUUV3CG3F523O4FN X-MailFrom: jvanveen@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "galene@lists.galene.org" X-Mailman-Version: 3.3.4 Precedence: list Reply-To: Jeroen van Veen Subject: [Galene] Re: Config branch [was: User management] List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Thanks for the explanation! I regulary mix up authorisation and authenticat= ion :) Such an authorisation scheme would be a great feature. It would be interest= ing at some point to make authorisation methods pluggable in Pyrite (like "login w= ith 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=C3=A8ne 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 c= onfigured, then recordings won't be accessible and stats.json won't have basic auth? I assume the admin permission is needed to deploy Gal=C3=A8ne without addit= ional 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 a= ccess to recordings (read directly from disk and proxied through Pyrite admin) and s= tats.json (http call from Pyrite admin to http://localhost:8443/stats.json) don't seem to need a= n additional security layer. What do you think? Cheers, Jeroen =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Op vrijdag 29 oktober 2021 om 7:52 PM schreef Juliusz Chroboczek : > > 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 grou= p > > 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 U= I. > > > 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