Реализация многопользовательского доступа для зрелого корпоративного приложения

Передо мной поставили задачу сделать корпоративное приложение многопользовательским. Оно имеет Java/Glassfish BLL, использующий SOAP веб-сервисы и PostgreSQL бэкенд. Каждый арендатор имеет свою собственную базу данных, поэтому (по крайней мере, в моем случае) "многопользовательский" означает поддержку нескольких баз данных на сервер приложений.

Текущий однопользовательский appserver инициализирует пул соединений C3P0 строкой соединения, которую он получает из конфигурационного файла. Я думаю, что теперь нужно будет создать один пул соединений для каждого клиента/базы данных, обслуживаемой аппсервером.

Как только пользователь войдет в систему, я смогу сопоставить его с нужным пулом соединений путем поиска его арендатора. Моя главная проблема заключается в том, как добиться этого - когда пользователь впервые входит в систему, запрашивается таблица User бэкенда и обслуживается соответствующий объект User. Похоже, мне нужно будет знать, какую базу данных использовать, имея только имя пользователя для работы.

Моя единственная достойная идея заключается в том, что должна быть база данных "config" - централизованная база данных для управления информацией об арендаторах, такой как строки подключения. BLL может запрашивать эту базу данных для получения информации, достаточной для инициализации необходимых пулов соединений. Но поскольку у меня есть только имя пользователя для работы, похоже, мне понадобится централизованный поиск имени пользователя, другими словами, таблица UserName с внешним ключом к таблице Tenant.

Именно здесь мой план проектирования начинает пахнуть, вызывая у меня сомнения. Теперь у меня будет информация о пользователях в двух отдельных базах данных, которые нужно будет поддерживать синхронно (добавление, обновление и удаление пользователей). Кроме того, имена пользователей теперь должны быть глобально уникальными, тогда как раньше они должны были быть уникальными только для каждого арендатора.

Я сильно подозреваю, что изобретаю колесо, или что существует, по крайней мере, лучшая архитектура. Я никогда раньше не занимался подобными вещами, как и никто из моей команды, отсюда и наше невежество. К сожалению, приложение мало использует существующие технологии (ORM, например, была сделана в домашних условиях), поэтому наш путь может оказаться нелегким.

Я прошу о следующем:

• Критика моего существующего плана проектирования и предложения по улучшению или переработке архитектуры.
• Рекомендации по существующим технологиям, которые обеспечивают решение этой проблемы. Я надеюсь на что-то, что можно будет легко подключить в конце игры, хотя это может быть нереально. Я читал о jspirit, но нашел мало информации о нем - любые отзывы о нем или других фреймворках будут полезны.

UPDATE: Решение было успешно реализовано и развернуто, и прошло первоначальное тестирование. Спасибо @mikera за его полезный и обнадеживающий ответ!