Re: I am missing (real) SSO

I onboarded my entire team to Cloudron; signed up, mailboxes set up, 2FA enabled, and more. Then I realized that the 2FA setting enabled on Cloudron is useless for other apps. Some apps don't have a 2FA option yet; for example, Taiga, which we use to manage all the projects. Also, Bookstack, where all our internal docs go, supports 2FA.

I have understood how Cloudron works, and that this topic has already been discussed in the forum. I started looking for ways to leverage 2FA settings of Cloudron to protect access to other apps. I have thought of a possible solution.

After researching for a while I discovered a solution. Cloudron itself has an active directory server. We could have the users append/prepend the 2FA token with their password every time they log in; the Cloudron LDAP server would see if 2FA is enabled on the account, and if enabled, it will extract the password & 2FA code from the password input and perform authentication. This is pretty trivial because the Cloudron login page has an optional 2FA token field, and the token is only looked required if the user has enabled 2FA.

One of the service offerings I came across has a simple but complete description of this method of using 2FA with LDAP with a dynamic password. https://www.protectimus.com/blog/active-directory-two-factor-authentication/.

This feature is absolutely necessary for me, and I believe there are other people like me. Do you think we could pull this off?

Re: Swagger Editor - define REST api

I have been using Postman with my team for developing and publishing APIs for our services, but the costs are adding up pretty quickly ($15/user/month), and still no support for SSO.

I am moving to Swagger Editor, Swagger Codegen & Swagger UI, but it would be great if I could install it inside my Cloudron instance instead of paying for another server.

I noticed that your documentation makes use of Swagger, so I am sure it would be fairly easy to add support for the same.

Please don't forget to upvote if you think it's a good idea.

@girish after giving some more thoughts, I don't see a reason to go through all the apps to see if they support 2FA? This only makes stuff more complicated. Even if the app supports 2FA, the Cloudron 2FA will make it redundant; so we can skip that. If someone would like to skip Cloudron 2FA they're free to use the app's own 2FA if it supports.

There could be a choice of ["Use Cloudron 2FA / Let the app handle it"] just like the choice of user management. If the first option is selected, TOTP is checked, otherwise it is not.

@girish I think creating separate passwords for individual apps is against what I'm trying to achieve using SSO. The TOTP 2FA is actually more secure, unlike yet another password saved in the same password manager. App passwords stored in the same password manager only protect the password from rogue clients that may leak passwords. But adding the dynamic password feature protects even if the password is compromised.

If a rogue client is an attack vector, the app-specific password doesn't really save from the damage on that particular app. App-specific password have a long lifetime, so they can be silently misused without your knowledge for a relatively long time.

Whereas, the TOTP tokens are refreshed every 30 seconds or so. Even if someone stole your password, they must (MUST) brute-force the TOTP code after 30 seconds, which is going to trigger the brute-force detection mechanism. With immediate session revocation, the damage can be contained.

Hence I believe the only savior is 2FA if that particular app supports. Unfortunately, not all apps support 2FA; even if they did, it's not really fun to enable 2FA, manage backup codes, and in case the authenticator & backup codes are lost, it's not easy to have the admin bypass 2FA on all services. For example, RocketChat admins should do that by directly changing the user's data using the mongo shell.

I haven't looked into the source code of Cloudron yet, but I'm sure we can also have the app-specific passwords to be appended with a TOTP code if 2FA is enabled on the account. The app-specific password and TOTP will be validated by Cloudron in the same way it would validate the account password.

I believe this system reduces friction:

• users don't fall into a victim of silent misuse of passwords
• users don't need to configure multiple 2fa
• users don't need to print even more backup codes
• admins don't don't need to disable 2fa for individual accounts in worst cases
• Cloudron will have a solid mechanism of authentication
• we can start using more apps [that don't support 2FA yet] as well as custom apps in Cloudron without worrying about 2FA

I'm sorry if this comment sounded like a marketing pitch, but I genuinely believe we should pull this off. I'm fascinated by Cloudron because it has saved me a lot of hassle, and by @girish's support, which is by far the best I've ever received from any service provider!

So quick! It works, thanks! @girish!

Re: Swagger Editor - define REST api

I have been using Postman with my team for developing and publishing APIs for our services, but the costs are adding up pretty quickly ($15/user/month), and still no support for SSO.

I am moving to Swagger Editor, Swagger Codegen & Swagger UI, but it would be great if I could install it inside my Cloudron instance instead of paying for another server.

I noticed that your documentation makes use of Swagger, so I am sure it would be fairly easy to add support for the same.

Please don't forget to upvote if you think it's a good idea.

@murgero thanks for the hint, but I'm afraid, I need to authenticate through LDAP only.

Is there a way to prevent normal Cloudron users from changing their username and email? That's because Gitlab, for instance, recommends against using LDAP authentication if the LDAP server supports changing username/email because that can lead to account takeover.

Is there any way to achieve this, or is there a possibility to add this feature in the admin panel?

Any plans to add the facility to append 2FA Token in LDAP Passwords?

My Gitlab instance (v13.0.5) on cloudron 5.2.4 displays the following warning:

Note that PostgreSQL 11 will become the minimum required PostgreSQL version in GitLab 13.0 (May 2020). PostgreSQL 9.6 and PostgreSQL 10 will no longer be supported in GitLab 13.0. Please consider upgrading your PostgreSQL version (10.12) soon.

@girish please look into it.

@girish after giving some more thoughts, I don't see a reason to go through all the apps to see if they support 2FA? This only makes stuff more complicated. Even if the app supports 2FA, the Cloudron 2FA will make it redundant; so we can skip that. If someone would like to skip Cloudron 2FA they're free to use the app's own 2FA if it supports.

There could be a choice of ["Use Cloudron 2FA / Let the app handle it"] just like the choice of user management. If the first option is selected, TOTP is checked, otherwise it is not.

If a rogue client is an attack vector, the app-specific password doesn't really save from the damage on that particular app. App-specific password have a long lifetime, so they can be silently misused without your knowledge for a relatively long time.

Whereas, the TOTP tokens are refreshed every 30 seconds or so. Even if someone stole your password, they must (MUST) brute-force the TOTP code after 30 seconds, which is going to trigger the brute-force detection mechanism. With immediate session revocation, the damage can be contained.

Hence I believe the only savior is 2FA if that particular app supports. Unfortunately, not all apps support 2FA; even if they did, it's not really fun to enable 2FA, manage backup codes, and in case the authenticator & backup codes are lost, it's not easy to have the admin bypass 2FA on all services. For example, RocketChat admins should do that by directly changing the user's data using the mongo shell.

I haven't looked into the source code of Cloudron yet, but I'm sure we can also have the app-specific passwords to be appended with a TOTP code if 2FA is enabled on the account. The app-specific password and TOTP will be validated by Cloudron in the same way it would validate the account password.

I believe this system reduces friction:

• users don't fall into a victim of silent misuse of passwords
• users don't need to configure multiple 2fa
• users don't need to print even more backup codes
• admins don't don't need to disable 2fa for individual accounts in worst cases
• Cloudron will have a solid mechanism of authentication
• we can start using more apps [that don't support 2FA yet] as well as custom apps in Cloudron without worrying about 2FA

I'm sorry if this comment sounded like a marketing pitch, but I genuinely believe we should pull this off. I'm fascinated by Cloudron because it has saved me a lot of hassle, and by @girish's support, which is by far the best I've ever received from any service provider!

So quick! It works, thanks! @girish!