Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Feature Requests
  3. The "real" SSO with

The "real" SSO with

Scheduled Pinned Locked Moved Feature Requests
usermanagementssofeature-request
21 Posts 9 Posters 3.3k Views 10 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • d19dotcaD d19dotca

    @girish said in The "real" SSO with:

    @nj I think this suggestion can work. I think Duo also has a similar idea - https://duo.com/docs/ldap#test-your-setup (you add the 2FA after the password separated by a comma). The main issue is only to communicate this to all the users, but maybe it's not a problem within small teams.

    What happens when the password contains a comma though? 😛

    girishG Offline
    girishG Offline
    girish
    Staff
    wrote on last edited by
    #6

    @d19dotca I think since 2FA is 6 digits, you just take the last 6 characters.

    d19dotcaD 1 Reply Last reply
    2
    • d19dotcaD d19dotca

      @girish said in The "real" SSO with:

      @nj I think this suggestion can work. I think Duo also has a similar idea - https://duo.com/docs/ldap#test-your-setup (you add the 2FA after the password separated by a comma). The main issue is only to communicate this to all the users, but maybe it's not a problem within small teams.

      What happens when the password contains a comma though? 😛

      fbartelsF Offline
      fbartelsF Offline
      fbartels
      App Dev
      wrote on last edited by
      #7

      @d19dotca or simply check the string from the end until the agreed upon separator.

      1 Reply Last reply
      1
      • girishG girish

        @d19dotca I think since 2FA is 6 digits, you just take the last 6 characters.

        d19dotcaD Offline
        d19dotcaD Offline
        d19dotca
        wrote on last edited by
        #8

        @girish ah good idea, that makes sense. 👍

        --
        Dustin Dauncey
        www.d19.ca

        1 Reply Last reply
        0
        • W Offline
          W Offline
          will
          wrote on last edited by
          #9
          This post is deleted!
          1 Reply Last reply
          0
          • girishG girish

            @nj I think this suggestion can work. I think Duo also has a similar idea - https://duo.com/docs/ldap#test-your-setup (you add the 2FA after the password separated by a comma). The main issue is only to communicate this to all the users, but maybe it's not a problem within small teams.

            One workaround until we implement this is to get your team to create an app specific password - https://cloudron.io/documentation/profile/#app-passwords . With this, each user can generate a new password for each app. If you have a password manager, it will remember it and get you similar security like 2FA.

            njN Offline
            njN Offline
            nj
            wrote on last edited by
            #10

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

            Founder / Coder • My Apps

            girishG 1 Reply Last reply
            0
            • njN nj

              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?

              murgeroM Offline
              murgeroM Offline
              murgero
              App Dev
              wrote on last edited by
              #11

              @nj said in The "real" SSO with:

              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 bad practice as it needs to assume the password is stored in plain text - Which is not OK.

              Best practice dictates that each app that supports MFA (2FA) should have it's own secret code and what not anyway..

              --
              https://urgero.org
              ~ Professional Nerd. Freelance Programmer. ~

              mehdiM 1 Reply Last reply
              0
              • murgeroM murgero

                @nj said in The "real" SSO with:

                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 bad practice as it needs to assume the password is stored in plain text - Which is not OK.

                Best practice dictates that each app that supports MFA (2FA) should have it's own secret code and what not anyway..

                mehdiM Offline
                mehdiM Offline
                mehdi
                App Dev
                wrote on last edited by
                #12

                @murgero This does not need the password to be stored in plaintext in the DB. While checking the credentials, the server has access to the password in plaintext that was just sent by the client.

                The problem in what you said is the "each app that supports MFA" part. A lot of apps don't.

                1 Reply Last reply
                2
                • njN nj

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

                  girishG Offline
                  girishG Offline
                  girish
                  Staff
                  wrote on last edited by
                  #13

                  @nj I think your initial idea/suggestion is valid.

                  I think there are two separate attack vectors. One that a random mobile app steals your raw password. This is what app password feature tries to solve - it provides you a password that is only valid for that one app. The other is that if your password is leaked because you re-used Cloudron password in some other place (i.e it got into https://haveibeenpwned.com/ and the likes), then having a 2FA atleast protects all services despite password being compromised.

                  1 Reply Last reply
                  1
                  • njN Offline
                    njN Offline
                    nj
                    wrote on last edited by nj
                    #14

                    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!

                    Founder / Coder • My Apps

                    mehdiM 1 Reply Last reply
                    1
                    • njN nj

                      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!

                      mehdiM Offline
                      mehdiM Offline
                      mehdi
                      App Dev
                      wrote on last edited by
                      #15

                      @nj I agree, this should be implemented.

                      However, this cannot be "app-specific passwords to be appended with a TOTP code". App-specific passwords are made to be stored by mobile / desktop clients, so they will be reused at a later date, at which point the appended TOTP code won't be valid anymore.

                      This scheme may also break certain apps that rely on basic-auth or something similar, so it should be possible to disable it.

                      In any case, still seems a great idea 🙂

                      1 Reply Last reply
                      0
                      • girishG Offline
                        girishG Offline
                        girish
                        Staff
                        wrote on last edited by
                        #16

                        Any suggestions on whether this should be app level or cloudron level? per-app, while flexible, might be confusing. Another option, in theory, we can go through each of the apps, find out what supports 2FA and what doesn't and enable this only for apps that don't support 2FA.

                        mehdiM njN 2 Replies Last reply
                        1
                        • girishG girish

                          Any suggestions on whether this should be app level or cloudron level? per-app, while flexible, might be confusing. Another option, in theory, we can go through each of the apps, find out what supports 2FA and what doesn't and enable this only for apps that don't support 2FA.

                          mehdiM Offline
                          mehdiM Offline
                          mehdi
                          App Dev
                          wrote on last edited by
                          #17

                          @girish I think it should be a boolean in the ldap addon in CloudronManifest. Of course, there would be no need to enable this for apps that natively support their own 2FA.

                          If the flag is true, and 2FA is enabled on the main server, the ldap addon verifies that the password is of the form ACTUAL_PASSWORD;TOTP, or is an app-specific password.

                          Also, it would be great to have an env var that says whether or not 2FA is enabled on the main server, so the app package can possibly adapt its interface / show a warning that explains the format / something

                          It could also be controlled /enabled by each user for each app, with a different TOTP per-app.

                          1 Reply Last reply
                          1
                          • girishG girish

                            Any suggestions on whether this should be app level or cloudron level? per-app, while flexible, might be confusing. Another option, in theory, we can go through each of the apps, find out what supports 2FA and what doesn't and enable this only for apps that don't support 2FA.

                            njN Offline
                            njN Offline
                            nj
                            wrote on last edited by
                            #18

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

                            Founder / Coder • My Apps

                            1 Reply Last reply
                            2
                            • W Offline
                              W Offline
                              will
                              wrote on last edited by
                              #19

                              This solution is getting pretty brittle and non-standard quite quickly..
                              I'd say have Cloudron handle TFA, and once logged in, not have TFA on each app. Like all the SSO solutions operate.

                              1 Reply Last reply
                              2
                              • girishG Offline
                                girishG Offline
                                girish
                                Staff
                                wrote on last edited by
                                #20

                                We now have mandatory 2FA in Cloudron 5.4

                                1 Reply Last reply
                                1
                                • adisonA Offline
                                  adisonA Offline
                                  adison
                                  wrote on last edited by
                                  #21

                                  i didn't know cloudron was like active directory. or had active directory builtin.

                                  my website is not available right now

                                  1 Reply Last reply
                                  0
                                  Reply
                                  • Reply as topic
                                  Log in to reply
                                  • Oldest to Newest
                                  • Newest to Oldest
                                  • Most Votes


                                  • Login

                                  • Don't have an account? Register

                                  • Login or register to search.
                                  • First post
                                    Last post
                                  0
                                  • Categories
                                  • Recent
                                  • Tags
                                  • Popular
                                  • Bookmarks
                                  • Search