User authentication: In HTTP Server vs. in Web Application

Question

Management decided to switch the authentication-backend from LDAP to Kerberos as LDAP is deemed "obsolete and insecure". Also they want to switch from Apache to nginx for "performance and reliability". Ultimate goal is to enable SPNEGO for single-sign-on within the domain.

Previously, we happily used Apache's mod_authnz_ldap. nginx however does not even seem to support authentication modules by default. I never worked with nginx before, so I might have missed something.

Asking local experts about this, I received the response "The HTTP server should not do the user authentication – that is the web application's responsibility." So now I am stuck with a bunch of services which were never designed to do user authentication themselves.

This made me think: What are the advantages of not having authentication in the HTTP server?

Performance might be one factor – but at what cost? Usually my stance is "never do it yourself". Especially when it comes to cryptography or – in this case – authentication schemes. Using the HTTP server's features, all authentication is done in one place. User information is simply forwarded to the server-side application. Without such a feature in the HTTP server, I would need to implement the authentication scheme in each and every application over and over again. As of today, I failed to find ready-to-use modules for our ancient php-based applications. There is a kerberos module for flask. It was last updated six years ago and does not play nice with me at all. I have not even looked into the other services yet. It seems to be a massive increase in the maintenance required. I suppose, there are upsides to this approach, but I fail to see the. What are the advantages?

Answer 1

The advantage of authenticating at the application is having this done independently of the OS and web server, you are not mixing your implementation layers (i.e. the application's authentication and access controls don't rely on information passed on from another piece of software).

Generally the advice of not authenticating at the web server level is a good one, since there's limited control of granularity and it affects the concept of server side sessions. But it's also a one-sided argument and there could be good reasons to use it. Context is critical.

Personally I find, at face value with the information you shared, I find it a poor decision to essentially break a functional setup and shoehorn a type of solution into multiple applications that may not be running on the most up to date platforms or receiving sufficient amount of maintenance effort. It's both fixing what isn't broken and multiplying effort. If/once it's done you'd probably be in a better position for the future, but getting there will become a problem.

Answer 2

I think that @Pedro has a very good and well balanced answer to your question. However, since I generally agree with your local experts, I think it is good to have some further context on why you might want to make this change. As Pedro mentioned, the issue is mixing implementation layers, and limited control becomes a real problem when you aren't authenticating at the web server level. What does that actually mean though? Consider the following questions, which represent real-life (and in my experience, common) business needs that may be very difficult or nearly impossible to execute in your current circumstances. Note that some of these are based on assumptions about your hosting setup that may or may not be applicable.

1. What happens if your hosting provider closes and you have trouble finding a new provider that supports Apache with the mod_authnz_ldap module enabled?
2. What if internal application changes force a change of OS, and you have difficulty getting the mod_authnz_ldap module installed and running on the new OS?
3. What if you need to change the application to allow in users who aren't in LDAP?
4. What if you need to migrate away from LDAP for reasons completely unrelated to this application anyway (hint: this is where you find yourself)
5. What if you are tired of running your own server and need to migrate to load-balanced cloud infrastructure? Will you still have access to LDAP? Will this module work properly in a completely new environment?
6. What if you want to ditch servers all together and run in Kubernetes or the like? Will this setup transition smoothly?
7. What if Apache drops support for the mod_authnz_ldap module?
8. What if you need to implement role based access instead of a global allow/disallow rule?

Many of these may not be applicable to you, but many of these are extremely common business needs. So while it sounds like the current reasons for these switches are not necessarily well thought out, and you may be able to put them off for a while, eventually there is going to be a compelling business need that forces this change and you will find yourself back right here. You definitely don't want to rush an overhaul to the authentication system for an application, but at the same time it seems unlikely to me that you will be able to continue to use this authentication setup in the long term.

Also, it is quite possible that there is a middle ground between "Leave the current system as-is" and "Do it all yourself" (although to be clear the rule of "never roll your own only goes so far - otherwise you wouldn't be building your own web application in the first place). For instance there are plenty of 3rd party authentication systems your application can integrate with to alleviate most of the burden. AWS Cognito and Auth0 would be two such examples, which I mention only for completeness and not as an endorsement.