3

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?

  • Your local experts aren't crazy. In fact, using Apache to authenticate people via LDAP is the crazy thing in this question. "Never do it yourself" doesn't apply everywhere, and there are often more options than just the immediately obvious one (i.e. there may be a third option that isn't "Continue to do things a crazy way" or "Implement everything ourselves"). However, making large changes for poorly-thought-out reasons and without adequate planning is probably the most dangerous choice, so some push back against this request may be reasonable. – Conor Mancone Jun 18 at 14:56
  • Still... while things depend on your particular use case, I would hazard a guess that the current way you are doing this is not a good solution in the long term solution. I suppose what this all boils down to is the fact that I agree with Pedro – Conor Mancone Jun 18 at 14:56
  • @ConorMancone "crazy" is pretty much the baseline description of the systems I am dealing with. I just remembered one of our services is written in Object Pascal and I really do not want to fiddle around with that. With the help of the answers here I might succeed in persuading folks to stick to Apache and use its authentication modules rather than to change all of our applications. – Hermann Jun 18 at 18:41
4

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.

| improve this answer | |
  • 1
    Your answer is insightful. I missed the aspect of deployment entirely. I now see you would want your application to run on any server in a self-contained manner without the need of configuring the server itself. It is not really applicable to my situation as I am dealing with self-hosted in-house software exclusively. Tough this is probably where my local experts are coming from and your answer helps me understand their view. – Hermann Jun 18 at 18:38
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.

| improve this answer | |
  • Your answer has a nice list of examples. I was looking at this from a security point of view: In my world, unsolicited access should be rejected as soon as possible. If the HTTP server already handles the authentication, I cannot mess it up in the application layer. Apart from that, it seems like a decision related to software design more than security. – Hermann Jun 18 at 18:31
  • If the authentication provider changes, I need to switch the authentication module. Whether I need to do so at the server or in application does not seem to make a difference in general. In my case I happen to have only a few servers, but a whole bunch of applications. I was too focused on my particular situation and forgot the large-scale case. Your answer makes much sense in that regard. – Hermann Jun 18 at 18:32
  • @Hermann you're right - from my perspective it is more of an issue of software management than security. I would rephrase one of your statements though. While I agree with "unsolicited access should be rejected as soon as possible", the devil is in the details. Consider again role-based access controls. If some users should have access to resources that others shouldn't, I'm pretty sure your current setup won't be able to handle that at all because it doesn't have the necessary information to do so. Therefore it is quite easy for "as soon as possible" to become "the application layer". – Conor Mancone Jun 18 at 18:48
  • Although I would also emphasize that software management and security are two sides of the same coin. Imagine a slightly different use case comes along and someone wants to store some data in the app but doesn't want all users to have access - i.e. RBAC is needed. Your system can't handle it, and when they ask about limiting access to a few they are told, "We can't do that without a huge overhaul" so they finally decide "Let's just put it up anyway but only share the link with people who need it". Now you have a security problem waiting to happen because of improper separation of concerns – Conor Mancone Jun 18 at 18:50
  • To bring it back though: is a full overhaul needed for your systems? I obviously have no idea! Every company/person needs to find their own balance between where and how they are willing to spend their money. This may not be the time to make this change. I would point out though that the importance of "Operation Excellence" and the resulting business adaptability is an easy aspect to overlook, and by the time you really need it, it is often too late to get it. – Conor Mancone Jun 18 at 18:53

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.