Unifying the data
Since the authentication was independent between the five projects, you may encounter several inconsistencies:
Different identifiers. For example if the user identifiers are e-mail addresses, the same person can register with
firstname.lastname@example.org for one project,
email@example.com for another one, and
firstname.lastname@example.org for a third one. It is practically impossible to solve this issue: you may have an idea through information aggregation¹, but it's not precise enough and may be insufficient in some cases².
Data standards inconsistency. What if both projects need to know where the user is, but the project 1 uses two letters convention, like
CA, while the second one uses the full name, like
Different authentication implementations. For example, the project 1 uses
SHA256, while the project 2 uses salt and
SHA512 and the project 3 uses
PBKDF2? In order to solve this issue, you'll need to store every hash used, which means having a table like this:
create table [People].[User]
[Mail] nvarchar(500) not null,
[Salt] char(16) null, -- Salt used by project 1.
[Hash] char(128) null, -- Hash used by project 1.
[AlternateSalt] varchar(12) null, -- Salt used by project 4 and 5.
[AlternateHash] char(64) null, -- Hash used by project 4 and 5.
[ThirdHash] char(20) null, -- Hash (no salt) used by project 2.
... -- etc.
and do consecutive checks, until finding a good one.
The good thing is that you may progressively consolidate the passwords for the users once they authenticate. For example, if the user successfully authenticate with the
SHA1 used by the fifth project, you may compute and store the
PBKDF2 hash and salt and remove the
SHA1 hash from the database.
After a year or two, if there are still users who didn't logon for a while, you may send them an e-mail to tell that they must logon if they want to keep their account.
Different passwords. The consolidation may work only if the user is registered at one project, or if she uses the same password for every project. What if the passwords she use for different projects are not the same? You still need to keep the ability to logon with several passwords.
Different data. If Vanessa Kelley told that she lives in Toronto to the project 1, and in Montreal to the project 2, which one is obsolete?
If the inconsistencies are too important, there is a risk that you will never be able to create the unified logon. If there are few or no inconsistencies, than the task will be pretty easy.
Unifying the process
Once you unified the data, you may provide a common process for the five projects. You may want to create a web service which will be accessed by the five projects, or you can modify those projects to access the common database directly. It would be probably much better to use a web service, instead of letting different applications to access the database.
If you can't modify the original projects, too bad. You may sync the data between databases, but it's not easy and not error prone.
Still, you don't want your common logon process to use all the five databases. Not only it costs too much in terms of resources, but it also makes your whole process dependent on five databases. If one of them is down, the logon process would fail.
¹ Example: according to the logs, both logons were made from the same machine, one at 3:00 PM, the second one at 3:15 AM. Moreover, the browser headers were the same, and the first name, last name and birth date are the same.
² Example: if two logons share the same first and last name, it doesn't mean anything at all. Two people can share the same machine or use the same browser too.