Iis basic authentication отличие от windows autentification

Обновлено: 05.07.2024

Anonymous Authentication (Анонимная аутентификация ) позволяет пользователям входить в места общего доступа сайта без ввода имени пользователя или пароля. Когда пользователь подключается к общему веб-сайту, веб- сервер присваивает ему учетную запись Windows с именем IUSR_< имя_компьютера >, где < имя_компьютера > – имя сервера, на котором выполняется IIS .

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

При использовании анонимной аутентификации можно включить опцию Allow IIS To Control Password (Разрешить IIS управление паролем). Когда разрешено управление паролем, пользователь уже не выполняет локальный вход, а входит в систему с использованием сетевого входа. При сетевом входе существуют несколько проблем. Например, невозможность доступа к удаленному ресурсу на другом сервере (даже к серверу Windows 2000, являющемуся доверенным для делегирования). В этом случае следует отключить параметр Allow IIS To Control Password (Разрешить IIS управление паролем) в Internet Services Manager ( Диспетчер служб интернета). Следует обязательно переустановить пароль в User Manager ( Диспетчер пользователей), чтобы он соответствовал учетной записи.

Базовая аутентификация

Метод Basic Authentication ( Базовая аутентификация ) широко используется и является стандартным методом получения имени пользователя и пароля. При помощи опции Basic Authentication веб- браузер на компьютере клиента отображает диалоговое окно , в котором пользователь вводит ранее присвоенные ему имена и пароли. После подтверждения сервером IIS соответствия имени пользователя и пароля действительной учетной записи Windows будет установлено соединение.

Интегрированная аутентификация Windows

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

В отличие от базовой, интегрированная аутентификация изначально не запрашивает у пользователей имена и пароли. Она использует информацию о пользователе из текущего сеанса на компьютере клиента. Если аутентификация не смогла идентифицировать пользователя, браузер запросит у него имя и пароль учетной записи для обработки интегрированной аутентификацией.

Интегрированная аутентификация использует как протокол аутентификации Kerberos v5, так и свой собственный протокол типа "вопрос/ответ". Если на сервере установлен компонент Directory Services (Службы каталогов), используются оба эти протокола, в противном случае используется только протокол "вопрос/ответ".

К сожалению, метод интегрированной аутентификации поддерживается только Microsoft Internet Explorer. Следовательно, для среды интранет-сети, в которой компьютеры пользователей и веб- сервер находятся в одном домене, и администраторы могут обеспечить использование всеми пользователями браузера Micrsoft Internet Explorer, лучше всего подходит метод интегрированной аутентификации.

Ассоциирование клиентских сертификатов

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

Протокол аутентификации Kerberos уже затрагивался в этом блоге ранее. В этом посте пойдет речь про аутентификацию Kerberos, NTLM и Negotiate в веб-сервере IIS. Будет проверено на практике какой протокол аутентификации используется в том или ином случае. Для этого будет проведен несколько тестов в каждом из которых будет сделан вывод. Все выводы можно прочитать в конце поста.

Kerberos

Начнем с общего описания аутентификации Kerberos. Пользователь заходит на рабочую станцию (клиент) в домене. Для аутентификации клиент связывается с центром выдачи ключей (key distribution center, KDC), для Windows это контроллер домена. Контроллер домена проверяет, что логин и хеш пароля, введенные пользователем, совпадают с хранящимися в базе KDC. Если учетные данные корректны, центр выдает удостоверение (ticket-granting ticket, TGT), подписанное особенным доменным пользователем krbtgt. TGT используется для подтверждения, что пользователь прошел аутентификацию. После этого пользователь подключается к какому-либо ресурсу в домене, например, общей папке на файловом сервере. Клиент обращается к KDC, прилагая TGT, за выдачей удостоверения запрашиваемого сервиса (service ticket, TGS). Контроллер домена проверяет, что такой сервис совпадает с хранящимся в базе KDC и выдает клиенту TGS. После этого клиент обращается к файловому серверу, прилагая TGS. Файловый сервер видит, что TGS выдан контроллером домена и принимает подключение пользователя.

Процесс показан на рисунке

Подключившись доменным пользователем можно вывести как TGT:

