Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
* [Galene] User management
@ 2021-09-28 18:29 Jeroen van Veen
  2021-10-01 11:55 ` [Galene] " Juliusz Chroboczek
  2021-10-01 14:43 ` [Galene] Re: User management Dernat Rémy
  0 siblings, 2 replies; 14+ messages in thread
From: Jeroen van Veen @ 2021-09-28 18:29 UTC (permalink / raw)
  To: galene

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

Hey!

I'm working on and off a management interface for Galene in Pyrite (https://github.com/garage44/pyrite/issues/9)
and was wondering how to best approach user management. Ideally the user definitions are separate from the group
files. Any thoughts on a separate users.json that contains entries like:

[
{"name":"jeroen","password":"foobar","groups":{"pyrite":{"op":true,"presenter":true,"other":true}}},
{"name":"pyrite","password":"foobar","groups":{}}
]

The idea is to be able to set permissions per group, while having only one user entry at a central place. After modifying users.json,
there will be another action from the backend that updates all accompanying group files. As I understand it, there is only 1 administrator user
defined in data/passwd? Would it be feasible to have multiple users in there, so each user can have an administrator flag?

And what would be a good approach to delete or rename a group? Doing a request to the new group name works fine to make
it available in the list, but I wonder what will happen to the group that is being renamed/deleted. Should I use protocol.js in the
backend as well to connect to a group and kick all users out, before attempting to rename/delete it? If so, would it be useful to have
a 'hidden' user available that can act on behalf of the backend?

Cheers,

Jeroen

