Disclaimer: For over a decade I worked on the topic of Cisco Unified Communications, so IP telephony, Cisco Jabber and video conferencing. Now I’m working at Univention doing some Linux and even Debian related stuff as an IT Consultant.
For years I’m self-hosting lots of stuff and also for family, friends and others. The user management was either standalone for each service like Nextcloud, Mastodon, Friendica, XMPP, or based on the mail auth backend on PostgreSQL, for example by authenticating against Dovecot IMAP server. This became complex over time and I was looking for a centralized auth backend. Basically this means: LDAP backend.
For that I took a look into 389ds, FusionDirectory and Univention Corporate Server (UCS). With 389ds I had installation or setup issues. FusionDirectory was way better and easier to use, but also very complex. In the end I went with UCS because of the UI experienced, the ease of use and having a working self-care portal for the users. And UCS comes with some kind of App Center with some nice apps in it that are preconfigured for the LDAP directory. So, really easy to use and to get started.
So, last year (even before I got employed by Univention) I migrated my users from PostgreSQL backend to UCS and LDAP backend. The migration was smooth and nice and worked like a charme. Only issue: things like my public XMPP server, Friendica or Mastodon are still using open registration and therefor internal auth backend. It will be much more difficult to migrate these with an existing user base of 3000-4000 users in total. So, having LDAP as user/auth backend is nice, but you should consider this at an early stage and not when you already have a plenty of services and users on your services. 😉
However, it’s even nicer when you can use Single Sign On (SSO) with your apps. I got a taste of SSO when I was doing Cisco UC stuff and liked it that I don’t need to enter my credentials over and over again. SSO is also possible with UCS, so I wanted to give it a try on my own server.
The official HowTo on setting up SAML SSO basically covers the process of setting it up, but my impression was, that this process can be made better, less error-prone and more reproducible by automatting the setup.
So I wrote in my spare time a small shell script to follow the instructions from the official HowTo and after many tests and enhancements, I released the script on Codeberg: setupSSO.sh.
So, what are the benefits of setupSSO.sh over the official HowTo?
- reproducible
- reduces copy & paste errors by automation
- works from Primary Directory Node (PDN) by logging into other Directory Nodes via SSH
- asks you some simple configuration settings instead of ing you to change the code snippets from the HowTo
- asks you for the passwords beforehand, e.g. if you are using a single password for all servers or different passwords.
- checks for hostnames in SSL certs
- checks your Identity Provider (IdP) SSL certs for validity and create a new IdP SSL cert if validity is shorter than 1 year, otherwise it will reuse the existing cert.
- maybe some more benefits.
So, if you are using UCS as well, you might want to have a look into setupSSO.sh when you are using SSO as well or plan to do so.
Disclaimer 2: As said I did this script in my spare time, so there is no support for it by Univention. Feedback via Codeberg is appreciated, of course.