Should I separate the public and private portions of an application into two separate apps?

Question

So I'm currently running an analysis task for my company. I won't go into too much detail but we are dealing with medical records and other confidential data. Previously this application was only used internally but now there's come a business requirement that would allow for external access by an unauthenticated user outside of the business to view a document once they've completed a sort of handshaking process involving emails and an access code.

So, my question is, should I separate the new requirements into another publicly accessible application separate from the original application that requires user authentication? The app currently sits on an angular/.Net/MSSQL stack so this could require duplicating all or some portions of the stack. What are the things to consider in regards to one app with both public and private access vs two apps, one for the public and one used internally?

Answer 1

This is a really bad idea:

1. Access should be determined by permissions, not which application code someone is running. Getting hold of a piece of code or an application should never be sufficient to gain access to anything secret. It's analogous to how an encryption algorithm should protect data even from someone who understands the algorithm completely.
2. Duplicating masses of code means duplicating bugs and introducing new bugs when trying to make copied code fit into some different architecture.
3. Duplicating code also means that bugs in the copied code needs to be fixed at least twice: once for each code base, and again ad nauseam because the fix for one turned out to break the other in some subtle way.

And those are just the security- and stability-related issues. Then there's the obvious duplicate work even if everything does work perfectly the first time, and the loss of morale when it obviously doesn't, because humans are terrible at (and justifiably hate) finicky, repetitive tasks.

It sounds like what this needs is a well-tested API, bulletproof permissions checks, and a thin, flexible GUI layer.

Answer 2

Should I separate the new requirements into another publicly accessible application separate from the original application that requires user authentication?

The answer is in the context. Worth meeting with your project manager and the stakeholders. Ask'em the questions you need about the new part. You want a better perspective (understanding) of the goals (needs) in the short (next 6 months), middle (next year) and long-run (two years or more). You need this information to decide how to proceed before taking any decision that affects the current design.

Figure out the conditions under which each part will operate. How both parts are going to be managed. By who? What about their respective development life cycle? Do both share budget? Roadmap?

Where is supposed to be deployed each part? Within the same network? Same network segment? Will any operate within a private network with hard access rules?¹ What's the expected or desired SLA and throughput of the public part? Do you need to change the stack? ...

Needs dictate, somehow, what you should do.

In relation to code duplication, unless you implement something that totally defeats the company's needs, even duplicating code (well managed) can be reasonable. Note that duplicated code is a side effect easy to handle. Libs and modules exist for some reason.

There're alternatives tho. For example, you could implement execution profiles. Basically, it's the same app deployed with different profiles where each profile enables or disabled a subset of features.

---

^{1: It's unlikely your security team will look with kind eyes at any request asking for access to this part of the infrastructure.}

Answer 3

Well, duplication is never recommended.

But you can achieve the functionality using below.

1. If some data is required to the external user, then give access to only that data. This can be done using Web API. That way, sensitive data which is allowed will only go out.
2. Create your views if required.
3. Create a route only for the external users. And remaining all routes will not be accessible to them. So you have the same code but users are allowed through routes.

I am not a regular angular user, but this should work.

Update: I found an example related to the above can be found here.