Our solution for user authentication with open standards
It's a well-known challenge among system administrators: managing user authentication within different systems. Our lead developer operations Christiaan dove into the matter and came up with an elegant solution.
Our situation
As a digital agency, we work with numerous external services; hosting servers, Zeplin, Simplicate and Monday are examples. In addition, several tools support us in a more internal setting. Examples include GitLab, Icinga, the WiFi network, central data storage, VPN connections and more. Managing users on all these platforms and tools can become quite complex, especially when one considers that information must be available interoperably. When a user wants to change their password, a change is required for each of these tools. Or, when a new employee starts, they need an account. After a while, I noticed that keeping track of all these changes became quite labor intensive. So, with the intention of lightening the workload, I set out to find a solution where our stringent security requirements would not be compromised.
Step 1: a suitable database for user data
The first step was to look for a central database that could store all user data: a system that would provide for communicating this data to and from our internal and external tooling. I soon arrived at LDAP, an industry standard. Because of this standard, many tools offer interfacing with LDAP. Also, GNU/Linux and MacOS (our hosting servers and desktops), offer native interfacing with LDAP. Another advantage is the fact that LDAP provides support for customizing data schedules, allowing me to customize data storage as needed.
Advantages and disadvantages of LDAP
Not only do we use LDAP to log into our WiFi and internal tools, it also connects us to our servers. This means our developers can log in with centrally managed SSH keys and password. Some additional customizations also allow us to manage permissions based on group-membership. This allows us, instead of adding individual users for a particular service they are entitled to use, to add the entire group. Among other things, this allows developers to access servers and GitLab.
One drawback of LDAP, however, is that the username and password are processed by the application. Especially for external tools, this is something I would like to avoid as these tools could store the data, making it more susceptible to hacking. Because of this reason, the decision was made to choose OAuth2 for external tooling.
A custom solution for external tools
OAuth2 was created to share user information, and validate a login without ever showing the user password. Chances are pretty good that you already use this to log in to a service with your Google account, for example. The user is redirected directly to a login screen. This meant that I first had to build an interface which uses the data from LDAP. Using SimpleSAML.php this was quite easy to create. After logging in, the user is returned to original website with a special token that automatically logs him in, while in the meantime validating that this is correct and that it was done from a trusted source.
Effective and efficient
I can only say that our account management (creating and deleting accounts) and managing user permissions (giving/denying access, compliance exports of current permissions) has improved significantly with the use of LDAP and OAuth2. It saves us a lot of time and I recommend it to anyone looking for a similar solution.
Do you have any questions about this solution or suggestions on how we can improve it further? Then feel free to contact me at christiaan@uncinc.nl or +31 (0)20 689 2000.
Good luck!