У нас похожая ситуация. Наши внутренние пользователи идут против AD, внешние парни против магазина ADAM. Отличается от вашего подхода к базе данных, но похож в том, что у них есть два пользовательских хранилища. Наша аутентификация против AD происходит в безопасной зоне, веб-серверы в демилитаризованной зоне выполняют вызов веб-службы в безопасную зону для аутентификации. Не знаю, что вы ищете, но ваш подход звучит нормально.
РЕДАКТИРОВАТЬ, чтобы ответить на комментарии:
- Хранилище ADAM не синхронизировано с базой данных.
- В основном было два провайдера, для которых был настроен веб-сервис, по одному для каждого магазина. На самом деле их было три за период времени, когда пользователи мигрировали из прежней системы. Чтобы определить, в каком хранилище находился пользователь, сначала приложение просто запросило наиболее распространенного провайдера (в нашем случае ADAM), и если пользователя не было, оно перешло к следующему провайдеру.
- Конечной точкой был веб-сервис внутри брандмауэра, работающий на сервере среднего уровня. На этом сервере работал IIS, так что технически это был веб-сервер, но на самом деле это наш сервер среднего уровня, поскольку он не обслуживал никаких страниц и не размещал ничего, кроме нескольких веб-сервисов.
- Похоже, у вас есть 2 типа внешних пользователей. Те, кто действительно внутренние пользователи (в AD) и те, которые действительно внешние (в БД). Это не очень элегантно, но вы можете иметь 2 экрана входа, по одному для каждого. Не публикуйте внешний экран входа внутренних пользователей кому-либо, кроме них, и публикуйте настоящий внешний экран входа в мир. Немного хакерски, но это сработает. В противном случае при входе в систему будет необходимо определить тип пользователя.