Request for feedback: Script to setup SSO for Kopano WebApp (through OpenID Provider App)

fbartels · April 17, 2020, 6:26am

Hello forum,

are you still looking for a weekend project? Last week I have spent some time on automating the steps to setup login through OpenID Connect (as provided by the OpenID Connect Provider app). With this its possible to automatically log users into Kopano Meet, when they have previously logged into WebApp (or the other way around). Or any other app supporting this kind of login, like for example ownCloud.

But before making this script available to the general public I am interesting in receiving some feedback on it. Like does it work for you (it did for my test machines and the colleges I have shared it with) or are the instructions clear enough.

What you need:

Kopano WebApp >= 3.5.5.2276 (a recent enough version is available either through the Kopano package repositories or the Test Appcenter)
an account on Github.com (so I can share the repository with you)

After you account has been added you can see the repo at https://github.com/Kopano-dev/ucs-oidc-webapp/ (since the repository is still private other users will currently get a 404).

If you are interested just send me a direct message here or reach out to feedback at kopano dot io.

Looking forward to your feedback.

The repository is now public and can directly be used. I want to thank everyone that took the time to test the script and provide feedback.

tose · April 18, 2020, 1:01am

Hi Felix,

I’d very much like to look over your script/s & provide some feedback. I have a github account. I spent a few minutes searching but didn’t turn up your repository. Can you post details please?

fbartels · April 18, 2020, 5:20am

Hi @tose,

the repository is (for the start) private and therefore you could not find it. I have managed to find your account and sent you an invitation.

tose · April 19, 2020, 5:21am

Many thanks Felix. I’ve now downloaded & reviewed your script and just want to be sure my assumptions about it are correct before proceeding.

Firstly a little about my setup. I run a single AD Compatible UCS Domain Controller that already has Kopano-Core, Kopano-Webapp, Kopano Meet and OpenID Connect Provider installed. The only thing to note is that the UCS domain name is different to the public FQDN that Webapp & Meet are accessed on.

eg: Internal UCS domain name = mydomain.lan
Publicly accessible FQDN = mail.mydomain.com.au

The OpenID Connect Issuer Identifyer is configured with the publicly accessible FQDN, and a LetsEncrypt Certificate is configured for the public FQDN.

So, reading your script I’m assuming that the only thing I will need to modify is:-

Replacing

FQDN_KONNECT=$hostname.$domainname

which would otherwise return the internal UCS domain name with

FQDN_KONNECT=mail.mydomain.com.au

I’m a little less certain about the implication of the following line:-

FQDN_SSO=$(ucr get ucs/server/sso/fqdn)

At the moment that would return:-

FQDN_SSO=ucs-sso.mydomain.lan

So I guess I’m just wanting to confirm that it’s ok to leave that FQDN_SSO variable as written?

If you can think of any other stumbling blocks I may of over-looked I’d be happy to hear about them. Thanks again.

fbartels · April 19, 2020, 6:16am

Hi @tose,

thanks for the feedback so far. There is no need to configure the actual script, values like FQDN_KONNECT are stored in a file called .env so if your environment does not match the default domains then you only need to change .env and rerun ./run.sh so that it can update the according configuration settings.

If that ucr variable still holds your internal domain name, then you need to update the ucr variable first. Since this change also needs to be reflected in the OpenID Provider app I would recommend to do so through its app settings.

tose · April 19, 2020, 7:45am

Felix,

Oh, ok I’m clearer on how the script uses the .env file now.

The OpenID Connect provider App settings (in the UMC GUI at least) only has one url setting which is already set to the public FQDN. So if the UCR variable ucs/server/sso/fqdn needs to point to the public FQDN I can only set that via the UCR (as opposed to the OpenID Connect app settings). Or am I missing your meaning?

fbartels · April 19, 2020, 8:16am

Ah, yes. I remembered it differently, but ucs/server/sso/fqdn only points towards the default sso provider and is not the setting used by the openid provider app to set its fqdn.

So it should be sufficient to just change the value in the .env.

tose · April 19, 2020, 8:53am

Very good. Thank you for the confirmation.

Bit late in the day here to try this now but I will definitely run the script early tomorrow after evening backup & snapshot & report back.

Stay safe & thanks for your development work on this.

tose · April 20, 2020, 1:05am

Hello again Felix,

Here’s what happened on my 1st attempt to run your script:-

