Design – Don’t Repeat Yourself vs Single Point of Failure in Authentication

designdry

In my work we've been tasked with implementing two factor authentication across a number of our web applications which currently share a credentials database (asp.net forms authentication) but have their own code for collecting and validating credentials etc.

In thinking through this problem I've reasoned that this might be a good time to consolidate all our authentication into one web service (FWIW I'm looking at IdentityServer) which all our various web applications could use.

To my mind this follows the DRY principle, will make implementing and testing the 2FA itself easier, and lead to a more maintainable system in the future. However in discussing my plan with a colleague he has suggested that I'm introducing a single point of failure to the system, and that if a bug were introduced to the Authentication service it would bring all our applications down. To be clear we're not talking about service availability (The service would be hosted with the same level of resilient infrastructure as our other applications which my colleague accepts as reasonable), but about the potential of a single bug to take down all our applications. His suggestion is that we either write the authentication into the individual applications or we should provide some sort of redundant auth system for if the primary system fails.

To me this argument just feels the wrong way round. If we're depending on different implementations to stop all our services failing then we're doing it wrong. However I've been unable to put a convincing case to make colleague. Some of the arguments I've put forward:

This is no different to using libraries between projects – If a critical bug in some of these libraries were to reach production it could take down a number of our applications – but we're not suggesting that we shouldn't be sharing code here. Is this conceptually any different?
Whilst there is room for improvement we don't have a terrible testing/deployment process. We use continuous integration, we have automated unit tests, a reasonable test environment and manual test scripts (not to mention the ability to revert a production deployment if we do get a bug through). Whilst bugs are always going to get through, this process is the mitigation against that, not writing things twice.
By its nature the authentication process is not the sort of thing that's going to be undergoing major changes regularly. Once we have an authentication system that works we're likely to leave it be, making the risk of breaking anything fairly low.
The DRY principle – Isn't writing the same thing multiple times more likely to lead to bugs and be a nightmare to maintain than having one service?
The idea of a redundant authentication implementation is pretty crazy to me. Maybe if we were writing autopilot software for an airliner, but not for non safety critical web applications.

My colleague remains unconvinced. Am I wrong? If I'm not, what is the killer argument that I'm missing here?

Best Answer

Consolidating authentication into a single service is called Single Sign-On and it's been a thing, even a best practice, for like thirty years.

His suggestion is that we either write the authentication into the individual applications or we should provide some sort of redundant auth system for if the primary system fails.

You already have your ASP.net authentication in the individual applications, so, to be fair, “write the authentication into the individual applications” (with a lot of cut and paste, or shared libraries, or whatever) is probably the least amount of work.

The redundant auth system suggestion is a security problem as well as a maintenance problem and is clearly bananas. It's not a serious suggestion.

It looks to me like you have a people problem, not a programming problem. Your people problem is that you need to figure out your colleague's real reason for objecting. It probably isn't anything he's actually said.

Some possibilities:

he feels that rewriting the whole auth stack for each application will be too much work.
he feels that rewriting the whole auth stack for each application is too risky, in terms of possibly breaking the existing credentials authentication.
he doesn't understand the IdentityServer solution and because of that isn't comfortable with it.
he didn't come up with the IdentityServer solution himself and because of that isn't comfortable with it.
he feels like taking on 2FA is enough new technology to deal with and enough new complexity to add to the apps, without taking on OpenID/OAuth/etc., etc.
something else I haven't thought of

You need to find that underlying objection and evaluate it fairly. (He might even be right!)

One approach would be to step back from the specific solutions you've each advocated and try to at least agree on the criteria that should be used to choose a solution, taking into account each of your preferences regarding technical risk, short-term vs. long-term workload, etc. (In negotiation school, they call this distinguishing interests from positions.)

If, in the end, he's still convinced that he's right and you're wrong, and you're still convinced that you're right and he's wrong, you need to kick it up a level to where you can each present your preferred options to someone empowered to make the call. And then you both need to accept the decision.

Related Solutions

Testing vs Don’t Repeat Yourself (DRY)

I believe this is a misconception any way I can think of.

The test-code that tests production-code is not at all similar. I'll demonstrate in python:

def multiply(a, b):
    """Multiply ``a`` by ``b``"""
    return a*b

Then a simple test would be:

def test_multiply():
    assert multiply(4, 5) == 20

Both functions have a similar definition but both do very different things. No duplicate code here. ;-)

It also occurs that people write duplicate tests essentially having one assertion per test function. This is madness and I have seen people doing this. This is bad practice.

def test_multiply_1_and_3():
    """Assert that a multiplication of 1 and 3 is 3."""
    assert multiply(1, 3) == 3

def test_multiply_1_and_7():
    """Assert that a multiplication of 1 and 7 is 7."""
    assert multiply(1, 7) == 7

def test_multiply_3_and_4():
    """Assert that a multiplication of 3 and 4 is 12."""
    assert multiply(3, 4) == 12

Imagine doing this for 1000+ effective lines of code. Instead you test on a per 'feature' basis:

def test_multiply_positive():
    """Assert that positive numbers can be multiplied."""
    assert multiply(1, 3) == 3
    assert multiply(1, 7) == 7
    assert multiply(3, 4) == 12

def test_multiply_negative():
    """Assert that negative numbers can be multiplied."""
    assert multiply(1, -3) == -3
    assert multiply(-1, -7) == 7
    assert multiply(-3, 4) == -12

Now when features are added/removed I only have to consider adding/removing one test function.

You may have noticed I have not applied for loops. This is because repeating some things is good. When I would have applied loops the code would be a lot shorter. But when an assertion fails it could obfuscate the output displaying an ambiguous message. If this occurs then your tests will be less useful and you will need a debugger to inspect where things go wrong.

Design – How to handle shared data across microservices

One of the solutions i've seen is to move shared data to eventsourced aggregates and make it publicly availible to any service that need this data. You may use Kafka or Eventstore to store them. In case of Kafka eventsourced topics are used by another microservices through streams API for example in form of tables with most actual state and new events that change state also come naturally as stream messages to any client. This means no direct queries to another services, no data duplication and data updates become reactive in some sense.

But this pattern is unfamiliar and foreign to many programmers, Kafka is a heavy service and brings ops burden and cognitive load to programmers, so, as an alternative i like the idea of shared database. It just demands strict limitations as - single writer principle. Other microservices may query all the tables but can only write to tables that belongs to them. Database permissions may help to enforce access rules.

I'm myself fairly new to microservices world so please take my words with a ton of salt. :)

Best Answer

Related Solutions

Testing vs Don’t Repeat Yourself (DRY)

Design – How to handle shared data across microservices

Related Topic