[-- Attachment #2: Type: text/html, Size: 2236 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: User management
  2021-09-28 18:29 [Galene] User management Jeroen van Veen
@ 2021-10-01 11:55 ` Juliusz Chroboczek
  2021-10-01 14:05   ` Dave Taht
  2021-10-03 19:15   ` [Galene] Re: User management Jeroen van Veen
  2021-10-01 14:43 ` [Galene] Re: User management Dernat Rémy
  1 sibling, 2 replies; 14+ messages in thread
From: Juliusz Chroboczek @ 2021-10-01 11:55 UTC (permalink / raw)
  To: Jeroen van Veen; +Cc: galene

> Any thoughts on a separate users.json that contains entries like:
> 
> [
>     {"name":"jeroen","password":"foobar","groups":{"pyrite":
>         {"op":true,"presenter":true,"other":true}}},
>     {"name":"pyrite","password":"foobar","groups":{}}
> ]
> 
> The idea is to be able to set permissions per group, while having only
> one user entry at a central place.

I'm open to that.

> After modifying users.json, there will be another action from the
> backend that updates all accompanying group files. As I understand it,
> there is only 1 administrator user defined in data/passwd? Would it be
> feasible to have multiple users in there, so each user can have an
> administrator flag?

I think we should make the data/passwd file obsolete, and define the
administrator role per-user in the users.json file.

> And what would be a good approach to delete or rename a group? Doing
> a request to the new group name works fine to make it available in the
> list, but I wonder what will happen to the group that is being
> renamed/deleted.

The group will exist as long as there are users, but no new users should
be able to login.  At least, that's the way the code was written, but
I don't recall if I've tested it.

> Should I use protocol.js in the backend as well to connect to a group
> and kick all users out, before attempting to rename/delete it?

I don't feel it's necesary, but it's up to you.

> If so, would it be useful to have a 'hidden' user available that can act
> on behalf of the backend?

No, please no hidden users -- normal users should have full visibility
into what's being done to them.  If you need a system user, please make it
visible.

-- Juliusz

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: User management
  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-03 19:15   ` [Galene] Re: User management Jeroen van Veen
  1 sibling, 1 reply; 14+ messages in thread
From: Dave Taht @ 2021-10-01 14:05 UTC (permalink / raw)
  To: Juliusz Chroboczek; +Cc: Jeroen van Veen, galene

On Fri, Oct 1, 2021 at 4:55 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> > Any thoughts on a separate users.json that contains entries like:
> >
> > [
> >     {"name":"jeroen","password":"foobar","groups":{"pyrite":
> >         {"op":true,"presenter":true,"other":true}}},
> >     {"name":"pyrite","password":"foobar","groups":{}}
> > ]
> >
> > The idea is to be able to set permissions per group, while having only
> > one user entry at a central place.
>
> I'm open to that.
>
> > After modifying users.json, there will be another action from the
> > backend that updates all accompanying group files. As I understand it,
> > there is only 1 administrator user defined in data/passwd? Would it be
> > feasible to have multiple users in there, so each user can have an
> > administrator flag?
>
> I think we should make the data/passwd file obsolete, and define the
> administrator role per-user in the users.json file.
>
> > And what would be a good approach to delete or rename a group? Doing
> > a request to the new group name works fine to make it available in the
> > list, but I wonder what will happen to the group that is being
> > renamed/deleted.
>
> The group will exist as long as there are users, but no new users should
> be able to login.  At least, that's the way the code was written, but
> I don't recall if I've tested it.
>
> > Should I use protocol.js in the backend as well to connect to a group
> > and kick all users out, before attempting to rename/delete it?
>
> I don't feel it's necesary, but it's up to you.
>
> > If so, would it be useful to have a 'hidden' user available that can act
> > on behalf of the backend?
>
> No, please no hidden users -- normal users should have full visibility
> into what's being done to them.  If you need a system user, please make it
> visible.


Yes, no sneaky users please. It's really hard to trust other "modern"
videoconferencing servers.

In fact I was thinking perhaps that having a "jch-blessed" binary
might be of use, but I have not
the foggiest idea how to go about having a means to prove, e2e, that
you are really
talking to a trusted videoconferencing server. I did rather like the
insertable streams idea:

https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/

> -- Juliusz
> _______________________________________________
> Galene mailing list -- galene@lists.galene.org
> To unsubscribe send an email to galene-leave@lists.galene.org



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] End-to-end encryption [was: User management]
  2021-10-01 14:05   ` Dave Taht
@ 2021-10-01 14:20     ` 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
  0 siblings, 2 replies; 14+ messages in thread
From: Juliusz Chroboczek @ 2021-10-01 14:20 UTC (permalink / raw)
  To: Dave Taht; +Cc: galene

> talking to a trusted videoconferencing server. I did rather like the
> insertable streams idea:
> 
> https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/

I like the idea of end-to-end encryption, but I feel that I'm not ready to
implement it yet.

Insertable streams gives you the ability to perform end-to-end encryption,
but it does not define the encryption format.  So you end up having to
design your own crypto, with all the dangers that this entails.  Before we
can use insertable streams, we need to have a clear specification of
a recommended encrypted format to use with it.  There is an IETF effort to
do that, but it's IETF, so it won't conclude before a few years.  (Last
time I checked, they were discussing the benefits of two approaches,
SFrame and Spacket, if memory serves, and there was no clear consensus yet.)

There are two other issues.  First, in order to do simulcast and keyframe
optimisation, Galene needs to look inside the packets.  Jitsi works around
the issue by not encrypting the first 8 octets of every packet, even one
that does not start a frame, but it's difficult to tell what amount of
information this leaks.  The proper solution to the issue is to have an
unencrypted header extension that contains the required information, but
that's only available with AV1 and not implemented yet (Chrome uses
a nonstandard format for AV1).

Second, simulcast for VP8 requires rewriting the packet contents, which is
obviously impossible if the data is encrypted.  This is solved with VP9,
but what it means is that you cannot have encrypted simulcast with VP8,
something has to give.

In short, Dave, I have given some serious thought to the issue of
end-to-end encryption, and I feel that it will need to wait a couple of
years before we can deploy it in production.

-- Juliusz

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: End-to-end encryption
  2021-10-01 14:20     ` [Galene] End-to-end encryption [was: User management] Juliusz Chroboczek
@ 2021-10-01 14:38       ` Michael Ströder
  2021-10-01 15:24       ` [Galene] Re: End-to-end encryption [was: User management] Dave Taht
  1 sibling, 0 replies; 14+ messages in thread
From: Michael Ströder @ 2021-10-01 14:38 UTC (permalink / raw)
  To: galene

On 10/1/21 16:20, Juliusz Chroboczek wrote:
> In short, Dave, I have given some serious thought to the issue of
> end-to-end encryption, and I feel that it will need to wait a couple of
> years before we can deploy it in production.

Full ack.

It's better to spend the time on making it easier for people to run 
their own Galène instance on own hardware to reach the goal of real 
confidentiality - including the meta data.

Ciao, Michael.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: User management
  2021-09-28 18:29 [Galene] User management Jeroen van Veen
  2021-10-01 11:55 ` [Galene] " Juliusz Chroboczek
@ 2021-10-01 14:43 ` Dernat Rémy
  2021-10-03 19:15   ` Jeroen van Veen
  1 sibling, 1 reply; 14+ messages in thread
From: Dernat Rémy @ 2021-10-01 14:43 UTC (permalink / raw)
  To: galene

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]

Hi,

FYI, I created some months ago a basic room PHP project here: 
https://github.com/remyd1/galene_room

Main goal was a bit different, because it was to let users create their 
own room.

Admins, however, may delete rooms, list rooms, etc, using an API.

Best regards,


Le 28/09/2021 à 20:29, Jeroen van Veen a écrit :
> Hey!
>
> I'm working on and off a management interface for Galene in Pyrite 
> (https://github.com/garage44/pyrite/issues/9)
> and was wondering how to best approach user management. Ideally the 
> user definitions are separate from the group
> files. Any thoughts on a separate users.json that contains entries like:
>
> [
> {"name":"jeroen","password":"foobar","groups":{"pyrite":{"op":true,"presenter":true,"other":true}}},
>     {"name":"pyrite","password":"foobar","groups":{}}
> ]
>
> The idea is to be able to set permissions per group, while having only 
> one user entry at a central place. After modifying users.json,
> there will be another action from the backend that updates all 
> accompanying group files. As I understand it, there is only 1 
> administrator user
> defined in data/passwd? Would it be feasible to have multiple users in 
> there, so each user can have an administrator flag?
>
> And what would be a good approach to delete or rename a group? Doing a 
> request to the new group name works fine to make
> it available in the list, but I wonder what will happen to the group 
> that is being renamed/deleted. Should I use protocol.js in the
> backend as well to connect to a group and kick all users out, before 
> attempting to rename/delete it? If so, would it be useful to have
> a 'hidden' user available that can act on behalf of the backend?
>
> Cheers,
>
> Jeroen
>
>
> _______________________________________________
> Galene mailing list --galene@lists.galene.org
> To unsubscribe send an email togalene-leave@lists.galene.org

-- 
Dernat Rémy
Chef de projet SI, CNRS
Infrastructure des Systèmes d'Information ISI
ISEM Montpellier

[-- Attachment #2: Type: text/html, Size: 4346 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: End-to-end encryption [was: User management]
  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       ` Dave Taht
  1 sibling, 0 replies; 14+ messages in thread
From: Dave Taht @ 2021-10-01 15:24 UTC (permalink / raw)
  To: Juliusz Chroboczek; +Cc: galene

On Fri, Oct 1, 2021 at 7:20 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> > talking to a trusted videoconferencing server. I did rather like the
> > insertable streams idea:
> >
> > https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/
>
> I like the idea of end-to-end encryption, but I feel that I'm not ready to
> implement it yet.
>
> Insertable streams gives you the ability to perform end-to-end encryption,
> but it does not define the encryption format.  So you end up having to
> design your own crypto, with all the dangers that this entails.  Before we
> can use insertable streams, we need to have a clear specification of
> a recommended encrypted format to use with it.  There is an IETF effort to
> do that, but it's IETF, so it won't conclude before a few years.  (Last
> time I checked, they were discussing the benefits of two approaches,
> SFrame and Spacket, if memory serves, and there was no clear consensus yet.)
>
> There are two other issues.  First, in order to do simulcast and keyframe
> optimisation, Galene needs to look inside the packets.  Jitsi works around
> the issue by not encrypting the first 8 octets of every packet, even one
> that does not start a frame, but it's difficult to tell what amount of
> information this leaks.  The proper solution to the issue is to have an
> unencrypted header extension that contains the required information, but
> that's only available with AV1 and not implemented yet (Chrome uses
> a nonstandard format for AV1).
>
> Second, simulcast for VP8 requires rewriting the packet contents, which is
> obviously impossible if the data is encrypted.  This is solved with VP9,
> but what it means is that you cannot have encrypted simulcast with VP8,
> something has to give.
>
> In short, Dave, I have given some serious thought to the issue of
> end-to-end encryption, and I feel that it will need to wait a couple of
> years before we can deploy it in production.

