Единый вход для приложения .NET, интегрированного с Active Directory

Question

У нас есть несколько клиентов, использующих наше веб-приложение (не интрасеть), некоторые клиенты хотят, чтобы их логин был интегрирован с их организациями Active Directory. Они просто хотят, чтобы этот пользователь должен был войти в свою учетную запись Windows и получить доступ к веб-приложению без ввода учетных данных пользователя.

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

Спасибо!

Answer 1

Подробнее по материалам комментариев.

Здесь есть хороший источник: AD FS 2.0 Content Map.

«Электронная книга» - here.

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

Update после комментария:

ADFS может аутентифицировать только против AD. Он не может аутентифицироваться в отношении БД. Он может получать атрибуты из базы данных SQL Server, которые затем могут преобразовываться в формулы, т. Е. Он может использовать SQL DB для авторизации.

Если вы хотите выполнить аутентификацию в SQL DB, вы можете выбрать два варианта.

1. Создание пользовательских STS
2. использовать существующий "обычай" STS как Identity Server, которая позволяет эту функциональность.

Answer 2

В вашем вопросе явно не указано, ограничено ли вы использованием ADFS для реализации единого входа. ADFS, безусловно, является одним из способов сделать это. Вы можете посмотреть OpenID-LDAP _{^{(был на www.openid-ldap.org, но проект теперь не функционирует)}} и другие identity providers в качестве альтернативы реализации единого входа.

Один из вариантов заключается в реализации поставщика OpenID, который использует интегрированную проверку подлинности Windows. Они могут установить его в DMZ, подвергая это интернету, а не ADFS. Он может разрешить единый вход в Internet Explorer и Chrome.

Реализация провайдера OpenID является нетривиальным вопросом. Вы должны будете уделять пристальное внимание безопасности. К счастью, существует ряд инфраструктур, таких как DotNetOpenAuth, которые могут вам помочь.

При использовании OpenID ваше приложение «облако» будет действовать как ссылка OpenID и получить заявленный идентификатор среди других атрибутов от поставщика OpenID. Вы должны сохранить это в своей базе данных, чтобы однозначно идентифицировать пользователя. Вы можете выбрать поставщика OpenID, чтобы он мог также предоставить вашему облачному приложению минимальную информацию, такую ​​как адрес электронной почты, имя человека и т. Д.

Преимущество использования OpenID в том, что ваше приложение «облако» может продолжать поддерживать другие известные поставщики OpenID, такие как Google и Yahoo, без особых изменений.

В конце концов вам нужно спросить своих клиентов, какие технологии им удобны. Вы обнаружите, что отсутствие доверия (бизнес-черта) между организациями чаще всего является проблемой, а не технологией.

Answer 3

Если вы создаете приложение на базе .NET, Microsoft предоставляет библиотеку с именем WIF, которая используется для связи с AD FS удобным + способом (конфигурация + небольшая адаптация кода для получения заявлений от сообщения аутентификации по АД ФС).

Существует несколько протоколов, которые поддерживают AD FS 2.0 и WIF, для обеспечения работы SSO наиболее распространенными являются (afaik) SAML 2.0 и WS-Federation. Оба построены на XML-сообщениях, но вам не обязательно знать подробности, если вы используете WIF.

Для WS-Federation библиотека WIF предоставляет плагин для Visual Studio, который позволяет настроить ваш сайт как полагающуюся сторону с помощью AD FS.

Вы можете использовать учетные данные в своей БД для идентификации пользователей, вы можете фактически указать customize всю страницу входа в систему и события аутентификации AD FS. Однако для базовой установки требуется, чтобы каждый пользователь определялся в вашей Active Directory. Вы также можете использовать свою БД в качестве хранилища претензий (другая база данных, используемая AD FS для предоставления доверяющим приложениям информации о пользователях). Обратите внимание, что если вы собираетесь использовать AD за AD FS, ваша служба AD FS должна иметь доступ к нему и запрос LDAP, который я не уверен, будет работать для вас, если ваши пользователи войдут в свой локальный домен, AD FS не знаком.

ЕСЛИ вы не обязаны поддерживать стандартные протоколы промышленных SSO (SAML 2.0, о которых я упоминал), я не уверен, что внедрение AD FS будет таким хорошим решением. Это заставляет вас работать определенным образом, что не всегда удобно.