I ran it for the 1st time and as expected it completed successfully in what seemed to be around 90 seconds or so. However, also somewhat as expected, it collected and applied my internal FQDN’s for both the FQDN_KONNECT and FQDN_SSO variables.

So I then edited the .env file to reflect the publicly accessible FQDN values and saved it’s contents. On re-running the script it simply returned:-

root@UCS4Master:~/ucs-oidc-webapp# ./run.sh
Object exists: (uid) oidc-helper

It sat at that point for 3 to 4 minutes & returned no further output. I checked Webapp which no longer appeared to be accessible. Although I only have a handful of users hanging off this box I retreated to a snapshot taken just prior to running the script pending further advice from yourself.

I hope I wasn’t too hasty to fall back but given how quickly the script ran 1st time thru it didn’t seem to be running as intended. Can you think of any reason for the described behaviour?

fbartels · April 20, 2020, 7:19am

the next command would have been https://github.com/Kopano-dev/ucs-oidc-webapp/blob/master/run.sh#L60. I don’t see how this can hang your system. Maybe you just had ssh connection problems?

tose · April 20, 2020, 7:50am

Ok then. I was running via ssh but will make my next attempt via the (virtual) console. Let you know how I go.

tose · April 20, 2020, 8:22am

Well, same result but more to report this time:-

I let the script run for a longer time, and received the following output when it completed:-

root@UCS4Master:~/ucs-oidc-webapp# ./run.sh
Object exists: (oidc-helper)
Unable to open Admin session: network error (0x80040115)
The server is not running, or not accessible through "default:".
Using the -v option (possibly multiple times) may give more hints.
An error occurred on line 60 of this script.

So by my reckoning the problem occurs at:-

kopano-admin --sync

One thing I neglected to mention is that I’m running this script as the root user, NOT the administrator user. Also, by default those users share the same password from setup, but on my instance they do not.

I’m out of time now but will run the script as “administrator” next chance and let you know how it goes.

fbartels · April 20, 2020, 8:59am

with the root user should be fine, actually trying it with administrator will not work as the script assumes having enough privileges on its own. I have added a small check if its run with the right user.

Your issue seems to be that kopano-server is not running.

tose · April 20, 2020, 9:51am

Ok, no worries. I can guarantee that kopano server was running. My own personal email account is on this box. Let you know how I go with it.

tose · April 20, 2020, 8:42pm

This is what I’m seeing. As described above, the script successfully completes on 1st run but sets the FQDN settings to the internal values. If at that point I check the status of the kopano-server service I see:-

kopano-server.service - Kopano Groupware Core Storage Server                                                                                                                                                                                             
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled; vendor preset: enabled)                                                                                                                                                             
   Active: active (running) since Tue 2020-04-21 05:53:04 AEST; 5min ago                                                                                                                                                                                   
     Docs: man:kopano-server(8)                                                                                                                                                                                                                            
           man:kopano-server.cfg(5)                                                                                                                                                                                                                        
           man:kopano-admin(8)                                                                                                                                                                                                                             
 Main PID: 1819 (kopano-server)                                                                                                                                                                                                                            
   CGroup: /system.slice/kopano-server.service                                                                                                                                                                                                             
           └─1819 /usr/sbin/kopano-server -F

Apr 21 05:57:36 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:57:41 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:57:46 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:57:51 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:57:56 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:58:01 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:58:06 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:58:11 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:58:16 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 05:58:21 UCS4Master kopano-server[1819]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan

So the kopano-server service is still running at that point, but showing a kcoid discovery error complaining about certificate validity. Webapp appears not to be accessible at this point however. I then edit the .env file and replace the internal FQDN values with the public ones & run the script again. The script output:-

root@UCS4Master:~/ucs-oidc-webapp# ./run.sh
Object exists: (uid) oidc-helper
Unable to open Admin session: network error (0x80040115)
The server is not running, or not accessible through "default:".
Using the -v option (possibly multiple times) may give more hints.
An error occurded on line 60 of this script.

And so at this point I check the status of the kopano-server service I see:-

