Идентификация ASP.NET + Аутентификация Windows (режим Mix - Forms + Windows)

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

Проблема

Как создать веб-сайт ASP.NET MVC 5, который использует "Windows Auth" для пользователей Intranet и "Forms Auth" для пользователей Интернета? Мы хотели бы выполнить это с помощью ASP.NET Identity. Более того, мы не хотим использовать группы Active Directory для авторизации. Для пользователей интрасети мы хотим аутентифицировать их с помощью Active Directory, а затем вернуться к идентификатору ASP.NET для управления их ролями и другими данными профиля.

Хорошо, если мы не попросим конечного пользователя выбрать метод auth. Веб-приложение должно беспрепятственно регистрировать пользователей интрасети. Они даже не должны знать, что есть экран входа в систему. Аналогичным образом, пользователям Интернета не следует запрашивать учетные данные своего домена. Они должны сразу увидеть экран входа в систему.

Есть ли какой-либо рекомендуемый способ решения этого? Или вы можете прокомментировать, если какие-либо из следующих решений являются правильными?

http://world.episerver.com/blogs/Dan-Matthews/Dates/2014/8/Mixing-Forms-and-Windows-Authentication/

https://github.com/MohammadYounes/MVC5-MixedAuth

http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/

FYI Это статья 2004 года, возможно, не поможет сейчас: https://msdn.microsoft.com/en-us/library/ms972958.aspx

Ответ 1

Конфигурация IIS
Включить анонимную аутентификацию в IIS для всего сайта и проверку подлинности Windows для некоторой папки под корневым каталогом (например,/WindowsLogin). В этой папке укажите aspx файл (для проекта WebForms) или создайте ApiController (для проекта MVC).

Настройка сайта
На странице входа в систему введите кнопку "Войти с учетной записью Windows/ActiveDirectory" (так же, как это обычно бывает, добавить кнопки "Вход в Twitter", "Facebook", "Gmail" и т.д.). Когда пользователь нажимает эту кнопку, они будут перенаправлены на страницу или контроллер в папке /WindowsLogin, для которой требуется проверка подлинности Windows. Если сайт использует некоторые функции единого входа, найдите его на этой странице или контроллере, в другом случае просто сохраните сеанс для пользователей Windows. Если пользователь обратился к этой странице или контроллеру, они уже прошли проверку подлинности как пользователи Windows.

Ответ 2

Одним из возможных способов может быть создание двух сайтов в IIS, но с одной и той же целевой папкой, где расположены источники сайта. Первый сайт предназначен для внутренних пользователей с включенным режимом проверки подлинности Windows и привязкой к порту 80, а второй - для внешних пользователей с включенным анонимным режимом и привязкой к порту 8080. Затем в брандмауэре вам нужно будет настроить NAT, чтобы все запросы, поступающие из локальной сети или VPN, были перенаправлены на локальный сервер IIS на порт 80 и все запросы, поступающие из Интернета, будут перенаправлены на порт 8080 сервера IIS.

Ответ 3

Термин для этого - аутентификация в смешанном режиме. Я делал это несколько раз. Вам нужно только настроить свой основной сайт. Вот как я это сделал.

Сохраните свой основной сайт MVC как есть, но запустите его как анонимный или под Windows Auth.

Внутренний сайт

Создать сайт URL-адреса перенаправления: Установите этот сайт как окно Auth, чтобы вы могли вытащить идентификатор пользователя из Active Directory. Дайте вашим пользователям этот URL-адрес и/или сделайте ссылку, которую они нажимают на вашу интрасеть. Затем этот сайт вызывает ваш сайт MVC и передает учетные данные пользователя (идентификатор входа).

а. Это можно сделать либо зашифрованной строкой по URL-адресу, либо зашифрованным значением в файле cookie. Вы также можете зашифровать с указанием даты и времени истечения срока действия.

б. (Выступая из формы Auth) Создайте Билет проверки подлинности форм с этим идентификатором пользователя. Запустите любую другую логику входа. Готово.

Внешний сайт - никаких изменений не требуется.. Пусть пользователи входят в систему как есть.

Ответ 4

Вы хотите обрабатывать формы и аутентификацию AD с одного URL-адреса? Я использовал thinktecture (основанный на утверждениях auth) как основу для WIF и маршалинг различных форм аутентификации. Однако для обработки, если с одного URL я должен был обрабатывать некоторую логику при входе в систему, которая ассоциировала пользователя с AD или Forms. В более позднем проекте это было обработано при управлении пользователями, когда мы создали учетную запись пользователя (она была связана с AD форм Auth). Затем, когда пользователь вошел в систему, они предисловивали бы доменное имя AD как часть входа. Существует несколько способов реализовать это, это был только тот, который я использовал. Например, вместо того, чтобы требовать домен, просто используйте имя пользователя, затем проверьте флаги на основе AD или форм на имени пользователя, а затем выполните проверку подлинности.

ИЗМЕНИТЬ Просто обновление в повторном чтении вашего вопроса. Являются ли пользователи Интернета и пользователи интрасети одинаковыми? Если это так, вам нужно просто перейти на бланки на основе auth через панель и управлять пользователями в DB продукта независимо от AD. Если они совпадают, то они могут войти в систему, предварительно задав имя домена для имени пользователя. если вы хотите полагаться исключительно на AD.

Ответ 5

Я сделал доказательство концепции этого некоторое время назад, на моей предыдущей работе, поэтому детали туманны, и у меня нет никакого кода для ссылки...

Требования:

Единый URL для внутреннего (LAN) и внешнего (интернет) доступа
Два типа пользователей, пользователи домена и внешние (не AD) пользователи
Аутентификация Windows для пользователей домена как внутри, так и снаружи
Возможность ввода сведений о регистрации в домене при использовании iPads (без авторизации Windows)

Основная идея решения, с которым я столкнулся, заключалась в том, что мы использовали групповую политику Active Directory для добавления пользовательской строки в пользовательский агент заголовка запроса HTTP, содержимое не имеет значения, на самом деле мы использовали длинную случайную строку символов.

https://technet.microsoft.com/en-us/library/cc770379.aspx

Затем целевая страница для сайта проверяет это, и если найденный перенаправляется в виртуальный каталог, с окнами auth, который проверил свою учетную запись AD, заполнил токен аутентификации ASP.NET, а затем перенаправил их на свою домашнюю страницу.

Если пользовательский заголовок не существует, он просто отображает обычную регистрационную форму.

Единственное, что было, это добавить проверку электронной почты/пароля AD в обычную форму входа, чтобы, если пользователь домена обратился к сайту с устройства, отличного от Windows (iPad), они могли использовать свои обычные данные для входа.

Ответ 6

Почему бы вам не поставить код вашего сайта на сервер, скопировать его на два отдельных веб-сайта и просто обработать изменения в аутентификации, настроив web.config. (один был бы настроен с анонимным и один с проверкой подлинности Windows.)

Это не так просто, как другие методы, но относительно безболезненно. Есть два сайта, но контент (за исключением web.config) идентичен.