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.
2
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.
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.
2