Проверка подлинности Windows в asp.net MVC 3 размещается на Windows Azure?

Question

Я перемещаю один веб-сайт интрасети ASP.NET MVC 3 в Windows Azure, а базу данных - в SQL Azure.

В Premise мой сайт использует проверку подлинности Windows для проверки подлинности и авторизации пользователя (путем размещения атрибута AUTHORIZE на контроллерах).

Было бы очень любезно с вашей стороны, если вы дадите мне знать, как поступить так же. Заранее спасибо!

Answer 1

У вас есть два варианта:

1. Используйте федеративную аутентификацию и что-то вроде ACSv2. Для этого требуется немного поработать, чтобы настроить проверяющую сторону, установить ADFS2 и т. Д. Однако это наиболее надежный и перспективный вариант. Это очень хороший вариант.
2. Используйте что-то вроде Windows Azure Connect. Это приведет к аутентификации Windows в облаке, присоединяя ваши запущенные экземпляры к локальному контроллеру домена. По сути, у вас есть что-то вроде VPN между вашими облачными экземплярами и локальным контроллером домена. Сегодня у этой модели есть некоторые оговорки (например, требуется установка агента на DC), но это будет с точки зрения «просто работает», проще всего. В долгосрочной перспективе это менее привлекательно, чем вариант № 1.

Подробнее о каждом из них можно узнать, ознакомившись с Учебным комплектом по платформе Windows Azure .

Я должен также добавить, что у вас нет возможности (по крайней мере, сегодня) использовать проверку подлинности Windows с SQL Azure. Там вы должны использовать аутентификацию SQL, поэтому то, о чем я здесь говорю, относится только к самому веб-сайту.

Answer 2

Я очень успешно использую Windows Identity Foundation с Azure AppFabric Access Control Service для аутентификации с использованием ADFS v2.

Помимо прямой аутентификации, она обеспечивает большую гибкость по сравнению с другими утверждениями, такими как роли (которые не должны основываться исключительно на членстве в группе AD).

По моему мнению, его самая большая сила в том, что не требуется канал связи между платформой Azure и вашей локальной AD. Все делается через браузер. С точки зрения безопасности это означает, что, хотя любой человек может получить доступ к вашему приложению, никто не может пройти к нему проверку подлинности, если они также не могут получить доступ к вашему серверу ADFS. Доступ к нему может быть ограничен только локальными клиентами или через VPN, что значительно уменьшает поверхность атаки.

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

Требуется только конфигурация, которая, хотя поначалу может показаться немного сложной, довольно проста, как только вы справитесь с ней. Вы настраиваете WIF для использования ACS в качестве поставщика удостоверений и создаете проверяющую сторону в ACS для приложения. Затем вы настраиваете ACS для использования ADFS в качестве поставщика удостоверений. Вы можете настроить WIF для непосредственного общения с ADFS, но может оказаться полезным дополнительный уровень абстракции при работе через ACS.

Как только вы выполнили настройку, используйте атрибут [Authorize] «просто работает».

Обратите внимание, что если вы используете вызовы Ajax в своих контроллерах, вам нужно принять некоторые меры предосторожности, так как вызовы Ajax не обрабатывают перенаправление федеративной аутентификации (или ADFS Shuffle, как мне нравится называть его), но ничто не является непреодолимым.

В целом, я очень впечатлен комбинацией WIF + ACS + ADFS для прозрачной встроенной аутентификации Windows.