Our situation
As a digital agency we work with quite some external services: hosting servers, Zeplin, Simplicate and Monday, to name just a few. We also have internal tools like Gitlab, Icinga, our WiFi, central data storage, VPN connections and a whole lot more. Managing users on all these different systems is quite a challenge, especially when considering information needs to be correct everywhere at all times. If someone wants to change their password, it requires changes in all of these tools. If a new employee joins the company, they need an account. After a while I noticed that working like this is very laborious. In an effort to make my life a bit easier, I went looking for an alternative way. One that would save time without lowering our high level of security.
Step 1: a suitable database for user data
A quick thought was to look for a central database that would store all the credentials and user information. A system that would provide to this authentication data to our internal and external systems. For this, I chose the industry-leading standard LDAP. An important advantage to this standard is that many systems used for running company tools offer an LDAP integration. GNU/Linux and MacOS (our hosting servers and desktops) also support logging in with LDAP natively. Furthermore, LDAP has support for custom schema’s, the definition of information fields which allows me to customize the data we store if needed.
Pros and cons of LDAP
Not only do we use LDAP for logging in to our WiFi and internal tools, it also connects with our servers. This means our developers can log in with centrally managed SSH keys and password. With a few extra changes I was able to add rights management via group membership. This means that instead of adding users to a service that they are allowed to use, we will add a group to the service and the users will be added to the group. This enables developers to get access to the servers and Gitlab.
One of the downsides of LDAP, though, is that username and password are handled by the application. Especially for external tools, this is something I want to avoid as they could store the authentication data, making them vulnerable for hacking. For external tools I therefore chose to use OAuth2.
A custom solution for external tools
OAuth2 is made for sharing user information and validating a login without ever exposing the user’s password. Most likely you already used it when logging in using Google on another system. At first, you will be redirected to the login screen of the provide. This meant I had to make our own interface that uses the user data from LDAP. With the help of SimpleSAMLphp, this was pretty easy to accomplish. After logging in you get redirected back to the original site with a special token that automatically logs you into the website while validating that this is correct and is coming from a trusted source.
