Background: I have a collection of Linux-based servers (let's say a few dozen) that are hosted in different locations. Some servers are lone satellites while others are hosted together in the same data centers. Some are physical hardware servers, and others are virtual private servers. The servers provide services like email, web application hosting, databases, and the server-side parts of some custom applications. The servers themselves already have tools for managing the hardware, and the operating system-level management (administrator accounts, virtual server management, etc.) is also taken care of.

Problem: So far, authentication to different services on the application level has used a number of solutions. Sometimes, this has meant that account passwords have had to be stored in multiple locations. A better solution would be to have a single source authentication system with centralised management that would allow each service to authenticate a user from a single instance of their account, and would allow operating on a single data item instead of figuring out which locations need to be updated when creating, changing, and removing an account. The credential data could be replicated to provide redundancy. (Note that the goal here is different than single sign-on: you have to authenticate separately to each application, but your credentials are stored in a single location. See this question.)

Several previous questions suggest LDAP, and also talk about Kerberos. This question asks about LDAP security and asks for a comparison between LDAP and Kerberos. Kerberos is nice but the single sign-on capability is not needed in this case, so setting up Kerberos may be overkill and cause unneccessary administrative burden. This question extends the scope to include network devices, and the focus is more on the OS level than the application level. In my case, it's just the application level authentication that is needed. This also means there is a larger variety in the kinds of authentication protocols that have to be supported; PAM is not enough. This question asks for alternatives to LDAP, but the answers point to LDAP, anyway, for good reasons. NIS is another proposed solution, but it's really not suitable in this case because it just solves the distribution of password (and other) information, not the storage, management, and authentication methods. Finally, this question seems quite similar, but the focus is really on VPN authentication. (There is also a similar question here, but was not precise enough to fit ServerFault.)

LDAP is one of the authentication sources I currently use. However, not all applications can use LDAP. Some need an HTTP-based interface, while others work best with an SQL interface. For example, there is a need to run an OpenID provider, and some of the custom software I need to run for users can only be configured to authenticate via ODBC.

Another suggestion is FreeIPA http://freeipa.org/, but it also has the extra burden of Kerberos and looks more like a solution for the OS level. It's been in development for some time, but I'm not entirely convinced it's mature enough, and it may also have too much unneceassary features while still not providing the ones I really need.

I would like to separate the storage of authentication data (user names and passwords) from the authentication service. I would use a single, well-defined, and secure location for storing the data, and several authentication services that use the storing location to provide authentication using a variety of protocols/interfaces. At least an LDAP and an SQL interface are needed, and an OpenID provider is also high up on the list. I think LDAP is a good candidate for the storage, but I'm open to other options as well. Preferably, they should be Free/Open Source Software.

Question: What software should I choose for storing authentication credentials, and how do I provide the different interfaces for authenticating against those credentials?

What recommendations do you have?


If you're using LDAP as your backing store for credentials, then:

  • You can use pam_ldap for system-level authentication.
  • Many databases can authentication directly against LDAP (e.g., Postgresql)
  • Other databases can use PAM, so that acts as your bridge to LDAP.
  • Many devices and web applications already know how to talk to LDAP.
  • There are LDAP modules for Apache and other web servers.

This seems to cover all of your requirements (if it doesn't, please give some explicit examples). For OpenID, there are a number of solutions, some of which (e.g., Atlassian Crowd) can authenticate against LDAP and others that can use HTTP basic authentication (which means you would be covered by the LDAP modules for Apache).

Incidentally, the benefit to Kerberos is not just single-signon. The other benefit is that -- when used correctly -- your password never, ever traverses the network. This means that a compromised server isn't able to harvest passwords. It's a big advantage, but really only useful if (a) people can acquire kerberos tokens from their local endpoint, and (b) all your applications support Kerberos or GSSAPI authentication. It's rare that you can actually meet both criteria in a heterogeneous environment.

  • Good answer, but what about accessing the credentials from a client that can only speak SQL? Can I somehow expose the LDAP directory via an SQL interface, and not only read the credentials but also modify them? – Fabian Fagerholm Aug 9 '12 at 14:42
  • I hadn't realized that you wanted to do more than authentication. If you want clients to be able to modify credentials via SQL, maybe you could use something like the SQL backend for OpenLDAP. More information here. – larsks Aug 9 '12 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.