Here is the situation I have inherited:
- We have approximately 10 websites (Asp.net web forms) that each have their own database.
- Each of these databases houses some site specific data, and each has some form of a user table that will map to what is called a User Service.
- The User Service is just another website that has a database with one table (User) that have about 3 different unique identifiers for a user: a UserId guid, an internal desktop application id (third party app, needed to map back to it), and a username.
- On all the different websites the databases have the User table, sometimes called Person, or Student, or whatever else, and they are inconsistent in which UserService.User.[IdentifyingColumn] they map to.
The Problem:
It is getting to a point where these application are now needing to share some data with each other, and I see that need increasing as the departments are streamlined even more. With this current set up, it is a lot of hoop jumping to get the right UserId column to match to the right UserId column in the UserService.
Confused yet? Me too..
The Question:
How to approach correcting the issue? I have a few different ideas, some I like more than others, but in order to implement them I need some solid benefits I can bring up to the head of IT, as well as justify the programming time taken for the re-write.
Idea 1: Create a true intranet application. One web application with one database. This way they all live in the same project, and sharing data between the various departments is very simple and quick.
Idea 2: Create a "Master Key" identifying field that will be the end all to identify a user. Make this key available on each database and so there will not be any odd mapping and the various sites can talk to each other. To me this one solves one problem, mapping each db to the next one. It is still very fragmented and there is very little code re-use.
Idea 3: Work with it in the current form trying to continue the present fashion of many small databases and sites.
Which of the above options would you suggest, and why?
Best Answer
Single Sign On is an excellent idea. Just so you know, you don't necessarily need to use a specific technology, such as Active Directory, WIF or OAuth. You can implement it with just ASP.NET forms auth. Here's how you do it:
Selling it to the head of IT
Deciding on How
Random Tips from my experience
To keep your application maintainable, I would make the configuration as simple as possible. To your question about the separate databases, if they don't buy you anything by being separate, reduce the complexity and merge them. Since they are an intranet, I'm assuming they won't ever be deployed separately.