Skip to main content

Login authentication federation the old way

You probably use federation on a regular basis without even realizing it, if you ever click on buttons like these:

Login federation is the concept of having a single source of user profiles, and sending all login authentication requests to that source in order to minimize the number of accounts and passwords needing to be kept. For example, you may have a server where users can login locally, then you may have a number of web apps that also have login forms, and you may have a VPN solution, again necessitating logins. This is a problem that a lot of organizations have been trying to solve as they add more and more applications, with the need to maintain a long list of separate accounts. You end up with users that have different passwords based on which service they use, and so federation services have come into play to try and solve the issue by sending all login requests to that same single source.

But while the problem may seem complex, implementing a federation solution can be even more complex and often costly, especially if you need a system that supports more than just web browsers. The interesting thing however is that this is not a new problem, and authentication federation is not the first solution. Pluggable Authentication Modules (also known as PAM) is the solution that the Linux community came up with many years ago. While it isn’t as flashy as things like Microsoft Federation Service or PingID, it’s free, lightweight and open source, and may just be the solution you need if your workloads all rely on Linux servers.

To demonstrate a use case for PAM, I will show you how I use it myself to concentrate authentication systems for 3 different scenarios: SSH, a custom web app running on Apache, and a VPN endpoint running on OpenVPN Access Server. All 3 services rely on the local Linux accounts instead of having multiple lists of accounts and passwords to maintain.


Perhaps the most well known use case for Linux PAM is as an interactive login on a terminal through the SSH protocol. Any modern Linux distribution comes with PAM installed, and the SSH daemon makes use of it for authentication. You really don’t have anything to do if you want local users to login using SSH and PAM. In my case however, I did add one more piece. As I said, PAM doesn’t just allow you to use local users in order to login using multiple methods, it’s also a system with extendible modules. So for SSH access, I added the Google Authenticator requirement. That means users must first enter their passwords, and then enter their current security token, making interactive login much more secure.

You can see how I implemented support for the Google Authenticator in this article, but basically all that’s required is installing the required module for PAM, and then adding one line to the SSH configuration file.


The OpenVPN Access Server also supports PAM out of the box. All you have to do is go to the Authentication section of the admin console, and turn it on. The module doesn’t even have any configuration option to it, once it’s turned on, your VPN endpoint will use users from the Linux host in order to authenticate:

Apache Basic Authentication

All of the web applications that run on this site use Basic Authentication in order to handle logins. This means that Apache itself handles authentication, and then lets the user access the relevant folders and web pages. Like most Linux based software, Apache comes with a PAM module, but it’s not installed by default. So the first thing to do is install the required packages:

yum install mod_authnz_external pwauth

Once done, you can create a .htaccess file in the folders you want to restrict access to, with the following code:

AuthName "Authentication Required"
AuthType Basic
Require valid-user
AuthBasicProvider external
AuthExternal pwauth

This will allow any user on the Linux host to access the web pages in that folder. You could also specify that only the root user can access the pages with Require user root instead. Just restart Apache and the new module should be in place and ready for use.

One important note is that I can easily create a user with a shell set to /sbin/nologin to allow them to use the web interface but without having console access through SSH. There are many more software packages out there that support PAM and as you can see, it’s pretty simple to enable this type of federation with no user impact, and minimal configuration effort. If you’d like to dig more into the PAM configuration itself, you can find the relevant files in the /etc/pam.d folder on the host.