I am missing (real) SSO
-
We use a reverse proxy setup. Many applications support extracting the logged in user from the HTTP headers. See this example for an explanation:
https://wiki.jenkins.io/display/JENKINS/Reverse+Proxy+Auth+PluginThis way, OAuth or SAML or whatever auth protocol you choose needs only be supported by the reverse proxy.
So far we were able to provide SSO for every application in our extranet.
Regarding the private apps, you can already set access controls for apps, but they will still be available publicly. For the moment this is likely out of scope for Cloudron. Not sure maybe this belongs to some VPN setup for organizations with this requirement?
Maybe there is a misunderstanding. For clarification:
Every app in our setup is theoretically accessible from the public internet. If the user is not authenticated and does not have rights to access the app, no HTTP traffic is getting through to the app. This improves security. The app is accessible from the public internet, but not directly exposed to it.
-
Since all apps are running within containers there is a reverse proxy (Nginx) running that facilitates access to these apps. While it is currently not possible to configure this through the Cloudron UI (and manual modifications will likely be overwritten) I think it could be a good idea to have options to add ip access restrictions to apps and optionally also do sso on the webserver (nginx running on cloudron, not in the app) level.
Something like https://github.com/vouch/vouch-proxy/ could then do the oauth part towards the cloudron user management.
-
We started out with wanting OAuth across apps (and is what we implemented). Sadly, we failed because most apps don't support this very well. I try to use the term 'Central user management' when possible to describe Cloudron's situation but maybe there are places in the docs that needs to be fixed. I will do a quick check and fix them up.
-
@girish So the driver for a lot of this "sso/app auth proxy" thinking comes from the Zero Trust model, its where every app is assumed to be exposed to the internet, and unified SSO controlls access, as opposed to have to VPN into a network to access a set of apps. Mostly outside the scope of Cloudron, but SSO being an app access broker is very much where things are going with places like Okta and Google and such.
Its a cool next level security concept.Some reading:
https://beyondcorp.com/ -
@will I would love true SSO as well but save a few apps most apps are not ready yet (meaning, there is no code for OAuth or OpenID integration in those apps). Someday, we (Cloudron) hope to get to a point where can sponsor development of those authentication backends in each app.
-
I would also love to see this, even if it's just with some apps. I have very confused users who don't understand that they have to login everytime, but the password is synchronized. One pattern I've seen is for instance:
Forgot password for nextcloud, reset password. Oh, my rocketchat password doesn't work anymore, reset password. oh, my nextcloud password doesn't work anymore, reset password. Resulting in frustration and people not using the apps. With cloudron it's easy to install the applications, but now it becomes hard on the users
-
@fair I was also thinking about this problem recently... the best thing I could come up in the short term and one that doesn't go 'out of the user's flow' too much is to simply use the Bitwarden browser plugin and there's an option in Settings -> Options to 'Enable Auto-fill On Page Load'. It won't log the user in automatically, but it will prefill the login form with the user's credentials on pages when it has something saved, leaving the user to simply hit 'Login'. Not sure how it handles sites with 2FA yet, I just enabled this myself the other day...
Unfortunately, without a browser plugin (that already has access to user's credentials, hence, Bitwarden) or without apps supporting something like OAuth or OpenID or SAML (requires individual development for each app), I don't know that this is possible.
-
Perhaps Keycloak?
@jdaviescoates said in OAuth support:
I note that the lovely people at Indiehosters (all in French) have launched a new service called Liiibre which by default is a nicely integrated Nextcloud, OnlyOffice, Rocket.Chat, and Jitsi Meet.
And I read over on the Meet.coop forum that they are using Keycloak to power their SSO stuff, so that might be worth exploring.
Here is the relevant thread for info:
https://forum.meet.coop/t/hi-from-indiehosters-onboarding-process/343?u=jdaviescoatesBut see especially this post:
https://forum.meet.coop/t/hi-from-indiehosters-onboarding-process/343/8?u=jdaviescoatesEdit: and looking back up the thread I see Keycloak has already been proposed/ discussed above too.
-
I suggested a solution that would work with what we already have here: https://forum.cloudron.io/topic/3285/2fa-for-all-ldap-apps/8?_=1607516708492
It's not SSO but the next best things with what's already available and wouldn't rely on any Apps supporting it as it would work with any kind of login method.
-
@jdaviescoates I took a quick look at some video tutorials, but I didn't see how Keycloak would be able to log the user into other applications without having said application specifically implementing the Keycloak integration.
@marcusquinn this is quite interesting, and definitely a way to go about this. Did you go through with this? Has it worked? One issue I see is that Bitwarden won't actually submit a login form for users, it will simply input the login credentials to the forms (unless I'm missing something?). Also, how are you automatically having Bitwarden do these actions on your behalf?
-
@thetomester13 said in I am missing (real) SSO:
@jdaviescoates I took a quick look at some video tutorials, but I didn't see how Keycloak would be able to log the user into other applications without having said application specifically implementing the Keycloak integration.
You've already looked into it more than me. I guess Indiehosters have implemented Keycloak integration into the apps they've integrated in their Liiibre service (perhaps they maintain forks or something, or have contributed upstream).
