4

Background: The company I work for uses different systems to hold their insurance data which is customer related. They want to have an app for their customers where they can find their insurance related things in. Some of these systems provide web services to get the necessary information, so proper user authentication and whatsoever is possible. However, some provide direct database access without anything which comes even close to user authentication, because it was not designed to do that.

To solve this issue we are building an adapter-service, which can connect to all the different systems to get the necessary data. However the user-authentication is still an issue for the systems which don't provide that.

Another software engineer suggested (we are the only engineers) we build a general authentication mechanism which provides authentication to all the systems to get the necessary customer information. We both have the same background, we are young, we don't have that much experience in designing such a system or understanding all the security issues for such a system.

Question: With the background as stated above, I am concerned about all the security concerns which may come up if we would do that. That for the serious kind of information (insurance data) we may lack the experience to set up a system like that, to ensure the best kind of security is possible and not limited by our knowledge (or Google).

  • His opinion on this matter is that a general authentication mechanism should be build for all systems. So with one login on our side they can get all the data from the different systems if it is available there. If we follow up with things such as OAuth that we don't have to fear the security issue that much. And if we (re)search these things on the internet, that it will be OK.
  • My opinion on this matter is that a general authentication mechanism will be a good thing for all the systems which don't provide the necessarry things for user authentication (which is also possible the only solution). However we should not override systems which provide their own authentication to access their system to get the necessary data from a customer. Perhaps information can be exchanged between all the systems to ensure the same kind of login is available everywhere (if user exists in a system which provides authentication and with a systems which uses the general authentication). If an password for example is changed. This idea would make sure if our general authentication mechanism is breached somehow, that not all the systems will be exposed to the attacker, and who knows what the consequences might be.

Should we just go through with the idea to make a general authentication mechanism or limit it to the systems who need it and possible exchange login-details if the user should exist in the two different kind of systems (system which supports authentication or doesn't). What are good arguments for or against these ideas?

Edit: The general public would be using it, each system would provide the contract(s) with its data (if the customer exists in the different systems). Example: for customer '1' system A (database) and B (web-service) contains both different contracts from him. However, for customer '2' only system A (database) contains a contract. Depending on the customer their kind of contract(s) they are stored in different systems. All of these systems are third party.

closed as too broad by gnat, GlenH7, user22815, Kilian Foth, user40980 Feb 2 '16 at 14:12

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Who will be using your app? Will that be employees of the company (who might know which database system to access for the data they need) or the general public (who generally don't know what a database is)? – Bart van Ingen Schenau Jan 27 '16 at 13:16
  • The general public would be using it, each system would provide the contract(s) with its data (if the customer exists in the different systems). Example: for customer '1' system A (database) and B (web-service) contains both different contracts from him. However, for customer '2' only system A (database) contains a contract. Depending on the customer their kind of contract(s) they are stored in different systems. All of these systems are third party. – usselite Jan 27 '16 at 13:37
6

Single-sign on makes it very convenient for your users to log-on to all your system, and it also provides improved security. Imagine that it will be extremely cumbersome for users if they have to log-on to ten different databases with different accounts and different passwords each day over-and over again. That leads them to ignore any recommendation about no reuse of passwords, to use weak (because easier to remember) passwords, or password lists written down on a "postit" fixed on the back of their smartphone.

But I think there is no need for you to develop this only the one way or the other. Start with a general, reusable authentication mechanism. As you wrote, you need it either for at least some of your systems. Make sure you do not reinvent the wheel, inform yourself well about available single sign-on mechanisms beforehand.

Afterwards, take one system with an existing custom authentication, and try out what is necessary to connect this to your new general authentication system. Collect experience. Maybe you find out you do not need to throw the old system away, but you just need to write a small adapter for that system. Maybe you find out that the task becomes harder than you expected - but then you at least know the reasons why. But instead of hoping here to find "the answer" on Programmers by people who actually don't know anything about the details of your system, just try it out, step-by-step. If it does not work or takes more effort than expected, you can stop further development any time, you do not have much to lose.

  • Some additional information was added to the question that seems to make your answer less relevant. – Bart van Ingen Schenau Jan 27 '16 at 16:22
  • @BartvanIngenSchenau: I think all I wrote is still valid after the edit - maybe when the OP starts to interface the "general authentication" with the first system having already having an existing authentication, he will find out that the best way to deal with it is exactly what you wrote in your answer. Who knows? – Doc Brown Jan 27 '16 at 21:23
  • It gives me an clear idea on how to start, just build an generic authentication, research it and later on couple the systems which provides their own authentication. Or perhaps go for an solution which involves a part of @BartvanIngenSchenau his answer. – usselite Jan 28 '16 at 7:55
3

As you are creating an app that faces the general public, it doesn't really matter how the contracts are stored internally and what access controls are used by those different systems.

If the company offers a portal to its customers to see their contracts and associated data, then as a customer, I expect to have a single login to the "My Company X" app and to be able to see all contracts that I have with Company X.
It is the job of this app to collect those contracts from the different storage locations and I should not even be aware that the contracts might be spread out over multiple systems.


The internal systems that currently do authentication will most likely not have accounts for all the customers of the company, but rather accounts for the employees that need to have access to the data that is stored there.
For the app you are developing, that will also have to authenticate itself to those systems to be able to read the relevant information. So, you will not be able to piggyback on the existing authentication databases for authenticating the customers using your app.

  • Some of the systems do provide employee and customer authentication (it can provide an web-interface for customers). You are suggesting to use an employee account (e.g. app employee) to authenticate to get the necessary data for the customers? – usselite Jan 28 '16 at 7:52
  • @usselite: Yes. I believe it is more secure to have a dedicated account for the app, rather than re-using whatever customer happens to be logged in. – Bart van Ingen Schenau Jan 28 '16 at 8:23

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