root@UCS4Master:~/ucs-oidc-webapp# service kopano-server status
kopano-server.service - Kopano Groupware Core Storage Server                                                                                                                                                                                             
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled; vendor preset: enabled)                                                                                                                                                             
   Active: failed (Result: exit-code) since Tue 2020-04-21 06:10:44 AEST; 26s ago                                                                                                                                                                          
     Docs: man:kopano-server(8)                                                                                                                                                                                                                            
           man:kopano-server.cfg(5)                                                                                                                                                                                                                        
           man:kopano-admin(8)                                                                                                                                                                                                                             
 Main PID: 15565 (code=exited, status=255)                                                                                                                                                                                                                 
      CPU: 240ms                                                                                                                                                                                                                                           

Apr 21 06:10:10 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:15 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:20 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:25 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:30 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:35 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:40 UCS4Master kopano-server[15565]: kcoid discovery error: Get https://UCS4Master.cts.lan/kopanoid//.well-known/openid-configuration: x509: certificate is valid for mail.tosi.id.au, mail2.tosi.id.au, not UCS4Master.cts.lan
Apr 21 06:10:44 UCS4Master systemd[1]: kopano-server.service: Main process exited, code=exited, status=255/n/a
Apr 21 06:10:44 UCS4Master systemd[1]: kopano-server.service: Unit entered failed state.
Apr 21 06:10:44 UCS4Master systemd[1]: kopano-server.service: Failed with result 'exit-code'.

So it appears that the kopano server service is crashing during the 2nd running of the script.

fbartels · April 21, 2020, 7:03am

See? I was telling you kopano-server was not running

But its not crashing, it is just giving up trying to reach the openid provider after a configured timeout.

I have reordered the script a bit, added a dynamic wait for kopano-server to start up and added an interactive prompt to verify the automatically set fqdn for konnect and sso. Please try again.

tose · April 21, 2020, 9:22am

All good. I’ll be able to try again in the morning. I know I’m not much help troubleshooting but I’m probably a good use case for designing a fool-proof solution

fbartels · April 21, 2020, 9:38am

but seriously thanks for trying it out. Will make it easier for the next one.

tose · April 22, 2020, 12:54am

Hi Felix,

I tried your script again with the same result which got me thinking about workarounds. Essentially we are running the script the 1st time KNOWING it will produce the wrong values, just so we can generate the .env file, edit it, and run the script again. Why not just make sure the script has the correct value 1st time around? So…

I hope you don’t mind, I took the liberty of changing the following lines in your script from:-

FQDN_KONNECT=$hostname.$domainname
FQDN_SSO=$(ucr get ucs/server/sso/fqdn)

To

FQDN_KONNECT=$(ucr get kopano/docker/FQDN_MEET)
FQDN_SSO=$(ucr get kopano/docker/FQDN_SSO)

This resulted in the script running to completion without error. Webapp url correctly redirects to the OpenID Connect (UCS) login prompt and after successful login back to a working Webapp. External access even hands off to the configured 2FA code screen. All working beautifully. The kopano-server service is running and active, albeit with a couple of errors:-

● kopano-server.service - Kopano Groupware Core Storage Server
   Loaded: loaded (/lib/systemd/system/kopano-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-04-22 10:17:04 AEST; 12min ago
     Docs: man:kopano-server(8)
           man:kopano-server.cfg(5)
           man:kopano-admin(8)
 Main PID: 22658 (kopano-server)
    Tasks: 30 (limit: 4915)
   Memory: 66.6M
      CPU: 3.286s
   CGroup: /system.slice/kopano-server.service
           └─22658 /usr/sbin/kopano-server -F

Apr 22 10:17:04 UCS4Master systemd[1]: Stopped Kopano Groupware Core Storage Server.
Apr 22 10:17:04 UCS4Master systemd[1]: Started Kopano Groupware Core Storage Server.
Apr 22 10:17:05 UCS4Master kopano-server[22658]: kcoid discovery error: unexpected response content-type: text/html
Apr 22 10:17:10 UCS4Master kopano-server[22658]: kcoid discovery error: unexpected response content-type: text/html

Looking at the timing of those errors I’d say they may have occurred during the running of the script & appear not to be recurring. So I don’t think that’s anything to worry about, just wanted to mention for completeness.

So a big thumbs up from me Felix . Hope that gives you some confidence in your solution knowing even I could make it work with a little head scratching.

And thanks also for your long running support of the Kopano4UCS integration, & your willingness to be so patient & helpful in these forums. Much appreciated.

fbartels · April 22, 2020, 5:51am

That is what I already did

Not through ucr variables (since I have the feeling most people struggle with them anyways) but printing the default value on the first run and giving the user the ability to correct it to the actually used fqdn.