thanks for having given it much deeper thought than I have so far!

I would like then, to somehow, push harder to embed videoconferencing
servers such as galene into more edge embedded products. I am very
disturbed by the widespread belief among users that videoconferencing
servers in the cloud are actually secure, and would like to see services
like baby-cams, and personal interactions, move back to the edge, and
back under user control (and there's also a bandwidth savings to be had)

There is a lot of work going on on edge cpe - like prplos, rdk-b,
and security products like these,

https://www.theverge.com/2021/9/28/22692073/ring-alarm-pro-amazon-event-release-date-specs-price-features

running on capable hardware,  that might be used.
> -- Juliusz



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: User management
  2021-10-01 11:55 ` [Galene] " Juliusz Chroboczek
  2021-10-01 14:05   ` Dave Taht
@ 2021-10-03 19:15   ` Jeroen van Veen
  2021-10-26 19:02     ` [Galene] Config branch [was: User management] Juliusz Chroboczek
  1 sibling, 1 reply; 14+ messages in thread
From: Jeroen van Veen @ 2021-10-03 19:15 UTC (permalink / raw)
  To: Juliusz Chroboczek; +Cc: galene

Hi Juliusz,

Thanks for explaining! I'll try to keep it simple for now and see if I can allow
basic group management that controls the group files. About the users; I'll try to
add a basic users.json that's controlled by Pyrite, and see how it works.

Cheers,

Jeroen

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

Op vrijdag 1 oktober 2021 om 1:55 PM schreef Juliusz Chroboczek <jch@irif.fr>:

> > Any thoughts on a separate users.json that contains entries like:
>
> > [
> >
> > {"name":"jeroen","password":"foobar","groups":{"pyrite":
> >
> > {"op":true,"presenter":true,"other":true}}},
> >
> > {"name":"pyrite","password":"foobar","groups":{}}
> >
> > ]
> >
> > The idea is to be able to set permissions per group, while having only
> >
> > one user entry at a central place.
>
> I'm open to that.
>
> > After modifying users.json, there will be another action from the
> >
> > backend that updates all accompanying group files. As I understand it,
> >
> > there is only 1 administrator user defined in data/passwd? Would it be
> >
> > feasible to have multiple users in there, so each user can have an
> >
> > administrator flag?
>
> I think we should make the data/passwd file obsolete, and define the
>
> administrator role per-user in the users.json file.
>
> > And what would be a good approach to delete or rename a group? Doing
> >
> > a request to the new group name works fine to make it available in the
> >
> > list, but I wonder what will happen to the group that is being
> >
> > renamed/deleted.
>
> The group will exist as long as there are users, but no new users should
>
> be able to login. At least, that's the way the code was written, but
>
> I don't recall if I've tested it.
>
> > Should I use protocol.js in the backend as well to connect to a group
> >
> > and kick all users out, before attempting to rename/delete it?
>
> I don't feel it's necesary, but it's up to you.
>
> > If so, would it be useful to have a 'hidden' user available that can act
> >
> > on behalf of the backend?
>
> No, please no hidden users -- normal users should have full visibility
>
> into what's being done to them. If you need a system user, please make it
>
> visible.
>
> -- Juliusz

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: User management
  2021-10-01 14:43 ` [Galene] Re: User management Dernat Rémy
@ 2021-10-03 19:15   ` Jeroen van Veen
  0 siblings, 0 replies; 14+ messages in thread
From: Jeroen van Veen @ 2021-10-03 19:15 UTC (permalink / raw)
  To: Dernat Rémy; +Cc: galene

[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]

Hey Dernat,

Thanks for sharing! Interesting idea to let users deal with room management

Cheers,

Jeroen

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Op vrijdag 1 oktober 2021 om 4:43 PM schreef Dernat Rémy <remy.dernat@umontpellier.fr>:

> Hi,
>
> FYI, I created some months ago a basic room PHP project here: https://github.com/remyd1/galene_room
>
> Main goal was a bit different, because it was to let users create their own room.
>
> Admins, however, may delete rooms, list rooms, etc, using an API.
>
> Best regards,
>
> Le 28/09/2021 à 20:29, Jeroen van Veen a écrit :
>
>> Hey!
>>
>> I'm working on and off a management interface for Galene in Pyrite (https://github.com/garage44/pyrite/issues/9)
>> and was wondering how to best approach user management. Ideally the user definitions are separate from the group
>> files. Any thoughts on a separate users.json that contains entries like:
>>
>> [
>> {"name":"jeroen","password":"foobar","groups":{"pyrite":{"op":true,"presenter":true,"other":true}}},
>> {"name":"pyrite","password":"foobar","groups":{}}
>> ]
>>
>> The idea is to be able to set permissions per group, while having only one user entry at a central place. After modifying users.json,
>> there will be another action from the backend that updates all accompanying group files. As I understand it, there is only 1 administrator user
>> defined in data/passwd? Would it be feasible to have multiple users in there, so each user can have an administrator flag?
>>
>> And what would be a good approach to delete or rename a group? Doing a request to the new group name works fine to make
>> it available in the list, but I wonder what will happen to the group that is being renamed/deleted. Should I use protocol.js in the
>> backend as well to connect to a group and kick all users out, before attempting to rename/delete it? If so, would it be useful to have
>> a 'hidden' user available that can act on behalf of the backend?
>>
>> Cheers,
>>
>> Jeroen
>>
>> _______________________________________________
>> Galene mailing list --
>> galene@lists.galene.org
>> To unsubscribe send an email to
>> galene-leave@lists.galene.org
>
> --
> Dernat Rémy
> Chef de projet SI, CNRS
> Infrastructure des Systèmes d'Information ISI
> ISEM Montpellier

[-- Attachment #2: Type: text/html, Size: 4405 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Config branch [was: User management]
  2021-10-03 19:15   ` [Galene] Re: User management Jeroen van Veen
@ 2021-10-26 19:02     ` Juliusz Chroboczek
  2021-10-27 18:23       ` [Galene] " Jeroen van Veen
  2021-10-29  9:10       ` Jeroen van Veen
  0 siblings, 2 replies; 14+ messages in thread
From: Juliusz Chroboczek @ 2021-10-26 19:02 UTC (permalink / raw)
  To: Jeroen van Veen; +Cc: galene

Jeroen,

I've just pushed a new branch

  git checkout -b config https://github.com/jech/galene

which implements a global configuration file and removes the data/passwd
file.  Please review, and let me know what you think.

(I'm going to use the global config file to hold shared secrets and public
keys as I implement third party authentication with JWTs, so while it's
not overly urgent, please do review, since we'll be stuck with it once
people start developing auth servers for Galene.)

-- Juliusz

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: Config branch [was: User management]
  2021-10-26 19:02     ` [Galene] Config branch [was: User management] Juliusz Chroboczek
@ 2021-10-27 18:23       ` Jeroen van Veen
  2021-10-29  9:10       ` Jeroen van Veen
  1 sibling, 0 replies; 14+ messages in thread
From: Jeroen van Veen @ 2021-10-27 18:23 UTC (permalink / raw)
  To: Juliusz Chroboczek; +Cc: galene

Hey Juliusz,

Nice! I'll check it out this week. JWT sounds good.
I'm currently halfway basic group/user management in Pyrite.
Currently using a simple users.json for now to keep track of users and
their groups (https://github.com/garage44/pyrite/blob/develop/packages/admin/lib/user.js#L8).

Cheers,

Jeroen

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

Op dinsdag 26 oktober 2021 om 9:02 PM schreef Juliusz Chroboczek <jch@irif.fr>:

> Jeroen,
>
> I've just pushed a new branch
>
> git checkout -b config https://github.com/jech/galene
>
> which implements a global configuration file and removes the data/passwd
>
> file. Please review, and let me know what you think.
>
> (I'm going to use the global config file to hold shared secrets and public
>
> keys as I implement third party authentication with JWTs, so while it's
>
> not overly urgent, please do review, since we'll be stuck with it once
>
> people start developing auth servers for Galene.)
>
> -- Juliusz
>
> Galene mailing list -- galene@lists.galene.org
>
> To unsubscribe send an email to galene-leave@lists.galene.org

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: Config branch [was: User management]
  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
  1 sibling, 1 reply; 14+ messages in thread
From: Jeroen van Veen @ 2021-10-29  9:10 UTC (permalink / raw)
  To: Juliusz Chroboczek; +Cc: galene

Hi Juliusz,

I checked your config branch and the new multiple admins feature.
Nice feature! It allows me to directly map the admin privilege
in Pyrite's users.json to a Galene admin, so multiple users can directly
access an endpoint like stats.json. It may be possible to use the single
admin user in Pyrite's Node.js service to proxy the request, but it's
better to have this directly in Galene I think(less dependencies).

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? For instance, would Galene call a
configurable HTTP endpoint that will do the authentication and return a JWT?
What user information will be stored by Galene? The JWT? I don't have
a solid understanding of how that's supposed to work yet. Would it make sense to
have user deduplication with the current file/authentication scheme like this?

data/users.json
[
    {"id": "3930b479-e669-432c-b163-8a3c79475820", "username": "root", "password": "secret"},
    {"id": "b0fba23a-4441-47dc-97ca-545a5b6b9142", "username": "foo", "password": "bar"}
]

data/config.json
{
    "admin": [
        "3930b479-e669-432c-b163-8a3c79475820"
    ]
}

data/groups/my-group.json
{
    "op": ["3930b479-e669-432c-b163-8a3c79475820"],
    "presenter": ["b0fba23a-4441-47dc-97ca-545a5b6b9142"]
}

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? e.g.

data/users.json
[
    {"id": "3930b479-e669-432c-b163-8a3c79475820", "username": "root", "password": "secret", "profile": {"email": "root@domain.org"}},
    {"id": "b0fba23a-4441-47dc-97ca-545a5b6b9142", "username": "foo", "password": "bar", "profile": {"email": "foo@bar.org"}}
]

Kind regards,

Jeroen

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

Op dinsdag 26 oktober 2021 om 9:02 PM schreef Juliusz Chroboczek <jch@irif.fr>:

> Jeroen,
>
> I've just pushed a new branch
>
> git checkout -b config https://github.com/jech/galene
>
> which implements a global configuration file and removes the data/passwd
>
> file. Please review, and let me know what you think.
>
> (I'm going to use the global config file to hold shared secrets and public
>
> keys as I implement third party authentication with JWTs, so while it's
>
> not overly urgent, please do review, since we'll be stuck with it once
>
> people start developing auth servers for Galene.)
>
> -- Juliusz

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: Config branch [was: User management]
  2021-10-29  9:10       ` Jeroen van Veen
@ 2021-10-29 17:52         ` Juliusz Chroboczek
  2021-10-30  8:22           ` Jeroen van Veen
  0 siblings, 1 reply; 14+ messages in thread
From: Juliusz Chroboczek @ 2021-10-29 17:52 UTC (permalink / raw)
  To: Jeroen van Veen; +Cc: galene

> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [Galene] Re: Config branch [was: User management]
  2021-10-29 17:52         ` Juliusz Chroboczek
@ 2021-10-30  8:22           ` Jeroen van Veen
  0 siblings, 0 replies; 14+ messages in thread
From: Jeroen van Veen @ 2021-10-30  8:22 UTC (permalink / raw)
  To: Juliusz Chroboczek; +Cc: galene

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-10-30  8:22 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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