Используя ADAM в проекте, я обнаружил, что это медведь. Документация для разработчиков может быть скудной, в ней есть причуды, отличающие ее от полной AD, и, самое главное, я не смог получить прямой ответ от MS относительно того, будет ли она полностью поддерживаться в будущем. У меня сложилось впечатление, что ADAM был дураком и что новые федеративные службы (ADFS) были тем местом, куда они хотели, чтобы люди шли. Просто перенести хранилище ADAM с одного рядового сервера на другой было больно. Тем не менее, мои проблемы с ADAM были связаны с разработкой и обслуживанием магазина. Он определенно обладает способностью масштабироваться и был надежным. Тем не менее, бывают случаи, когда вам нужно углубиться в заклинания 80-го уровня магии LDAP / Directory, чтобы понять, что она делает или не делает.
Для общедоступного сайта AD / ADAM может быть излишним IMO. Вы можете использовать альтернативных MembershipProviders, таких как SqlMembership, чтобы получить хороший уровень безопасности в отношении учетных данных. Если вы хотите пойти дальше, вы можете использовать шифрование базы данных (по крайней мере, в SQL Server встроена эта возможность) для шифрования информации, попадающей в область PII (Личная информация), и, конечно, для шифрования резервных копий. Преимущество хранилища аутентификации на основе базы данных состоит в том, что у вас есть все инструменты, которые предоставляет ваш продукт базы данных для масштабирования, резервного копирования, контроля доступа и т. Д.
РЕДАКТИРОВАТЬ: Позвольте мне добавить, что с .NET вы можете настроить свой сайт так, чтобы он работал под пользователем Windows и подключался к базе данных с помощью аутентификации Windows (при условии, что база данных поддерживает ее). Таким образом, учетные данные не должны храниться в файле конфигурации. Однако если по какой-либо причине вам пришлось хранить учетные данные, вы можете использовать DPAPI для шифрования учетных данных в файле конфигурации.
ADDITION В ответ на вопрос о защите ключей шифрования у вас есть пара вариантов. Во-первых, просто хэшируйте номера кредитных карт. Это значительно упрощает любые проблемы с доступом к данным, однако, это означает, что клиент должен будет повторно вводить номер своей карты для каждой покупки. Если вы хотите запомнить номер карты клиента, то вы переходите в новую область обслуживания ключей дешифрования. В этом случае вам абсолютно необходимо использовать проверку подлинности Windows для базы данных и изучить функцию расширенного управления ключами в SQL Server 2008, которая позволяет подключить стороннюю программу управления ключами к функциям шифрования SQL. Таким образом, только пользователь сайта будет иметь доступ к ключам, используемым для расшифровки. Существуют и другие решения, гарантирующие, что сайт не будет взломан. Больше всего беспокоит то, что кто-то получает копию базы данных незамеченной. Вот ссылка на использование SQL Server для совместимости с PCI:
Развертывание SQL Server 2008 на основе отраслевых стандартов безопасности данных платежных карт (PCI DSS) версии 1.2.