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

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

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

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

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

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

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

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

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

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

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

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

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

Тим

Ответы

Ответ 1

Так я справился с аналогичной ситуацией, основанной на этой информации:

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

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

Ответ 2

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

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

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

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

Ответ 3

Ну, можно использовать 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