Accessing Connection Strings via a Web Service

Question

The idea of storing connection strings in a data base is a perverse idea, but please hear me out first. We all know that it’s best practice to encrypt connection strings in the web.config file, but what if we just skip the web.config file completely?

A couple of 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 various databases. This is the 3rd time in 2 years I’ve had to move databases from one server to another. So I thought of storing connection strings in a database and assigning each a GUID to be accessed via a web service. Instead of placing connection strings in a web.config, you would just need to store the connection string GUID in the web.config, and reference the connection string web service so that you could request that connection string. Encryption can be done at the application level and connection strings are just stored encrypted in the database.

I’ve created a proof of concept and it works fine (its just on a local intranet and not exposed to the internet).

The benefit is obvious to me; such as being able to quickly update connection strings without having to touch the web application. This means that you could build a web application just for editing connection string in the database, that a DBA could use on there own, so they never have to bother a programmer when moving databases.

But the benefit is not what I’m interested in. I’m interested in what everyone here thinks about doing something like this?

Answer 1

What about when your webservice changes location? Then you would have to update all of the web.configs anyway.

Are your applications on the same server, or spread across just a few servers? You could edit the machine web.configs to incldue the DB connection strigns to save a lot of repitition.

Answer 2

I tend to do one of two things. I will store the connections in Machine.Config, or I will create a new host name which just refers to the DB Server. I then put a record in the hosts file.

The benefit of this is I never have to change a config file when I move from my local box, to dev qa or production environments.

Answer 3

Take your connection strings out of the main web.config and put them in a separate config file. This file will then be the same for all your apps so if they have to change you just have to copy and paste the same file into all your app folders instead of edit each config separately.

Answer 4

The main disadvantages I can see are the obvious performance penalty (and if you then cache the connection string) and the single point of failure you are likely to introduce to all your applications(unless you're going to load balance this service, which would seem a bit of an overkill)

Answer 5

Very interesting question. I found it because I just had the same idea.

It seems very similar to UDDI to me and it gives you another layer of indirection with possible security enhancements & improved maintainability (except for single point of failure which you can solve anyway).

Of course there's DNS which would solve the problem of host names, but with such web service you have incredible possibilities like returning different connection strings based on who's asking (depending on i.e. SSL cert or user/pass or token, directory services like AD, LDAP, user role, etc. - the sky is the limit :)

Additionally all connection strings would be properly protected and inaccessible for prying eyes of curious users.

At first this idea seems perverse, but the more I think about it the more I'm convinced that an Enterprise-level company could benefit a lot from introducing such solution.