Хранение пользователей общедоступного веб-сайта в Active Directory

Question

Я работаю над архитектурой системы для управляющего фондом / пенсией. Мы предоставляем два веб-приложения ASP.NET MVC; один позволяет членам пенсионного фонда входить в систему и проверять их остатки, управлять своими инвестициями и т. д., а другой - разрешать работодателям делать взносы в фонд от имени работников (участников). Есть также внутренние приложения, доставляемые через интранет.

Мы рассматривали возможность использования Active Directory для хранения, аутентификации / авторизации не только внутренних пользователей (которые уже используют AD для входа в домен и авторизации ресурсов), но и для учетных записей пользователей и работодателей. Учетные записи пользователей и работодателей будут располагаться в другой иерархии (может быть, даже в другом экземпляре AD?) Для внутренних пользователей.

Однако мне интересно, является ли это лучшим вариантом использования для AD ... учитывая, что AD является таким "внутренним" ресурсом, следует ли его использовать для хранения деталей аутентификации для "внешних" пользователей (альтернативой является таблица USERS в базе данных)?

Преимущества: AD спроектирован и оптимизирован для хранения данных такого типа, приложения ASP.NET легко интегрируются с авторизацией AD, возможно, существуют инструменты для работы с данными (сброс пароля и т. Д.).

Каковы риски?

Answer 1

Я бы рекомендовал против гибрида внутренних и внешних пользователей. Судя по опыту, это создает много проблем с безопасностью. Возможно, было бы лучше создать отдельные системы аутентификации, одна из которых использует AD напрямую для внутреннего домена, а другая - каталог ADAM, предназначенный просто для хранения внешних пользователей. (т. е. внутренние пользователи должны проходить проверку подлинности с использованием NTLM с AD, чтобы обеспечить зашифрованный вход Kerberos, в то время как формы будут использоваться для экземпляра ADAM).

AD легко интегрировать, хотя, и если прямая интеграция нежелательна из-за сетевых проблем, вы всегда можете попробовать LDAP: // для достижения тех же результатов аутентификации.

Answer 2

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