Приложение ASP.NET для аутентификации в Active Directory или SQL с помощью аутентификации Windows или Forms Authentication - PullRequest
14 голосов
/ 20 ноября 2008

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

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

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

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

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

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


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

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

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

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

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

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

Тим

Ответы [ 3 ]

8 голосов
/ 22 ноября 2008

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

  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.

2 голосов
/ 23 ноября 2008

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

О смешанной аутентификации (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

2 голосов
/ 21 ноября 2008

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

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

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

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

...