Access connection strings through the web service

Question

The idea of ​​storing connection strings in a database is a perverted idea, but listen to me first. We all know that its best practice for encrypting connection strings in the web.config file, but what if we just completely skip the web.config file?

A few months ago I was asked to move databases from one server to another. This meant having to update connection strings in every program that accessed these different databases. This is the third time in 2 years. I had to move databases from one server to another. So I thought about storing the connection strings in the database and assigning each GUID to access through the web service. Instead of placing the connection strings in the web.config file, you just need to save the connection string GUID in the web.config file and specify the connection string web service so that you can request this connection string. Encryption can be done at the application level, and connection strings are simply encrypted in the database.

Ive created a proof of concept and it works great (its only on the local intranet and is not exposed to the Internet).

The benefit is obvious to me; for example, the ability to quickly update connection strings without having to touch a web application. This means that you can only create a web application to edit the connection string in the database, which the DBA can use on its own device, so they do not need to bother the programmer when moving the databases.

But this is not what interests me. I wonder what everyone here thinks of doing something like this?

Answer 1

Take the connection strings from the main web.config and put them in a separate configuration file. This file will be the same for all your applications, so if they need to change, you just need to copy and paste the same file into all application folders, and not edit each configuration separately.

Answer 2

The main disadvantages that I see are the obvious performance degradation (and if you then cache the connection string) and the single point of failure that you are likely to present to all your applications (if you are not going to load the balance of this service, which might seem too redundant)

Answer 3

How will the location of your web service change? Then you still have to update all web.configs.

Are your applications on a single server or distributed on only a few servers? You can edit the machine's web.configs file to enable database binding to save many repetitions.

Answer 4

I tend to do one of two things. I will store the connections in Machine.Config, or I will create a new host name that just refers to the database server. Then I put the entry in the hosts file.

The advantage of this is that I never need to change the configuration file when I switch from my local field, to dev qa or to production environments.

Answer 5

Very interesting question. I found this because I had the same idea.

It seems very similar to UDDI to me, and it gives you another level of indirection with possible improvements in security and improved maintainability (except for one point of failure that you can resolve anyway).

Of course, there is a DNS that would solve the host name problem, but with such a web service, you have incredible features, such as returning different connection strings based on who is asking (depending on the SSL certificate or user / pass or token, services directories such as AD, LDAP, user role, etc. - the sky is the limit :)

In addition, all connection strings will be properly protected and inaccessible to search for curious users.

At first, this idea seems perverted, but the more I think about it, the more I become convinced that a company at the enterprise level can greatly benefit from the introduction of such a solution.

Answer 6

I see that I am not the only one who had this idea. I just recently started to think it over after some thought about the range of user applications and Intranet sites (not to mention the numerous databases and servers). It seems that the WCF service can or should be written in such a way as to return database connection information in several ways: the connection string, the actual connection, or simply the name of the server and database. Moreover, the service itself must obtain information from a central auxiliary database and table, which can be used to manage various connection points. For example: give me a connection, creating or developing an account database, etc.