Приложение ASP.NET для аутентификации в Active Directory или SQL с помощью аутентификации Windows или аутентификации с помощью форм

Я пишу приложение, для которого потребуется несколько форм аутентификации.

Приложение должно поддерживать аутентификацию в Active Directory, но иметь возможность вернуться к поставщику членства в SQL, если пользователь не находится в Active Directory. Мы можем справиться с ошибкой поставщика SQL в коде на основе предоставленного имени пользователя, потому что имя пользователя будет отличаться от формата имени пользователя Active Directory.

Это вообще возможно? Я имею в виду, могу ли я использовать членство и одновременно использовать как ActiveDirectoryMembershipProvider, так и SqlMembershipProvider, или мне придется использовать собственное?

Еще одна дополнительная сложность заключается в том, что я хотел бы автоматически аутентифицировать моих внутренних пользователей на основе аутентификации Windows обратно в AD, но использовать аутентификацию с помощью форм для пользователей, не входящих в нашу внутреннюю сеть, или пользователей, которые используют поставщик SQL.

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

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


Спасибо за ответ.

Причина, по которой я спросил изначально, заключалась в том, что около 7 лет назад мне удалось заставить этот конкретный senerio работать с использованием IIS для аутентификации и последующей передачи учетных данных в веб-приложение Lotus Domino Server. Если пользователь не был аутентифицирован через Windows Authentication / ISS, тогда Domino обработает аутентификацию. Это было то, что я хотел здесь сделать, но действительно не мог придумать, как заставить это работать в IIS.

Что касается остальной части вашего ответа, я думаю, вы идете по тому пути, по которому мне нужно идти. Я обдумал это и много вертел в голове. В любом случае приложение будет несколько отличаться на двух серверах, поскольку в любом случае будет ограничен доступ к данным на внешнем сервере. Тот факт, что уже так много будет отличаться, я могу просто рассматривать их как два приложения, тем самым устраняя необходимость использования двух типов аутентификации в одном приложении в любом случае.

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

В качестве дополнительной мысли - есть ли способ втянуть достаточно AD в базу данных SQL, чтобы позволить мне аутентифицировать пользователей в базе данных SQL с внешнего сервера, используя их учетные данные AD, без каких-либо проблем с безопасностью? Надеюсь, я четко печатаю то, о чем думаю ...

Еще раз спасибо!

Тим


person divtag    schedule 20.11.2008    source источник
comment
Так как этому вопросу и ответу почти 10 лет. Интересно, работает ли это решение сегодня с IIS 8 и Windows 7+?   -  person T L    schedule 13.04.2016


Ответы (3)


Вот как я справился с подобной ситуацией на основе эта информация:

  1. Настроил приложение для использования проверки подлинности с помощью форм.
  2. Установите LoginUrl на страницу WinLogin.aspx.
  3. В WinLogin.aspx используйте Request.ServerVariables ["LOGON_USER"], чтобы получить имя пользователя, затем вызовите FormsAuthentication.RedirectFromLoginPage (authorizedUserName, false), чтобы войти в систему. Я думаю, вы также можете вручную проверить Active Directory в этой точке.
  4. Создайте html-страницу, которая перенаправляет на страницу с именем Login.aspx.
  5. Login.aspx - это ваше стандартное имя пользователя / пароль для входа.
  6. В IIS включите интегрированную проверку подлинности и анонимность на всем сайте, но запретите анонимный доступ к WinLogin.aspx.
  7. В IIS установите ошибку 401 на страницу, созданную на шаге 3.

В основном происходит то, что когда неавторизованный пользователь попадает на сайт, он перенаправляется на WinLogin.aspx. Поскольку анонимность отключена, встроенная безопасность выполняет проверку. Если это пройдет, ваш пользовательский код в WinLogin может работать. В случае сбоя встроенной проверки безопасности возникает ошибка 401. Ваша настраиваемая страница 401 перенаправляется на Login.aspx, где пользователь может войти в систему, используя свое имя пользователя и пароль с помощью поставщика SQL.

person Greg    schedule 21.11.2008
comment
Я использовал точно такой же подход в нашем основном веб-продукте. Не скажу, что это идеальное решение, но самое близкое, что можно получить, не накатывая что-то совершенно новое. - person Torbjørn; 23.11.2008

Насколько мне известно, веб-приложения настроены на использование либо проверки подлинности Windows, либо проверки подлинности с помощью форм, но не обоих сразу. Поэтому я не верю, что можно автоматически аутентифицировать внутренних пользователей, требуя, чтобы другие вводили имя пользователя / пароль.

Вы можете пройти аутентификацию в Active Directory или хранилище пользователей SQL с помощью аутентификации с помощью форм, используя настраиваемый поставщик. Однако пользователям AD все равно потребуется вводить свое имя пользователя и пароль. Хотя я никогда не совмещал эти два метода, я использовал проверку подлинности с помощью форм для проверки подлинности в обоих источниках в то или иное время.

С учетом сказанного, я думаю, вы можете рассмотреть возможность уменьшения «гибкости» вашей системы. Если у вас есть внешний сервер и внутренний сервер, вы можете просто изменить конфигурацию поставщика для каждой копии приложения, чтобы использовать другой источник. Затем вы можете настроить внутреннюю проверку подлинности Windows (автоматическую), а внешнюю - проверку подлинности с помощью форм.

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

person DCNYAM    schedule 21.11.2008

Что ж, можно использовать ActiveDirectoryMembershipProvider и SqlMembershipProvider, но для этого необходимо создать страницу входа в систему с собственным кодом вместо элементов управления входом.

Что касается смешанной аутентификации (Windows и Forms), насколько мне известно, только IIS 7 делает ее простой и понятной. См. Этот пост для подробностей,

http://mvolo.com/blogs/serverside/archive/2008/02/11/IIS-7.0-Two_2D00_Level-Authentication-with-Forms-Authentication-and-Windows-Authentication.aspx

person Lex Li    schedule 23.11.2008