From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=irif.fr (client-ip=2001:660:3301:8000::1:2; helo=korolev.univ-paris7.fr; envelope-from=jch@irif.fr; receiver=) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by mail.toke.dk (Postfix) with ESMTPS id C32A78DA2F4 for ; Fri, 29 Oct 2021 19:52:15 +0200 (CEST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 19THqE2q017370; Fri, 29 Oct 2021 19:52:14 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id F0B31D2717; Fri, 29 Oct 2021 19:52:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id iJ3xv93kqrAW; Fri, 29 Oct 2021 19:52:12 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0234BD2714; Fri, 29 Oct 2021 19:52:12 +0200 (CEST) Date: Fri, 29 Oct 2021 19:52:11 +0200 Message-ID: <87y26bwwfo.wl-jch@irif.fr> From: Juliusz Chroboczek To: Jeroen van Veen In-Reply-To: References: <9SCVvWIB9TfyEmG6di6LYCmoEeeJ_2Fsqzh8Y58_q0wSF1hRxJ_2I3YKATYXSCnaZQMJ6CdhvseVnbHsDmnSheS5b9SvRk1f9xhna0e2Y5Q=@protonmail.com> <87pmsp3qnx.wl-jch@irif.fr> <8735on1ues.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 29 Oct 2021 19:52:14 +0200 (CEST) X-Miltered: at korolev with ID 617C34CE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 617C34CE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 617C34CE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Message-ID-Hash: K3XOKEXRJT3MC5BOJZRPVHZ2SWTP2SCW X-Message-ID-Hash: K3XOKEXRJT3MC5BOJZRPVHZ2SWTP2SCW X-MailFrom: jch@irif.fr 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 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: > 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