При запросе доступа к сервису вводится понятие название службы (service principal name, SPN). SPN позволяет клиенту однозначно указать к какому сервису запрашивает доступ пользователь. Название уникально в рамках леса. Таким образом при обращении к сервису клиент включает TGS, для того, чтобы сервис увидел, что пользователь получил разрешение от KDC. Получив ответ от сервиса, пользователь удостоверяется, что сервис работает под учетной записью ассоциированной с SPN, потому что он смог расшифровать TGS.

Существуют два вида SPN: по имени компьютера и пользователя. Когда компьютер вводится в домен Active Directory, его учетной записи присваивается стандартный список SPN.

<Название сервиса>/<Имя Компьютера>:<Порт>

Подготовка к тестам.

Тесты.

Аутентификация в обычном режиме провайдеры Negotiate, NTLM.
Сервер включен с Windows аутентификацией с провайдерами Negotiate и NTLM
Клиент в домене
Клиент имеет полную связь с контроллером домена и веб сервером

Обычная проверка подлинности работает следующим образом.

Если для запроса требуется проверка подлинности, сервер возвращает 401 (несанкционированный). Ответ включает заголовок WWW-Authenticate, указывающий, что сервер поддерживает обычную проверку подлинности.
Клиент отправляет другой запрос с учетными данными клиента в заголовке авторизации. Учетные данные форматируются как строка "имя: пароль" в кодировке Base64. Учетные данные не шифруются.

Обычная проверка подлинности выполняется в контексте области. Сервер включает имя области в заголовке WWW-Authenticate. Учетные данные пользователя действительны в этой области. Точный диапазон области определяется сервером. Например, можно определить несколько областей для секционирования ресурсов.

Обычная проверка подлинности также уязвима для атак CSRF. После того как пользователь введет учетные данные, браузер автоматически отправляет их при последующих запросах к тому же домену в течение сеанса. Сюда входят запросы AJAX. См. раздел предотвращение атак с подделкой межсайтовых запросов (CSRF).

Обычная проверка подлинности в IIS

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

В проекте веб-API добавьте атрибут [Authorize] для всех действий контроллера, требующих проверки подлинности.

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

Обычная проверка подлинности с пользовательским членством

Как уже упоминалось, обычная проверка подлинности, встроенная в IIS, использует учетные данные Windows. Это означает, что необходимо создать учетные записи для пользователей на сервере размещения. Но для Интернет – учетные записи пользователей обычно хранятся во внешней базе данных.

Замените "Йоурассемблинаме" именем сборки (не включая расширение "DLL").

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

Давайте сначала рассмотрим возможности конфигурирования аутентификации с помощью форм из среды консоли управления IIS 8. Конфигурировать аутентификацию с помощью форм можно с использованием средства настройки аутентификации консоли управления IIS 8, как показано на рисунке ниже:

После разрешения аутентификации с помощью форм подобным образом также понадобится сконфигурировать необходимые правила авторизации. Наиболее важно добавить правило deny для анонимных пользователей с помощью средства конфигурирования авторизации в консоли управления IIS 8:

Обе конфигурационные настройки затрагивают файл web.config и веб-сервер берет эту информацию из web.config для определения собственного поведения, что видно в следующем фрагменте кода:

Вы заметите, что аутентификация с помощью форм, сконфигурированная IIS, как и следовало ожидать, находится в разделе <system.web>. Но по умолчанию (и если вы ранее не добавили этого вручную), никаких правил авторизации там не будет. Как упоминалось ранее, не все опции конфигурации по умолчанию помещаются непосредственно в файл web.config. Авторизация URL - одна из таких опций конфигурации.

Теперь просто откройте доступ к папке, где расположен PHP-файл (например, test.php), как к виртуальному каталогу или веб-приложению внутри IIS. После этого можно сконфигурировать аутентификацию с помощью форм и настройки авторизации, как было описано ранее.

Однако просто поместить содержимое PHP вместе с основанными на ASP.NET страницами входа и сконфигурировать аутентификацию с помощью форм еще недостаточно. Когда вы попытаетесь выполнить переход на страницу PHP, аутентификация с помощью форм пока работать не будет. В зависимости от аутентификации и правил авторизации, вы либо получите ответ "unauthorized" ("неавторизовано"), либо сможете переходить к странице PHP без приглашения на вход.

Конфигурация FormsAuthenticationModule важна. Флажок в неотмеченном состоянии задает preCondition="", которое по умолчанию установлено в managedHandler.

Читайте также: