Use Cloudron Logins for host protected settings

[nebulon]

@MiroTalk this is great news! Let us know if you need help or have questions about OpenID integration.

[jdaviescoates]

@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]

@Mirotalk did the update that was deployed to cloudron include the openid logins?

[nebulon]

We are still in contact with @MiroTalk to edge out the login/auth modes, currently we keep updating the package but have not yet enabled OpenID there

[MiroTalk]

@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:

1. 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.

2. Room Creation and Sharing: After logging in successfully, users can create and share rooms with others. This lets them collaborate easily within MiroTalk.

3. Guest Access Control: Guests (people who aren't logged in) can't access certain parts of MiroTalk, like the landing page or new room 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:

1. Full Authentication: If authRequired is set to true, everything in MiroTalk requires logging in. No login, no access.

2. 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.

3. 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.

4. 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.

[nebulon]

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.

[avatar1024]

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?

[MiroTalk]

@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.

[avatar1024]

@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.

[cvachery]

I don't get the what the configuration should be to use the OIDC?

From what I understood putting in the env file

HOST_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

[cvachery]

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

[girish]

@cvachery oidc integration is built into the sfu app already. You don't need to configure this manually. If you reinstall, it should work out of the box.

[cvachery]

@girish Hmm it's only for the SFU was trying for the p2p app
Thanks a lot, so for the SFU I should just put protected: true in the config.js and it should work out of the box?

[nebulon]

@cvachery correct, that should work.

[cvachery]

It doesn't work but I think there is an issue in the config file generation as the template is not used

[nebulon]

@cvachery what makes you think the template is not used? If there is some misconfiguration, maybe you can also just try to reinstall the app as it has no persistent data anyways.

[cvachery]

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

[nebulon]

In that case maybe just try to reinstall the app so it gets provisioned with a fresh config.js if the migration during update didn't work out for some reason.

[cvachery]

The reinstall doesn't change the content of this file.
And I don't see how it could be looking at the docker file but maybe I'm missing something

[nebulon]

To be clear the file you were linking from the package repo is a wrapper for config.js which will read values from /app/data/config.js and merges it with Cloudron specific ones. Maybe this is where the confusion comes from?