Use Cloudron Logins for host protected settings
-
Title pretty much says all.
Would it be possible to use the Cloudron logins as the base for auth when enabling host protection?
It is not very user friendly to have to set up accounts manually in the config file.On the same idea does anyone know if it's possible to protect only certain rooms?
-
-
@MiroTalk said in Use Cloudron Logins for host protected settings:
We're working on integrating OpenID Connect, and you can expect it to roll out with our upcoming release.
That's great news!
-
@cvachery said in Use Cloudron Logins for host protected settings:
@Mirotalk did the update that was deployed to cloudron include the openid logins?
The OIDC (OpenID Connect) option is available in both MiroTalk P2P v.1.3.29 And MiroTalk SFU v.1.4.32.
It works like this:
-
Authentication Prompt: When someone wants to access restricted features on MiroTalk, they're asked to log in using a service like Auth0 or Other providers. This sends them to Auth0's login page to prove they're who they say they are.
-
Room Creation and Sharing: After logging in successfully, users can create and share rooms with others. This lets them collaborate easily within MiroTalk.
-
Guest Access Control: Guests (people who aren't logged in)
can't access
certain parts of MiroTalk, like thelanding page
or newroom creation
. They can only join rooms shared with them by someone who's logged in. This ensures that only verified users can use all of MiroTalk's features, keeping things safe and private.
How Does OIDC Fit In?
Now, instead of the old way where MiroTalk checked a config file or called an API to see if a user was valid, we can use OIDC for authentication. Here's how:
-
Full Authentication: If
authRequired
is set totrue
, everything in MiroTalk requires logging in. No login, no access. -
Optional Authentication: With this setup, certain parts of MiroTalk might need authentication while others don't. Enabling OIDC with
host_protection
means that authenticated users can access the platform, while Guests can join room, like the old logic but in conjuction with OIDC. -
No Authentication: In some cases, you might want MiroTalk to be completely open, no login needed. This is good for things like public resources or demos.
-
OIDC disabled: When OIDC is disabled, the previous logic remains in place.
That's the gist of it! OIDC gives us more options for keeping MiroTalk secure and flexible for different situations. Furthermore, for those who opt out of OIDC usage, our existing security measures remain intact.
-
-
The latest SFU package has OpenID optionally enabled. If you want to use this, you have install a fresh instance which is setup to authenticate with the Cloudron user management.
This will essentially be setup as @MiroTalk has outlined above in 2 by default.
-
Thanks for this. Just to make it clear to people, in order to obtain the behaviour in 2, you still need to modify the config.js file and enable authentication (protected: true). Otherwise, while guest cannot enter the app base domain without a login, they can still create rooms freely by creating a url: mirotalkappprefix.mydomain.com/join/roomname
@MiroTalk is that behaviour intended?
@nebulon perhaps the "protected: true" should be enable by default in the package with OICD as I imagine this is the behaviour most users expect if they want authentication?
-
@avatar1024 said in Use Cloudron Logins for host protected settings:
Otherwise, while guest cannot enter the app base domain without a login, they can still create rooms freely by creating a url: mirotalkappprefix.mydomain.com/join/roomname
@MiroTalk is that behaviour intended?
Not a behaviour intended! I'm considering a refinement where guests are only allowed to join specified rooms that have already been created by authenticated users. This approach might offer better control and security. Will be released in the next version.
-
@MiroTalk said in Use Cloudron Logins for host protected settings:
Not a behaviour intended! I'm considering a refinement where guests are only allowed to join specified rooms that have already been created by authenticated users. This approach might offer better control and security. Will be released in the next version.
I thought that might be the case. Though as I mentioned the behaviour is achieved though by setting "protected: true" in the config.js combined with OICD. It just feels like if OICD is enabled then it shouldn't be possible for guests to create rooms so the setting shouldn't be necessary.
-
I don't get the what the configuration should be to use the OIDC?
From what I understood putting in the
env
fileHOST_PROTECTED=true authRequired=true
Should be enough to use my Cloudron accounts and allow guests to only join created rooms but my accounts aren't recognized I didn't find anything about OIDC/OpenID in the doc
-
Ok I found the block to add in the
env
file :OIDC_ENABLED=false # true or false OIDC_ISSUER_BASE_URL='https://server.example.com' OIDC_BASE_URL='http://localhost:3000' # https://p2p.mirotalk.com OIDC_CLIENT_ID='ClientID' OIDC_CLIENT_SECRET='ClientSecret' OIDC_AUTH_REUIRED=false # set to true if authentication is required for all routes SESSION_SECRET='mirotalk-p2p-oidc-secret'
But I don't know how to set those variables. I created a new client in cloudron
OpenID Connect Provider
but not sure of what the callback URL should be -
N nebulon marked this topic as a question on
-
I keep having the same error when trying to create a room
Oops, Room not allowed This room is not allowed for this user
My config.js file looks like this:
// All options at https://github.com/miroslavpejic85/mirotalksfu/blob/main/app/src/config.template.js module.exports = { host: { /* Host Protection (default: false) To enhance host security, enable host protection - user auth and provide valid usernames and passwords in the users array. */ protected: true, user_auth: false, users: [ /* { username: 'username', password: 'password', }, { username: 'username2', password: 'password2', }, ... */ ] }, presenters: { /* By default, the presenter is identified as the first participant to join the room, distinguished by their username and UUID. Additional layers can be added to specify valid presenters and co-presenters by setting designated usernames. */ list: [], join_first: true, // Set to true for traditional behavior, false to prioritize presenters } };
And looking at the app repo here the config file should look quite different to be able to handle OIDC connection